Difference between revisions of "Stakeholder Needs and Requirements"

From SEBoK
Jump to: navigation, search
(Additional References and Readings)
Line 113: Line 113:
  
 
{{5comments}}
 
{{5comments}}
 +
[[Category:Concept Definition]]

Revision as of 11:04, 23 February 2012

Introduction

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 has been done when starting the activities for defining the Stakeholder Needs and Requirements. This means that the context of use of the new or modified mission, operation, or capability has been characterized (see Mission Analysis topic).

The Stakeholder Requirements represent the view of the users, acquirers, and customers of the problem or of the opportunity, through a set of requirements for a solution that can provide the services needed by the acquirer, users, and other stakeholders in a defined environment. This topic provides knowledge about the notion of stakeholder needs and requirements, and the activities for identifying and prioritized the needs and transforming those needs into stakeholder requirements.. The definition of the set of Stakeholder Requirements is the primary outcome.

Purpose and definition

The purpose of Stakeholder Needs and Requirements is to elicit a set of needs related to a new or changed mission/operation for the enterprise (see mission analysis for information of identifying and defining the mission/operation); and to transform the needs into clear, concise, and verifiable stakeholder requirements.

Stakeholder Needs Analysis is the elicitation, communication, validation , and refinement of the needs and objectives of the enterprise or set of stakeholders (typically including customer, users, and interacting organizations within an enterprise) aimed at understanding a potential capability (often identified through Mission Analysis) that is needed to address an identified problem or opportunity. After defining the needs, Stakeholder Needs and Requirements interact with the Mission Analysis to transform the defined set of needs into Stakeholder Requirements (aka, Mission Requirements) that reflect the needs.

Principles and concepts

From capture of needs to Stakeholder Requirements definition

Several steps are necessary to state the maturity of the needs, from "real needs" to reaching a realized solution (that could be called "realized needs"). Figure 1 presents the “Cycle of needs” as it can be deduced from Professor Shoji Shiba and Professor Noriaki Kano's works and courses, and is adapted here for systems engineering purposes.

FIGURE 1
Figure 1 – Cycle of needs

Figure 1 shows these steps and the position of the Stakeholder Requirements and System Requirements in the engineering cycle:

  1. Real needs are those that lie behind any perception, and indeed may not be perceived at all; they are conditioned by the context in which people live. As an example, a generic need could be “identify infectious diseases easily”. It often looks like a simple action.
  2. Perceived needs are based on a person’s awareness (possibly imperfect) 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 / market opportunities. Perceived needs are often presented as a list of more or less organized expectations, often resulting from an analysis of the usage conditions for the considered action (see Mission Analysis topic). Following on from the example above, the real need might be perceived as a need to "carry out medical tests in particular circumstances (laboratories, point of care, hospital, human dispensary)". Since the real need is seldom expressed, the 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.
  3. Expressed needs originate from perceived needs in the form of generic actions or constraints, and are typically prioritized. For example, if safety is the top concern, the expressed need “Protect the operator against contamination” may take priority over other expressed needs, such as “Assist in the execution of tests.” Here the analysis of the expected mission or services in terms of Operational Scenarios takes place.
  4. Retained needs are selected from a more or less important number of expressed needs. The selection uses the prioritization of expressed needs in order to achieve something or make solutions feasible. The retained needs allow the consideration of potential solutions for a System-of-Interest. 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, Requirements Engineering) Characteristics of good requirements can be found in ISO/IEC/IEEE 29148, Requirements Engineering. Exploration of potential solutions must start from this step (see Mission Analysis topic). 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 System-of-Interest.
  5. Specified needs, generally called “ System Requirements”, are the translation of the Stakeholder Requirements to represent the view and expression of the supplier of the solution to the problem or opportunity, having in mind potential preferred and feasible solutions. “The stakeholder requirements are then transformed into system requirements for the system-of-interest, in accordance with Clauses 5.2.4, 5.2.5, and 5.2.6. 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 in Clause 6 will generate lower-level system element requirements.” (ISO/IEC/IEEE 29148, Requirements Engineering)
  6. Realized needs are the Product, Service or Enterprise realized, taking into account every System Requirement (and hence Stakeholder Requirement).

Stakeholders and their requirements

There are many ways to collect the stakeholder needs, expectations, and objectives. Some of the most common techniques are stakeholders' interviews (including user surveys); technical, operational, and strategy document reviews; feedback from the verification Process and the Validation Process; and review of outcomes from the System Analysis Process. (ISO/IEC. 2008)

Stakeholder Requirements are developed from these needs. There are varying stakeholders of a System-of-Interest throughout the lifecycle. Thus, in order to get a complete set of needs and subsequent requirements, it is important to consider all stages of the lifecycle 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 [Life Cycle Models]. For each stage, a list of all stakeholders having an interest in the future system is identified. The aim is to get every stakeholder 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. Examples of Stakeholders are provided in Table 1.


TABLE 1
Table 1 – Stakeholders Identification Based on Life Cycle Stages

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 under the following categories as indicated in Table 2.

TABLE 2
Table 2 – Example of Stakeholder Requirements classification

Process Approach

Activities of the Process

Major activities and tasks performed during this process include:

  1. Identify the stakeholders or classes of stakeholders across the life cycle.
  2. Elicit, capture or consolidate the stakeholders' needs, expectations, and objectives, as well as any constraints coming from Mission Analysis.
  3. Prioritize the stakeholder needs.
  4. Transform the prioritized, retained stakeholder needs into stakeholder requirements.
  5. Verify quality of each Stakeholder Requirement and of the set of Stakeholder Requirements using the characteristics of good requirements identified in System Requirements, Tables 4 and 5.
  6. Validate content and relevance of each Stakeholder Requirement with corresponding stakeholder representatives providing rationale of the existence of the requirement.
  7. Identify potential Risk (or threats and hazards) that could be generated by the Stakeholder Requirements (for further information, see Risk Management).
  8. Synthesize, record and manage the Stakeholder Requirements and potential associated Risks.

Artifacts and Ontology Elements

This process may create several artifacts such as:

  1. Stakeholder Requirements Document
  2. Stakeholder Interview Report
  3. Stakeholder Requirements Database
  4. Stakeholder Requirements Justification Document (for traceability purpose)

This process handles the ontology elements of Table 3.


TABLE 3
Table 3 – Main ontology elements within stakeholder requirements definition

Methods and Modeling Techniques

It is recommended to consider several techniques or methods for identifying needs, expectations, and requirements during the elicitation activity to better accommodate the diverse set of requirements sources, including:

  • Structured workshops with brainstorming
  • Interviews and questionnaires
  • Technical, operational, and/or strategy documentation review
  • Simulations and visualizations
  • Prototyping
  • Modeling
  • Quality Function Deployment (QFD), which can be used during the needs analysis. QFD is a technique for deploying the "Voice of the Customer.” It provides a fast way to translate customer needs into requirements.
  • Use Case Diagram (OMG. 2010)
  • Activity Diagram (OMG. 2010)
  • Functional Flow Block Diagram

Practical Considerations

Major pitfalls encountered with Stakeholder Requirements are presented in Table 4.

TABLE 4
Table 4 – Major pitfalls

Proven practices with Stakeholder Requirements are presented in Table 5.

TABLE 5
Table 5 – Major proven practices

References

Works Cited

Primary References

Additional References and Readings


<- Previous Article | Parent Article | Next Article ->