Difference between pages "Stakeholder Needs and Requirements" and "Analysis and Selection between Alternative Solutions"

From SEBoK
(Difference between pages)
Jump to: navigation, search
(Tech and grammar edits as discussed with Bkcase)
 
m (Text replacement - "<center>'''SEBoK v. 2.0, released 1 June 2019'''</center>" to "<center>'''SEBoK v. 2.1, released 31 October 2019'''</center>")
 
Line 1: Line 1:
{{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.  
+
This topic is part of the [[Systems Approach Applied to Engineered Systems]] knowledge area (KA).  It describes knowledge related to the analysis and selection of a preferred {{Term|Solution (glossary)|solution}} from the possible options, which may have been proposed by [[Synthesizing Possible Solutions]].  Selected solution options may form the starting point for [[Implementing and Proving a Solution]].  Any of the activities described below may also need to be considered {{Term|Concurrently (glossary)|concurrently}} with other activities in the {{Term|Systems Approach (glossary)|systems approach}} at a particular point in the life of a {{Term|System-of-Interest (glossary)|system-of-interest}} (SoI).  
  
Stakeholder requirements play major roles in systems engineering, as they:
+
The activities described below should be considered in the {{Term|Context (glossary)|context}} of the [[Overview of the Systems Approach]] topic at the start of this KA. The final topic in this KA, [[Applying the Systems Approach]], considers the dynamic aspects of how these activities are used as part of the systems approach and how this relates in detail to {{Term|Element (glossary)|elements}} of {{Term|Systems Engineering (glossary)|systems engineering}} (SE).
* 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.
 
  
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.
+
==System Analysis==
==Purpose and Definition==
+
{{Term|System Analysis (glossary)|System analysis}} is an activity in the systems approach that evaluates one or more {{Term|System (glossary)|system}} artifacts created during the activities involved in [[Synthesizing Possible Solutions]], such as:
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.
+
* Defining {{Term|Assessment Criterion (glossary)|assessment criteria}} based on the required properties and behavior of an identified {{Term|Problem (glossary)|problem}} or {{Term|Opportunity (glossary)|opportunity}} system situation.
+
* Accessing the properties and behavior of each candidate solution in comparison to the criteria.
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.
+
* Comparing the assessments of the candidate solutions and identification of any that could resolve the problem or exploit the opportunities, along with the selection of candidates that should be further explored.
  
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]].
+
As discussed in [[Synthesizing Possible Solutions]] topic, the problem context for an {{Term|Engineered System (glossary)|engineered system}} will include a logical or ideal system solution description. It is assumed that the solution that “best” matches the ideal one will be the most acceptable solution to the {{Term|Stakeholder (glossary)|stakeholders}}. Note, as discussed below, the “best” solution should include an understanding of {{Term|Cost (glossary)|cost}} and {{Term|Risk (glossary)|risk}}, as well as {{Term|Effectiveness (glossary)|effectiveness}}. The problem context may include a {{Term|Soft System (glossary)|soft system}} {{Term|Concept (glossary)|conceptual}} {{Term|Model (glossary)|model}} describing the logical elements of a system to resolve the problem situation and how these are perceived by different stakeholders (Checkland 1999). This soft context view will provide additional criteria for the analysis {{Term|Process (glossary)|process}}, which may become the critical issue in selecting between two equally effective solution alternatives.  
  
==Principles and Concepts==
+
Hence, analysis is often not a one-time process of solution selection; rather, it is used in combination with problem understanding and solution {{Term|Synthesis (glossary)|synthesis}} to progress towards a more complete understanding of problems and solutions over time (see [[Applying the Systems Approach]] topic for a more complete discussion of the dynamics of this aspect of the approach).
  
