|
|
Line 1: |
Line 1: |
− | [[Stakeholder Requirement (glossary)|Stakeholder requirements]] represent the views of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], and [[Customer (glossary)|customers]] regarding the problem (or opportunity), through a set of requirements for a solution that can provide the services needed by the [[Stakeholder (glossary)|stakeholders]] in a defined environment. Stakeholder Requirements describe the overall objectives of the system, its principal stakeholders, its context of use, the specific needs which should be satisfied and how success will be assessed.
| + | {{Term|Concept (glossary)|Concept}} Definition is the set of systems engineering (SE) activities in which the problem space and the needs and requirements of the business or enterprise and {{Term|Stakeholder (glossary)|stakeholders}} are closely examined. The activities are grouped and described as generic processes which include Mission Analysis and Stakeholder Needs and Requirements. Concept Definition begins before any formal definition of the {{Term|System-of-Interest (glossary)|system-of-interest}} (SoI) is developed. |
| | | |
− | Stakeholder requirements play major roles in the Systems Engineering, they
| + | {{Term|Mission Analysis (glossary)|Mission Analysis}} focuses on the needs and requirements of business or enterprise — that is, on defining the problem or opportunity that exists (in what is often called the problem space or problem situation), as well as understanding the constraints on and boundaries of the selected system when it is fielded (in what is often called the solution space). The {{Term|Stakeholder Requirement (glossary)|Stakeholder Needs and Requirements}} process explores and defines the operational aspects of a potential solution for the stakeholders from their point of view, independent of any specific solution. In these two Concept Definition activities, business or enterprise decision makers and other stakeholders describe ''what'' a solution should accomplish and ''why'' it is needed. Both ''why'' and ''what'' need to be answered before consideration is given to ''how'' the problem will be addressed (i.e., what type of solution will be implemented) and ''how'' the solution will be defined and developed. |
− | *form the basis of [[System Requirement (glossary)|system requirements]] activities;
| |
− | *form the basis of system [[Validation (glossary)|validation]] and stakeholder acceptance ;
| |
− | *are a reference for [[Integration (glossary)]] and [[Verification (glossary)|verification]] activities; and
| |
− | *a means of communication between the technical staff, management and finance and the stakeholder community.
| |
| | | |
− | This topic provides knowledge about the idea of stakeholder needs and requirements; the activities necessary to elicit and prioritize the needs of the stakeholder(s); and transforming those needs into stakeholder requirements. The definition of the set of stakeholder requirements is the primary outcome of these activities which start in [[Concept Definition]]. The definition of the problem or the issue to be solved and/or the opportunity for developing a new solution or improving a system-of-interest (SoI) 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 the [[Mission Analysis]] topic). System Requirements are considered in detail during [[System Definition (glossary)]]. None of the above can be considered complete until consistency between the two has been achieved, as demonstrated by Traceability, for which a number of iterations may be needed.
| + | If a new or modified system is needed, then {{Term|System Definition (glossary)|System Definition}} activities are performed to assess the system. See [[Life Cycle Processes and Enterprise Need]] for further detail on the transformation of needs and requirements from the business or enterprise and stakeholder levels of abstraction addressed in Concept Definition to the system and system element level of abstraction addressed in System Definition. |
| | | |
| + | The specific activities and sequence of Concept Definition activities and their involvement with the life cycle activities of any system, and in particular the close integration with System Definition activities, will be dependent upon the type of {{Term|Life Cycle Model (glossary)|life cycle model}} being utilized. See [[Applying Life Cycle Processes]] for further discussion of the concurrent, iterative and recursive nature of these relationships. |
| | | |
− | ==Purpose and Definition== | + | ==Topics== |
− | The purpose of defining stakeholder requirements is to elicit a set of needs related to a new or changed mission for an enterprise (see [[Mission Analysis]] (MA) for information relevant to identifying and defining the mission or operation), and to transform these needs into clear, concise, and verifiable stakeholder requirements.
| + | Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: |
− |
| + | *[[Business or Mission Analysis]] |
− | Stakeholder needs analysis is the elicitation, communication, [[Validation (glossary)|validation (glossary)]] and refinement of the needs and objectives of the enterprise or set of stakeholders. Stakeholder needs analysis is aimed at understanding a potential capability (often identified through MA) that is needed to address an identified problem or opportunity. After defining the stakeholder needs and requirements, they interact with the MA to transform the defined set of needs into stakeholder requirements (also known as mission requirements) that reflect these needs.
| + | *[[Stakeholder Needs and Requirements]] |
| + | See the article [[Matrix of Implementation Examples]] for a mapping of case studies and vignettes included in Part 7 as well as topics covered in Part 3. |
| | | |
− | ==Principles and Concepts== | + | ==Concept Definition Activities== |
| + | There are two primary activities discussed under concept definition: {{Term|Mission Analysis (glossary)|Mission Analysis}} and the definition of {{Term|Stakeholder Requirement (glossary)|Stakeholder Needs and Requirements}}: |
| | | |
− | ===From the Capture of Needs to the Definition of Stakeholder Requirements===
| + | # [[Business or Mission Analysis|Mission Analysis]] begins an iteration of the life cycle of a potential SoI that could solve a problem or realize an opportunity for developing a new product, service, or enterprise. These activities assist business or enterprise decision makers to define the problem space, identify the stakeholders, develop preliminary operational concepts, and distinguish environmental conditions and constraints that bound the solution space. In other words, mission analysis takes the enterprise capability gap or opportunity and defines the problem/opportunity in a manner that provides a common understanding encapsulated in what are referred to as “business or mission needs.” Business or mission needs are then used to produce a clear, concise, and verifiable set of business 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.
| + | #The [[Stakeholder Needs and Requirements]] activity works with stakeholders across the life cycle to elicit and capture a set of needs, expectations, goals, or objectives for a desired solution to the problem or opportunity, referred to as "stakeholder needs". The stakeholder needs are used to produce a clear, concise, and verifiable set of stakeholder requirements. Stakeholder needs and requirements identify and define the needs and requirements of the stakeholders in a manner that enables the characterization of the solution alternatives. |
| | | |
− | [[File:SEBoKv05_KA-SystDef_Cycle_of_needs.png|600px|thumb|center| '''Figure 1. Cycle of Needs (Faisandier 2012).''' Permission granted by Singery'Com. All other rights are reserved by the copyright owner.]]
| + | Mission Analysis takes the business and stakeholders' needs and requirements and carries the analysis down from problem space to solution space, including concept, mission, and boundary or context so that a solution concept (at the black-box level) can be selected from the alternatives. Figure 1 in the [[Business or Mission Analysis|Mission Analysis]] topic depicts this interaction. The products and artifacts produced during Concept Definition are then used in {{Term|System Definition (glossary)|System Definition}}. |
| | | |
− | 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, an example of a system related to infectious disease identification is provided:
| + | The different aspects of how {{Term|Systems Thinking (glossary)|systems thinking}} is applicable to concept definition are discussed in SEBoK Part 2. In particular, the use of a combination of {{Term|Hard System (glossary)|hard system}} and {{Term|Soft System (glossary)|soft system}} approaches depending on the type of problem or class of solution is discussed in [[Identifying and Understanding Problems and Opportunities]] and the contrast between top-down and bottom-up approaches in [[Synthesizing Possible Solutions]]. |
| | | |
− | *'''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.
| + | ==Drivers of Solution on Problem Definition: Push Versus Pull== |
− | *'''Perceived needs''' are based on a person’s awareness that something is wrong, that there is a lack of something, that there is something that could improve a situation, or that there are business, investment, or market opportunities. Perceived needs are often presented as a list of organized expectations resulting from an analysis of the usage conditions for the considered action (see the [[Mission Analysis]] topic). Following from the infectious disease example above, the real need might be perceived as a need to ''carry out medical tests in particular circumstances (laboratories, points of care, hospitals, and/or human dispensaries).'' Since the real need is seldom clearly expressed, richness of the knowledge of the perceived needs is used as a basis for potential solutions. This step has to be as complete as possible to cover all the contexts of use.
| |
− | *'''Expressed needs''' originate from perceived needs in the form of generic actions or constraints, and are typically prioritized. In the example, if safety is the primary concern, the expressed need to ''protect the operator against contamination'' may take priority over other expressed needs such as ''assist in the execution of tests.'' When determining the expressed needs, the analysis of the expected mission or services in terms of operational scenarios takes place.
| |
− | *'''Retained needs''' are selected from the expressed needs. The selection process uses the prioritization of expressed needs to achieve something or make solutions feasible. The retained needs allow the consideration of potential solutions for a SoI. These retained ''stakeholder intentions do not serve as stakeholder requirements, since they often lack definition, analysis, and possibly consistency and feasibility. Using the concept of operations to aid the understanding of the stakeholder intentions at the organizational level and the system operational concept from the system perspective, requirements engineering leads stakeholders from those initial intentions to structured and more formal stakeholder requirement statements'' (ISO/IEC/IEEE 29148 2011). Characteristics of good requirements can be found in ISO/IEC/IEEE 29148 (2011). Exploration of potential solutions must start from this step. The various solutions suggested at this step are not yet products, but describe means of satisfying the stakeholder requirements. Each potential solution imposes constraints on the potential future SoI.
| |
− | *'''Specified needs''', generally called [[System Requirement (glossary) |system requirements (glossary)]], are the translation of the stakeholder requirements to represent the views of the supplier, keeping in mind the potential, preferred, and feasible solutions. Consistent practice has shown this process requires [[Iteration (glossary)|iterative]] and [[Recursion (glossary)|recursive]] steps in parallel with other life cycle processes through the system design hierarchy. (ISO/IEC/IEEE 29148 2011).
| |
− | *'''Realized needs''' are the product, service or enterprise realized, taking into account every system requirement (and hence, the stakeholder requirement(s)).
| |
| | | |
− | Each class of needs listed above aligns with an area of the SE process. For example, the development of ''specified needs'' requirements is discussed in the [[System Requirements]] topic. For more information on how requirements are used in the systems engineering process, please see the [[System Definition]] knowledge area (KA).
| + | Problem definition and solution design depend on each other. Solutions should be developed to respond appropriately to well-defined problems. Problem definitions should be constrained to what is feasible in the solution space. {{Term|System Analysis (glossary)|System Analysis}} activities are used to provide the link between problems and solutions. |
| | | |
− | ===Identifying Stakeholders and their Requirements===
| + | There are two paradigms that drive the ways in which concept definition is done: ''push'' and ''pull''. The ''pull'' paradigm is based on providing a solution to an identified problem or gap, such as a missing mission capability for defense or infrastructure. The ''push'' paradigm is based on creating a solution to address a perceived opportunity, such as the emergence of an anticipated product or service that is attractive to some portion of the population (i.e. whether a current market exists or not). This can impact other life cycle processes, such as in verification and validation, or alpha/beta testing as done in some commercial domains. |
− | Stakeholders of a SoI may vary throughout the [[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 life cycle when identifying the stakeholders or classes of stakeholders.
| |
| | | |
− | Every system has its own stages of life; these may include concept, development, production, operations, sustainment, and retirement (for more information, please see [[Life Cycle Models]]). For each stage, a list of all stakeholders having an interest in the future system is identified. The goal is to get every stakeholder’s point of view for every stage of the system life in order to consolidate a complete set of stakeholder needs that can be prioritized and transformed into the set of stakeholder requirements as exhaustively as possible. Examples of stakeholders are provided in Table 1.
| + | As systems generally integrate existing and new {{Term|System Element (glossary)|system elements}} in a mixture of push and pull, it is often best to combine a bottom-up approach with a top-down approach to take into account legacy elements, as well as to identify the services and capabilities that must be provided in order to define applicable interface requirements and constraints. This is discussed in [[Applying Life Cycle Processes]]. |
| | | |
− | <center>
| + | ==References== |
− | {|
| |
− | |+'''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.
| |
− | |}
| |
− | </center>
| |
| | | |
| + | ===Works Cited=== |
| + | None. |
| | | |
− | There are many ways to collect stakeholder needs, expectations, and objectives. Some of the most common techniques are interviews (including user surveys); technical, operational, and strategy document reviews; analysis of potential hazards and threats coming from the context of use of the system; feedback from [[System Verification|verification]] and [[System Validation|validation]] processes; and review of the outcomes from the [[System Analysis|system analysis]] process (ISO/IEC 2008). Stakeholder requirements are developed from these needs.
| + | ===Primary References=== |
| + | ANSI/EIA. 1998. ''[[ANSI/EIA 632|Processes for Engineering a System]]''. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA 632-1998. |
| | | |
− | ===Classification of Stakeholder Requirements===
| + | INCOSE. 2015. '[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0. |
− | 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 categories indicated in Table 2.
| |
| | | |
− | <center>
| + | 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. |
− | {|
| |
− | |+'''Table 2. Example of Stakeholder Requirements Classification.''' (SEBoK Original)
| |
− | !Type of Stakeholder Requirement
| |
− | !Description
| |
− | |-
| |
− | |'''Service or Functional'''
| |
− | |Sets of actions to perform the mission or operation of the system-of-interest; enhanced by effectiveness or performance characteristics attached to the mission or operations.
| |
− | |-
| |
− | |'''Operational'''
| |
− | |This category may include:
| |
− | *Operational concept that indicates the operational features to be provided without specifying design solutions;
| |
− | *Operational scenarios describing the sequence or series of activities supported by the system-of-interest;
| |
− | *Operational modes and transitions of modes between states/modes of the system-of-interest during its utilization to include dynamic interactions between the system-of-interest (viewed as a black box) and the system-of-interest's interface with external components in the context of its use.
| |
− | |-
| |
− | |'''Interface'''
| |
− | |Matter, energy, or information flows exchanged between the system-of-interest and its external components in the context of its use, including physical interfaces. | |
− | |-
| |
− | |'''Environmental'''
| |
− | |External conditions affecting the system when in operation.
| |
− | |-
| |
− | |'''Utilization Characteristics'''
| |
− | |The '-ilities' used to indicate conditions of the utilization of the system-of-interest (e.g. usability, dependability, security, etc.)
| |
− | |-
| |
− | |'''Human Factors'''
| |
− | |Capabilities of users and operators, ergonomics, and associated constraints.
| |
− | |-
| |
− | |'''Logistical'''
| |
− | |Acquisition, transportation, and storage of elements needed by the system-of-interest to perform its services (e.g. constraints for logistical support).
| |
− | |-
| |
− | |'''Design and Realization Constraints'''
| |
− | |Re-use of existing system elements or forbidden materials, for example.
| |
− | |-
| |
− | |'''Process Constraints'''
| |
− | |These are stakeholder (usually acquirer or user) requirements imposed through the contract or statement of work. These requirements do not directly address the end-item system, but rather ''how'' the end-item system is developed and provided. Process requirements include compliance with national, state, or local laws, including environmental laws; administrative requirements; acquirer/supplier relationship requirements; and specific work directives. Process requirements may also be imposed on a program by corporate policy or practice. System or system element implementation process requirements, such as mandating a particular design method, are usually captured in project agreement documentation such as contracts, statements of work (SOW), and quality plans.
| |
− | |-
| |
− | |'''Project Constraints'''
| |
− | |Constraints to performing the project and/or the end-item system within cost and schedule.
| |
− | |-
| |
− | |'''Business Model Constraints'''
| |
− | |Constraints related to the expected business goal achieved by the system-of-interest, when this is relevant within the context of use; these may include geographic position (local, national, international) of the future product, service, or organization resulting from the system-of-interest, distribution channels, alliance and partnership, finance and revenue model etc.
| |
− | |}
| |
− | </center>
| |
| | | |
− | ==Process Approach==
| + | 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]]. |
| | | |
− | ===Activities of the Process=== | + | ===Additional References=== |
− | Major activities and tasks performed during this process include the following:
| + | Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley & Sons. |
− | *Identify the stakeholders or classes of stakeholders across the life cycle;
| |
− | *Elicit, capture, or consolidate the stakeholders' needs, expectations, and objectives as well as any constraints coming from the mission and business analysis processes;
| |
− | *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 Tables 4 and 5 in [[System Requirements]];
| |
− | *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 [[Risk (glossary) |risks]] (or threats and hazards) that could be generated by the stakeholder requirements (for further information, see [[Risk Management]]); and
| |
− | *Synthesize, record, and manage the stakeholder requirements and potential associated risks.
| |
− | | |
− | ===Artifacts and Ontology Elements===
| |
− | This process may create several artifacts, such as
| |
− | *stakeholder requirements documents;
| |
− | *stakeholder interview reports;
| |
− | *stakeholder requirements database; and
| |
− | *stakeholder requirements justification documents (for traceability purposes).
| |
− | | |
− | This process utilizes the ontology elements of Table 3.
| |
− | | |
− | <center>
| |
− | {|
| |
− | |+'''Table 3. Main Ontology Elements as Handled within Stakeholder Requirements Definition.''' (SEBoK Original)
| |
− | !Element
| |
− | !Definition Attributes (examples)
| |
− | |-
| |
− | |'''Stakeholder'''
| |
− | |Party having a right, share, or claim in a system or in its possession of characteristics that meets that party's needs and expectations (ISO/IEC 2008). N.B.: Stakeholders include, but are not limited to, end users, end user organizations, supporters, developers, producers, trainers, maintainers, disposers, acquirers, customers, operators, supplier organizations, and regulatory bodies. (ISO/IEC 2011)
| |
− | ----
| |
− | Identifier; name; description; status (identified, interviewed)
| |
− | |-
| |
− | |'''Stakeholder Requirement'''
| |
− | |Necessity or desire expected by an end user, formally drafted and expressed in terms of a client and end user; service, objective, capability expected from the future system by the end users. Equivalent to expectation; includes user requirements.
| |
− | ----
| |
− | Identifier; name; description; origin (the owner of the expression of the stakeholder requirement); type (classification); flexibility (possibilities for negotiation - possibly supplemented with a margin rate); priority (immediately satisfied, allocated to a later version, etc.); decision (result of a trade-off study having led to choosing or rejecting the requirement); status (proposed, in review, validated, deleted, etc.); history records (date, author, identification, and contents of the modification, type of modification, reason for the modification); comment.
| |
− | |-
| |
− | |'''Rationale'''
| |
− | |Argument that provides the justification for the selection of an engineering element.
| |
− | ----
| |
− | Identifier; name; description (rational, reasons for a requirement to be satisfied)
| |
− | |-
| |
− | |'''Scenario'''
| |
− | |A set of actions/functions representing the dynamic of exchanges between the functions allowing the system to achieve a mission or a service.
| |
− | ----
| |
− | Identifier; name; description
| |
− | |-
| |
− | |'''Risk'''
| |
− | |An event having a probability of occurrence and a gravity degree on its consequence onto the system mission or on other properties (used for technical risk in engineering). A risk is the combination of vulnerability and of a danger or a threat.
| |
− | ----
| |
− | Identifier; name; description; status
| |
− | |}
| |
− | </center>
| |
| | | |
− | ===Methods and Modeling Techniques===
| + | ''ISO/IEC. 2003. Systems Engineering – A Guide for The Application of ISO/IEC 15288 System Life Cycle Processes''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E). http://www.hitchins.net/EmergenceEtc.pdf. |
− | It is recommended that several techniques or methods for identifying needs, expectations, and requirements be considered during the elicitation activity to better accommodate the diverse set of requirements sources, including
| |
− | *structured brainstorming workshops;
| |
− | *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 and is a technique for deploying the "voice of the customer”. It provides a fast way to translate customer needs into requirements;
| |
− | *use case diagrams (OMG 2010);
| |
− | *activity diagrams (OMG 2010); and
| |
− | *functional flow block diagrams.
| |
| | | |
− | ==Practical Considerations==
| + | ISO/IEC. 2007. ''Systems Engineering – Application and Management of The Systems Engineering Process''. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 26702:2007. |
− | Major pitfalls encountered with stakeholder requirements are presented in Table 4.
| |
| | | |
− | <center>
| + | Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight.'' (April 2010): 41-43. |
− | {|
| |
− | |+'''Table 4. 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. In consequence, elements are forgotten (e.g. roles of operators).
| |
− | |-
| |
− | |'''Exchanges with external objects forgotten'''
| |
− | |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).
| |
− | |-
| |
− | |'''Physical connections with external objects forgotten'''
| |
− | |Within the interface issue, physical connections of the stem-of-interest with external objects can be forgotten (technological constraints).
| |
− | |-
| |
− | |'''Forgotten stakeholders'''
| |
− | |Stakeholders can be forgotten; everyone thinks of direct users, customers, and suppliers, but those who do not want the system to exist and malevolent persons are often left out.
| |
− | |}
| |
− | </center>
| |
| | | |
| + | NASA. 2007. ''Systems Engineering Handbook''. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105. |
| | | |
− | Proven practices with stakeholder requirements are presented in Table 5.
| + | ---- |
− | | + | <center>[[Lean Engineering|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[Business or Mission Analysis|Next Article >]]</center> |
− | <center>
| |
− | {|
| |
− | |+'''Table 5. 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 for 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===
| |
− | Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.
| |
− | | |
− | OMG. 2010. ''OMG Systems Modeling Language specification'', version 1.2, July 2010. http://www.omg.org/technology/documents/spec_catalog.htm.
| |
− | | |
− | 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. 2008. ''Systems and Software Engineering - System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).
| |
− | | |
− | ===Primary References===
| |
− | 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.
| |
− | | |
− | ISO/IEC/IEEE. 2008. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288]]:2008 (E).
| |
− | | |
− | 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]].
| |
| | | |
− | ===Additional References===
| + | <center>'''SEBoK v. 2.0, released 1 June 2019'''</center> |
− | 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]].
| |
− | ----
| |
− | <center>[[Mission Analysis|< Previous Article]] | [[Concept Definition|Parent Article]] | [[System Definition|Next Article >]]</center>
| |
| | | |
− | [[Category:Concept Definition]] | + | [[Category:Part 3]][[Category:Knowledge Area]] |
− | {{DISQUS}}
| |
ConceptConcept Definition is the set of systems engineering (SE) activities in which the problem space and the needs and requirements of the business or enterprise and stakeholdersstakeholders are closely examined. The activities are grouped and described as generic processes which include Mission Analysis and Stakeholder Needs and Requirements. Concept Definition begins before any formal definition of the system-of-interestsystem-of-interest (SoI) is developed.
Mission AnalysisMission Analysis focuses on the needs and requirements of business or enterprise — that is, on defining the problem or opportunity that exists (in what is often called the problem space or problem situation), as well as understanding the constraints on and boundaries of the selected system when it is fielded (in what is often called the solution space). The Stakeholder Needs and RequirementsStakeholder Needs and Requirements process explores and defines the operational aspects of a potential solution for the stakeholders from their point of view, independent of any specific solution. In these two Concept Definition activities, business or enterprise decision makers and other stakeholders describe what a solution should accomplish and why it is needed. Both why and what need to be answered before consideration is given to how the problem will be addressed (i.e., what type of solution will be implemented) and how the solution will be defined and developed.
If a new or modified system is needed, then System DefinitionSystem Definition activities are performed to assess the system. See Life Cycle Processes and Enterprise Need for further detail on the transformation of needs and requirements from the business or enterprise and stakeholder levels of abstraction addressed in Concept Definition to the system and system element level of abstraction addressed in System Definition.
The specific activities and sequence of Concept Definition activities and their involvement with the life cycle activities of any system, and in particular the close integration with System Definition activities, will be dependent upon the type of life cycle modellife cycle model being utilized. See Applying Life Cycle Processes for further discussion of the concurrent, iterative and recursive nature of these relationships.
Topics
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics:
See the article Matrix of Implementation Examples for a mapping of case studies and vignettes included in Part 7 as well as topics covered in Part 3.
Concept Definition Activities
There are two primary activities discussed under concept definition: Mission AnalysisMission Analysis and the definition of Stakeholder Needs and RequirementsStakeholder Needs and Requirements:
- Mission Analysis begins an iteration of the life cycle of a potential SoI that could solve a problem or realize an opportunity for developing a new product, service, or enterprise. These activities assist business or enterprise decision makers to define the problem space, identify the stakeholders, develop preliminary operational concepts, and distinguish environmental conditions and constraints that bound the solution space. In other words, mission analysis takes the enterprise capability gap or opportunity and defines the problem/opportunity in a manner that provides a common understanding encapsulated in what are referred to as “business or mission needs.” Business or mission needs are then used to produce a clear, concise, and verifiable set of business requirements.
- The Stakeholder Needs and Requirements activity works with stakeholders across the life cycle to elicit and capture a set of needs, expectations, goals, or objectives for a desired solution to the problem or opportunity, referred to as "stakeholder needs". The stakeholder needs are used to produce a clear, concise, and verifiable set of stakeholder requirements. Stakeholder needs and requirements identify and define the needs and requirements of the stakeholders in a manner that enables the characterization of the solution alternatives.
Mission Analysis takes the business and stakeholders' needs and requirements and carries the analysis down from problem space to solution space, including concept, mission, and boundary or context so that a solution concept (at the black-box level) can be selected from the alternatives. Figure 1 in the Mission Analysis topic depicts this interaction. The products and artifacts produced during Concept Definition are then used in System DefinitionSystem Definition.
The different aspects of how systems thinkingsystems thinking is applicable to concept definition are discussed in SEBoK Part 2. In particular, the use of a combination of hard systemhard system and soft systemsoft system approaches depending on the type of problem or class of solution is discussed in Identifying and Understanding Problems and Opportunities and the contrast between top-down and bottom-up approaches in Synthesizing Possible Solutions.
Drivers of Solution on Problem Definition: Push Versus Pull
Problem definition and solution design depend on each other. Solutions should be developed to respond appropriately to well-defined problems. Problem definitions should be constrained to what is feasible in the solution space. System AnalysisSystem Analysis activities are used to provide the link between problems and solutions.
There are two paradigms that drive the ways in which concept definition is done: push and pull. The pull paradigm is based on providing a solution to an identified problem or gap, such as a missing mission capability for defense or infrastructure. The push paradigm is based on creating a solution to address a perceived opportunity, such as the emergence of an anticipated product or service that is attractive to some portion of the population (i.e. whether a current market exists or not). This can impact other life cycle processes, such as in verification and validation, or alpha/beta testing as done in some commercial domains.
As systems generally integrate existing and new system elementssystem elements in a mixture of push and pull, it is often best to combine a bottom-up approach with a top-down approach to take into account legacy elements, as well as to identify the services and capabilities that must be provided in order to define applicable interface requirements and constraints. This is discussed in Applying Life Cycle Processes.
References
Works Cited
None.
Primary References
ANSI/EIA. 1998. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA 632-1998.
INCOSE. 2015. 'Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
ISO/IEC/IEEE. 2015. 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. 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.
Additional References
Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. Hoboken, NJ, USA: John Wiley & Sons.
ISO/IEC. 2003. Systems Engineering – A Guide for The Application of ISO/IEC 15288 System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E). http://www.hitchins.net/EmergenceEtc.pdf.
ISO/IEC. 2007. Systems Engineering – Application and Management of The Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 26702:2007.
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE Insight. (April 2010): 41-43.
NASA. 2007. Systems Engineering Handbook. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.
< Previous Article | Parent Article | Next Article >
SEBoK v. 2.0, released 1 June 2019