SSD.SG 1 Develop and Analyze Stakeholder Requirements

This goal covers the transformation of collected stakeholder needs, expectations, and constraints into requirements that can be used to develop a service system that enables service delivery.

Needs are collected from sources that can include service agreements; standard defined services; organizational policies; and communication with end users, customers, and other relevant stakeholders. These service needs can define stakeholder expectations of what is to be delivered, specify particular levels or grades of service, or identify constraints on how, when, how often, or to whom services are to be delivered. In particular, the quality attribute related needs, expectations, and constraints of relevant stakeholders should be determined. Quality attributes are properties of the service and service system (e.g., responsiveness, availability, security) that are critical to customer satisfaction and to meeting the needs of relevant stakeholders. (See the definition of “quality attributes” in the glossary.)

These needs, expectations, and constraints in turn may need to be analyzed and elaborated to identify needed details of delivered services not considered by the original sources. The result is a set of stakeholder requirements specified in the language of service system developers, not in the language of those who submitted the requirements.

For example, a customer might establish a requirement to “maintain the equipment listed in Table 25 in working order” with additional details of availability rates, average repair times, and other service levels. However, this requirement may also imply a need for a variety of specialized sub-services, such as diagnostics, field support, and preventive maintenance, each with their own implied sub-service requirements. These refinements may not be of interest or even visible to the original stakeholders but their full specification is needed to identify everything that a service system must do to meet the service delivery requirements.

As service requirements are analyzed and elaborated, they eventually yield derived service system requirements, which define and constrain what the service system must accomplish to ensure the required service is delivered. For example, if the service has a response time requirement, the service system must have derived requirements that enable it to support that response time.

The process of developing and analyzing requirements can involve multiple iterations that include all relevant stakeholders in communicating requirements and their ramifications so that everyone agrees on a consistent defined set of requirements for the service system. Changes can be driven by changes to stakeholder expectations, or by new needs discovered during subsequent service system development activities, service system transition, or service delivery. Since needs often change throughout the service lifecycle, the development and analysis of requirements should rarely be considered a one-time process.

As with all requirements, appropriate steps are taken to ensure that the approved set of service and service system requirements is effectively managed to support development of the service and service system.