Business or Mission Analysis
4.1. Introduction, Definition and Purpose of Stakeholder Requirements
Introduction - 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 a set of stakeholders’ requirements for a system that can provide the services needed by the acquirer, the users, and the other stakeholders in a defined environment. 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 read sections 3.3.3.1 and 3.3.3.2 first.
Definition and Purpose - An initial presentation 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 in terms of purpose, expected mission, services or operations, objectives, exchanges, and physical links 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 Stakeholders’ Requirements applicable to the system-of-interest;
- the analysis and translation of the Stakeholders’ Requirements into a set of System Requirements (see section 3.3.5).
Requirements engineering is performed in an iterative manner with the other life cycle processes and recursively through the system design hierarchy.
4.2. Principles about Stakeholder Requirements
4.2.1. From capture of needs to the Stakeholders’ 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 4 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 4
This figure shows these steps and the position of the Stakeholder Requirements and System Requirements in the engineering cycle:
- 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.
- Perceived needs are based on a person’s awareness (possibly imperfect) that something is wrong, that there is a lack of something, or that there is something that could improve a situation. 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.
- 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.
- Retained needs use the prioritization of expressed needs in order to achieve something or make solutions feasible. The retained needs allow the consideration of potential solutions. 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.
- 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. The expression of the System Requirements means that potential solutions exist or can be developed, manufactured, or bought.
- Realized needs are the system, product, or service realized, taking into account every System Requirement (and hence Stakeholder Requirement).
ADD ACTION RELATED TO COMMENTS 379, 826, 1180
4.2.2. Mission Analysis and Operational Concept
The notion of Mission Analysis and of Concept of Operations originated from Defense organizations to define the tasks and actions performed within a context of military operations, taking into account the strategic, operational, and tactical aspects of a given situation.
- The mission analysis is the process used to identify all unit missions and critical collective tasks. Collective tasks must be identified to determine exactly what the unit must be trained in to support accomplishment of unit missions. ((TRADOC 1999, Appendix A), specifically references for AR 25-30, The Army Integrated Publishing and Printing Program; FM 25-100, Training the Force; FM 25-101, Battle Focused Training; and FM 100-23, Peace Operations. Etc.)
- The concept of operations is a clear, concise statement of where, when, and how the commander intends to concentrate combat power to accomplish the mission. It broadly outlines considerations necessary for developing a scheme of maneuver. (U.S. Army 1997, 1-268)
These notions are also used in industrial sectors as aviation administrations and aeronautic transportation, health care systems, Space, etc. with adapted definitions and/or terms, such as operational concepts. Examples include:
- “Mission Analysis” is the term used to describe the mathematical analysis of satellite orbits, performed to determine how best to achieve the objectives of a space mission (European Space Agency).
- In a large-scale system, such as chemical and nuclear plants, the system functional requirement changes during its operation and its component must also play various roles depending on the system state. Since the logical relation between the system and its components changes during system operation, the phased mission analysis (PMA) must be introduced into their reliability analysis (Kohda, Wada, and Inoue 1994, 299-309).
Anywhere these notions are used, it is evident that they are based on fundamental concepts such as operational mode (or operational state of the system), scenario (of actions), operational concepts, functions (provided services), etc. In other words, the system encounters different states during its utilization or operation (operational modes). During each state scenarios of services are performed (operational concept); therefore, a scenario is a sequence of actions, functions or services. This means that during the Stakeholder Requirements definition, the description of operational scenarios is a powerful means to identify 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.
ADD ACTION RELATED TO COMMENT 1151
4.2.3. Classification of Stakeholder Requirements
Several classifications of stakeholder requirements are possible, e.g., (ISO/IEC June 2010, section 9.4.2.3). These classifications of Stakeholder Requirements have the goal 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:
- Service or functional: sets of actions to perform the mission or operations of the system-of-interest; enhanced by effectiveness or performance characteristics attached to the mission or operations
- Operational: states and transitions between states 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 links
- 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
- Logistical: acquisition, transportation, and storage of elements needed by the system-of-interest to perform its services
- Design constraints: re-use of existing components or forbidden materials, for example
- Further categories as necessary.
ADD ACTION RELATED TO COMMENT 1152
4.3. Process Approach - Stakeholder Requirements
4.3.1. Purpose and principles of the approach
The purpose of the Stakeholder Requirements Definition Process is to identify all the needs and expectations from every stakeholder (acquirer, users, and others) and to define the Stakeholder Requirements that express the intended interaction 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, stakeholders’ 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 Table 1 below:
TABLE 1
ADD ACTION RELATED TO COMMENT 837
Considering and questioning the classification, as presented in section 3.3.4.2.3, allows completion of the set of stakeholders’ requirements.
A synthesis of the potential system-of-interest that could satisfy the stakeholders’ requirements is established by defining its major objectives and its purpose, mission, or services.
4.3.2. Activities of the Process
Action (Alain): make the link with ontology elements in the process activities
Major activities and tasks performed during this process include:
- 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.
- Analyzing the acquirers’ and users' needs and defining the corresponding Stakeholder Requirements, including the definition of operational/utilization concepts or scenarios.
- 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.
- Verifying the quality, completeness of each Stakeholder Requirement and the consistency of the set of Stakeholder Requirements.
- Validating the content and relevance of each Stakeholder Requirement with the corresponding stakeholder representative.
- Synthesizing, recording and managing the Stakeholder Requirements.
4.3.3. Artifacts and Ontology Elements
This process may create several artifacts such as:
- Stakeholder Requirements Document
- Organizational Concept of Operations
- System Operational Concept
- Stakeholder Interview Report
- Stakeholder Requirements Database
- Stakeholder Requirements Justification Document (for traceability purpose)
This process handles the ontology elements of the Table 2.
TABLE 2
The main relationships between ontology elements are presented in Figure 5.
FIGURE 5
4.3.4. Checking and correctness of Stakeholder Requirements
Stakeholder Requirements should be checked to gauge whether they are well expressed and appropriate. There are number of characteristics which can be used to check stakeholders’ requirements. In general, stakeholders’ requirements should have characteristics as described in section 3.3.5.3.5.4.
ADD ACTION RELATED TO COMMENT 1154
4.3.5. 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.
ADD ACTION RELATED TO COMMENT 2492
4.4. Application to Product systems, Service systems, Enterprise systems
TO BE WRITTEN
4.5. Practical Considerations about Stakeholder requirements
Major pitfalls encountered with definition of Stakeholder Requirements:
- Stakeholders themselves often do not think in terms of needs but rather in terms of a solution. The solution the stateholder envisions may not be appropriate for their needs.
- When delineating the boundaries of the system-of-interest and defining the mission and purpose of the system at the very beginning of SE, a classic mistake is to place the system-of-interest at the wrong level of abstraction. The level of abstraction can be too high or too low (seating respectively in the upper-system or in a sub-system). This is the consequence of the principle stating that a system is always included in a larger system and of confusing the purpose and the mission of the system-of-interest.
- Sometimes engineers do not take into account the humans acting as operators inside a system or those who use the system and are outside of the system. In consequence, elements are forgotten (ex: roles of operators).
- The exhaustiveness of requirements is an issue; in particular, the interfaces with external objects of the context of the system can be forgotten (exchanges of matter, energy, information).
- Within the interface issue, physical connections of the system-of-interest with external objects can be forgotten (technological constraints).
- In commercial products or systems, the lack or insufficient description of operational modes and scenarios (how the system-of-interest will be used, in which situations, etc.) is often encountered.
- Stakeholders can be forgotten; everyone thinks to direct users, customers, and suppliers, but those who do not want the system to exist and malevolent persons are often left out.
The following proven practices with stakeholders' requirements engineering have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development:
- Involve the stakeholders early in the Stakeholder Requirements development process.
- Capture the rationale for each Stakeholder Requirement.
- Complete Stakeholder Requirements as much as possible before starting the definition of the System Requirements.
- Use modeling techniques as indicated in sections 3.3.4.3.5.
- Consider using a requirements management tool. This tool should have the capability to trace linkages between the Stakeholder Requirements and the System Requirements and to record the source of each Stakeholder Requirement.
(van Lamsweerde 2009)
(Faisandier 2011)
(ISO/IEC June 2010)
IEEE Standard 830
ISO/IEC 15288 System Life Cycle Processes (ISO/IEC 2008)
INCOSE SE Handbook (INCOSE 2010)
TO BE COMPLETED
References
Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.
Citations
List all references cited in the article. Note: SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.
Primary References
All primary references should be listed in alphabetical order. Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ (title). Please do not include version numbers in the links.
Additional References
All additional references should be listed in alphabetical order.