It is assumed that the definition of the problem or the issue to be solved and/or the opportunity for developing a new solution or improving a system of interest (SoI) has been done prior to starting the activities necessary to define stakeholder needs and requirements. This means that the context of use of the new or modified mission, operation, or capability has been characterized (see the Mission Analysis topic).
Purpose and Definition
The purpose of defining stakeholder requirements is to elicit a set of needs related to a new or changed mission for an enterprise (see Mission Analysis (MA) for information relevant to identifying and defining the mission or operation), and to transform these needs into clear, concise, and verifiable stakeholder requirements.
Stakeholder needs analysis is the elicitation, communication, validation (glossary) and refinement of the needs and objectives of the enterprise or set of stakeholders. Stakeholder needs analysis is aimed at understanding a potential capability (often identified through MA) that is needed to address an identified problem or opportunity. After defining the stakeholder needs and requirements, they interact with the MA to transform the defined set of needs into stakeholder requirements (also known as mission requirements) that reflect these needs.
From the Capture of Needs to the Definition of Stakeholder Requirements
There are:
• Real needs are those that lie behind any perceived needs (see below); they are conditioned by the context in which people live. As an example, a generic need could be the ability to “identify infectious diseases easily.” Often, real needs appear to be simple tasks.
• Perceived needs are based on a person’s awareness that something is wrong, that there is a lack of something, that there is something that could improve a situation, or that there are business, investment, or market opportunities. Perceived needs are often presented as a list of organized expectations resulting from an analysis of the usage conditions for the considered action (see the Mission Analysis topic). Following from the infectious disease example above, the real need might be perceived as a need to "carry out medical tests in particular circumstances (laboratories, points of care, hospitals, and/or human dispensaries).” Since the real need is seldom clearly expressed, richness of the knowledge of the perceived needs is used as a basis for potential solutions. This step has to be as complete as possible to cover all the contexts of use.
• Expressed needs originate from perceived needs in the form of generic actions or constraints, and are typically prioritized. In the example, if safety is the primary concern, the expressed need to “protect the operator against contamination” may take priority over other expressed needs such as “assist in the execution of tests.” When determining the expressed needs, the analysis of the expected mission or services in terms of operational scenarios takes place.
• Retained needs are selected from the expressed needs. The selection process uses the prioritization of expressed needs to achieve something or make solutions feasible. The retained needs allow the consideration of potential solutions for a SoI. These retained “stakeholder intentions do not serve as stakeholder requirements, since they often lack definition, analysis, and possibly consistency and feasibility. Using the concept of operations to aid the understanding of the stakeholder intentions at the organizational level and the system operational concept from the system perspective, requirements engineering leads stakeholders from those initial intentions to structured and more formal stakeholder requirement statements” (ISO/IEC/IEEE 29148 2011). Characteristics of good requirements can be found in ISO/IEC/IEEE 29148 (2011). Exploration of potential solutions must start from this step. The various solutions suggested at this step are not yet products, but describe means of satisfying the stakeholder requirements. Each potential solution imposes constraints on the potential future SoI.
• Specified needs, generally called “system requirements (glossary),” are the translation of the stakeholder requirements to represent the views of the supplier, keeping in mind the potential, preferred, and feasible solutions. “The stakeholder requirements are then transformed into system requirements for the SoI, Consistent practice has shown this process requires iterative and recursive steps in parallel with other life cycle processes through the system design hierarchy. The recursive application of the processes will generate lower-level system element requirements.” (ISO/IEC/IEEE 29148 2011).
• Realized needs are the product, service or enterprise realized, taking into account every system requirement (and hence, the stakeholder requirement(s)). Each class of needs listed above aligns with an area of the SE process. For example, the development of "specified needs" requirements is discussed in the System Requirements topic. For more information on how requirements are used in the systems engineering process, please see the System Definition knowledge area (KA).
Identifying Stakeholders and their Requirements
Stakeholders of a SoI may vary throughout the life cycle. Thus, in order to get a complete set of needs and subsequent requirements, it is important to consider all stages of the life cycle when identifying the stakeholders or classes of stakeholders.
Every system has its own stages of life; these may include concept, development, production, operations, sustainment, and retirement (for more information, please see Life Cycle Models). For each stage, a list of all stakeholders having an interest in the future system is identified. The goal is to get every stakeholder’s point of view for every stage of the system life in order to consolidate a complete set of stakeholder needs that can be prioritized and transformed into the set of stakeholder requirements as exhaustively as possible.
Classification of Stakeholder Requirements
Several classifications of stakeholder requirements are possible, e.g. ISO/IEC 29148, section 9.4.2.3 (ISO/IEC 2011) provides a useful set of elements for classification. One possible way to classify the stakeholder requirements is:
Functional Sets of actions to perform the mission or operation of the system-of-interest; enhanced by effectiveness or performance characteristics attached to the mission or operations.
Operational This category may include:
• Operational concept that indicates the operational features to be provided without specifying design solutions;
• Operational scenarios describing the sequence or series of activities supported by the system-of-interest;
• Operational modes and transitions of modes between states/modes of the system-of-interest during its utilization to include dynamic interactions between the system-of-interest (viewed as a black box) and the system-of-interest's interface with external components in the context of its use.
Interface Matter, energy, or information flows exchanged between the system-of-interest and its external components in the context of its use, including physical interfaces.
Environmental External conditions affecting the system when in operation.
Utilization Characteristics The '-ilities' used to indicate conditions of the utilization of the system-of-interest (e.g. usability, dependability, security, etc.)
Human Factors Capabilities of users and operators, ergonomics, and associated constraints. Logistical Acquisition, transportation, and storage of elements needed by the system-of-interest to perform its services (e.g. constraints for logistical support).
Design and Realization Constraints Re-use of existing system elements or forbidden materials, for example.
Process Constraints: These are stakeholder, usually acquirer or user, requirements imposed through the contract or statement of work. These requirements do not directly address the end-item system, but rather how the end-item system is developed and provided.
Process requirements include compliance with national, state, or local laws, including environmental laws; administrative requirements; acquirer/supplier relationship requirements; and specific work directives. Process requirements may also be imposed on a program by corporate policy or practice. System or system element implementation process requirements, such as mandating a particular design method, are usually captured in project agreement documentation such as contracts, statements of work (SOW), and quality plans.
Project Constraints: Constraints to performing the project and/or the end-item system within cost and schedule.
Business Model Constraints: Constraints related to the expected business goal achieved by the system-of-interest, when this is relevant within the context of use; these may include geographic position (local, national, international) of the future product, service, or organization resulting from the system-of-interest, distribution channels, alliance and partnership, finance and revenue model etc.
Stakeholder Requirement
Necessity or desire expected by an end user, formally drafted and expressed in terms of a client and end user; service, objective, capability expected from the future system by the end users. Equivalent to expectation; includes user requirements.
Scenario: A set of actions/functions representing the dynamic of exchanges between the functions allowing the system to achieve a mission or a service.
Risk: An event having a probability of occurrence and a gravity degree on its consequence onto the system mission or on other properties (used for technical risk in engineering). A risk is the combination of vulnerability and of a danger or a threat.