This transform method requires that all the functions are traced to the same set of functional requirements. As such, one can consider this method to be an evolution of the behavioral model from an activity-model (traced to initial functional requirements) into an interaction model (traced to final functional requirements). This method can be done by the same person or a different person from the Requirements Analysis phase and supports parallel working in separate models, if needed. The focus switches from the left hand side of the V to the right-hand side of the V.
The essential steps are:
- Create a functional analysis model structure for performing the model execution based on a given requirements-analysis model.
- Take the activity diagram for each use case. Progressively work through it transforming the textual steps into operations, events or attributes. Integrate these system functions, inputs and outputs into an executable state machine. Ensure that the related-requirements trace to transitions in the state machine for coverage.
- Execute the state machine to generate a scenario that was described in the original textual-based activity diagram. Validate the emergent behavior of the integrated scenarios.
- Once all the scenarios are integrated, we will start to find missing requirements, hence can fill in the gaps, add new requirements and clarify ambiguous ones in the context of the richer model.
- Capture each key usage scenario as a test case that is traced to the requirements.
- Fix issues including removing duplicate requirements, correcting ambiguous requirements, and adding missing requirements prior to hand-off. Sign off all the test cases with stakeholders.
The purpose of the state machine is to ensure that all the paths are consistent. It also allows the verification of the desirable emergent behavior through simulation. Inevitably this finds unexpected and desirable emergent behavior and gaps in the requirements that need to be corrected before cascading into the architectural model (in Design Synthesis). It is very similar to unit testing the requirements model as a suite of tests can be built up and results executed to ensure that modifications do not break existing test cases.
This method aligns in principal and goal to the original Harmony-SE method proven by Dr Hans-Peter Hoffman. As well as working from text-based activity model the SysMLHelper also applies a design pattern to support guard-based, rather than event-based, transitions to be expressed in the state-machine. This is a tailoring of the Harmony-SE method for automotive based applications, and enables a more continuous-based simulation semantic to be expressed. This smooths the hand-off to software engineering teams downstream and eases adoption by engineers familiar with Stateflow.
Importantly, the model is not a software implementation model. It is a requirements definition model and is fully traced to all the functional requirements. It is the test cases traced to functional requirements defined as sequence diagrams that is the primary hand-off to the next level not the state machine. Included in this definition is a set of system functions, system attributes, and events sent to/from the actors that all trace to the functional requirements. In the subsequent stage of the method, Design Synthesis, it is these that will be allocated to components inside the system. This allocation will result in the creation of logical interfaces between the components.
This method can be done by a different engineer than the Requirements Analysis phase. However, it does not generate a new set of requirements, rather it "unit tests" the existing requirements. This requires very close collaboration to correct and improve the requirements in the context of the interaction model.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.