General info
Page properties | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Goals
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
- Anton Khvorov
- Zilya Yagafarova
- Pavel Golovkin
- Bogdan Mingela
- Ruslan Rezin
- 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 preconditionsPreconditions) |
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 |
| Postconditions |
| ||||||||||||||||||||||
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 the Iroha network | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
PostconditionsPost-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0002] Adding peer to the Iroha network | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
PostconditionsPost-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0003] Removing peer from the Iroha network | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
PostconditionsPost-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow | N/A |
Use case title | [FR0004] Configuring initial state of the Iroha network | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source | |||||||
Preconditions |
| ||||||
Use case flow Postconditions |
| ||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow | N/A |
Use case title | [FR0005] Changing configuration of working Iroha network | ||||||||
---|---|---|---|---|---|---|---|---|---|
Status |
| ||||||||
Source |
| ||||||||
Preconditions |
| ||||||||
Use case flow |
| ||||||||
PostconditionsPost-conditions |
| ||||||||
Alternative flow | N/A | ||||||||
Exception flow | N/A |
Use case title | [FR0006] Changing configuration of the particular peer | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
PreconditionsPreconditions |
| ||||||
Use case flow |
| ||||||
PostconditionsPost-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 the Iroha network | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
PostconditionsPost-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow |
|
Use case title | [FR0101] Creation of the account in the Iroha network | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
PostconditionsPost-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 |
| ||||||
PostconditionsPost-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 |
| ||||||
PostconditionsPost-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0104] Sending complex instruction using ISI DSL | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
PostconditionsPost-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 |
| ||||||
PostconditionsPost-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow |
|
Use case title | [FR0106] Creation of the multi-signature account in the Iroha network | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
PreconditionsPreconditions |
| ||||||
Use case flow |
| ||||||
PostconditionsPost-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0107] Changing quorum for the multi-signature account | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
PostconditionsPost-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 |
| ||||||
PostconditionsPost-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0109] Signing multi-signature transaction | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
PostconditionsPost-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow |
|
Use case title | [FR0110] Changing the conditions for the multi-signature account | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
PostconditionsPost-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 |
| ||||||
PostconditionsPost-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 |
| ||||||
PostconditionsPost-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow |
|
Use case title | [FR0113] Sending instruction with the payload | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
PostconditionsPost-conditions |
| ||||||
Alternative flow | N/A | Exception flow |
|
02. Acquiring data from the Iroha network by queries
❇️❇️❇️
In this section all use cases related to retrieving data from the Iroha network will be described
| |
Exception flow |
|
Use case title | [FR0200] Acquiring data from the Iroha network by queryFR0114] 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 | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Postconditions |
| |||||||||||||
Alternative flow | N/A | |||||||||||||
Exception flow |
| |||||||||||||
Use case title | [FR0201] Acquiring the information about the selected account | |||||||||||||
Status |
| |||||||||||||
Source | Preconditions | Use case flow | Postconditions | Alternative flow | Exception flow | |||||||||
Use case title | [FR0202] Acquiring of the current permissions for the selected account | |||||||||||||
| ||||||||||||||
Preconditions |
| |||||||||||||
Use case flow | Status
|
| discuss | Source | Preconditions | Use case flow |
| |||||||
Post-conditions |
| |||||||||||||
Alternative flow | N/A | |||||||||||||
Exception flow |
|
Use case title | [FR0203FR0201] Acquiringa list of pending multi-signature instructionsthe information about the selected account | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source | |||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| Postconditions |
| ||||
Alternative flow | N/A | ||||||
Exception flow |
| N/A |
Use Use case title | [FR0204FR0202] Acquiringa listof the currentconditions for a multi-signaturepermissions for the selected account | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source | |||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
PostconditionsPost-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
| N/A |
Use case title | [FR0203] Acquiring a list of pending multi-signature transactions | Use case title | [FR0205] Acquiring a block by its number | ||||||
---|---|---|---|---|---|---|---|---|---|
Status |
| ||||||||
Source |
| ||||||||
Preconditions |
| ||||||||
Use case flow | Status
| ||||||||
Postconditions |
| ||||||||
Alternative flow | N/A | ||||||||
Exception flow |
| ||||||||
Use case title | [FR0206] Acquiring blocks subscription | ||||||||
|
| discuss
| (can be extended with a start block number index)|||||||
Source | |||||||||
Preconditions |
| ||||||||
Use case flow |
| ||||||||
Postconditions |
| ||||||||
Alternative flow | N/A | ||||||||
Exception flow | N/A | ||||||||
| |||||||||
Post-conditions |
| ||||||||
Alternative flow |
| ||||||||
Exception flow |
|
Use case title | [FR0204] Acquiring a list of current conditions for a multi-signature account | Use case title | [FR0207] Acquiring pending transactions subscription | ||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| Postconditions |
| ||||
Alternative flow | N/A | ||||||
Exception flow | N/A |
|
Use case title | [FR0205] Acquiring a block by its number | Use case title | [FR0208] Subscribing on the query results | ||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Post-conditions |
| Postconditions |
| ||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0206] Acquiring blocks subscription | |||||||||
---|---|---|---|---|---|---|---|---|---|---|
Status |
| TBD |
| |||||||
Source | ||||||||||
Preconditions |
| |||||||||
Use case flow |
| |||||||||
Post-conditions |
| |||||||||
Alternative flow | N/A | |||||||||
Exception flow | N/A |
Use case title | [FR0207] Acquiring pending transactions subscription | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Use case title | [FR0209] Validate result of the query | ||||||
Status |
| ||||||
Source | |||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Postconditions |
| ||||||
| |||||||
Post-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
| N/A |
Use case title | [FR0208] Subscribing on the query results | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
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:
| ||||||
| |||||||
Use case flow |
| ||||||
Post-conditions |
| Postconditions |
| ||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [FR0211FR0209]Querying listValidate result ofaccounts withthepredefined filterquery | ||||||||
---|---|---|---|---|---|---|---|---|---|
Status |
| ||||||||
Source |
| Source |
| ||||||
Preconditions |
| ||||||||
Use case flow |
| ||||||||
Post-conditions |
| ||||||||
Alternative flow | N/A | Alternative flow | On step 1, the user can include the query to the DSL sequence as a part of the complex instruction | ||||||
Exception flow |
|
Use case title | [FR0212] Retrieving the list of keys of data payload, associated with the target accountFR0210] Query old Iroha state (e.g., query balance month ago) | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
| |||||||
Use case flow | <<extends>> FR0200, substitutes step 4:
| ||||||
Post-conditions |
| Postconditions |
| ||||
Alternative flow | N/A | ||||||
Exception flow |
|
Use case title | [ |
---|
FR0211] Querying list of accounts with the predefined filter | |||||||
---|---|---|---|---|---|---|---|
Status |
|
- probably optional for MVP, if there will be another way for gathering data for the award calculation for liquidity providers in DEX solution | |
Source |
|
Preconditions |
|
| |
Use case flow |
|
|
|
|
Post-conditions |
|
| |
Alternative flow |
|
Exception flow |
|
|
|
|
|
Use case title | [FR0214FR0212]QueryingRetrieving the list oftransactions with predefined filterkeys of data payload, associated with the target account | ||||||||
---|---|---|---|---|---|---|---|---|---|
Status |
| ||||||||
Source |
| ||||||||
Preconditions |
| ||||||||
Use case flow |
| ||||||||
Post-conditionsPostconditions |
| ||||||||
Alternative flow | N/A | ||||||||
Exception Alternative flow |
| Exception flow |
| ||||||
Use case title | [FR0215] Subscription on incoming transactions | ||||||||
Use case title | [FR0213] Retrieving the value of data payload by the key, associated with the target account | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
|
| |
Preconditions |
|
|
| |
Use case flow |
|
|
|
|
|
|
|
|
|
- The user has all incoming transactions during the period when the subscription was active
- On step 1, the user can configure list of accounts, which should be used as filter for the query
N/A
03. Setting up and executing triggers
❇️❇️❇️
| |
Post-conditions |
|
Alternative flow | N/A |
Exception flow |
|
Use case title | [FR0300] Setting up a trigger in the Iroha networkFR0214] Querying list of transactions with predefined filter | ||||||||
---|---|---|---|---|---|---|---|---|---|
Status |
| ||||||||
Source |
| ||||||||
- probably optional for MVP, if there will be another way for gathering data for the getting list of all transactions | |||||||||
Source |
| ||||||||
Preconditions |
| ||||||||
Use case flow |
| ||||||||
Postconditions |
| ||||||||
Alternative flow | N/A | ||||||||
Post-conditions |
| ||||||||
Alternative flow |
| ||||||||
Exception flow |
| Exception flow | On step 4
|
Use case title | [FR0301] Manually firing the triggerFR0215] Subscription on incoming transactions | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Postconditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flow |
| ||||||
| |||||||
Post-conditions |
| ||||||
Alternative flow |
| ||||||
Exception flow | N/A |
Use case title | [FR0216] Requesting list of non-fungible assets in account | ||||||
---|---|---|---|---|---|---|---|
Status | |||||||
Use case title | [FR0302] Removing the trigger | ||||||
Status |
| ||||||
Source |
|
| |||||
Preconditions | Preconditions | The trigger was created by the FR0300 |
| ||||
Use case flow |
| ||||||
Postconditions |
| ||||||
Alternative flow | N/A | ||||||
| |||||||
Post-conditions |
| ||||||
Alternative Exception flow |
|
09. High-level use cases
Info |
---|
❇️❇️❇️ In this section all high-level use cases will be described |
| |
Exception flow | N/A |
Use case title | [FR0217] Requesting data from the block storage by using special request language | Use case title | [FR0900] Configuration of fees for transfers inside the current Iroha network | ||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
PostconditionsPost-conditions |
| ||||||
Alternative flow | N/A | ||||||
Exception flowOn step 3, if the user does not have enough permissions, the Iroha peer will return "not enough permissions" error status; use case flow stops | 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 | [FR0901] Sending transaction with feesFR0300] Setting up a trigger in the Iroha network | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
Source |
| ||||||
Preconditions |
| ||||||
Use case flow |
| ||||||
Postconditions |
| ||||||
Alternative flow |
| ||||||
Exception flow |
| ||||||
Use case title | [FR0902] Delegation of account control with time limit | ||||||
Status |
| ||||||
Source |
| ||||||
Preconditions |
| Use case flow | |||||
Postconditions |
| Alternative flow | Exception 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 | ||||||||
---|---|---|---|---|---|---|---|---|---|
Use case title | [FR0903] Inheritance of the account after period of inactivity | ||||||||
Status |
| ||||||||
Source |
| ||||||||
Preconditions |
| ||||||||
Use case flow |
| ||||||||
Postconditions |
| ||||||||
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 |
| ||||||||
Postconditions |
| ||||||||
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):
| |
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:
|
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 | ||||||
---|---|---|---|---|---|---|---|
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 | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
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 | |||||||
Quality attribute name | [NFR0000] Example quality attribute; ID should be unique | ||||||
|
02. Security
Quality attribute name | [NFR0200] Non-repudiation of data between peer and client | |||
---|---|---|---|---|
Status | discuss | |||
Status | ||||
colour | Green | title | decided
| |
SourceSource (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 |
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 | [NFR0001] Transaction processing speedNFR0300] Convenient documentation for different user types | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
SourceIroha 2 white-paper |
| ||||||
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|||||
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 | [NFR0001] Delay of block creationNFR0400] Available proofs of efficiency of technical decisions and implementation | ||||||
---|---|---|---|---|---|---|---|
Status |
| ||||||
SourceIroha 2 white-paper | |||||||
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 | ||||||
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 | Response measure | The Iroha network should create new block each 2-3 seconds |
Quality attribute name | [NFR0002NFR0401]DelaySafety ofrestartingthepeerintegrated DSL language for triggers | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Status |
| ||||||||||||||
Source |
| ||||||||||||||
Source of stimulusAdministrator of the host with running Iroha peer | Code in triggers or smart contracts, defined on the integrated DSL language | ||||||||||||||
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:
| ||||||||||||||
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:
| Response measure | The Iroha peer successfully restarted, with following metrics:
|
Questions
Below is a list of questions to be addressed as a result of this requirements document:
Question | Outcome |
---|---|