| Практика выполнения: Создание и проверка прецедентов |
 |
 |
|
The main value proposition of this practice is to accelerate the approval by stakeholder of system requirements. The main emphasis is on the transformation of the functional system requirements into a coherent description of system functions (operations). The analysis is use case-based, i.e. each system-level use case that was identified in the previous requirements analysis phase is translated into an executable model. The model and the underlying requirements then are verified and validated through model execution. There are three alternatives on how to perform this practice, depending on the available information and the modeler's preference. The same set of artifacts will be produced, but the order will differ. Regardless of the approach, the central artifact is the statechart diagram. Alternative 1 starts with the definition of use case scenarios. Customers often describe sequences of required system usage. Once a set of essential scenarios is captured, the identified functional flow is merged into a common description in an activity diagram. Ports and interfaces are created from the sequence diagrams. The final step in this approach is the definition of the state-based behavior in a statechart diagram. Alternative 2 starts with the definition of the use case functional flow. This is a common approach, if systems engineers have to elaborate requirements. Typically, customers like to express their requirements from the "big picture" point of view. Once the overall functional flow is defined, use case scenarios are derived from the activity diagram. Ports and interfaces are created from the sequence diagrams. Lastly, its state-based behavior is captured in a statechart diagram. Alternative 3 starts with the definition of the use case state-based behavior. This approach is recommended if the system under design (SuD) is strongly state-based. In this case, the creation of an activity diagram may even be skipped. Use case scenarios then are derived as paths through the statechart diagram. From the sequence diagram then ports and associated interfaces are generated. Whenever during the use case based functional analysis new requirements are identified or high-level requirements are detailed by derived requirements, they need to be documented. The use case model is analyzed through model execution using the black-box use case scenarios as the basis for respective stimuli. Once the use case model and the underlying functional requirements are verified and validated, Rainy Day Analysis may be performed. This analysis focuses on the identification of system error / fail behavior that was not covered by the initial set of requirements. |
Get familiar with the types of diagrams involved in this practice. Each diagram plays a specific role in the elaboration of the use case behavior. The activity diagram describes the overall functional flow of the use case. It groups functional requirements in actions and shows, how these actions/operations are linked to each other. The sequence diagram describes a specific path through the use case and defines the interactions (messages) between the operations and the actors. The statechart diagram aggregates the information from the activity diagram (functional flow) and the sequence diagrams (actor interactions). It puts this information into the context of system states and adds to it the system behavior due to external stimuli of different priority The central work product is the state-chart diagram, as it comprises the information of both the black-box sequence diagrams and the use case black-box activity diagrams and can be verified and validated through model execution. As there are three alternative approaches on how to perform this practice, first identify which one(s) are applicable to your specific environment. Follow the appropriate workflow and focus on the order of producing the main artifacts and on the tasks involved in their production/consumption. |
Licensed Materials - Property of IBM |