Business or Mission Analysis

The starting point of engineering a system is the definition of the problem to be solved. The stakeholders’ requirements represent the view of the users , acquirers , and customers of the problem. An important set of activities has to be performed to establish the set of stakeholders’ requirements. This section provides knowledge about the notions of needs, expectations, stakeholders’ requirements, concept of operations, and the related systems engineering activities and methods. The set of Stakeholder Requirements represents one of the major outcomes of these activities. For better understanding of this chapter, it is recommended that you first read the Introduction to System Definition Knowledge Area and the topic Fundamentals of System Definition.

Definition and Purpose

An initial expression of stakeholders’ intention is not necessarily a requirement, since it has not been defined, analyzed, or determined to be feasible. This intention is distinguished from a requirement as being (stakeholder) needs, goals or objectives. The distinction between requirements and needs is related to which system is concerned; for example, a requirement for a system may be allocated to a software element of the system, viewed as needs by the supplier of this software element, and further elaborated as (a) requirement(s) for this software element.

An important aspect of engineering is “requirements engineering.” Some activities gathered under this term include:

• the capture of the needs, goals, and objectives of the various stakeholders ;
• the preliminary identification of the engineering elements of this system of interest (soi) in terms of purpose, expected mission, services or operations, objectives, exchanges, and physical interfaces with the objects of its context of use;
• the enrichment of the needs through the analysis of these first engineering elements of the system, in particular what is called the “mission analysis”;
• the transformation of these needs into clear, concise, and verifiable Stakeholder Requirements applicable to the System of Interest;
• the analysis and translation of the Stakeholder Requirements into a set of System Requirements (see topic System Requirements).

Requirements engineering is performed in an iterative manner with the other life cycle processes and recursively through the system design hierarchy.

Principles Applicable to Stakeholder Requirements

From capture of needs to the 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. Cycle of needs (Faisandier, 2011)

This figure 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 disorganized expectations, often resulting from an analysis of the usage conditions for the considered action. 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. The retained needs are generally called "Stakeholder Requirements,” and 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 future System of Interest.
5. Specified needs, generally called “System Requirements”, are the translation of the stakeholders’ requirements to represent the view and expression of the supplier of the problem, having in mind potential feasible solutions. The expression of the System Requirements means that potential solutions as systems exist or can be developed, manufactured, or bought.
6. Realized needs are the product , service or Enterprise (glossary)realized, taking into account every System Requirement (and hence Stakeholder Requirement).

Other authors have defined similar processes and definitions; for example (Parnell, Driscoll, Henderson 2008). ISO 29148 also has a detailed process.

Mission Analysis and Concept of Operations

The notions of Mission Analysis and Concept of Operations originated from Defense organizations to define the tasks and actions performed within the context of military operations, taking into account the strategic, operational, and tactical aspects of a given situation. It has been generalized to wider applications. These notions permit the user to define what the system should do, and why, in the user language and context. These in turn are used to write technical stakeholder and then system requirements.

During the Stakeholder Requirements definition, the description of operational scenarios is a powerful means of identifying the expected or required services of the future system. On the other hand, if the expected services are (pre)defined, the expression of Operational Scenarios provides the expected behavior of the system in use; that is to say, how the user intends to use the system in its various operational modes. For more explanations about the notion of Concept of Operations, refer to (IEEE.1998). Useful information can be found in (ISO/IEC. 2011) Annex A (System Operational Concept) and Annex B (Concept of Operations).

Classification of Stakeholder Requirements

Several classifications of stakeholder requirements are possible. ISO/IEC 29148, section 9.4.2.3 (ISO/IEC. 2011) provides interesting elements for classification. These classifications of Stakeholder Requirements are defined to facilitate the classification of the System Requirements and, subsequently, to prepare the design and validation activities. One possible way to classify the Stakeholder Requirements is under the following categories as indicated in Table 1.

Table 1 – Example of Stakeholder Requirements classification

---

Process Approach - Stakeholder Requirements

Purpose and principles of the approach

The purpose of the Stakeholder Requirements Definition Process is to identify the needs and expectations from every stakeholder (acquirer, users, regulator, and others) and to define the Stakeholder Requirements that express the intended interactions that the System of Interest will have with its operational environment. They are the reference against which each resulting operational service is validated.

Needs and expectations are collected through stakeholders' interviews (including user surveys), technical documents, feedback from the Verification Process and the Validation Process, and from outcomes of the System Analysis Process. (ISO/IEC. 2008)

From these needs, the stakeholders’ requirements can be developed. To get a complete set of needs, expectations, and, finally, Stakeholder Requirements, it is necessary to consider the System of Interest in various stages across its typical life cycle. Every system has its own stages of life, from the initial need to the disposal; these may include transfer for use or deployment, normal use in operation, production, maintenance, and disposal. For each stage, a list of all actors having an interest in the future system is identified. Those actors are called stakeholders . The aim is to get every stakeholder point of view for every stage of the system life in order to establish the list of Stakeholder Requirements as exhaustively as possible.

An example is provided in the Table 2 below:

Table 2. Stakeholders Identification Based on Life Cycle Stages