===Identifying Stakeholders===
+
==Effectiveness Analysis==
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.  
+
Effectiveness studies use the problem or opportunity system context as a starting point.  
  
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.
+
The effectiveness of a synthesized system solution will include performance criteria associated with both the system’s primary and enabling {{Term|Function (glossary)|functions}}. These are derived from the system’s {{Term|Purpose (glossary)|purpose}}, in order to enable the realization of stakeholder needs in one or more, wider system contexts.
{|
 
|+'''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''' ===
+
For a {{Term|Product System (glossary)|product system}} there are a set of generic non-functional qualities that are associated with different types of solution patterns or technology, e.g., {{Term|Safety (glossary)|safety}}, {{Term|Security (glossary)|security}}, {{Term|Reliability (glossary)|reliability}}, {{Term|Maintainability (glossary)|maintainability}}, usability, etc. These criteria are often explicitly stated as parts of the {{Term|Domain (glossary)|domain}} knowledge of related technical disciplines in technology domains.
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''' ===
+
For a {{Term|Service System (glossary)|service system}} or {{Term|Enterprise System (glossary)|enterprise system}} the criteria will be more directly linked to the identified {{Term|User (glossary)|user}} needs or {{Term|Enterprise (glossary)|enterprise}} goals. Typical qualities for such systems include agility, {{Term|Resilience (glossary)|resilience}}, {{Term|Flexibility (glossary)|flexibility}}, upgradeability, etc.
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''' ===
+
In addition to assessments of the absolute effectiveness of a given solution system, {{Term|Systems Engineer (glossary)|systems engineers}} must also be able to combine effectiveness with the limitations of cost and timescales included in the problem context. In general, the role of system analysis is to identify the proposed solutions which can provide some effectiveness within the cost and time allocated to any given {{Term|Iteration (glossary)|iteration}} of the systems approach (see [[Applying the Systems Approach]] for details). If none of the solutions can deliver an effectiveness level that justifies the proposed investment, then it is necessary to return to the original framing of the problem. If at least one solution is assessed as sufficiently effective, then a choice between solutions can be proposed.
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)
 
  
=== From the Capture of Stakeholder Needs to the Definition of Stakeholder Requirements ===
+
==Trade-Off Studies==
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.
+
In the context of the definition of a system, a trade-off study consists of comparing the characteristics of each candidate system element to those of each candidate system {{Term|Architecture (glossary)|architecture}}, in order to determine the solution that globally balances the assessment criteria in the best way. The various characteristics analyzed are gathered in cost analysis, technical risks analysis, and effectiveness analysis (NASA 2007). To accomplish a trade off study there are a variety of methods, often supported by tooling. Each class of analysis is the subject of the following topics:
[[File:SEBoKv05_KA-SystDef_Cycle_of_needs.png|centre|thumb|600x600px|
+
* Assessment criteria are used to classify the various candidate solutions. They are either absolute or relative. For example, the maximum cost per unit produced is c$, cost reduction shall be x%, effectiveness improvement is y%, and risk mitigation is z%.
'''Figure 1. Cycle of Needs (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.
+
* '''{{Term|Boundary (glossary)|Boundaries}}''' identify and limit the characteristics or criteria to be taken into account at the time of analysis (e.g., the kind of costs to be taken into account, acceptable technical risks, and the type and level of effectiveness).
]]
+
* '''Scales''' are used to quantify the characteristics, properties, and/or criteria and to make comparisons. Their definition requires knowledge of the highest and lowest limits, as well as the type of evolution of the characteristic (linear, logarithmic, etc.).
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:
+
* An {{Term|Assessment Score (glossary)|assessment score}} is assigned to a characteristic or criterion for each candidate solution. The goal of the trade-off study is to succeed in quantifying the three variables (and their decomposition in sub-variables) of cost, risk, and effectiveness for each candidate solution. This operation is generally complex and requires the use of models.
* '''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.
+
* The '''optimization''' of the characteristics or properties improves the scoring of interesting solutions.
* '''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).
 
  
===Classification of Stakeholder Requirements===
+
A decision-making process is not an accurate science; ergo, trade-off studies have limits. The following concerns should be taken into account:
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.
+
*Subjective Criteria – personal bias of the analyst; for example, if the component has to be beautiful, what constitutes a “beautiful” component?
 +
*Uncertain Data – for example, inflation has to be taken into account to estimate the cost of maintenance during the complete {{Term|Life Cycle (glossary)|life cycle}} of a system, how can a systems engineer predict the evolution of inflation over the next five years?
 +
*Sensitivity Analysis – A global assessment score that is designated to every candidate solution is not absolute; thus, it is recommended that a robust selection is gathered by performing a sensitivity analysis that considers small variations of assessment criteria values (weights). The selection is robust if the variations do not change the order of scores.
  
==Process Approach==
+
A thorough trade-off study specifies the assumptions, variables, and confidence intervals of the results.
  
===Activities of the Process===
+
==Systems Principles of System Analysis==
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.
 
  
===Artifacts, Methods and Modeling Techniques===
+
From the discussions above, the following general {{Term|Principle (glossary)|principles}} of systems analysis can be defined:
  
This process may create several artifacts, such as:
+
*Systems analysis is an iterative activity consisting of trade studies made between various solution options from the systems synthesis activity.
* Recommendations to refine the Business Requirement Specification (if necessary)
+
*Systems analysis uses assessment criteria based upon a problem or opportunity system description.
* Refined life-cycle concepts (OpsCon, acquisition concept, deployment concept, support concept, and retirement concept)
+
** These criteria will be based around an ideal system description that assumes a {{Term|Hard System (glossary)|hard system}} problem context can be defined.
* Stakeholder requirements (in the form of a model or a document containing textual requirements, such as the Stakeholder Requirement Specification)  
+
** The criteria must consider required system behavior and properties of the complete solution in all of the possible wider system contexts and environments.
* Stakeholder interview reports
+
** Trade studies require equal consideration to the primary system and the enabling system working as a single sytem to address the User need.  These trades need to consider system requirements for Key Performance Parameters (KPPs), systems safety, security, and affordability across the entire life cycle
* Stakeholder requirements database
+
** This ideal system description may be supported by {{Term|Soft System (glossary)|soft system}} descriptions from which additional “soft” criteria may be defined (e.g., a stakeholder preference for or against certain kinds of solutions and relevant social, political, or cultural conventions to be considered in the likely solution environment, etc.).
* Stakeholder requirements justification documents (for traceability purposes)
+
* At a minimum, the assessment criteria should include the constraints on cost and time scales acceptable to stakeholders.
* Input for draft verification and validation plans
+
* Trade studies provide a mechanism for conducting analysis of alternative solutions.
 +
** A trade study should consider a “system of assessment criteria”, designating special attention to the limitations and dependencies between individual criteria.
 +
** Trade studies need to deal with both objective and subjective criteria. Care must be taken to assess the sensitivity of the overall assessment to particular criteria.
  
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.
+
==References==
  
==Practical Considerations==
 
Major pitfalls encountered with stakeholder requirements are presented in Table 3.
 
 
<center>
 
{|
 
|+'''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.
 
|}
 
</center>
 
 
 
Proven practices with stakeholder requirements are presented in Table 4.
 
 
<center>
 
{|
 
|+'''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===
 
===Works Cited===
 +
Checkland, P.B. 1999. ''Systems Thinking, Systems Practice''. Chichester, UK: John Wiley & Sons Ltd.
  
Faisandier, A. 2012. ''Systems Architecture and Design.'' Belberaud, France: Sinergy'Com.
+
NASA. 2007. ''Systems Engineering Handbook'', Revision 1. Washington, DC, USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.
 
 
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. ''[[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===
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. 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 Organisation for Standardisation / International Electrotechnical Commissions / / Institute of Electrical and Electronics Engineer. [[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]].
+
Jackson, S., D. Hitchins and H. Eisner. 2010. "[[What is the Systems Approach?]]" INCOSE ''Insight.'' 13(1) (April 2010): 41-43.
  
 
===Additional References===
 
===Additional References===
Buede, D.M. 2009. ''The engineering design of systems: Models and methods''. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc.
+
None.
 
 
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>[[Business or Mission Analysis|< Previous Article]] | [[Concept Definition|Parent Article]] | [[System Definition|Next Article >]]</center>
+
<center>[[Synthesizing Possible Solutions|< Previous Article]] | [[Systems Approach Applied to Engineered Systems|Parent Article]] | [[Implementing and Proving a Solution|Next Article >]]</center>
  
<center>'''SEBoK v. 2.0, released 1 June 2019'''</center>
+
<center>'''SEBoK v. 2.1, released 31 October 2019'''</center>
  
[[Category:Concept Definition]]
+
[[Category:Part 2]][[Category:Topic]]
 +
[[Category:Systems Approach Applied to Engineered Systems]]

Revision as of 20:40, 19 October 2019

This topic is part of the Systems Approach Applied to Engineered Systems knowledge area (KA). It describes knowledge related to the analysis and selection of a preferred solutionsolution from the possible options, which may have been proposed by Synthesizing Possible Solutions. Selected solution options may form the starting point for Implementing and Proving a Solution. Any of the activities described below may also need to be considered concurrentlyconcurrently with other activities in the systems approachsystems approach at a particular point in the life of a system-of-interestsystem-of-interest (SoI).

The activities described below should be considered in the contextcontext of the Overview of the Systems Approach topic at the start of this KA. The final topic in this KA, Applying the Systems Approach, considers the dynamic aspects of how these activities are used as part of the systems approach and how this relates in detail to elementselements of systems engineeringsystems engineering (SE).

System Analysis

System analysisSystem analysis is an activity in the systems approach that evaluates one or more systemsystem artifacts created during the activities involved in Synthesizing Possible Solutions, such as:

  • Defining assessment criteriaassessment criteria based on the required properties and behavior of an identified problemproblem or opportunityopportunity system situation.
  • Accessing the properties and behavior of each candidate solution in comparison to the criteria.
  • Comparing the assessments of the candidate solutions and identification of any that could resolve the problem or exploit the opportunities, along with the selection of candidates that should be further explored.

As discussed in Synthesizing Possible Solutions topic, the problem context for an engineered systemengineered system will include a logical or ideal system solution description. It is assumed that the solution that “best” matches the ideal one will be the most acceptable solution to the stakeholdersstakeholders. Note, as discussed below, the “best” solution should include an understanding of costcost and riskrisk, as well as effectivenesseffectiveness. The problem context may include a soft systemsoft system conceptualconceptual modelmodel describing the logical elements of a system to resolve the problem situation and how these are perceived by different stakeholders (Checkland 1999). This soft context view will provide additional criteria for the analysis processprocess, which may become the critical issue in selecting between two equally effective solution alternatives.

Hence, analysis is often not a one-time process of solution selection; rather, it is used in combination with problem understanding and solution synthesissynthesis to progress towards a more complete understanding of problems and solutions over time (see Applying the Systems Approach topic for a more complete discussion of the dynamics of this aspect of the approach).

Effectiveness Analysis

Effectiveness studies use the problem or opportunity system context as a starting point.

The effectiveness of a synthesized system solution will include performance criteria associated with both the system’s primary and enabling functionsfunctions. These are derived from the system’s purposepurpose, in order to enable the realization of stakeholder needs in one or more, wider system contexts.

For a product systemproduct system there are a set of generic non-functional qualities that are associated with different types of solution patterns or technology, e.g., safetysafety, securitysecurity, reliabilityreliability, maintainabilitymaintainability, usability, etc. These criteria are often explicitly stated as parts of the domaindomain knowledge of related technical disciplines in technology domains.

For a service systemservice system or enterprise systementerprise system the criteria will be more directly linked to the identified useruser needs or enterpriseenterprise goals. Typical qualities for such systems include agility, resilienceresilience, flexibilityflexibility, upgradeability, etc.

In addition to assessments of the absolute effectiveness of a given solution system, systems engineerssystems engineers must also be able to combine effectiveness with the limitations of cost and timescales included in the problem context. In general, the role of system analysis is to identify the proposed solutions which can provide some effectiveness within the cost and time allocated to any given iterationiteration of the systems approach (see Applying the Systems Approach for details). If none of the solutions can deliver an effectiveness level that justifies the proposed investment, then it is necessary to return to the original framing of the problem. If at least one solution is assessed as sufficiently effective, then a choice between solutions can be proposed.

Trade-Off Studies

In the context of the definition of a system, a trade-off study consists of comparing the characteristics of each candidate system element to those of each candidate system architecturearchitecture, in order to determine the solution that globally balances the assessment criteria in the best way. The various characteristics analyzed are gathered in cost analysis, technical risks analysis, and effectiveness analysis (NASA 2007). To accomplish a trade off study there are a variety of methods, often supported by tooling. Each class of analysis is the subject of the following topics:

  • Assessment criteria are used to classify the various candidate solutions. They are either absolute or relative. For example, the maximum cost per unit produced is c$, cost reduction shall be x%, effectiveness improvement is y%, and risk mitigation is z%.
  • BoundariesBoundaries identify and limit the characteristics or criteria to be taken into account at the time of analysis (e.g., the kind of costs to be taken into account, acceptable technical risks, and the type and level of effectiveness).
  • Scales are used to quantify the characteristics, properties, and/or criteria and to make comparisons. Their definition requires knowledge of the highest and lowest limits, as well as the type of evolution of the characteristic (linear, logarithmic, etc.).
  • An assessment scoreassessment score is assigned to a characteristic or criterion for each candidate solution. The goal of the trade-off study is to succeed in quantifying the three variables (and their decomposition in sub-variables) of cost, risk, and effectiveness for each candidate solution. This operation is generally complex and requires the use of models.
  • The optimization of the characteristics or properties improves the scoring of interesting solutions.

A decision-making process is not an accurate science; ergo, trade-off studies have limits. The following concerns should be taken into account:

  • Subjective Criteria – personal bias of the analyst; for example, if the component has to be beautiful, what constitutes a “beautiful” component?
  • Uncertain Data – for example, inflation has to be taken into account to estimate the cost of maintenance during the complete life cyclelife cycle of a system, how can a systems engineer predict the evolution of inflation over the next five years?
  • Sensitivity Analysis – A global assessment score that is designated to every candidate solution is not absolute; thus, it is recommended that a robust selection is gathered by performing a sensitivity analysis that considers small variations of assessment criteria values (weights). The selection is robust if the variations do not change the order of scores.

A thorough trade-off study specifies the assumptions, variables, and confidence intervals of the results.

Systems Principles of System Analysis

From the discussions above, the following general principlesprinciples of systems analysis can be defined:

  • Systems analysis is an iterative activity consisting of trade studies made between various solution options from the systems synthesis activity.
  • Systems analysis uses assessment criteria based upon a problem or opportunity system description.
    • These criteria will be based around an ideal system description that assumes a hard systemhard system problem context can be defined.
    • The criteria must consider required system behavior and properties of the complete solution in all of the possible wider system contexts and environments.
    • Trade studies require equal consideration to the primary system and the enabling system working as a single sytem to address the User need. These trades need to consider system requirements for Key Performance Parameters (KPPs), systems safety, security, and affordability across the entire life cycle
    • This ideal system description may be supported by soft systemsoft system descriptions from which additional “soft” criteria may be defined (e.g., a stakeholder preference for or against certain kinds of solutions and relevant social, political, or cultural conventions to be considered in the likely solution environment, etc.).
  • At a minimum, the assessment criteria should include the constraints on cost and time scales acceptable to stakeholders.
  • Trade studies provide a mechanism for conducting analysis of alternative solutions.
    • A trade study should consider a “system of assessment criteria”, designating special attention to the limitations and dependencies between individual criteria.
    • Trade studies need to deal with both objective and subjective criteria. Care must be taken to assess the sensitivity of the overall assessment to particular criteria.

References

Works Cited

Checkland, P.B. 1999. Systems Thinking, Systems Practice. Chichester, UK: John Wiley & Sons Ltd.

NASA. 2007. Systems Engineering Handbook, Revision 1. Washington, DC, USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.

Primary References

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 Engineer. ISO/IEC/IEEE 15288:2015.

Jackson, S., D. Hitchins and H. Eisner. 2010. "What is the Systems Approach?" INCOSE Insight. 13(1) (April 2010): 41-43.

Additional References

None.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.1, released 31 October 2019