Difference between pages "System Implementation" and "Stakeholder Needs and Requirements"

From SEBoK
(Difference between pages)
Jump to: navigation, search
(Robot improving glossary links)
 
(Tech and grammar edits as discussed with Bkcase)
 
Line 1: Line 1:
{{Term|Implementation (glossary)|System Implementation}} uses the structure created during {{Term|Architecting (glossary)|architectural design}} and the results of [[System Analysis|system analysis]] to construct {{Term|System Element (glossary)|system elements}} that meet the {{Term|Stakeholder Requirement (glossary)|stakeholder requirements}} and {{Term|System Requirement (glossary)|system requirements}} developed in the early {{Term|Life Cycle (glossary)|life cycle}} phases. These system elements are then integrated to form intermediate {{Term|Aggregate (glossary)|aggregates}} and finally the complete {{Term|System-of-Interest (glossary)|system-of-interest (SoI)}}. See [[System Integration]].  
+
{{Term|Stakeholder Requirement (glossary)|Stakeholder needs and requirements}} represent the views of those at the business or enterprise operations level—that is, of {{Term|User (glossary)|users}}, {{Term|Acquirer (glossary)|acquirers}}, {{Term|Customer (glossary)|customers}}, and other {{Term|Stakeholder (glossary)|stakeholders}} as they relate to the problem (or opportunity), as a set of requirements for a solution that can provide the services needed by the stakeholders in a defined environment. Using enterprise-level life cycle concepts (see [[Business or Mission Analysis]] for details) as guidance, stakeholders are led through a structured process to elicit stakeholder needs (in the form of a refined set of system-level life-cycle concepts). Stakeholder needs are transformed into a defined set of Stakeholder Requirements, which may be documented in the form of a model, a document containing textual requirement statements or both.  
  
==Definition and Purpose==
+
Stakeholder requirements play major roles in systems engineering, as they:
Implementation is the process that actually yields the lowest-level system elements in the system hierarchy (system breakdown structure). System elements are made, bought, or reused. Production involves the hardware fabrication processes of forming, removing, joining, and finishing, the software realization processes of coding and testing, or the operational procedures development processes for operators' roles. If implementation involves a production process, a manufacturing system which uses the established technical and management processes may be required.
+
* Form the basis of {{Term|System Requirement (glossary)|system requirements}} activities.
 +
* Form the basis of system {{Term|Validation (glossary)|validation}} and stakeholder acceptance .
 +
* Act as a reference for {{Term|Integration (glossary)|integration}} and {{Term|Verification (glossary)|verification}} activities.
 +
* Serve as means of communication between the technical staff, management, finance department, and the stakeholder community.
  
The purpose of the implementation process is to design and create (or fabricate) a system element conforming to that element’s design properties and/or requirements. The element is constructed employing appropriate technologies and industry practices. This process bridges the [[System Definition|system definition]] processes and the integration process. Figure 1 portrays how the outputs of system definition relate to system implementation, which produces the implemented (system) elements required to produce aggregates and the SoI.
+
This topic describes the definition of stakeholder needs and requirements which involves the activities necessary to elicit and prioritize the needs of the stakeholder(s), and transform those needs into a set of defined stakeholder requirements. Defining the problem or the issue to be solved, identifying the opportunity for developing a new solution, or improving a {{Term|System-of-Interest (glossary)|system-of-interest (SoI)}} must begin prior to starting the activities necessary to define stakeholder needs and requirements. This means that an initial context of use of the new or modified mission, operation, or capability has already been characterized (see [[Business or Mission Analysis]]).  System requirements are considered in detail during {{Term|System Definition (glossary)|system definition}}. None of the above can be considered complete until consistency between the two has been achieved, as demonstrated by {{Term|Traceability (glossary)|traceability}}, for which a number of iterations may be needed.
 +
==Purpose and Definition==
 +
The purpose of the Stakeholder Needs and Requirements definition activities are to elicit a set of clear and concise needs related to a new or changed mission for an enterprise (see [[Business or Mission Analysis|mission analysis]] (MA) for information relevant to identifying and defining the mission or operation), and to transform these stakeholder needs into verifiable stakeholder requirements.
 +
 +
Stakeholders may well begin with desires, and expectations that may contain vague, ambiguous statements that are difficult to use for SE activities. Care must be taken to ensure that those desires and expectations are coalesced into a set of clear and concise need statements that are useful as a start point for system definition. These need statements will then need to be further clarified and translated into more ''engineering-oriented'' language in a set of stakeholder requirements to enable proper architecture definition and requirement activities. As an example, a need or an expectation such as, ''to easily ''manoeuvre ''a car in order to park'', will be transformed in a set of {{Term|Stakeholder Requirement (glossary)|stakeholder requirements}} to a statement such as, ''increase the driviability of the car'', ''decrease the effort for handling'', ''assist the piloting'', ''protect the coachwork against shocks or scratches'', etc.
  
