Summary

Refine and elaborate stakeholder requirements to develop service system requirements.

Description

Stakeholder requirements are analyzed in conjunction with the development of the operational concept to derive more detailed and precise sets of requirements called “derived requirements.” These requirements address all aspects of the service system associated with service delivery, including work products, services, processes, consumables, and customer and other resources; as well as the functionality and quality attribute needs of relevant stakeholders.

Derived requirements arise from constraints, consideration of issues implied but not explicitly stated in the stakeholder requirements baseline, and factors introduced by the selected service system architecture, the design, the developer’s unique business considerations, and strategic priorities, including industry market trends. The extent and depth of derived requirements vary with the complexity of the service system needed to meet stakeholder requirements.

Refer to the Strategic Service Management (STSM) (CMMI-SVC) process area for more information about establishing standard services.


In some service contexts, derived requirements can be as simple as identification and quantification of required resources. For complex service systems with many types of components and interfaces, the initial requirements are iteratively refined into lower level sets of more detailed requirements that can be allocated to service system components as the preferred solution is refined.

Through such analysis, refinement, derivation, and allocation activities, the functionality and quality attribute requirements for the service system are established.

Example Work Products



  1. Derived requirements with relationships and priorities
  2. Service requirements
  3. Service system requirements
  4. Requirement allocations
  5. Architectural requirements, which specify or constrain the relationships among service system components
  6. Interface requirements
  7. Skill level requirements


Subpractices

1. Develop requirements and express them in the terms necessary for service and service system design.

In particular, these requirements include architectural requirements that specify critical quality attributes.



2. Derive requirements that result from solution selections and design decisions.

3. Establish and maintain relationships among requirements for consideration during change management and requirements allocation.

Relationships include dependencies in which a change in one requirement can affect other requirements.

Relationships among requirements can aid in design and in evaluating the impact of changes.



4. Prioritize derived requirements.

Prioritization of requirements can assist in defining iterative development cycles.



5. Allocate the requirements to logical entities, service system components, and other entities as appropriate.

As the operational concept evolves, requirements are allocated to logical entities (e.g., functions, processes) that aid in relating the requirements to the operational concept. These logical entities also serve to organize the requirements and assist in synthesis of the technical solution. As the technical solution is selected or emerges, requirements are allocated to service system components (or the architecture, in the case of many nonfunctional requirements) as appropriate.

In the case of an iterative or incremental approach to developing the service system, requirements are also allocated to iterations or increments.



6. Identify interfaces both external and internal to the service system.

7. Develop requirements for the identified interfaces.