Practice: Elaborate Draft System Requirements Specification
This practice focuses on providing the first cut definition of system requirements derived from stakeholder requirements delivered as the Systems Requirements Specification (draft). The functional requirements are grouped and prioritized as system use cases.
Purpose

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.

How to read this practice

Start with the practice description and then use the associated workflow as an entry point in this material. Understand in detail each task involved in this practice and then shift your focus on the artifacts which are produced and their states: Stakeholder Requirements Specification, Systems Requirements Specification (draft), System Use Cases.

Relationships