[[File:SEBoKv05_KA-SystRealiz_how_outputs_of_Definition_relate_to_Implementation.png|thumb|600px|center|'''Figure 1. Simplification of How the Outputs of System Definition Relate to System Implementation, which Produces the System Elements Required to Produce Systems and Subsystems.''' (SEBoK Original)]]
+
To allow a clear description of the activities of stakeholder needs and requirements to be described, a generic view of the business teams and roles involved in a typical enterprise has been used below., tThis includes teams such as business management and business operations;, and roles including requirements engineer and business analyst. For an overview of these roles and how they enable both stakeholder and business requirements across the layers of a typical enterprise see [[Life Cycle Processes and Enterprise Need]].
  
==Process Approach==
+
==Principles and Concepts==
===Purpose and Principle of the Approach===
 
During the implementation process, engineers apply the design properties and/or requirements allocated to a system element to design and produce a detailed description. They then fabricate, code, or build each individual element using specified materials, processes, physical or logical arrangements, standards, technologies, and/or information flows outlined in detailed descriptions (drawings or other design documentation). A system element will be verified against the detailed description of properties and validated against its requirements. 
 
  
If subsequent verification and validation (V&V) actions or configuration audits reveal discrepancies, recursive interactions occur, which includes predecessor activities or processes, as required, to mitigate those discrepancies and to modify, repair, or correct the system element in question. Figure 2 provides the context for the implementation process from the perspective of the U.S. Defense Acquisition University (DAU).  
+
===Identifying Stakeholders===
 +
Stakeholders of a SoI may vary throughout the {{Term|Life Cycle (glossary)|life cycle}}. Thus, in order to get a complete set of needs and subsequent requirements, it is important to consider all stages of the {{Term|Life Cycle Model (glossary)|life cycle model}} when identifying the stakeholders or classes of stakeholders.  
  
[[File:JS_Figure_5.png|thumb|500px|center|'''Figure 2. Context Diagram for the Implementation Process (DAU 2010).''' Released by the Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).]]
+
Every system has its own stages of life, which typically include stages such as 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 must be 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.  Examples of stakeholders are provided in Table 1.
 +
{|
 +
|+'''Table 1. Stakeholder Identification Based on Life Cycle Stages.''' (SEBoK Original)
 +
!Life Cycle Stage
 +
!Example of Related Stakeholders
 +
|-
 +
|Engineering
 +
|Acquirer, panel of potential users, marketing division, research and development department, standardization body, suppliers, verification and validation team, production system, regulator/certification authorities, etc.
 +
|-
 +
|Development
 +
|Acquirer, suppliers (technical domains for components realization), design engineers, integration team, etc.
 +
|-
 +
|Transfer for Production or for Use
 +
|Quality control, production system, operators, etc.
 +
|-
 +
|Logistics and Maintenance
 +
|Supply chain, support services, trainers, etc.
 +
|-
 +
|Operation
 +
|Normal users, unexpected users, etc.
 +
|-
 +
|Disposal
 +
|Operators, certifying body, etc.
 +
|}
 +
 
 +
=== '''Identifying Stakeholder Needs''' ===
 +
Once business management is satisfied that their needs and requirements are reasonably complete, they pass them on to the business operations team. Here, the Stakeholder Needs and Requirements (SNR) Definition Process uses the ConOps, or Strategic Business Plan (SBP), and the life-cycle concepts as guidance. The requirements engineer (RE) or business analyst (BA) leads stakeholders from the business operations layer through a structured process to elicit stakeholder needs—in the form of a refined OpsCon (or similar document) and other life-cycle concepts.  The RE or BA may use a fully or partially structured process to elicit specific needs, as described in models such as user stories, use cases, scenarios, system concepts, and operational concepts.  
  
Such figures provide a useful overview of the {{Term|Systems Engineering (glossary)|systems engineering}} (SE) community’s perspectives on what is required for implementation and what the general results of implementation may be. These are further supported by the discussion of implementation inputs, outputs, and activities found in the National Aeronautics and Space Association's (NASA's) ''Systems Engineering Handbook'' (NASA 2007). It is important to understand that these views are process-oriented. While this is a useful model, examining implementation only in terms of process can be limiting.  
+
=== '''Identifying Stakeholder Requirements''' ===
 +
