Requirements Analysis

The first stage of the method is called Requirements Analysis. The purpose of this method is to produce functional requirements driven from use case analysis of the system.

The Requirements Analysis method is a 10 minute method. Using the open-source 'SysML Helper' profile takes only 10 minutes to use Rhapsody end-to-end to create a SysML project from scratch and get the requirements created in it into Rational DOORS (it takes about 1 hour to show someone how to do it).

The essential steps are:

1. Create the Rhapsody project, populate a package structure with a use case diagram and setup the Rhapsody Gateway project to sync requirements into a formal module in DOORS.
2. Create use cases and their related high-level requirements (goals).
3. For each use case create a simplified (text-based) activity diagram of the steps including both the sunny and rainy day scenarios.
4. For each step create a new, or trace an existing, functional requirement, such that all steps are covered by at least 1 functional requirement (in some cases a step may be covered by more than one requirement, or a requirement may be related to more than one step).
5. (Optional) Sync all requirements into Requirements Management tool such that they can be management and tracked with allocated unique ID's.
6. (Optional) Sync all diagrams into the RM tool such that they can provide additional information to support the requirements.

In this instance the context of the use cases is important. The system is defined by the emergent behavior of a set of system components that is not realized by any individual component alone. As such the use cases are those defined for the system, not for the components. As an example, in an insulin pump system there may be a blood glucose tester, an insulin pump and a Cannula set. A use case for the system may be to deliver insulin for a meal that involves taking a bG reading, entering it into the insulin pump and delivering the insulin (via the Cannula). Taking a bG reading is a step in the system use case when we define the system as the behavior that is realized only by a combination of components.

If we changed the system context to the glucose meter then a valid use case would be to "Take a bG reading" and a step in that use case would be to prick the finger to get blood. Note how the granularity of steps is very different when we consider the context of a system to be only the use cases that are realized by a combination of components (sub-systems) not use cases of the components themselves. This abstraction is usually very critical to managing complexity. Abstraction allows us to retain the higher level picture without polluting it with downstream choices. Abstraction reduces volatility while retaining clarity of need vs design.