...
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
|
| Postconditions | - The Iroha network is running
- The administrator has access to the root account of the network
|
| Alternative flow |
|
| Exception flow | - On step 2, in case of invalid genesis block the Iroha peer shows corresponding error messages to the administrator and halts the network creation process
|
...
| 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 | [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 - <<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.
|
Acquiring data from the Iroha network by queries
...