Stakeholder needs are transformed into a formal set of stakeholder requirements, which are captured as models or documented as textual requirements in and output typically called a Stakeholder Requirement Specification (StRS), Stakeholder Requirement Document (StRD) or similar.  That transformation should be guided by a well‐defined, repeatable, rigorous, and documented process of requirements analysis. This requirements analysis may involve the use of functional flow diagrams, timeline analysis, N2 Diagrams, design reference missions, modeling and simulations, movies, pictures, states and modes analysis, fault tree analysis, failure modes and effects analysis, and trade studies.
  
Depending on the technologies and systems chosen when a decision is made to produce a system element, the implementation process outcomes may generate constraints to be applied on the architecture of the higher-level system; those constraints are normally identified as derived system requirements and added to the set of system requirements applicable to this higher-level system. The architectural design has to take those constraints into account.
+
=== '''Collecting Stakeholder Needs and Requirements''' ===
 +
There are many ways to collect stakeholder needs and requirements. It is recommended that several techniques or methods be considered during elicitation activities to better accommodate the diverse set of sources, including:
 +
* Structured brainstorming workshops
 +
* Interviews and questionnaires
 +
* Technical, operational, and/or strategy documentation review
 +
* Simulations and visualizations
 +
* Prototyping
 +
* Modeling
 +
* Feedback from [[System Verification|verification]] and [[System Validation|validation]] processes,
 +
* Review of the outcomes from the [[System Analysis|system analysis]] process (ISO/IEC 2015)
 +
* Quality function deployment (QFD) - can be used during the needs analysis and is a technique for deploying the "voice of the customer”. It provides a fast way to translate customer needs into requirements. (Hauser and Clausing 1988)
 +
* Use case diagrams (OMG 2010)
 +
* Activity diagrams (OMG 2010)
 +
* Functional flow block diagrams (Oliver, Kelliher, and Keegan 1997)
  
If the decision is made to purchase or reuse an existing system element, it has to be identified as a constraint or system requirement applicable to the architecture of the higher-level system. Conversely, the implementation process may involve some adaptation or adjustments to the system requirement in order to be integrated into a higher-level system or aggregate.  
+
=== From the Capture of Stakeholder Needs to the Definition of Stakeholder Requirements ===
 +
Several steps are necessary to understand the maturity of stakeholder needs and to understand how to improve upon that maturity. Figure 1 presents the ''cycle of needs ''as it can be deduced from Professor Shoji Shiba's and Professor Noriaki Kano's works and courses, and is adapted here for systems engineering (SE) purposes.
 +
