Commit 75d79a73 authored by Bock, Florian (I/EF-A3)'s avatar Bock, Florian (I/EF-A3)
Browse files

updated usage/pragmatics section

parent 5fe17867
Pipeline #1097 passed with stage
in 15 seconds
...@@ -99,15 +99,23 @@ As already stated, scenarios are used throughout the development process with di ...@@ -99,15 +99,23 @@ As already stated, scenarios are used throughout the development process with di
The goal of defining one single workflow for the creation and usage of scenarios seems ambitious and possibly unachievable. To cover all defined use cases, this would result in a very complex process, that would be hardly usable. Nevertheless, the goal should be to cover as much use cases as possible. To do so, an iterative approach for the application within the OSC 2.0 standardization project seems reasonable. The goal of defining one single workflow for the creation and usage of scenarios seems ambitious and possibly unachievable. To cover all defined use cases, this would result in a very complex process, that would be hardly usable. Nevertheless, the goal should be to cover as much use cases as possible. To do so, an iterative approach for the application within the OSC 2.0 standardization project seems reasonable.
This implies several steps: This implies several steps:
- A review of the already defined use cases should be done to identify missing use cases, improve the description and the differentiation among themselves and finalize the list - A review of the already defined use cases should be done to identify missing use cases, improve the description and the differentiation among themselves and finalize the list (Use cases and usage&pragmatics section of the concept document)
- Cluster/restructure the user stories/use case examples ( e.g., grouping according to the feature sets)
- Link all user stories/use case examples to corresponding content from the usage &
pragmatics section if possible
- Representatives for each use case should be determined to deliver insight in the background and the underlying assumptions - Representatives for each use case should be determined to deliver insight in the background and the underlying assumptions
- Each representative should write down his or her workflow/definition in a similar way (e.g., by using the same type of diagram or template) - Each representative should write down his or her workflow/definition in a similar way (e.g., by using the same type of diagram or template)
- Each worfklow should be reviewed by at least one reviewer to find flaws, unclear parts and missing elements - Each worfklow should be reviewed by at least one reviewer to find flaws, unclear parts and missing elements
- All workflows should be checked for duplicates (either in whole or in parts) - All workflows should be checked for duplicates (either in whole or in parts)
- All workflows should be split into atomic parts that can be separated - All workflows should be split into atomic parts that can be separated
- A generic workflow should be created/designed based on the separated atomic parts - A generic workflow should be created/designed based on the separated atomic parts
- Each covered use case should be documented within the workflow - Any gaps in the workflow, that are identified in the standard should be
communicated to the other working groups, so that they are able to fill the gaps
- Each covered use case should be documented within the workflow and all user stories/use case examples have to be linked appropriately
- Uncovered use cases should be documented with ideas, how to proceed with them - Uncovered use cases should be documented with ideas, how to proceed with them
- Review and discuss key requirements and decide about a reference implementation/API/interface
Note: A requirement for all other points above is that the reusability of subelements from a scenario should be possible.
The created workflow should include all lifetime phases for a scenario, from prerequesites and ideas, over the creation and modification, until the maintenance and documentation phases. This enables the user to track the scenario in its current lifetime phase and to know how to proceed. The created workflow should include all lifetime phases for a scenario, from prerequesites and ideas, over the creation and modification, until the maintenance and documentation phases. This enables the user to track the scenario in its current lifetime phase and to know how to proceed.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment