...
For the functional requirements, we should follow the default use case template by example:
| Use case title | [FR0000] Example use-case; ID should be unique |
|---|
| Preconditions | - 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
|
| Postconditions | - One or more results of successfully finished use case
|
| Alternative flow | - 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
|
| Exception 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
| Use case title | [FR0001] Starting the Iroha network |
|---|
| Preconditions | - 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
|
| Postconditions | - The Iroha network is running
- The administrator has access to the root account of the network
|
| Alternative flow |
|
| Exception flow | - 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
|
| Use case title | [FR0002] Adding peer to the Iroha network |
|---|
| Preconditions |
|
Use case flow |
|
| Postconditions |
|
| Alternative flow |
|
| Exception flow |
|
| Use case title | [FR0003] Removing peer from the Iroha network |
|---|
| Preconditions |
|
Use case flow |
|
| Postconditions |
|
| Alternative flow |
|
| Exception flow |
|
| Use case title | [FR0004] Configuring initial state of the Iroha network |
|---|
| Preconditions |
|
Use case flow |
|
| Postconditions |
|
| Alternative flow |
|
| Exception flow |
|
...
Making changes in Iroha network data by Iroha special instructions
| Use case title | [FR0100] Sending the instruction to the Iroha network |
|---|
| Preconditions | - The user has an account in the Iroha network
- The user has prepared the command
- The user has permissions to execute the instruction
- The Iroha network is working in normal condition
|
Use case flow | - The user sends the instruction to the Iroha peer through the API
- The Iroha peer receives the instruction and validates its contents
- The Iroha peer checks that the user's account have enough permissions to run the instruction
- The Iroha peer executes the instruction by applying it to the current block
- The Iroha peer returns the result of the operation to the user
|
| Postconditions | - The instruction is successfully executed and applied to the network state
|
| Alternative flow | - On step 4, if the current user's account is multi-signature, the result of instruction will be applied to the block-store only when the number of signatures will reach the current quorum value. In other casecases, the Iroha peer will return "pending" status as a response on step 5.
|
| Exception flow | - On step 2, of the instruction has invalid structure, the Iroha peer returns an error message with description to the users and stops the flow
- On step 3, if the user's account does not have required permissions, the Iroha peer returns information about that error and stops the flow
- On step 3, in case of multi-signature instruction, if the instruction signed using the key pair, which was already used for signing that instruction, the Iroha peer will return "already signed" error status and stop the flow
|
| Use case title | [FR0101] Creation of the user in the Iroha network |
|---|
| Preconditions | - The user has permission to create other users
|
Use case flow | - The user prepares information about the account that should be created, which includes name, domain, the public key and permissions list
- The user prepares instruction to send to the Iroha network according to the prepared information
- The user sends the instruction to the Iroha peer (includes FR0100)
- Tha Iroha peer returns the result of the instruction execution to the user
|
| Postconditions | - The new account in the Iroha network is created
|
| Alternative flow |
|
| Exception flow |
|
| Use case title | [FR0102] Configuring permissions for the account in the Iroha network |
|---|
| Preconditions |
|
Use case flow |
|
| Postconditions |
|
| Alternative flow |
|
| Exception flow |
|
| Use case title | [FR0102] Granting permissions for the account in the Iroha network |
|---|
| Preconditions | - The user has access to his/her account in the Iroha network
- The user's account has permissions to provide grantable permissions
|
Use case flow | - The user prepares the instruction to grant one or more permissions to another account
- The user sends the instruction with the prepared instruction to the Iroha peer (<<includes>> FR0100)
- The Iroha peer returns the result of the instruction to the user
|
| Postconditions | - The permission was granted to another account
|
| Alternative flow |
|
| Exception flow |
|
| Use case title | [FR0104] Sending complex instruction using ISI DSL |
|---|
| Preconditions |
|
Use case flow |
|
| Postconditions |
|
| Alternative flow |
|
| Exception flow |
|
| Use case title | [FR0105] Sending instruction and subscribing to the status of finalization |
|---|
| Preconditions | - The user has permissions to execute requested instruction
|
Use case flow | - The user prepares the instruction parameters according to his/her needs
- The user sends the instruction into the Iroha peer (<<includes>> FR0100)
- The user uses the same connection for obtaining the status of the instruction finalization
- The Iroha peer sends updates about the instruction finalization status to the user
- The user receives the "successfully finalized" status about the instruction
|
| Postconditions | - The instruction is accepted and finalized in the block-storage
- The user did not spend additional resources for redundant network connections and requests
|
| Alternative flow |
|
| Exception flow | - At step 4 if the instruction cannot pass the validation, the user would not get the "successfully finalized" status; instead, he/she will get the "invalid instruction" status.
- At step 4 if the network is in "bad" condition, the user would get the "successfully finalized" status eventually, when the network will return in a "good" state.
|
| Use case title | [FR0106] Creation of the multi-signature account in the Iroha network |
|---|
| Preconditions |
|
Use case flow |
|
| Postconditions |
|
| Alternative flow |
|
| Exception flow |
|
| Use case title | [FR0107] Changing quorum for the multi-signature account |
|---|
| Preconditions |
|
Use case flow |
|
| Postconditions |
|
| Alternative flow |
|
| Exception flow |
|
| Use case title | [FR0108] Changing list of signatories for the multi-signature account |
|---|
| Preconditions | - The user has permissions to change the list of signatories to the required account
- The user has generated key pair for adding it as a signatory to the
|
Use case flow |
|
| Postconditions |
|
| Alternative flow |
|
| Exception flow |
|
| Use case title | [FR0109] Signing multi-signature transactioninstruction |
|---|
| Preconditions | - There is a multi-signature account in the Iroha network
- The user has access to the one or many key pairs for the multi-signature account
- The current amount of signatures to the multi-signature instruction is lower than a current quorum value
|
Use case flow | - The user obtains the current list of pending instructions (<<include>> FR0203)
- The user finds information
- required instruction that can be signed by his/her signatures
- The user signs
- required instruction using the available key pair by calling corresponding method from CLI or client SDK
- The user sends signed instructions to the Iroha peer (<<include>> FR0100)
|
| Postconditions | - Amount of signatures in the signed instruction increased by 1 signature
- Signed instruction disappears from the list of pending instructions for the current user's account
|
| Alternative flow | - On step 2 the user can select more than one instruction, all of them can be sent on step 4 as a separate requests
- On step 3 the user can sign the instruction by more than one signature, and all of them can be sent as a single request per single instruction on step 4
|
| Exception flow | - On step 1, in case of the empty list of pending instructions, the Iroha peer will return corresponding status and the use case flow stops
- On step 3, if the user uses key pair, which was already used for signing the instruction, the CLI/SDK will return corresponding error status; use case flow stops if there are no more available key pairs.
|
Acquiring data from the Iroha network by queries
| Use case title | [FR0200] Acquiring data from the Iroha network by query |
|---|
| Preconditions |
|
Use case flow |
|
| Postconditions |
|
| Alternative flow |
|
| Exception flow |
|
| Use case title | |
|---|
| 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 |
|
| Postconditions |
|
| Alternative flow |
|
| Exception flow |
|
| Use case title | [FR0203] Acquiring a list of pending multi-signature instructions |
|---|
| Preconditions |
|
Use case flow |
- (should the Iroha expose all pending instructions, or we need to add the account ID / public key to request?)
|
| Postconditions |
|
| Alternative flow |
|
| Exception flow |
|
...