[[File:SEBoKv05_KA-SystDef_Cycle_of_needs.png|centre|thumb|600x600px|
 +
'''Figure 1. Cycle of Needs (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.
 +
]]
 +
Figure 1 shows the steps and the position of the stakeholder requirements and system requirements in the engineering cycle. Below are explanations of each stage of requirements (Faisandier 2012); to illustrate this, consider this example of a system related to infectious disease identification:
 +
* '''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 something is lacking, that improvements could be made, or that there are business, investment, or market opportunities that are not being capitalized upon. Perceived needs are often presented as a list of organized expectations resulting from an analysis of the usage conditions for the considered action (see [[Business or Mission Analysis]]). 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 a solution or to make attaining 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 ''Systems and software engineering - Requirements engineering '' (ISO 2011). Characteristics of good requirements can be found in (ISO 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''', are the translation of the stakeholder needs to represent the views of the supplier, keeping in mind the potential, preferred, and feasible solutions. Specified needs are translated into system requirements. Consistent practice has shown this process requires {{Term|Iteration (glossary)|iterative}} and {{Term|Recursion (glossary)|recursive}} steps in parallel with other life cycle processes through the system design hierarchy (ISO 2011).
 +
* '''Realized needs '''are the product, service, or enterprise realized, taking into account every specified need (and hence, the retained needs).
 +
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).
  
Implementation also involves packaging, handling, and storage, depending on the concerned technologies and where or when the system requirement needs to be integrated into a higher-level aggregate. Developing the supporting documentation for a system requirement, such as the manuals for operation, maintenance, and/or installation, is also a part of the implementation process; these artifacts are utilized in the [[System Deployment and Use|system deployment and use]] phase. The system element requirements and the associated verification and validation criteria are inputs to this process; these inputs come from the {{Term|Architecting (glossary)|architectural design}} process detailed outputs.  
+
===Classification of Stakeholder Requirements===
 +
Several classifications of stakeholder requirements are possible, e.g. ISO/IEC 29148, section 9.4.2.3 (ISO 2011) provides a useful set of elements for classification. Examples of classification of stakeholder requirements include: service or functional, operational, interface, environmental, human factors, logistical, maintenance, design, production, verification requirements, validation, deployment, training, certification, retirement, regulatory, environmental, reliability, availability, maintainability, design, usability, quality, safety, and security requirements. Stakeholders will also be faced with a number of constraints, including: enterprise, business, project, design, realization, and process constraints.
  
Execution of the implementation process is governed by both industrial and government standards and the terms of all applicable agreements. This may include conditions for packaging and storage, as well as preparation for use activities, such as operator training. In addition, packaging, handling, storage, and transportation (PHS&T) considerations will constrain the implementation activities. For more information, refer to the discussion of PHS&T in the [[System Deployment and Use]] article. The developing or integrating organization will likely have enterprise-level safety practices and guidelines that must also be considered.
+
==Process Approach==
  
 
===Activities of the Process===
 
===Activities of the Process===
The following major activities and tasks are performed during this process:
+
Major activities and tasks performed during this process include the following:
 +
* Identify the stakeholders or classes of stakeholders across the life cycle.
 +
* Elicit, capture, or consolidate the stakeholder needs, expectations, and objectives as well as any constraints coming from the mission and business analysis processes.
 +
*Refine the OpsCon and other life-cycle concepts (acquisition concept, deployment concept, support concept, and retirement concept).
 +
*Prioritize the stakeholder needs.
 +
*Transform the prioritized and retained stakeholder needs into stakeholder requirements.
 +
* Verify the quality of each stakeholder requirement and of the set of stakeholder requirements using the characteristics of good requirements identified in the [[System Requirements]] article.
 +
* Validate the content and the relevance of each stakeholder requirement with corresponding stakeholder representatives providing {{Term|Rationale (glossary)|rationale (glossary)}} for the existence of the requirement.
 +
* Identify potential {{Term|Risk (glossary)|risks}} (or threats and hazards) that could be generated by the stakeholder requirements (for further information, see [[Risk Management]]).
 +
* Synthesize, record, and manage the stakeholder requirements and potential associated risks.
  
* '''Define the implementation strategy''' - Implementation process activities begin with detailed design and include developing an implementation strategy that defines fabrication and coding procedures, tools and equipment to be used, implementation tolerances, and the means and criteria for auditing configuration of resulting elements to the detailed design documentation. In the case of repeated system element implementations (such as for mass manufacturing or replacement elements), the implementation strategy is defined and refined to achieve consistent and repeatable element production; it is retained in the project decision database for future use. The implementation strategy contains the arrangements for packing, storing, and supplying the implemented element.
+
===Artifacts, Methods and Modeling Techniques===
* '''Realize the system element''' - Realize or adapt and produce the concerned system element using the implementation strategy items as defined above. Realization or adaptation is conducted with regard to standards that govern applicable safety, security, privacy, and environmental guidelines or legislation and the practices of the relevant implementation technology. This requires the fabrication of hardware elements, development of software elements, definition of training capabilities, drafting of training documentation, and the training of initial operators and maintainers.
 
* '''Provide evidence of compliance''' - Record evidence that the system element meets its requirements and the associated verification and validation criteria as well as the legislation policy. This requires the conduction of peer reviews and unit testing, as well as inspection of operation and maintenance manuals. Acquire measured properties that characterize the implemented element (weight, capacities, effectiveness, level of performance, reliability, availability, etc.).
 
* '''Package, store, and supply the implemented element''' - This should be defined in the implementation strategy.
 
  
===Artifacts and Ontology Elements===
+
This process may create several artifacts, such as:
This process may create several artifacts such as
+
* Recommendations to refine the Business Requirement Specification (if necessary)
* an implemented system
+
* Refined life-cycle concepts (OpsCon, acquisition concept, deployment concept, support concept, and retirement concept)
*implementation tools
+
* Stakeholder requirements (in the form of a model or a document containing textual requirements, such as the Stakeholder Requirement Specification)
* implementation procedures
+
* Stakeholder interview reports
* an implementation plan or strategy
+
* Stakeholder requirements database
* verification reports
+
* Stakeholder requirements justification documents (for traceability purposes)
* issue, anomaly, or trouble reports
+
* Input for draft verification and validation plans
* change requests (about design)
 
  
This process handles the ontology elements shown in Table 1 below.
+
The content, format, layout and ownership of these artifacts will vary depending on who is creating them and in which domains they will be used.  Between these artifacts and the outputs of the process, activities should cover the information identified in the first part of this article.
  
 +
==Practical Considerations==
 +
Major pitfalls encountered with stakeholder requirements are presented in Table 3.
 +
 +
<center>
 
{|
 
{|
|+'''Table 1. Main Ontology Elements as Handled within System Element Implementation.''' (SEBoK Original)
+
|+'''Table 3. Major Pitfalls for Stakeholder Requirements.''' (SEBoK Original)
!Element
+
!Pitfall
!Definition
+
!Description
----
+
|-
Attributes (examples)
+
|'''Operator Role Not Considered'''
 +
|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. As a consequence, elements are forgotten (e.g. roles of operators).
 +
|-
 +
|'''Exchanges with External Objects Forgotten'''
 +
|The exhaustiveness of requirements can be an issue; in particular, the interfaces with external objects of the context of the system can be forgotten (exchanges of matter, energy, information).
 
|-
 
|-
|'''Implemented Element'''
+
|'''Physical Connections with External Objects Forgotten'''
|An implemented element is a system element that has been implemented. In the case of hardware it is marked with a part/serial number.
+
|Within the interface issue, physical connections of the system-of-interest with external objects can be forgotten (technological constraints).
----
 
Identifier, name, description, type (hardware, software application, software piece, mechanical part, electric art, electronic component, operator role, procedure, protocol, manual, etc.)
 
 
|-
 
|-
|'''Measured Property'''
+
|'''Forgotten Stakeholders'''
|A measured property is a characteristic of the implemented element established after its implementation. The measured properties characterize the implemented system element when it is completely realized, verified, and validated. If the implemented element complies with a design property, the measured property should equal the design property. Otherwise one has to identify the difference or non-conformance which treatment could conclude to modify the design property and possibly the related requirements, or to modify (correct, repair) the implemented element, or to identify a deviation.
+
|Stakeholders can be forgotten, as everyone thinks of direct users, customers, and suppliers; however, one may fail to consider those who do not want the system to exist and malevolent persons.
----
 
Identifier, name, description, type (effectiveness, availability, reliability, maintainability, weight, capacity, etc.), value, unit, etc.
 
 
|}
 
|}
 +
</center>
  
The main relationships between ontology elements are presented in Figure 3.
 
  
[[File:SEBoKv05_KA-SystRealiz_Implementation_relationships.png|thumb|300px|center|'''Figure 3. Implementation Elements Relationships with Other Engineering Elements.''' (SEBoK Original)]]
+
Proven practices with stakeholder requirements are presented in Table 4.
  
===Methods, Techniques, and Tools===
+
<center>
There are many software tools available in the implementation and integration phases. The most basic method would be the use of N-squared diagrams as discussed in Jeff Grady’s book ''System Integration'' (Grady 1994).
+
{|
 +
|+'''Table 4. Stakeholder Requirements Proven Practices.''' (SEBoK Original)
 +
!Practice
 +
!Description
 +
|-
 +
|'''Involve Stakeholders'''
 +
|Involve the stakeholders early in the stakeholder requirements development process.
 +
|-
 +
|'''Presence of Rationale'''
 +
|Capture the rationale for each stakeholder requirement.
 +
|-
 +
|'''Analyze Sources before Starting'''
 +
|Complete stakeholder requirements as much as possible before starting the definition of the system requirements.
 +
|-
 +
|'''Modeling Techniques'''
 +
|Use modeling techniques as indicated in sections above.
 +
|-
 +
|'''Requirements Management Tool'''
 +
|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.
 +
|}
 +
</center>
 +
 
 +
==References==
 +
===Works Cited===
  
===Checking and Correctness of Implementation===
+
Faisandier, A. 2012. ''Systems Architecture and Design.'' Belberaud, France: Sinergy'Com.
Proper implementation checking and correctness should include testing to determine if the implemented element (i.e., piece of software, hardware, or other product) works in its intended use. Testing could include mockups and breadboards, as well as modeling and simulation of a prototype or completed pieces of a system. Once this is completed successfully, the next process would be [[System Integration|system integration]].
 
  
==References==
+
Hauser, J. and D. Clausing. 1988. "The House of Quality." ''Harvard Business Review.'' (May - June 1988).
  
===Works Cited===
+
OMG. 2010. ''OMG Systems Modeling Language specification'', version 1.2. Needham, MA: Object Management Group. July 2010.
DAU. February 19, 2010. ''Defense acquisition guidebook (DAG)''. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense.  
+
 
 +
Oliver, D., T. Kelliher, and J. Keegan. 1997. ''Engineering complex systems with models and objects''. New York, NY, USA: McGraw-Hill.
  
Grady, J.O. 1994. ''System integration.'' Boca Raton, FL, USA: CRC Press, Inc.
+
ISO/IEC/IEEE. 2011. ''Systems and software engineering - Requirements engineering.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), ISO/IEC/IEEE 29148.
  
NASA. 2007. ''Systems Engineering Handbook.'' Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.
+
ISO/IEC/IEEE. 2015. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering -- System Life Cycle Processes]]''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.
  
 
===Primary References===
 
===Primary References===
DAU. 2010. ''[[Defense Acquisition Guidebook (DAG)]]''. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense (DoD). February 19, 2010.
+
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 29148|Systems and software engineering - Requirements engineering]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), ISO/IEC/IEEE 29148.
  
Grady, J.O. 1994. ''[[System Integration (reference)|System Integration]]''. Boca Raton, FL, USA: CRC Press, Inc.
+
ISO/IEC/IEEE. 2015. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering -- System Life Cycle Processes]]''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.
  
ISO/IEC/IEEE. 2015. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288]]:2015.
+
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 42010|Systems and Software Engineering - Architecture Description]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), [[ISO/IEC/IEEE 42010]].
  
NASA. 2007. ''[[NASA Systems Engineering Handbook|Systems Engineering Handbook]].'' Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.
+
===Additional References===
 +
Buede, D.M. 2009. ''The engineering design of systems: Models and methods''. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc.  
  
===Additional References===
+
MITRE. 2011. "Requirements Engineering." ''Systems Engineering Guide.'' Accessed 9 March 2012 at http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/requirements_engineering/.
Faisandier, A. 2012. ''Systems Architecture and Design''. Belberaud, France: Sinergy'Com.
 
  
 +
MITRE. 2011. "Stakeholder Assessment and Management." ''Systems Engineering Guide.'' Accessed 9 March 2012 at http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/transformation_planning_org_change/stakeholder_assessment_management.html.
 
----
 
----
<center>[[System Realization|< Previous Article]] | [[System Realization|Parent Article]] | [[System Integration|Next Article >]]</center>
+
<center>[[Business or Mission Analysis|< Previous Article]] | [[Concept Definition|Parent Article]] | [[System Definition|Next Article >]]</center>
  
 
<center>'''SEBoK v. 2.0, released 1 June 2019'''</center>
 
<center>'''SEBoK v. 2.0, released 1 June 2019'''</center>
  
[[Category: Part 3]][[Category:Topic]]
+
[[Category:Concept Definition]]
[[Category:System Realization]]
 

Revision as of 03:26, 19 October 2019

Stakeholder needs and requirementsStakeholder needs and requirements represent the views of those at the business or enterprise operations level—that is, of usersusers, acquirersacquirers, customerscustomers, and other stakeholdersstakeholders as they relate to the problem (or opportunity), as a set of requirements for a solution that can provide the services needed by the stakeholders in a defined environment. Using enterprise-level life cycle concepts (see Business or Mission Analysis for details) as guidance, stakeholders are led through a structured process to elicit stakeholder needs (in the form of a refined set of system-level life-cycle concepts). Stakeholder needs are transformed into a defined set of Stakeholder Requirements, which may be documented in the form of a model, a document containing textual requirement statements or both.

Stakeholder requirements play major roles in systems engineering, as they:

  • Form the basis of system requirementssystem requirements activities.
  • Form the basis of system validationvalidation and stakeholder acceptance .
  • Act as a reference for integrationintegration and verificationverification activities.
  • Serve as means of communication between the technical staff, management, finance department, and the stakeholder community.

This topic describes the definition of stakeholder needs and requirements which involves the activities necessary to elicit and prioritize the needs of the stakeholder(s), and transform those needs into a set of defined stakeholder requirements. Defining the problem or the issue to be solved, identifying the opportunity for developing a new solution, or improving a system-of-interest (SoI)system-of-interest (SoI) must begin prior to starting the activities necessary to define stakeholder needs and requirements. This means that an initial context of use of the new or modified mission, operation, or capability has already been characterized (see Business or Mission Analysis). System requirements are considered in detail during system definitionsystem definition. None of the above can be considered complete until consistency between the two has been achieved, as demonstrated by traceabilitytraceability, for which a number of iterations may be needed.

Purpose and Definition

The purpose of the Stakeholder Needs and Requirements definition activities are to elicit a set of clear and concise 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 stakeholder needs into verifiable stakeholder requirements.

Stakeholders may well begin with desires, and expectations that may contain vague, ambiguous statements that are difficult to use for SE activities. Care must be taken to ensure that those desires and expectations are coalesced into a set of clear and concise need statements that are useful as a start point for system definition. These need statements will then need to be further clarified and translated into more engineering-oriented language in a set of stakeholder requirements to enable proper architecture definition and requirement activities. As an example, a need or an expectation such as, to easily manoeuvre a car in order to park, will be transformed in a set of stakeholder requirementsstakeholder requirements to a statement such as, increase the driviability of the car, decrease the effort for handling, assist the piloting, protect the coachwork against shocks or scratches, etc.

To allow a clear description of the activities of stakeholder needs and requirements to be described, a generic view of the business teams and roles involved in a typical enterprise has been used below., tThis includes teams such as business management and business operations;, and roles including requirements engineer and business analyst. For an overview of these roles and how they enable both stakeholder and business requirements across the layers of a typical enterprise see Life Cycle Processes and Enterprise Need.

Principles and Concepts

Identifying Stakeholders

Stakeholders of a SoI may vary throughout the life cyclelife 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 modellife cycle model when identifying the stakeholders or classes of stakeholders.

Every system has its own stages of life, which typically include stages such as 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 must be 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. Examples of stakeholders are provided in Table 1.

Table 1. Stakeholder Identification Based on Life Cycle Stages. (SEBoK Original)
Life Cycle Stage Example of Related Stakeholders
Engineering Acquirer, panel of potential users, marketing division, research and development department, standardization body, suppliers, verification and validation team, production system, regulator/certification authorities, etc.
Development Acquirer, suppliers (technical domains for components realization), design engineers, integration team, etc.
Transfer for Production or for Use Quality control, production system, operators, etc.
Logistics and Maintenance Supply chain, support services, trainers, etc.
Operation Normal users, unexpected users, etc.
Disposal Operators, certifying body, etc.

Identifying Stakeholder Needs

Once business management is satisfied that their needs and requirements are reasonably complete, they pass them on to the business operations team. Here, the Stakeholder Needs and Requirements (SNR) Definition Process uses the ConOps, or Strategic Business Plan (SBP), and the life-cycle concepts as guidance. The requirements engineer (RE) or business analyst (BA) leads stakeholders from the business operations layer through a structured process to elicit stakeholder needs—in the form of a refined OpsCon (or similar document) and other life-cycle concepts. The RE or BA may use a fully or partially structured process to elicit specific needs, as described in models such as user stories, use cases, scenarios, system concepts, and operational concepts.

Identifying Stakeholder Requirements

Stakeholder needs are transformed into a formal set of stakeholder requirements, which are captured as models or documented as textual requirements in and output typically called a Stakeholder Requirement Specification (StRS), Stakeholder Requirement Document (StRD) or similar. That transformation should be guided by a well‐defined, repeatable, rigorous, and documented process of requirements analysis. This requirements analysis may involve the use of functional flow diagrams, timeline analysis, N2 Diagrams, design reference missions, modeling and simulations, movies, pictures, states and modes analysis, fault tree analysis, failure modes and effects analysis, and trade studies.

Collecting Stakeholder Needs and Requirements

There are many ways to collect stakeholder needs and requirements. It is recommended that several techniques or methods be considered during elicitation activities to better accommodate the diverse set of sources, including:

  • Structured brainstorming workshops
  • Interviews and questionnaires
  • Technical, operational, and/or strategy documentation review
  • Simulations and visualizations
  • Prototyping
  • Modeling
  • Feedback from verification and validation processes,
  • Review of the outcomes from the system analysis process (ISO/IEC 2015)
  • Quality function deployment (QFD) - can be used during the needs analysis and is a technique for deploying the "voice of the customer”. It provides a fast way to translate customer needs into requirements. (Hauser and Clausing 1988)
  • Use case diagrams (OMG 2010)
  • Activity diagrams (OMG 2010)
  • Functional flow block diagrams (Oliver, Kelliher, and Keegan 1997)

From the Capture of Stakeholder Needs to the Definition of Stakeholder Requirements

Several steps are necessary to understand the maturity of stakeholder needs and to understand how to improve upon that maturity. Figure 1 presents the cycle of needs as it can be deduced from Professor Shoji Shiba's and Professor Noriaki Kano's works and courses, and is adapted here for systems engineering (SE) purposes.

Figure 1. Cycle of Needs (Faisandier 2012). Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.

Figure 1 shows the steps and the position of the stakeholder requirements and system requirements in the engineering cycle. Below are explanations of each stage of requirements (Faisandier 2012); to illustrate this, consider this example of a system related to infectious disease identification:

  • 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 something is lacking, that improvements could be made, or that there are business, investment, or market opportunities that are not being capitalized upon. Perceived needs are often presented as a list of organized expectations resulting from an analysis of the usage conditions for the considered action (see Business or Mission Analysis). 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 a solution or to make attaining 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 Systems and software engineering - Requirements engineering (ISO 2011). Characteristics of good requirements can be found in (ISO 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, are the translation of the stakeholder needs to represent the views of the supplier, keeping in mind the potential, preferred, and feasible solutions. Specified needs are translated into system requirements. Consistent practice has shown this process requires iterativeiterative and recursiverecursive steps in parallel with other life cycle processes through the system design hierarchy (ISO 2011).
  • Realized needs are the product, service, or enterprise realized, taking into account every specified need (and hence, the retained needs).

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).

Classification of Stakeholder Requirements

Several classifications of stakeholder requirements are possible, e.g. ISO/IEC 29148, section 9.4.2.3 (ISO 2011) provides a useful set of elements for classification. Examples of classification of stakeholder requirements include: service or functional, operational, interface, environmental, human factors, logistical, maintenance, design, production, verification requirements, validation, deployment, training, certification, retirement, regulatory, environmental, reliability, availability, maintainability, design, usability, quality, safety, and security requirements. Stakeholders will also be faced with a number of constraints, including: enterprise, business, project, design, realization, and process constraints.

Process Approach

Activities of the Process

Major activities and tasks performed during this process include the following:

  • Identify the stakeholders or classes of stakeholders across the life cycle.
  • Elicit, capture, or consolidate the stakeholder needs, expectations, and objectives as well as any constraints coming from the mission and business analysis processes.
  • Refine the OpsCon and other life-cycle concepts (acquisition concept, deployment concept, support concept, and retirement concept).
  • Prioritize the stakeholder needs.
  • Transform the prioritized and retained stakeholder needs into stakeholder requirements.
  • Verify the quality of each stakeholder requirement and of the set of stakeholder requirements using the characteristics of good requirements identified in the System Requirements article.
  • Validate the content and the relevance of each stakeholder requirement with corresponding stakeholder representatives providing rationale (glossary)rationale (glossary) for the existence of the requirement.
  • Identify potential risksrisks (or threats and hazards) that could be generated by the stakeholder requirements (for further information, see Risk Management).
  • Synthesize, record, and manage the stakeholder requirements and potential associated risks.

Artifacts, Methods and Modeling Techniques

This process may create several artifacts, such as:

  • Recommendations to refine the Business Requirement Specification (if necessary)
  • Refined life-cycle concepts (OpsCon, acquisition concept, deployment concept, support concept, and retirement concept)
  • Stakeholder requirements (in the form of a model or a document containing textual requirements, such as the Stakeholder Requirement Specification)
  • Stakeholder interview reports
  • Stakeholder requirements database
  • Stakeholder requirements justification documents (for traceability purposes)
  • Input for draft verification and validation plans

The content, format, layout and ownership of these artifacts will vary depending on who is creating them and in which domains they will be used. Between these artifacts and the outputs of the process, activities should cover the information identified in the first part of this article.

Practical Considerations

Major pitfalls encountered with stakeholder requirements are presented in Table 3.

Table 3. Major Pitfalls for Stakeholder Requirements. (SEBoK Original)
Pitfall Description
Operator Role Not Considered 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. As a consequence, elements are forgotten (e.g. roles of operators).
Exchanges with External Objects Forgotten The exhaustiveness of requirements can be an issue; in particular, the interfaces with external objects of the context of the system can be forgotten (exchanges of matter, energy, information).
Physical Connections with External Objects Forgotten Within the interface issue, physical connections of the system-of-interest with external objects can be forgotten (technological constraints).
Forgotten Stakeholders Stakeholders can be forgotten, as everyone thinks of direct users, customers, and suppliers; however, one may fail to consider those who do not want the system to exist and malevolent persons.


Proven practices with stakeholder requirements are presented in Table 4.

Table 4. Stakeholder Requirements Proven Practices. (SEBoK Original)
Practice Description
Involve Stakeholders Involve the stakeholders early in the stakeholder requirements development process.
Presence of Rationale Capture the rationale for each stakeholder requirement.
Analyze Sources before Starting Complete stakeholder requirements as much as possible before starting the definition of the system requirements.
Modeling Techniques Use modeling techniques as indicated in sections above.
Requirements Management Tool 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.

References

Works Cited

Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.

Hauser, J. and D. Clausing. 1988. "The House of Quality." Harvard Business Review. (May - June 1988).

OMG. 2010. OMG Systems Modeling Language specification, version 1.2. Needham, MA: Object Management Group. July 2010.

Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering complex systems with models and objects. New York, NY, USA: McGraw-Hill.

ISO/IEC/IEEE. 2011. Systems and software engineering - Requirements engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), ISO/IEC/IEEE 29148.

ISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.

Primary References

ISO/IEC/IEEE. 2011. Systems and software engineering - Requirements engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), ISO/IEC/IEEE 29148.

ISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.

ISO/IEC/IEEE. 2011. Systems and Software Engineering - Architecture Description. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 42010.

Additional References

Buede, D.M. 2009. The engineering design of systems: Models and methods. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc.

MITRE. 2011. "Requirements Engineering." Systems Engineering Guide. Accessed 9 March 2012 at http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/requirements_engineering/.

MITRE. 2011. "Stakeholder Assessment and Management." Systems Engineering Guide. Accessed 9 March 2012 at http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/transformation_planning_org_change/stakeholder_assessment_management.html.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.0, released 1 June 2019