The main value proposition points for this practice are:
-
Enables early collaboration with stakeholders to validate requirements and to provide the foundation for system
architecture.
-
More rapid achievement and more complete SRS.
The objective of this practice is to analyze the process inputs: the stakeholder requirements are translated
into system requirements that define what the system must do (functional requirements) and how well it must perform
(quality of service requirements). It starts with the analysis and optional refinement of the stakeholder requirements,
having as an output the Stakeholder Requirements Specification. Essentially, stakeholder requirements focus on required
capabilities. These are transformed into required system functions ("shall" statements) and documented in the Draft
System Requirements Specification. For traceability, the identified system requirements are linked to the associated
stakeholder requirements. Next major step is the definition of system use cases. A use case describes a specific
operational aspect of the system (operational thread). It specifies the behavior as perceived by the actors (user) and
the message flow between the actors and the use case. An actor may be a person, another system or a piece of hardware
external to the System under Design (SuD). A use case does not reveal or imply the system's internal structure (black
box view).
Use cases may be structured hierarchically - but care should be taken not to functionally decompose the use cases. Use
cases are not functions, they use functions. There is no "golden rule" with regard to the number of use cases needed to
describe a system. Experience shows that for large systems, typically 6 to 24 use cases may be defined at the top
level. At the lowest level a use case should be described by at least 5, with a maximum of 25 essential use case
scenarios. At this stage, emphasis is put on the identification of "sunny day" use cases, assuming an error/fail free
system behavior. Exception scenarios will be identified at a later stage through model execution. If more than 5
error/fail scenarios are found for a use case, they should be grouped in a separate exception use case, which are then
linked to the "sunny day" use case via an include or extend dependency.
In order to assure that all functional and associated performance requirements are covered by the use cases, respective
traceability links need to be established. If functional system requirements are traced to multiple use cases, it is an
indication that the use cases are not independent. Ideally, use cases should be independent of one another.
Once the system-level use cases are defined and the complete coverage of the functional and associated performance
requirements is assured, the requirements analysis phase ends.
|