Considering and questioning the classification, as presented in the previous section, allows completion of the set of Stakeholder Requirements.

A synthesis of the potential System of Interest that could satisfy the Stakeholder Requirements is established by defining its major objectives and its purpose , mission , or services.

Activities of the Process

Major activities and tasks performed during this process include:

1. Eliciting or capturing the stakeholders' needs, expectations, and requirements; determining the purpose, mission, or services and the major objectives of the potential System of Interest.
2. Analyzing the acquirers’ and users' needs and defining the corresponding Stakeholder Requirements, including the definition of operational/utilization concepts or scenarios .
3. Exploring, analyzing, and identifying the needs and expectations of the other stakeholders (the list of the stakeholders depends on the system life cycle), including various life cycle constraints.
4. Verifying the quality, completeness of each Stakeholder Requirement and the consistency of the set of Stakeholder Requirements.
5. Validating the content and relevance of each Stakeholder Requirement with the corresponding stakeholder representative providing rationale of the existence of the requirement.
6. Identifying potential risks (or threats and hazards) that could be generated by the Stakeholder requirements.
7. Synthesizing, recording and managing the Stakeholder Requirements and potential associated Risks.

Artifacts and Ontology Elements

This process may create several artifacts such as:

1. Stakeholder Requirements Document
2. Organizational Concept of Operations
3. System Operational Concept
4. Stakeholder Interview Report
5. Stakeholder Requirements Database
6. Stakeholder Requirements Justification Document (for traceability purpose)

This process handles the ontology elements of Table 3.

Table 3. Main ontology elements as handled within Stakeholder Requirements definition.

The main relationships between ontology elements are presented in Figure 2.

Figure 2. Stakeholder Requirements relationships with other engineering elements (Faisandier, 2011)

Checking and correctness of Stakeholder Requirements

Stakeholder Requirements should be checked to gauge whether they are well expressed and appropriate. There are a number of characteristics which can be used to check Stakeholder Requirements. In general, Stakeholder Requirements should have characteristics as described in section "Presentation and Quality of Requirements" in the topic System Requirements.

Determining the correctness of Stakeholder Requirements requires user-domain expertise which would involve one or more subject matter experts if the system engineering team does not have stakeholder domain expertise.

Methods and Modeling Techniques

It is strongly recommended that the engineers consider several different 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
• Observation of environment or work patterns (e.g., time and motion studies)
• Technical documentation review
• Market analysis or competitive system assessment
• Simulations, prototyping, and modeling
• Benchmarking processes and systems
• Organizational analysis techniques (e.g., Strengths, Weaknesses, Opportunities, Threats - SWOT analysis, product portfolio)
• 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 of SysML
• Context diagram based on Block diagram of SysML
• Functional Flow Block Diagram

---

Application to Product systems, Service systems, Enterprise systems

The classification of Stakeholder Requirements may have differences between those types of systems.

---

Practical Considerations about Stakeholder requirements

Some major pitfalls encountered with definition of Stakeholder Requirements are indicated in Table 4.

Table 4. Major pitfalls with definition of Stakeholder Requirements

The following proven practices with Stakeholder Requirements engineering have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development - see Table 5.

Table 5. Proven practices with definition of Stakeholder Requirements

---

References

Citations

Kohda, T., M. Wada, and K. Inoue. 1994. "A simple method for phased mission analysis." Reliability Engineering & System Safety 45 (3): 299-309.

IEEE. 1998. Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document. Institute of Electrical and Electronics Engineers, IEEE 1362:1998.

ISO/IEC. 2008. Systems and software engineering - system life cycle processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC 15288:2008 (E).

ISO/IEC. 2011. Systems and software engineering - Life cycle processes - Requirements engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC FDIS 29148.

Primary References

ISO/IEC. 2008. Systems and software engineering - system life cycle processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC 15288:2008 (E).

ISO/IEC. 2011. Systems and software engineering - Life cycle processes - Requirements engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC FDIS 29148.

INCOSE. 2010. INCOSE systems engineering handbook, version 3.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.

van Lamsweerde, A. 2009. Requirements Engineering. New York, NY, USA: Wiley.

Additional References

Center for Quality Management. 1993. Special issue on kano's methods for understanding customer defined quality. Center for Quality Management Journal 2 (4) (Fall 1993).

Faisandier, A. 2011. Engineering and architecting multidisciplinary systems. (expected--not yet published).

IEEE. 1998. Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document. Institute of Electrical and Electronics Engineers, IEEE 1362:1998.

Hull, M. E. C., Jackson, K., Dick, A. J. J. 2010. Systems Engineering. 3rd ed. London, UK: Springer.

Kano, N. 1984. Attractive quality and must-be quality. Quality JSQC 14 (2) (October 1984).

Kohda, T., M. Wada, and K. Inoue. 1994. A simple method for phased mission analysis. Reliability Engineering & System Safety 45 (3): 299-309.

Marca, D. A., and C. L. McGowan. 1987. SADT: Structured analysis and design techniques. Software Engineering. New York, NY: McGraw-Hill.

Article Discussion

[Go to discussion page]

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

Signatures

--Dholwell 16:37, 1 September 2011 (UTC) core edit