General info
Page properties | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Goals
Background and strategic fit
Table of Contents |
---|
Status colour Yellow title TBD
Background and strategic fit
Status | ||||
---|---|---|---|---|
|
Sources
- Iroha 2 white-paper: https://github.com/hyperledger/iroha/blob/iroha2-wp/iroha_2_whitepaper.md
- Sora 2 project requirements
- Bakong project requirements
- Zilya Yagafarova
- Andrey Marin
- KYC project requirements
- Other internal project requirements
Assumptions
Status colour Yellow title TBD
Table of contents
Table of Contents |
---|
Changes history
Expand | ||
---|---|---|
| ||
|
Requirements
Actors
Actor name | Role definition |
---|---|
The Iroha peer | One of active peers of the Iroha network, accessible by network for the current user. |
The administrator | The user of the Iroha network with the extended rights towards manipulating the peers and network configuration |
The user | Generic user of the Iroha network with common list of permissions (required permissions are always mentioned in the use case Preconditions) |
Functional requirements
For describing functional requirements, we should follow the default use case template by example:
Use case title | [FR0000] Example use-case; ID should be unique | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Status |
| ||||||||||||||||||||||||
Source | Source (or list of sources) of the function: project name / stakeholder name / document title (e.g., whitepaper) / etc. | ||||||||||||||||||||||||
Preconditions |
| ||||||||||||||||||||||||
Use case flow |
| ||||||||||||||||||||||||
Post-conditions |
| ||||||||||||||||||||||||
Alternative flow |
| ||||||||||||||||||||||||
Exception flow |
|
Info | ||
---|---|---|
| ||
Assuming, that each section would not have more than 100 use cases, the use case ID should be formed using that template: FR<section_number> <use_case_number_in_section_starting_from_zero> For example, for second use case in section 02 it should be: FR02 01 |
00. Iroha network operations
Info |
---|
❇️❇️❇️ In this section all use cases related to generic operations with Iroha network and peers will be described |
Use case title | [FR0001] Starting |
---|
Change History |
---|
Assumptions
Requirements
Functional requirements
For the functional requirements, we should follow the default use case template by example:
[FR0000] Example use-case; ID should be unique
Status | ||||
---|---|---|---|---|
|
Status | ||||
---|---|---|---|---|
|
Status | ||||
---|---|---|---|---|
|
- List of preconditions which must be satisfied before the use case can be applied
- Each precondition should be defined as the point in the list
Use case flow
- The enumerated list of actions, which describes the interaction between actors step by step
- Each step should involve a single actor as an object of the action
- Each step can involve one or more actors as a subject of the action
- Each use case can involve other use cases as dependencies by include or extend relationships
- One or more results of successfully finished use case
- List of alternative flows that can happen with the use case.
- Each entry should have the link to the step of the main use case flow when the alternative can occur
- If needed, each entry can contain sub-entries
- Each entry should describe the consequences of the alternative flow
- List of exceptions that can happen during the use case flow, which can prevent it to be successfully finished
- Each entry should have the link to the step of the main use case flow when the exception can occur
- If needed, each entry can contain sub-entries
- Each entry should describe the consequences of the exception
Iroha network operations
[FR0001] Starting the Iroha network
Status | ||||
---|---|---|---|---|
|
- The administrator has configured environment for running Iroha executables
- The administrator has prepared the genesis block
Use case flow
- The administrator launches the command to run Iroha peer and providing the path to the genesis block description
- The Iroha peer read and validates the genesis block configuration
- The Iroha peer starts the Iroha network according to the configuration in the genesis block
- The Iroha peer provides "successfully started" report to the administrator
- The Iroha network is running
- The administrator has access to the root account of the network
- At step 2, in case of the invalid genesis block, the Iroha peer shows corresponding error messages to the administrator and halts the network creation process
[FR0002] Adding peer to the Iroha network
Status | ||||
---|---|---|---|---|
|
Use case flow
[FR0003] Removing peer from the Iroha network
Status | ||||
---|---|---|---|---|
|
Use case flow
[FR0004] Configuring initial state of the Iroha network
Status | ||||
---|---|---|---|---|
|
Use case flow
Making changes in Iroha network data by Iroha special instructions
Use case title | [FR0100] Sending the transaction to the Iroha network | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Postconditions |
| ||||||
Alternative flow |
| ||||||
Exception flow |
| ||||||
Use case title | [FR0101] Creation of the user in the Iroha network | ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0002] Adding peer to the Iroha network | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0003] Removing peer from the Iroha network | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Status |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Postconditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flowOn step 3, if the account with the provided name or public key already exists in the network, the Iroha peer will return "already exists" error status; user case flow will stop. | N/A |
Use case title | [FR0102FR0004] Configuringpermissions for the account ininitial state of the Iroha network | |||||||||
---|---|---|---|---|---|---|---|---|---|---|
Status |
| |||||||||
Source | ||||||||||
Preconditions |
| |||||||||
Use case flow Postconditions |
| Use case
| ||||||||
Post-conditions |
| |||||||||
Alternative flow | N/A | |||||||||
Exception flow | N/A |
Use case title | [FR0005] Changing configuration of working[FR0102] Granting permissions for the account in theIroha network | ||||||||
---|---|---|---|---|---|---|---|---|---|
Status |
| ||||||||
Source |
| ||||||||
Preconditions |
| ||||||||
Use case flow |
| ||||||||
Post-conditions |
| Postconditions |
| ||||||
Alternative flow | N/A | ||||||||
Exception flow | N/A |
Use case title | [FR0104] Sending complex instruction using ISI DSLFR0006] Changing configuration of the particular peer | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
Status |
| Preconditions | Use case flow | Postconditions | Alternative flow | Exception flow | ||||||
Use case title | [FR0105] Sending instruction and subscribing to the status of finalization | |||||||||||
Status |
| |||||||||||
Source |
| |||||||||||
Preconditions |
| Preconditions |
| |||||||||
Use case flow |
| |||||||||||
Postconditions |
| Alternative flow | ||||||||||
Exception flow |
| |||||||||||
| ||||||||||||
Post-conditions |
| |||||||||||
Alternative flow | N/A | |||||||||||
Exception flow |
|
01. Making changes in Iroha network data by Iroha special instructions
Info |
---|
❇️❇️❇️ In this section all use cases related to changing data in the Iroha network will be described |
Use case title | [FR0100] Sending the transaction to | Use case title | [FR0106] Creation of the multi-signature account in the Iroha network | ||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source | Preconditions | Use case flow | Postconditions | Alternative flow | Exception flow | ||
Use case title | [FR0107] Changing quorum for the multi-signature account | ||||||
Status |
| Preconditions | Use case flow | Postconditions | Alternative flow | Exception flow | |
Use case title | [FR0108] Changing list of signatories for the multi-signature account | ||||||
Status |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Postconditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
| ||||||
| |||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow |
|
Use case title | [FR0101] Creation of the account in the Iroha network | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0102] Configuring permissions for the account in the Iroha network | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0102] Granting permissions for the account in the Iroha network | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0104] Sending complex instruction using ISI DSL | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0105] Sending instruction and subscribing to the status of finalization | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow |
|
Use case title | [FR0106] Creation of the multi-signature account in the Iroha network | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0107] Changing quorum for the multi-signature account | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0108] Changing list of signatories for the multi-signature account | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0109] Signing multi-signature transaction | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow |
|
Use case title | [FR0110] Changing the conditions for the multi-signature account | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow | N/A |
Use case title | [FR0111] Assigning weights to the signatories of the multi-signature account | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow | N/A |
Use case title | [FR0112] Associating and changing arbitrary data payload with the account | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow |
|
Use case title | [FR0113] Sending instruction with the payload | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow |
|
Use case title | [FR0114] Sending non-fungible assets | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow | N/A |
02. Acquiring data from the Iroha network by queries
Info |
---|
❇️❇️❇️ In this section all use cases related to retrieving data from the Iroha network will be described |
Use case title | [FR0200] Acquiring data from the Iroha network by query | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0201] Acquiring the information about the selected account | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source | |||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow | N/A |
Use case title | [FR0202] Acquiring of the current permissions for the selected account | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source | |||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow | N/A |
Use case title | [FR0203] Acquiring a list of pending multi-signature transactions | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow |
|
Use case title | [FR0204] Acquiring a list of current conditions for a multi-signature account | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0205] Acquiring a block by its number | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0206] Acquiring blocks subscription | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source | |||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow | N/A |
Use case title | [FR0207] Acquiring pending transactions subscription | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow | N/A |
Use case title | [FR0208] Subscribing on the query results | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0209] Validate result of the query | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0210] Query old Iroha state (e.g., query balance month ago) | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow | <<extends>> FR0200, substitutes step 4:
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0211] Querying list of accounts with the predefined filter | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow |
|
Use case title | [FR0212] Retrieving the list of keys of data payload, associated with the target account | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0213] Retrieving the value of data payload by the key, associated with the target account | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0214] Querying list of transactions with predefined filter | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow |
|
Use case title | [FR0215] Subscription on incoming transactions | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow | N/A |
Use case title | [FR0216] Requesting list of non-fungible assets in account | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow | N/A |
Use case title | [FR0217] Requesting data from the block storage by using special request language | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow | N/A |
03. Setting up and executing triggers
Info |
---|
❇️❇️❇️ In this section all use cases related to triggers in the Iroha network will be described |
Use case title | [FR0300] Setting up a trigger in the Iroha network | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0301] Manually firing the trigger | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0302] Removing the trigger | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
09. High-level use cases
Info |
---|
❇️❇️❇️ In this section all high-level use cases will be described |
Use case title | [FR0900] Configuration of fees for transfers inside the current Iroha network | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0901] Sending transaction with fees | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow |
|
Use case title | [FR0902] Delegation of account control with time limit | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow | N/A |
Use case title | [FR0903] Inheritance of the account after period of inactivity | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow | N/A |
Use case title | [FR0904] Distribution of fees according to business rules of the project | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow | N/A |
Use case title | [FR0905] Managing the list of signatories | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow |
|
Use case title | [FR0906] Making decisions by parliament voting | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow | N/A |
Use case title | [FR0907] Management of non-fungible assets | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow | N/A |
Use case title | [FR0908] Nominating validator by staking assets | ||||||||
---|---|---|---|---|---|---|---|---|---|
Status |
| ||||||||
Source |
| ||||||||
Preconditions |
| ||||||||
Use case flow |
TBD, need requirements details from the Sora project Pavel Golovkin | ||||||||
Post-conditions |
| ||||||||
Alternative flow | TBD | ||||||||
Exception flow | TBD |
Use case title | [FR0909] Slashing of stakes for inappropriate behaviour of validator | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow | N/A |
Use case title | [FR0910] Obtaining a list of trusted peers | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow | N/A |
Use case title | [FR0911] Configuring a minimum limit of assets needed to create an account | ||||||||
---|---|---|---|---|---|---|---|---|---|
Status |
| ||||||||
Source |
| ||||||||
Preconditions |
| ||||||||
Use case flow |
| ||||||||
Post-conditions |
| ||||||||
Alternative flow |
| ||||||||
Exception flow | N/A |
Use case title | [FR0912] Creation of account with configured minimum amount of tokens | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow | N/A |
Non-functional requirements
Non-functional requirements (also named as "Quality attributes") describes the behavior of the system not directly related to the functions of the system, but answers the question "How system works?". The template for all quality attributes should follow the example (link to source):
Quality attribute name | [NFR0000] Example quality attribute; ID should be unique | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Status |
| ||||||||||||||||||
Source | Source (or list of sources) of the quality characteristic: project name / stakeholder name / document title (e.g., whitepaper) / etc. | ||||||||||||||||||
Source of stimulus | Entity, which initiates the stimulus, may be one of system users, another software system, etc. | ||||||||||||||||||
Stimulus | Condition, which requires the response from the system | ||||||||||||||||||
Environment | Definition of specific conditions when stimulus occurs, and which is important for the result of response. Typical environment values are: normal operation, overload of requests, starting up the system, etc. | ||||||||||||||||||
Artifact | Particular subject of stimulus, may be the whole system, some subset of parts or single part of the system. | ||||||||||||||||||
Response | Result of reaction of the system to the stimulus | ||||||||||||||||||
Response measure | Measurable characteristic of the response, which can be checked for understanding how the system satisfies the requirements |
Info | ||
---|---|---|
| ||
The systematization of quality attributes should follow the approach in standard ISO/IEC 25010:2011 |
00. Performance
Quality attribute name | [NFR0001] Transaction processing speed | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Source of stimulus | Client applications of the Iroha network | ||||||
Stimulus | Client application sends transactions to the Iroha network | ||||||
Environment | Normal operation of the system | ||||||
Artifact | Whole Iroha network | ||||||
Response | The Iroha peer accepts the transactions and adds them to the blockchain | ||||||
Response measure | The Iroha network should process at least 20.000 transactions per second For Sora 2 project:
|
Quality attribute name | [NFR0001] Delay of block creation | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Source of stimulus | Client applications of the Iroha network | ||||||
Stimulus | Client application sends transactions to the Iroha network | ||||||
Environment | Normal operation of the system | ||||||
Artifact | Whole Iroha network | ||||||
Response | The Iroha peer accepts the transactions and to the block | ||||||
Response measure | The Iroha network should create new block each 2-3 seconds |
Quality attribute name | [NFR0002] Delay of restarting the peer | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Status |
| ||||||||||||
Source |
| ||||||||||||
Source of stimulus | Administrator of the host with running Iroha peer | ||||||||||||
Stimulus | Administrator restarts the Iroha peer (manually or automatically by external script) | ||||||||||||
Environment | Normal operation of the system; the block storage is not corrupted. | ||||||||||||
Artifact | Current Iroha peer | ||||||||||||
Response | The Iroha peer restarts and restores the WSV in the storage using one of two modes:
| ||||||||||||
Response measure | The Iroha peer successfully restarted, with following metrics:
|
Quality attribute name | [NFR0003] Performing as expected on predefined hardware | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Source of stimulus | The Validator | ||||||
Stimulus | Attempt to run Iroha peer on the validators' machines | ||||||
Environment | Normal operation of the system; the host machine is satisfying minimal requirements from the Iroha documentation | ||||||
Artifact | The Iroha peer | ||||||
Response | The Iroha peer start the execution | ||||||
Response measure | The Iroha peer should start working properly, without functional issue and satisfying all non-functional requirements to performance |
Quality attribute name | [NFR0004] Providing enough capacity for user's accounts | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source | |||||||
Source of stimulus | Users of the network | ||||||
Stimulus | Creation of personal accounts in the network | ||||||
Environment | Normal operation of the system | ||||||
Artifact | The Iroha network and block storage | ||||||
Response | The Iroha network allows to register as much users as needed in the target system; block storage can successfully keep all the relevant data | ||||||
Response measure | The Iroha network can successfully handle at least 20 million of users' accounts |
01. Portability
Quality attribute name | [NFR0100] Easy integration from client side applications | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Source of stimulus | Client applications of the Iroha network | ||||||
Stimulus | Client application needs interaction with the Iroha network | ||||||
Environment | Development of the client-side applications | ||||||
Artifact | Client-side applications | ||||||
Response | There are client libraries with efficient SDK available. | ||||||
Response measure | Client libraries available for following programming languages and platforms:
|
Quality attribute name | [NFR0101] Horizontal scalability of the network size | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Source of stimulus | User of the Iroha network with permissions to change list of validating peers | ||||||
Stimulus | Sending operation of adding more validating peers to perform horizontal scalability of the network | ||||||
Environment | Normal system functioning | ||||||
Artifact | Whole Iroha network | ||||||
Response | The size of Iroha network was increased by new validating peers, provided in the request | ||||||
Response measure | The size of Iroha network should be increased at least up to 22 validating peers
|
Quality attribute name | [NFR0102] Adaptability for different environments and projects | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Source of stimulus | The operations engineer with permissions to configure the network | ||||||
Stimulus | Changing system configuration parameters | ||||||
Environment | On system start | ||||||
Artifact | Whole Iroha network | ||||||
Response | The system configuration changes according to the request from the user | ||||||
Response measure | The system configuration should provide possibility to tune up following parameters:
| ||||||
Use case title | [FR0109] Signing multi-signature transaction | ||||||
Status |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Postconditions |
| ||||||
Alternative flow |
| ||||||
Exception flow |
| ||||||
Use case title | [FR0110] Changing the conditions for the multi-signature account | ||||||
Status |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Postconditions |
| Alternative flow | Exception flow |
Acquiring data from the Iroha network by queries
- we need to define metrics there |
Quality attribute name | [NFR0102] Flexibility of integrated DSL for complex operations and triggers | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Source of stimulus | The system engineer of the external project | ||||||
Stimulus | Need to describe the logic of core operations within the Iroha network | ||||||
Environment | On design and implementation of the project over Iroha | ||||||
Artifact | DSL of the Iroha | ||||||
Response | The DSL allows to describe all required manipulations with the internal entities in the Iroha network | ||||||
Response measure | The DSL provides system of data-manipulation rules, so it can be used to manipulate all entities in the Iroha network (available by permissions) and to manage control flow by using functions, conditions, loops, etc. |
Quality attribute name | [NFR0103] Reusability of the Iroha interface during integration with external systems | Use case title | [FR0200] Acquiring data from the Iroha network by query | |||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
Status |
| Preconditions | Use case flow | Postconditions | Alternative flow | Exception flow | ||||||
Use case title | [FR0201] Acquiring the information about the selected account | |||||||||||
Status |
| |||||||||||
Source |
| |||||||||||
Source of stimulus | The external software system | |||||||||||
Stimulus | Performing operations with the Iroha network using standardized interfaces | |||||||||||
Environment | Normally functioning Iroha network | |||||||||||
Artifact | API of the Iroha network | |||||||||||
Response | The Iroha network should provide the convenient interface for interaction from the other systems. | |||||||||||
Response measure | The interface should be widely used and correspond to the industrial standard. Good candidate for such interface is HTTP(S) for single requests and WebSockets for continuous communication. |
Quality attribute name | [NFR0103] Configurability of permission | Preconditions | Use case flow | Postconditions | Alternative flow | Exception flow | Use case title | [FR0202] Acquiring of the current permissions for the selected account | ||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
Status |
| Preconditions | Use case flow | Postconditions | Alternative flow | Exception flow | ||||||
Use case title | [FR0203] Acquiring a list of pending multi-signature instructions | |||||||||||
Status |
| |||||||||||
Preconditions |
| |||||||||||
Source |
| |||||||||||
Source of stimulus | The external client of the Iroha network | |||||||||||
Stimulus | Changing permissions for some entities in the Iroha network:
| |||||||||||
Environment | Normally running Iroha network | |||||||||||
Artifact | Permission of entities in the Iroha network | |||||||||||
Response | The Iroha provides flexibility in the permissions configuration, so the user may configure it for each mentioned entity | |||||||||||
Response measure | Use case flow |
– define the measure in concrete details |
02. Security
Quality attribute name | [NFR0200] Non-repudiation of data between peer and client | ||||||
---|---|---|---|---|---|---|---|
Postconditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
| ||||||
Use case title | [FR0204] Acquiring a list of current conditions for a multi-signature account | ||||||
Status |
| ||||||
Source | |||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Postconditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
| ||||||
| |||||||
Source of stimulus | Client-side applications of the Iroha network | ||||||
Stimulus | Client-side application sends the request to the Iroha peer and gets the response | ||||||
Environment | Normal functioning system | ||||||
Artifact | Connection between client-side application and Iroha peer. | ||||||
Response | Client-side application checks the authenticity of the response | ||||||
Response measure | Client-side application can be sure that data received from the Iroha peer is not changed by the man-in-the-middle attack |
03. Usability
Quality attribute name | [NFR0300] Convenient documentation for different user types | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Source of stimulus | Different types of users of the Iroha
| ||||||
Stimulus | Need to get all related information about the Iroha | ||||||
Environment | In process of research and development of digital solutions | ||||||
Artifact | Documentation of the Iroha | ||||||
Response | Documentation can provide excessive information about all entities and fundamentals of Iroha | ||||||
Response measure | Each user of all different types can explore the documentation and get answer on required question within acceptable amount of time. |
04. Reliability
Quality attribute name | [NFR0400] Available proofs of efficiency of technical decisions and implementation | ||||||
---|---|---|---|---|---|---|---|
Use case title | [FR0205] Acquiring a block by its number | ||||||
Status |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Postconditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
| ||||||
Use case title | [FR0206] Acquiring blocks subscription (can be extended with a start block number index) | ||||||
Status |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Postconditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow | N/A | ||||||
Source | |||||||
Source of stimulus | Analysts of blockchain solutions | ||||||
Stimulus | Request to get excessive information about proofs for efficiency of technical decisions and implementation design | ||||||
Environment | In process of analyzing effectiveness and soundness of the Iroha | ||||||
Artifact | Documentation of the Iroha | ||||||
Response | Documentation provides information about experiments, benchmarks and researches made for making all major decisions and designing structure of the software solution for the Iroha | ||||||
Response measure | All provided data is clear for understanding of specialists and can be easily verified by repeating the same experiments or benchmarks mentioned as proofs |
Quality attribute name | [NFR0401] Safety of the integrated DSL language for triggers | Use case title | [FR0207] Acquiring pending transactions subscription | ||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Postconditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow | N/A |
Source |
| ||||||
Source of stimulus | Code in triggers or smart contracts, defined on the integrated DSL language | ||||||
Stimulus | Execution of the smart contract or firing of the trigger | ||||||
Environment | Running Iroha network in normal mode | ||||||
Artifact | Stability of all peers in the network | ||||||
Response | The DSL should be designed to prevent the possibility of crashing whole network or it's parts by executing the code | ||||||
Response measure | The DSL should prevent any kind of attacks, including:
|
Questions
Below is a list of questions to be addressed as a result of this requirements document:
Question | Outcome |
---|---|