https://sandbox.sebokwiki.org/api.php?action=feedcontributions&user=Groedler&feedformat=atomSEBoK - User contributions [en]2024-03-28T11:19:15ZUser contributionsMediaWiki 1.35.13https://sandbox.sebokwiki.org/index.php?title=Stakeholder_Requirements_Definition&diff=48838Stakeholder Requirements Definition2013-10-23T23:04:50Z<p>Groedler: /* Presentation and Quality of Requirements */</p>
<hr />
<div>[[System Requirement (glossary)|System requirements]] are all of the [[Requirement (glossary)|requirements]] at the ''system level'' that describe the functions which the system as a whole should fulfill to satisfy the [[Stakeholder Requirement (glossary)|stakeholder needs and requirements]], and is expressed in an appropriate combination of textual statements, views, and non-functional requirements; the latter expressing the levels of safety, security, reliability, etc., that will be necessary. <br />
<br />
System requirements play major roles in systems engineering, as they: <br />
* Form the basis of system [[Architecture (glossary)|architecture]] and [[Design (glossary)|design]] activities.<br />
*Form the basis of system [[Integration (glossary)]] and [[Verification (glossary)|verification]] activities.<br />
* Act as reference for [[Validation (glossary)|validation]] and stakeholder acceptance.<br />
* Provide a means of communication between the various technical staff that interact throughout the project.<br />
<br />
Elicitation of stakeholder requirements starts in [[Concept Definition|Concept Definition]], and will be initially developed though interview and mission analysis. System requirements are considered in detail during [[System Definition|System Definition]]. Neither 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. <br />
<br />
==Definition and Purpose of Requirements==<br />
A requirement is a statement that identifies a product or processes operational, functional, or design characteristic or constraint, which is unambiguous, testable, or measurable and necessary for product or process acceptability (ISO/IEC 2007).<br />
<br />
To avoid confusion in the multitude of terms pertaining to ''[[Requirement (glossary)|requirements]]'', consider the following classifications:<br />
* '''Process Role or State''': The role the requirement plays in the definition process; for instance, its position in the system block (e.g. translated, derived, satisfied) or its state of agreement (e.g. proposed, approved, cancelled). <br />
* '''Level of Abstraction''': The level within the definition process that the requirement stands; for instance, stakeholder requirement, system requirement, system element requirement.<br />
* '''Type of Requirement''': The nature of the requirement itself; for instance, functional, performance, constraint, etc.<br />
<br />
Any single requirement may simultaneously be in a particular state, at a particular level abstraction, and of a particular type. For additional explanations about differences between the types of requirements, refer to Chapter 2 of Martin (1997).<br />
<br />
==Principles Governing System Requirements==<br />
===Relationship to Stakeholder Requirements and Logical Architecture===<br />
A set of [[Stakeholder Requirement (glossary)|stakeholder requirements]] are clarified and translated from statements of need into ''engineering-oriented'' language in order to enable proper architecture definition, design, and verification activities that are needed as the basis for system requirements analysis. <br />
<br />
The system requirements are based around identification and synthesis of the functions required of any solution system associated with performance and other quality measures and provide the basis for the assessment candidate solutions and verification of the completed system. The [[System Requirement (glossary)|system requirements]] are expressed in technical language that is useful for architecture and design: unambiguous, consistent, coherent, exhaustive, and verifiable. Of course, close coordination with the stakeholders is necessary to ensure the translation is accurate and traceability is maintained. This results in a set of system functions and requirements specifying measurable characteristics which can form the basis for [[System Realization (glossary)|system realization]].<br />
<br />
The [[Logical Architecture (glossary)]] defines system boundary and functions, from which more detailed system requirements can be derived. The starting point for this process may be to identify functional requirements from the stakeholder requirements and to use this to start the architectural definition, or to begin with a high level functional architecture view and use this as the basis for structuring system requirements. The exact approach taken will often depend on whether the system is an evolution of an already understood product or service, or a new and unprecedented solution (see [[Synthesizing Possible Solutions]]). However, when the process is initiated it is important that the stakeholder requirements, system requirements, and logical architecture are all complete, consistent with each other, and assessed together at the appropriate points in the systems [[Life Cycle Model (glossary)]].<br />
<br />
====Traceability and the Assignment of System Requirements during Architecture and Design====<br />
Requirements traceability provides the ability to track information from the origin of the stakeholder requirements, to the top level of requirements and other system definition elements at all levels of the system hierarchy (see section "Top-down and Recursive Approach to System Decomposition" in the [[System Definition]] article). Traceability is also used to provide an understanding as to the extent of a change as an input when impact analyses is performed in cases of proposed engineering improvements or requests for change.<br />
<br />
During [[Architecture (glossary) |architecture]] definition and [[Design (glossary) |design]], the assignment of requirements from one level to lower levels in the system hierarchy can be accomplished using several methods, as appropriate - see Table 1.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 1. Assessment Types for a System Requirement.''' (SEBoK Original)<br />
!Assignment Type for a System Requirement<br />
!Description<br />
|-<br />
|'''Direct Assignment'''<br />
|The system requirement from the higher level is directly assigned to a system or a system element for a lower level (e.g. the color used to paint visible parts of the product).<br />
|-<br />
|'''Indirect Assignment (Simply Decomposed)'''<br />
|The system requirement is distributed across several systems or system elements and the sum of a more complex calculation for distribution is equal to the requirement of higher level (e.g. a mass requirement, power distribution, reliability allocation, etc.) with sufficient margin or tolerance. A documented and configuration-managed "assignment budget" for each assignment must be maintained.<br />
|-<br />
|'''Indirect Assignment (Modeled and Decomposed)'''<br />
|The system requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique. The resulting design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, in the case of a radar detection requirement that is being analyzed, these lower-level parameters for output power, beam size, frequencies, etc. will be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.<br />
|-<br />
|'''Derived Requirement (from Design)'''<br />
|Such system requirements are developed during the design activities as a result of the decision of the design team, not the stakeholder community. These requirements may include the use of commercial-off-the-shelf (COTS) items, existing systems or system elements in inventory, common components, and similar design decisions in order to produce a "best value" solution for the customer. As such, these derived requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or a constraint.<br />
|}<br />
</center><br />
<br />
===Classification of System Requirements===<br />
Several classifications of system requirements are possible, depending on the requirements definition methods and/or the architecture and design methods being applied. (ISO/IEC 2011) provides a classification which is summarized in Table 2 (see references for additional classifications).<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Example of System Requirements Classification.''' (SEBoK Original)<br />
!Types of System Requirement<br />
!Description<br />
|-<br />
|'''Functional Requirements'''<br />
|Describe qualitatively the system functions or tasks to be performed in operation.<br />
|-<br />
|'''Performance Requirements'''<br />
|Define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task. <br />
|-<br />
|'''Usability Requirements'''<br />
|Define the quality of system use (e.g. measurable effectiveness, efficiency, and satisfaction criteria).<br />
|-<br />
|'''Interface Requirements'''<br />
|Define how the system is required to interact or to exchange material, energy, or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface requirements include physical connections (physical interfaces) with external systems or internal system elements supporting interactions or exchanges.<br />
|-<br />
|'''Operational Requirements'''<br />
|Define the operational conditions or properties that are required for the system to operate or exist. This type of requirement includes: human factors, ergonomics, availability, maintainability, reliability, and security.<br />
|-<br />
|'''Modes and/or States Requirements'''<br />
|Define the various operational modes of the system in use and events conducting to transitions of modes.<br />
|-<br />
|'''Adaptability Requirements'''<br />
|Define potential extension, growth, or scalability during the life of the system.<br />
|-<br />
|'''Physical Constraints'''<br />
|Define constraints on weight, volume, and dimension applicable to the system elements that compose the system.<br />
|-<br />
|'''Design Constraints'''<br />
|Define the limits on the options that are available to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an online repository).<br />
|-<br />
|'''Environmental Conditions'''<br />
|Define the environmental conditions to be encountered by the system in its different operational modes. This should address the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-induced environmental effects (e.g. motion, shock, noise, electromagnetism, thermal, etc.), and threats to societal environment (e.g. legal, political, economic, social, business, etc.).<br />
|-<br />
|'''Logistical Requirements'''<br />
|Define the logistical conditions needed by the continuous utilization of the system. These requirements include sustainment (provision of facilities, level support, support personnel, spare parts, training, technical documentation, etc.), packaging, handling, shipping, transportation.<br />
|-<br />
|'''Policies and Regulations'''<br />
|Define relevant and applicable organizational policies or regulatory requirements that could affect the operation or performance of the system (e.g. labor policies, reports to regulatory agony, health or safety criteria, etc.).<br />
|-<br />
|'''Cost and Schedule Constraints'''<br />
|Define, for example, the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc.<br />
|}<br />
</center><br />
<br />
===Requirements Management===<br />
Requirements management is performed to ensure alignment of the system and system element requirements with other representations, analysis, and artifacts of the system. It includes providing an understanding of the requirements, obtaining commitment, managing changes, maintaining bi-directional traceability among the requirements and with the rest of the system definition, and alignment with project resources and schedule. <br />
<br />
There are many tools available to provide a supporting infrastructure for requirements management; the best choice is the one that matches the processes of the project or enterprise. Requirements management is also closely tied to [[Configuration Management|configuration management]] for baseline management and control. When the requirements have been defined, documented, and approved, they need to be put under baseline management and control. The baseline allows the project to analyze and understand the impact (technical, cost, and schedule) of ongoing proposed changes.<br />
<br />
==Process Approach==<br />
===Purpose and Principle of the Approach===<br />
The purpose of the system requirements analysis process is to transform the stakeholder, user-oriented view of desired services and properties into a technical view of the product that meets the operational needs of the user. This process builds a representation of the system that will meet stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable system requirements that specify, from the supplier’s perspective, what performance and non-performance characteristics it must possess in order to satisfy stakeholders' requirements (ISO/IEC 2008).<br />
<br />
===Activities of the Process===<br />
Major activities and tasks during this process include:<br />
# Analyzing the stakeholder requirements to check completeness of expected services and [[Operational Scenario (glossary)|operational scenarios]], conditions, operational modes, and constraints.<br />
# Defining the system requirements and their [[Rationale (glossary)|rationale]].<br />
# Classifying the system requirements using suggested classifications (see examples above).<br />
# Incorporating the derived requirements (coming from architecture and design) into the system requirements baseline.<br />
# Establishing the upward traceability with the stakeholder needs and requirements. <br />
# Establishing bi-directional traceability between requirements at adjacent levels of the system hierarchy. <br />
# Verifying the quality and completeness of each system requirement and the consistency of the set of system requirements.<br />
# Validating the content and relevance of each system requirement against the set of stakeholder requirements.<br />
# Identifying potential [[Risk (glossary)|risks]] (or threats and hazards) that could be generated by the system requirements.<br />
# Synthesizing, recording, and managing the system requirements and potential associated risks.<br />
# Upon approval of the requirements, establishing control baselines along with the other system definition elements in conjunction with established configuration management practices.<br />
<br />
===Checking Correctness of System Requirements===<br />
System requirements should be checked to gauge whether they are well expressed and appropriate. There are a number of characteristics that can be used to check system requirements, such as standard peer review techniques and comparison of each requirement against the set of requirements characteristics, which are listed in Table 2 and Table 3 of the "Presentation and Quality of Requirements" section (below). Requirements can be further validated using the requirements elicitation and rationale capture described in the section "Methods and Modeling Techniques" (below).<br />
<br />
===Methods and Modeling Techniques===<br />
====Requirements Elicitation and Prototyping====<br />
Requirements elicitation requires user involvement and can be effective in gaining stakeholder involvement and buy-in. Quality Function Deployment (QFD) and prototyping are two common techniques that can be applied and are defined in this section. In addition, interviews, focus groups, and Delphi techniques are often applied to elicit requirements.<br />
<br />
QFD is a powerful technique to elicit requirements and compare design characteristics against user needs (Hauser and Clausing 1988). The inputs to the QFD application are user needs and operational concepts, so it is essential that the users participate. Users from across the life cycle should be included to ensure that all aspects of user needs are accounted for and prioritized.<br />
<br />
Early prototyping can help the users and developers interactively identify functional and operational requirements as well as user interface constraints. This enables realistic user interaction, discovery, and feedback, as well as some sensitivity analysis. This improves the users' understanding of the requirements and increases the probability of satisfying their actual needs.<br />
<br />
====Capturing Requirements Rationale====<br />
One powerful and cost-effective technique to translate stakeholder requirements to system requirements is to capture the rationale for each requirement. Requirements rationale is merely a statement as to why the requirement exists, any assumptions made, the results of related design studies, or any other related supporting information. This supports further requirements analysis and decomposition. The rationale can be captured directly in a requirements database (Hull, Jackson, and Dick 2010).<br />
<br />
Some of the benefits of this approach include:<br />
* '''Reducing the total number of requirements''' - The process aids in identifying duplicates. Reducing requirements count will reduce project cost and risk.<br />
* '''Early exposure of bad assumptions'''<br />
* '''Removes design implementation''' - Many poorly written stakeholder requirements are design requirements in disguise, in that the customer is intentionally or unintentionally specifying a candidate implementation. <br />
* '''Improves communication with the stakeholder community''' - By capturing the requirements rationale for all stakeholder requirements, the line of communication between the users and the designers is greatly improved. (Adapted from Chapter 8 of (Hooks and Farry 2000)).<br />
<br />
====Modeling Techniques====<br />
Modeling techniques that can be used when requirements must be detailed or refined, or in cases in which they address topics not considered during the stakeholder requirements definition and mission analysis, include:<br />
* State-charts models (ISO/IEC 2011, Section 8.4)<br />
* Scenarios modeling (ISO/IEC 2011, Section 6.2.3.1)<br />
* Simulations, prototyping (ISO/IEC 2011, Section 6.3.3.2)<br />
* Quality Function Deployment (INCOSE. 2010, p. 83)<br />
* Sequence diagrams, activity diagrams, use cases, state machine diagrams, Systems Modeling Language (SysML) requirements diagrams<br />
* Functional Flow Block Diagram for operational scenarios<br />
<br />
====Presentation and Quality of Requirements====<br />
Generally, requirements are provided in a textual form. Guidelines exist for writing good requirements; they include recommendations about the syntax of requirements statements, wording (exclusions, representation of concepts, etc.), and characteristics (specific, measurable, achievable, feasible, testable, etc.). Refer to INCOSE (2010, Section 4.2.2.2) and ISO/IEC (2011).<br />
<br />
There are several characteristics of both requirements and sets of requirements that are used to aid their development and to verify the implementation of requirements into the solution. Table 3 provides a list and descriptions of the characteristics for individual requirements and Table 4 provides a list and descriptions of characteristics for a set of requirements, as adapted from ISO/IEC (2011, Sections 5.2.5 and 5.2.6).<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 3. Characteristics of Individual Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Necessary'''<br />
|The requirement defines an essential capability, characteristic, constant, and/or quality factor. If it is removed or deleted, a deficiency will exist which cannot be fulfilled by other capabilities of the product or process.<br />
|-<br />
|'''Implementation Independent'''<br />
|The requirement, while addressing what is necessary and sufficient in the system, avoids placing unnecessary constraints on the architectural design. The objective is to be implementation-independent. The requirement states what is required, not how the requirement should be met.<br />
|-<br />
|'''Unambiguous'''<br />
|The requirement is stated in such a way so that it can be interpreted in only one way. The requirement is stated simply and is easy to understand.<br />
|-<br />
|'''Complete'''<br />
|The stated requirement needs no further amplification because it is measurable and sufficiently describes the capability and characteristics to meet the identified business, mission, and stakeholder needs. <br />
|-<br />
|'''Singular'''<br />
|The requirement statement includes only one requirement with no use of conjunctions.<br />
|-<br />
|'''Achievable'''<br />
|The requirement must be technically achievable within constraints and requires advances in technology within acceptable risk.<br />
|-<br />
|'''Verifiable'''<br />
|The requirement has the means to prove that the system satisfies the specified requirement. Verifiability is enhanced when the requirement is measurable.<br />
|-<br />
|'''Conforming'''<br />
|In many instances, there are applicable government, industry, and product standards, specifications, and interfaces with which compliance is required. The requirement may also need to conform to an organizational template for its sentence structure.<br />
|}<br />
</center><br />
<br />
Note: Traceability is considered by some sources as a characteristic (ISO/IEC (2011)). However, a recent viewpoint is that Traceability is actually an attribute of a requirement; that is, something that is appended to the requirement, not an intrinsic characteristic of a requirement (INCOSE (2010)). The traceability characteristic or attribute is defined as: The requirement is upwards traceable to specific documented stakeholder statement(s) of need, higher tier requirement, or another source (e.g., a trade or design study). The requirement is also downwards traceable to the specific requirements in the lower tier requirements specifications or other system definition artifacts. That is, all parent-child relationships for the requirement are identified in tracing such that the requirement traces to its source and implementation. <br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 4. Characteristics of a Set of Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Complete'''<br />
|The set of requirements needs no further amplification because it contains everything pertinent to the definition of the system or system element being specified. In addition, the set does not contain any to be defined (TBD), to be specified (TBS), or to be resolved (TBR) clauses. Resolution of the TBx designations may be iterative and there is an acceptable time frame for TBx items, determined by risks and dependencies. Note - Some practices are recommended to improve completeness: include all requirement types, account for requirements in all stages of the life cycle, and involve all stakeholders in the requirements elicitation activity.<br />
|-<br />
|'''Consistent'''<br />
|The set of requirements does not have individual requirements which are contradictory. Requirements are not duplicated. The same term is used for the same item in all requirements. There is nothing in the set of requirements as a whole to invalidate individual requirement traceability or verification.<br />
|-<br />
|'''Feasible'''<br />
|The set of requirements are technically achievable and fits within system and life cycle constraints (e.g., cost, schedule, technical, legal, regulatory, etc.). (Note: Feasible includes the concept of "affordable".)<br />
|-<br />
|'''Bounded'''<br />
|The set of requirements maintains the identified scope for the intended solution without increasing beyond what is necessary to satisfy user needs.<br />
|}<br />
</center><br />
<br />
====Requirements in Tables====<br />
Requirements may be provided in a table, especially when specifying a set of parameters for the system or a system element. It is good practice to make standard table templates available. For tables, the following conventions apply: <br />
* Invoke each requirements table in the requirements set that clearly points to the table.<br />
* Identify each table with a unique title and table number.<br />
* Include the word “requirements” in the table title.<br />
* Identify the purpose of the table in the text immediately preceding it and include an explanation of how to read and use the table, including context and units.<br />
* For independent-dependent variable situations, organize the table in a way that best accommodates the use of the information.<br />
* Each cell should contain, at most, a single requirement.<br />
<br />
====Requirements in Flow Charts====<br />
Flow charts often contain requirements in a graphical form. These requirements may include logic that must be incorporated into the system, operational requirements, process or procedural requirements, or other situations that are best defined graphically by a sequence of interrelated steps. For flow charts, the following conventions apply:<br />
* Invoke flow charts in the requirements set that clearly points to the flow chart.<br />
* Identify each flow chart with a unique title and figure number.<br />
* Include the word “requirements” in the title of the flow chart.<br />
* Clearly indicate and explain unique symbols that represent requirements in the flow chart.<br />
<br />
====Requirements in Drawings====<br />
Drawings also provide a graphical means to define requirements. The type of requirement defined in a drawing depends on the type of drawing. The following conventions apply:<br />
* Drawings are used when they can aid in the description of the following:<br />
** Spatial Requirements<br />
** Interface Requirements<br />
** Layout Requirements<br />
* Invoke drawings in the requirements set that clearly point to the drawing.<br />
<br />
===Artifacts===<br />
This process may create several artifacts, such as:<br />
* System Requirements Document<br />
* System Requirements Justification Document (for traceability purpose)<br />
* System Requirements Database, including traceability, analysis, rationale, decisions, and attributes, where appropriate.<br />
* System External Interface Requirements Document (this document describes the interfaces of the system with external elements of its context of use; the interface requirements can be integrated or not to the system requirements document.<br />
<br />
The content, format, layout and ownership of these artifacts will vary depending on who is creating them as well as in which domain they will be utilized. Between them and the outputs of the process, activities should cover the information identified in the first part of this article.<br />
<br />
==Practical Considerations about System Requirements==<br />
There are several '''pitfalls''' that will inhibit the generation and management of an optimal set of system requirements, as discussed in Table 5.<br />
<br />
<center><br />
{|<br />
|+'''Table 5. Major Pitfalls with Definition of System Requirements.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|'''Insufficient Analysis of Stakeholder Requirements'''<br />
|If the receivers of the stakeholder requirements do not perform a sufficient critical analysis of them, the consequence could be difficulties translating them into system requirements and the obligation to come back to the stakeholders, losing time.<br />
|-<br />
|'''Insufficient Analysis of Operational Modes and Scenarios'''<br />
|The operational modes and operational scenarios are not sufficiently analyzed or defined by the person in charge of writing the system requirements. Those elements allow the structuring of the system and its use early in the engineering process and help the designer to remember functions and interfaces.<br />
|-<br />
|'''Incomplete Set of System Requirements'''<br />
|If the system requirements are not sufficiently precise and complete, there is a great risk that the design will not have the expected level of quality and that the verification and validation of the system will be delayed.<br />
|-<br />
|'''Lack of Verification Method'''<br />
|Delaying the capture of verification methods and events for each system requirement; identification of the verification approach for each requirement often provides additional insight as to the correctness and necessity of the requirement itself.<br />
|-<br />
|'''Missing traceability'''<br />
|Incorrect or missing traceability of each requirement, both to an upper-level "parent" requirement as well as allocation to an inappropriate system or system element.<br />
|}<br />
</center><br />
<br />
<br />
The '''proven practices''' in Table 6 have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development.<br />
<br />
<center><br />
{|<br />
|+'''Table 6. Proven Practices for System Requirements.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|'''Involve Stakeholders'''<br />
|Involve the stakeholders as early as possible in the system requirements development process.<br />
|-<br />
|'''Presence of Rationale'''<br />
|Capture the rationale for each system requirement.<br />
|-<br />
|'''Always Complete before Starting'''<br />
|Check that stakeholder requirements are complete as much as possible before starting the definition of the system requirements.<br />
|-<br />
|'''Peer Reviews'''<br />
|Organize peer reviews of system requirements with applicable subject matter experts.<br />
|-<br />
|'''Modeling Techniques'''<br />
|Use modeling techniques as indicated in sections above.<br />
|-<br />
|'''Requirements Management Tool'''<br />
|Consider using a requirements management tool, especially for more complex projects. This tool should have the capability to trace linkages between system requirements to display relationships. A requirements management tool is intended to facilitate and support the systematic managing of system requirements throughout the project life cycle.<br />
|-<br />
|'''Measures for Requirement Engineering'''<br />
|Use typical measures for requirement engineering; for further information, refer to the ''Systems Engineering Leading Indicators Guide'' (Roedler et al. 2010). Both process and product measures should be used for requirements engineering. To get the desired insight to facilitate risk-managed requirements engineering, it may be necessary to use more than one measure based on the information needs (risks, objectives, issues) for the requirements. Useful measures include:<br />
* Requirements Volatility<br />
* Requirements Trends<br />
* Requirements Verification Progress (plan vs. actual)<br />
* Requirements Validation Progress (plan vs. actual)<br />
* TBD and TBR Closure Per Plan<br />
* Peer Review Defects<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Hauser, J. and D. Clausing. 1988. "The House of Quality." ''Harvard Business Review.'' (May - June 1988). <br />
<br />
Hooks, I.F. and K.A. Farry. 2000. ''Customer-centered products: Creating successful products through smart requirements management''. New York, NY, USA: American Management Association.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering,'' 3rd ed. London, UK: Springer.<br />
<br />
INCOSE. 2011. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities,'' version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ISO/IEC. 2007. ''Systems and Software Engineering -- Recommended Practice for Architectural Description of Software-Intensive Systems''. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 42010:2007.<br />
<br />
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. <br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
Martin, J.N. 1997. ''Systems Engineering Guidebook: A Process for Developing Systems and Products,'' 1st ed. Boca Raton, FL, USA: CRC Press.<br />
<br />
===Primary References===<br />
<br />
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]].<br />
<br />
ISO/IEC/IEEE. 2008. ''[[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]]:2008 (E).<br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities,'' version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]: From System Goals to UML Models to Software Specifications''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com. <br />
<br />
Hooks, I.F. and K.A. Farry. 2000. ''Customer-Centered Products: Creating Successful Products through Smart Requirements Management.'' New York, NY, USA: American Management Association. <br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering,'' 3rd ed. London, UK: Springer.<br />
<br />
Roedler, G., D. Rhodes, C. Jones, and H. Schimmoller. 2010. ''Systems Engineering Leading Indicators Guide,'' version 2.0. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2005-001-03.<br />
<br />
SEI. 2007. "Requirements Management Process Area" and "Requirements Development Process Area." in ''Capability Maturity Model Integrated (CMMI) for Development'', version 1.2. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU). <br />
<br />
----<br />
<br />
<center>[[System Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Logical Architecture Design|Next Article >]]</center><br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Stakeholder_Requirements_Definition&diff=48837Stakeholder Requirements Definition2013-10-23T22:49:16Z<p>Groedler: /* Practical Considerations about System Requirements */</p>
<hr />
<div>[[System Requirement (glossary)|System requirements]] are all of the [[Requirement (glossary)|requirements]] at the ''system level'' that describe the functions which the system as a whole should fulfill to satisfy the [[Stakeholder Requirement (glossary)|stakeholder needs and requirements]], and is expressed in an appropriate combination of textual statements, views, and non-functional requirements; the latter expressing the levels of safety, security, reliability, etc., that will be necessary. <br />
<br />
System requirements play major roles in systems engineering, as they: <br />
* Form the basis of system [[Architecture (glossary)|architecture]] and [[Design (glossary)|design]] activities.<br />
*Form the basis of system [[Integration (glossary)]] and [[Verification (glossary)|verification]] activities.<br />
* Act as reference for [[Validation (glossary)|validation]] and stakeholder acceptance.<br />
* Provide a means of communication between the various technical staff that interact throughout the project.<br />
<br />
Elicitation of stakeholder requirements starts in [[Concept Definition|Concept Definition]], and will be initially developed though interview and mission analysis. System requirements are considered in detail during [[System Definition|System Definition]]. Neither 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. <br />
<br />
==Definition and Purpose of Requirements==<br />
A requirement is a statement that identifies a product or processes operational, functional, or design characteristic or constraint, which is unambiguous, testable, or measurable and necessary for product or process acceptability (ISO/IEC 2007).<br />
<br />
To avoid confusion in the multitude of terms pertaining to ''[[Requirement (glossary)|requirements]]'', consider the following classifications:<br />
* '''Process Role or State''': The role the requirement plays in the definition process; for instance, its position in the system block (e.g. translated, derived, satisfied) or its state of agreement (e.g. proposed, approved, cancelled). <br />
* '''Level of Abstraction''': The level within the definition process that the requirement stands; for instance, stakeholder requirement, system requirement, system element requirement.<br />
* '''Type of Requirement''': The nature of the requirement itself; for instance, functional, performance, constraint, etc.<br />
<br />
Any single requirement may simultaneously be in a particular state, at a particular level abstraction, and of a particular type. For additional explanations about differences between the types of requirements, refer to Chapter 2 of Martin (1997).<br />
<br />
==Principles Governing System Requirements==<br />
===Relationship to Stakeholder Requirements and Logical Architecture===<br />
A set of [[Stakeholder Requirement (glossary)|stakeholder requirements]] are clarified and translated from statements of need into ''engineering-oriented'' language in order to enable proper architecture definition, design, and verification activities that are needed as the basis for system requirements analysis. <br />
<br />
The system requirements are based around identification and synthesis of the functions required of any solution system associated with performance and other quality measures and provide the basis for the assessment candidate solutions and verification of the completed system. The [[System Requirement (glossary)|system requirements]] are expressed in technical language that is useful for architecture and design: unambiguous, consistent, coherent, exhaustive, and verifiable. Of course, close coordination with the stakeholders is necessary to ensure the translation is accurate and traceability is maintained. This results in a set of system functions and requirements specifying measurable characteristics which can form the basis for [[System Realization (glossary)|system realization]].<br />
<br />
The [[Logical Architecture (glossary)]] defines system boundary and functions, from which more detailed system requirements can be derived. The starting point for this process may be to identify functional requirements from the stakeholder requirements and to use this to start the architectural definition, or to begin with a high level functional architecture view and use this as the basis for structuring system requirements. The exact approach taken will often depend on whether the system is an evolution of an already understood product or service, or a new and unprecedented solution (see [[Synthesizing Possible Solutions]]). However, when the process is initiated it is important that the stakeholder requirements, system requirements, and logical architecture are all complete, consistent with each other, and assessed together at the appropriate points in the systems [[Life Cycle Model (glossary)]].<br />
<br />
====Traceability and the Assignment of System Requirements during Architecture and Design====<br />
Requirements traceability provides the ability to track information from the origin of the stakeholder requirements, to the top level of requirements and other system definition elements at all levels of the system hierarchy (see section "Top-down and Recursive Approach to System Decomposition" in the [[System Definition]] article). Traceability is also used to provide an understanding as to the extent of a change as an input when impact analyses is performed in cases of proposed engineering improvements or requests for change.<br />
<br />
During [[Architecture (glossary) |architecture]] definition and [[Design (glossary) |design]], the assignment of requirements from one level to lower levels in the system hierarchy can be accomplished using several methods, as appropriate - see Table 1.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 1. Assessment Types for a System Requirement.''' (SEBoK Original)<br />
!Assignment Type for a System Requirement<br />
!Description<br />
|-<br />
|'''Direct Assignment'''<br />
|The system requirement from the higher level is directly assigned to a system or a system element for a lower level (e.g. the color used to paint visible parts of the product).<br />
|-<br />
|'''Indirect Assignment (Simply Decomposed)'''<br />
|The system requirement is distributed across several systems or system elements and the sum of a more complex calculation for distribution is equal to the requirement of higher level (e.g. a mass requirement, power distribution, reliability allocation, etc.) with sufficient margin or tolerance. A documented and configuration-managed "assignment budget" for each assignment must be maintained.<br />
|-<br />
|'''Indirect Assignment (Modeled and Decomposed)'''<br />
|The system requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique. The resulting design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, in the case of a radar detection requirement that is being analyzed, these lower-level parameters for output power, beam size, frequencies, etc. will be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.<br />
|-<br />
|'''Derived Requirement (from Design)'''<br />
|Such system requirements are developed during the design activities as a result of the decision of the design team, not the stakeholder community. These requirements may include the use of commercial-off-the-shelf (COTS) items, existing systems or system elements in inventory, common components, and similar design decisions in order to produce a "best value" solution for the customer. As such, these derived requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or a constraint.<br />
|}<br />
</center><br />
<br />
===Classification of System Requirements===<br />
Several classifications of system requirements are possible, depending on the requirements definition methods and/or the architecture and design methods being applied. (ISO/IEC 2011) provides a classification which is summarized in Table 2 (see references for additional classifications).<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Example of System Requirements Classification.''' (SEBoK Original)<br />
!Types of System Requirement<br />
!Description<br />
|-<br />
|'''Functional Requirements'''<br />
|Describe qualitatively the system functions or tasks to be performed in operation.<br />
|-<br />
|'''Performance Requirements'''<br />
|Define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task. <br />
|-<br />
|'''Usability Requirements'''<br />
|Define the quality of system use (e.g. measurable effectiveness, efficiency, and satisfaction criteria).<br />
|-<br />
|'''Interface Requirements'''<br />
|Define how the system is required to interact or to exchange material, energy, or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface requirements include physical connections (physical interfaces) with external systems or internal system elements supporting interactions or exchanges.<br />
|-<br />
|'''Operational Requirements'''<br />
|Define the operational conditions or properties that are required for the system to operate or exist. This type of requirement includes: human factors, ergonomics, availability, maintainability, reliability, and security.<br />
|-<br />
|'''Modes and/or States Requirements'''<br />
|Define the various operational modes of the system in use and events conducting to transitions of modes.<br />
|-<br />
|'''Adaptability Requirements'''<br />
|Define potential extension, growth, or scalability during the life of the system.<br />
|-<br />
|'''Physical Constraints'''<br />
|Define constraints on weight, volume, and dimension applicable to the system elements that compose the system.<br />
|-<br />
|'''Design Constraints'''<br />
|Define the limits on the options that are available to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an online repository).<br />
|-<br />
|'''Environmental Conditions'''<br />
|Define the environmental conditions to be encountered by the system in its different operational modes. This should address the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-induced environmental effects (e.g. motion, shock, noise, electromagnetism, thermal, etc.), and threats to societal environment (e.g. legal, political, economic, social, business, etc.).<br />
|-<br />
|'''Logistical Requirements'''<br />
|Define the logistical conditions needed by the continuous utilization of the system. These requirements include sustainment (provision of facilities, level support, support personnel, spare parts, training, technical documentation, etc.), packaging, handling, shipping, transportation.<br />
|-<br />
|'''Policies and Regulations'''<br />
|Define relevant and applicable organizational policies or regulatory requirements that could affect the operation or performance of the system (e.g. labor policies, reports to regulatory agony, health or safety criteria, etc.).<br />
|-<br />
|'''Cost and Schedule Constraints'''<br />
|Define, for example, the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc.<br />
|}<br />
</center><br />
<br />
===Requirements Management===<br />
Requirements management is performed to ensure alignment of the system and system element requirements with other representations, analysis, and artifacts of the system. It includes providing an understanding of the requirements, obtaining commitment, managing changes, maintaining bi-directional traceability among the requirements and with the rest of the system definition, and alignment with project resources and schedule. <br />
<br />
There are many tools available to provide a supporting infrastructure for requirements management; the best choice is the one that matches the processes of the project or enterprise. Requirements management is also closely tied to [[Configuration Management|configuration management]] for baseline management and control. When the requirements have been defined, documented, and approved, they need to be put under baseline management and control. The baseline allows the project to analyze and understand the impact (technical, cost, and schedule) of ongoing proposed changes.<br />
<br />
==Process Approach==<br />
===Purpose and Principle of the Approach===<br />
The purpose of the system requirements analysis process is to transform the stakeholder, user-oriented view of desired services and properties into a technical view of the product that meets the operational needs of the user. This process builds a representation of the system that will meet stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable system requirements that specify, from the supplier’s perspective, what performance and non-performance characteristics it must possess in order to satisfy stakeholders' requirements (ISO/IEC 2008).<br />
<br />
===Activities of the Process===<br />
Major activities and tasks during this process include:<br />
# Analyzing the stakeholder requirements to check completeness of expected services and [[Operational Scenario (glossary)|operational scenarios]], conditions, operational modes, and constraints.<br />
# Defining the system requirements and their [[Rationale (glossary)|rationale]].<br />
# Classifying the system requirements using suggested classifications (see examples above).<br />
# Incorporating the derived requirements (coming from architecture and design) into the system requirements baseline.<br />
# Establishing the upward traceability with the stakeholder needs and requirements. <br />
# Establishing bi-directional traceability between requirements at adjacent levels of the system hierarchy. <br />
# Verifying the quality and completeness of each system requirement and the consistency of the set of system requirements.<br />
# Validating the content and relevance of each system requirement against the set of stakeholder requirements.<br />
# Identifying potential [[Risk (glossary)|risks]] (or threats and hazards) that could be generated by the system requirements.<br />
# Synthesizing, recording, and managing the system requirements and potential associated risks.<br />
# Upon approval of the requirements, establishing control baselines along with the other system definition elements in conjunction with established configuration management practices.<br />
<br />
===Checking Correctness of System Requirements===<br />
System requirements should be checked to gauge whether they are well expressed and appropriate. There are a number of characteristics that can be used to check system requirements, such as standard peer review techniques and comparison of each requirement against the set of requirements characteristics, which are listed in Table 2 and Table 3 of the "Presentation and Quality of Requirements" section (below). Requirements can be further validated using the requirements elicitation and rationale capture described in the section "Methods and Modeling Techniques" (below).<br />
<br />
===Methods and Modeling Techniques===<br />
====Requirements Elicitation and Prototyping====<br />
Requirements elicitation requires user involvement and can be effective in gaining stakeholder involvement and buy-in. Quality Function Deployment (QFD) and prototyping are two common techniques that can be applied and are defined in this section. In addition, interviews, focus groups, and Delphi techniques are often applied to elicit requirements.<br />
<br />
QFD is a powerful technique to elicit requirements and compare design characteristics against user needs (Hauser and Clausing 1988). The inputs to the QFD application are user needs and operational concepts, so it is essential that the users participate. Users from across the life cycle should be included to ensure that all aspects of user needs are accounted for and prioritized.<br />
<br />
Early prototyping can help the users and developers interactively identify functional and operational requirements as well as user interface constraints. This enables realistic user interaction, discovery, and feedback, as well as some sensitivity analysis. This improves the users' understanding of the requirements and increases the probability of satisfying their actual needs.<br />
<br />
====Capturing Requirements Rationale====<br />
One powerful and cost-effective technique to translate stakeholder requirements to system requirements is to capture the rationale for each requirement. Requirements rationale is merely a statement as to why the requirement exists, any assumptions made, the results of related design studies, or any other related supporting information. This supports further requirements analysis and decomposition. The rationale can be captured directly in a requirements database (Hull, Jackson, and Dick 2010).<br />
<br />
Some of the benefits of this approach include:<br />
* '''Reducing the total number of requirements''' - The process aids in identifying duplicates. Reducing requirements count will reduce project cost and risk.<br />
* '''Early exposure of bad assumptions'''<br />
* '''Removes design implementation''' - Many poorly written stakeholder requirements are design requirements in disguise, in that the customer is intentionally or unintentionally specifying a candidate implementation. <br />
* '''Improves communication with the stakeholder community''' - By capturing the requirements rationale for all stakeholder requirements, the line of communication between the users and the designers is greatly improved. (Adapted from Chapter 8 of (Hooks and Farry 2000)).<br />
<br />
====Modeling Techniques====<br />
Modeling techniques that can be used when requirements must be detailed or refined, or in cases in which they address topics not considered during the stakeholder requirements definition and mission analysis, include:<br />
* State-charts models (ISO/IEC 2011, Section 8.4)<br />
* Scenarios modeling (ISO/IEC 2011, Section 6.2.3.1)<br />
* Simulations, prototyping (ISO/IEC 2011, Section 6.3.3.2)<br />
* Quality Function Deployment (INCOSE. 2010, p. 83)<br />
* Sequence diagrams, activity diagrams, use cases, state machine diagrams, Systems Modeling Language (SysML) requirements diagrams<br />
* Functional Flow Block Diagram for operational scenarios<br />
<br />
====Presentation and Quality of Requirements====<br />
Generally, requirements are provided in a textual form. Guidelines exist for writing good requirements; they include recommendations about the syntax of requirements statements, wording (exclusions, representation of concepts, etc.), and characteristics (specific, measurable, achievable, feasible, testable, etc.). Refer to INCOSE (2010, Section 4.2.2.2) and ISO/IEC (2011).<br />
<br />
There are several characteristics of both requirements and sets of requirements that are used to aid their development and to verify the implementation of requirements into the solution. Table 3 provides a list and descriptions of the characteristics for individual requirements and Table 4 provides a list and descriptions of characteristics for a set of requirements, as adapted from ISO/IEC (2011, Sections 5.2.5 and 5.2.6).<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 3. Characteristics of Individual Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Necessary'''<br />
|The requirement defines an essential capability, characteristic, constant, and/or quality factor. If it is removed or deleted, a deficiency will exist which cannot be fulfilled by other capabilities of the product or process.<br />
|-<br />
|'''Implementation Independent'''<br />
|The requirement, while addressing what is necessary and sufficient in the system, avoids placing unnecessary constraints on the architectural design. The objective is to be implementation-independent. The requirement states what is required, not how the requirement should be met.<br />
|-<br />
|'''Unambiguous'''<br />
|The requirement is stated in such a way so that it can be interpreted in only one way. The requirement is stated simply and is easy to understand.<br />
|-<br />
|'''Complete'''<br />
|The stated requirement needs no further amplification because it is measurable and sufficiently describes the capability and characteristics to meet the identified business, mission, and stakeholder needs. <br />
|-<br />
|'''Singular'''<br />
|The requirement statement includes only one requirement with no use of conjunctions.<br />
|-<br />
|'''Achievable'''<br />
|The requirement must be technically achievable within constraints and requires advances in technology within acceptable risk.<br />
|-<br />
|'''Verifiable'''<br />
|The requirement has the means to prove that the system satisfies the specified requirement. Verifiability is enhanced when the requirement is measurable.<br />
|-<br />
|'''Conforming'''<br />
|In many instances, there are applicable government, industry, and product standards, specifications, and interfaces with which compliance is required. The requirement may also need to conform to an organizational template for its sentence structure.<br />
|}<br />
</center><br />
<br />
Note: Traceability is considered by some sources as a characteristic (ISO/IEC (2011)). However, a ercent viewpoint is that Traceability is actually an attribute of a requirement; that is, something that is appended to the requirement, not an intrinsic characteristic of a requirement (INCOSE (2010)). The traceability charteristic or attribute is defined as: The requirement is upwards traceable to specific documented stakeholder statement(s) of need, higher tier requirement, or another source (e.g., a trade or design study). The requirement is also downwards traceable to the specific requirements in the lower tier requirements specifications or other system definition artifacts. That is, all parent-child relationships for the requirement are identified in tracing such that the requirement traces to its source and implementation. <br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 4. Characteristics of a Set of Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Complete'''<br />
|The set of requirements needs no further amplification because it contains everything pertinent to the definition of the system or system element being specified. In addition, the set does not contain any to be defined (TBD), to be specified (TBS), or to be resolved (TBR) clauses. Resolution of the TBx designations may be iterative and there is an acceptable time frame for TBx items, determined by risks and dependencies. Note - Some practices are recommended to improve completeness: include all requirement types, account for requirements in all stages of the life cycle, and involve all stakeholders in the requirements elicitation activity.<br />
|-<br />
|'''Consistent'''<br />
|The set of requirements does not have individual requirements which are contradictory. Requirements are not duplicated. The same term is used for the same item in all requirements. There is nothing in the set of requirements as a whole to invalidate individual requirement traceability or verification.<br />
|-<br />
|'''Feasible'''<br />
|The set of requirements are technically achievable and fits within system and life cycle constraints (e.g., cost, schedule, technical, legal, regulatory, etc.). (Note: Feasible includes the concept of "affordable".)<br />
|-<br />
|'''Bounded'''<br />
|The set of requirements maintains the identified scope for the intended solution without increasing beyond what is necessary to satisfy user needs.<br />
|}<br />
</center><br />
<br />
====Requirements in Tables====<br />
Requirements may be provided in a table, especially when specifying a set of parameters for the system or a system element. It is good practice to make standard table templates available. For tables, the following conventions apply: <br />
* Invoke each requirements table in the requirements set that clearly points to the table.<br />
* Identify each table with a unique title and table number.<br />
* Include the word “requirements” in the table title.<br />
* Identify the purpose of the table in the text immediately preceding it and include an explanation of how to read and use the table, including context and units.<br />
* For independent-dependent variable situations, organize the table in a way that best accommodates the use of the information.<br />
* Each cell should contain, at most, a single requirement.<br />
<br />
====Requirements in Flow Charts====<br />
Flow charts often contain requirements in a graphical form. These requirements may include logic that must be incorporated into the system, operational requirements, process or procedural requirements, or other situations that are best defined graphically by a sequence of interrelated steps. For flow charts, the following conventions apply:<br />
* Invoke flow charts in the requirements set that clearly points to the flow chart.<br />
* Identify each flow chart with a unique title and figure number.<br />
* Include the word “requirements” in the title of the flow chart.<br />
* Clearly indicate and explain unique symbols that represent requirements in the flow chart.<br />
<br />
====Requirements in Drawings====<br />
Drawings also provide a graphical means to define requirements. The type of requirement defined in a drawing depends on the type of drawing. The following conventions apply:<br />
* Drawings are used when they can aid in the description of the following:<br />
** Spatial Requirements<br />
** Interface Requirements<br />
** Layout Requirements<br />
* Invoke drawings in the requirements set that clearly point to the drawing.<br />
<br />
===Artifacts===<br />
This process may create several artifacts, such as:<br />
* System Requirements Document<br />
* System Requirements Justification Document (for traceability purpose)<br />
* System Requirements Database, including traceability, analysis, rationale, decisions, and attributes, where appropriate.<br />
* System External Interface Requirements Document (this document describes the interfaces of the system with external elements of its context of use; the interface requirements can be integrated or not to the system requirements document.<br />
<br />
The content, format, layout and ownership of these artifacts will vary depending on who is creating them as well as in which domain they will be utilized. Between them and the outputs of the process, activities should cover the information identified in the first part of this article.<br />
<br />
==Practical Considerations about System Requirements==<br />
There are several '''pitfalls''' that will inhibit the generation and management of an optimal set of system requirements, as discussed in Table 5.<br />
<br />
<center><br />
{|<br />
|+'''Table 5. Major Pitfalls with Definition of System Requirements.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|'''Insufficient Analysis of Stakeholder Requirements'''<br />
|If the receivers of the stakeholder requirements do not perform a sufficient critical analysis of them, the consequence could be difficulties translating them into system requirements and the obligation to come back to the stakeholders, losing time.<br />
|-<br />
|'''Insufficient Analysis of Operational Modes and Scenarios'''<br />
|The operational modes and operational scenarios are not sufficiently analyzed or defined by the person in charge of writing the system requirements. Those elements allow the structuring of the system and its use early in the engineering process and help the designer to remember functions and interfaces.<br />
|-<br />
|'''Incomplete Set of System Requirements'''<br />
|If the system requirements are not sufficiently precise and complete, there is a great risk that the design will not have the expected level of quality and that the verification and validation of the system will be delayed.<br />
|-<br />
|'''Lack of Verification Method'''<br />
|Delaying the capture of verification methods and events for each system requirement; identification of the verification approach for each requirement often provides additional insight as to the correctness and necessity of the requirement itself.<br />
|-<br />
|'''Missing traceability'''<br />
|Incorrect or missing traceability of each requirement, both to an upper-level "parent" requirement as well as allocation to an inappropriate system or system element.<br />
|}<br />
</center><br />
<br />
<br />
The '''proven practices''' in Table 6 have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development.<br />
<br />
<center><br />
{|<br />
|+'''Table 6. Proven Practices for System Requirements.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|'''Involve Stakeholders'''<br />
|Involve the stakeholders as early as possible in the system requirements development process.<br />
|-<br />
|'''Presence of Rationale'''<br />
|Capture the rationale for each system requirement.<br />
|-<br />
|'''Always Complete before Starting'''<br />
|Check that stakeholder requirements are complete as much as possible before starting the definition of the system requirements.<br />
|-<br />
|'''Peer Reviews'''<br />
|Organize peer reviews of system requirements with applicable subject matter experts.<br />
|-<br />
|'''Modeling Techniques'''<br />
|Use modeling techniques as indicated in sections above.<br />
|-<br />
|'''Requirements Management Tool'''<br />
|Consider using a requirements management tool, especially for more complex projects. This tool should have the capability to trace linkages between system requirements to display relationships. A requirements management tool is intended to facilitate and support the systematic managing of system requirements throughout the project life cycle.<br />
|-<br />
|'''Measures for Requirement Engineering'''<br />
|Use typical measures for requirement engineering; for further information, refer to the ''Systems Engineering Leading Indicators Guide'' (Roedler et al. 2010). Both process and product measures should be used for requirements engineering. To get the desired insight to facilitate risk-managed requirements engineering, it may be necessary to use more than one measure based on the information needs (risks, objectives, issues) for the requirements. Useful measures include:<br />
* Requirements Volatility<br />
* Requirements Trends<br />
* Requirements Verification Progress (plan vs. actual)<br />
* Requirements Validation Progress (plan vs. actual)<br />
* TBD and TBR Closure Per Plan<br />
* Peer Review Defects<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Hauser, J. and D. Clausing. 1988. "The House of Quality." ''Harvard Business Review.'' (May - June 1988). <br />
<br />
Hooks, I.F. and K.A. Farry. 2000. ''Customer-centered products: Creating successful products through smart requirements management''. New York, NY, USA: American Management Association.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering,'' 3rd ed. London, UK: Springer.<br />
<br />
INCOSE. 2011. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities,'' version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ISO/IEC. 2007. ''Systems and Software Engineering -- Recommended Practice for Architectural Description of Software-Intensive Systems''. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 42010:2007.<br />
<br />
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. <br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
Martin, J.N. 1997. ''Systems Engineering Guidebook: A Process for Developing Systems and Products,'' 1st ed. Boca Raton, FL, USA: CRC Press.<br />
<br />
===Primary References===<br />
<br />
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]].<br />
<br />
ISO/IEC/IEEE. 2008. ''[[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]]:2008 (E).<br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities,'' version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]: From System Goals to UML Models to Software Specifications''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com. <br />
<br />
Hooks, I.F. and K.A. Farry. 2000. ''Customer-Centered Products: Creating Successful Products through Smart Requirements Management.'' New York, NY, USA: American Management Association. <br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering,'' 3rd ed. London, UK: Springer.<br />
<br />
Roedler, G., D. Rhodes, C. Jones, and H. Schimmoller. 2010. ''Systems Engineering Leading Indicators Guide,'' version 2.0. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2005-001-03.<br />
<br />
SEI. 2007. "Requirements Management Process Area" and "Requirements Development Process Area." in ''Capability Maturity Model Integrated (CMMI) for Development'', version 1.2. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU). <br />
<br />
----<br />
<br />
<center>[[System Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Logical Architecture Design|Next Article >]]</center><br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Stakeholder_Requirements_Definition&diff=48836Stakeholder Requirements Definition2013-10-23T22:45:19Z<p>Groedler: /* Presentation and Quality of Requirements */</p>
<hr />
<div>[[System Requirement (glossary)|System requirements]] are all of the [[Requirement (glossary)|requirements]] at the ''system level'' that describe the functions which the system as a whole should fulfill to satisfy the [[Stakeholder Requirement (glossary)|stakeholder needs and requirements]], and is expressed in an appropriate combination of textual statements, views, and non-functional requirements; the latter expressing the levels of safety, security, reliability, etc., that will be necessary. <br />
<br />
System requirements play major roles in systems engineering, as they: <br />
* Form the basis of system [[Architecture (glossary)|architecture]] and [[Design (glossary)|design]] activities.<br />
*Form the basis of system [[Integration (glossary)]] and [[Verification (glossary)|verification]] activities.<br />
* Act as reference for [[Validation (glossary)|validation]] and stakeholder acceptance.<br />
* Provide a means of communication between the various technical staff that interact throughout the project.<br />
<br />
Elicitation of stakeholder requirements starts in [[Concept Definition|Concept Definition]], and will be initially developed though interview and mission analysis. System requirements are considered in detail during [[System Definition|System Definition]]. Neither 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. <br />
<br />
==Definition and Purpose of Requirements==<br />
A requirement is a statement that identifies a product or processes operational, functional, or design characteristic or constraint, which is unambiguous, testable, or measurable and necessary for product or process acceptability (ISO/IEC 2007).<br />
<br />
To avoid confusion in the multitude of terms pertaining to ''[[Requirement (glossary)|requirements]]'', consider the following classifications:<br />
* '''Process Role or State''': The role the requirement plays in the definition process; for instance, its position in the system block (e.g. translated, derived, satisfied) or its state of agreement (e.g. proposed, approved, cancelled). <br />
* '''Level of Abstraction''': The level within the definition process that the requirement stands; for instance, stakeholder requirement, system requirement, system element requirement.<br />
* '''Type of Requirement''': The nature of the requirement itself; for instance, functional, performance, constraint, etc.<br />
<br />
Any single requirement may simultaneously be in a particular state, at a particular level abstraction, and of a particular type. For additional explanations about differences between the types of requirements, refer to Chapter 2 of Martin (1997).<br />
<br />
==Principles Governing System Requirements==<br />
===Relationship to Stakeholder Requirements and Logical Architecture===<br />
A set of [[Stakeholder Requirement (glossary)|stakeholder requirements]] are clarified and translated from statements of need into ''engineering-oriented'' language in order to enable proper architecture definition, design, and verification activities that are needed as the basis for system requirements analysis. <br />
<br />
The system requirements are based around identification and synthesis of the functions required of any solution system associated with performance and other quality measures and provide the basis for the assessment candidate solutions and verification of the completed system. The [[System Requirement (glossary)|system requirements]] are expressed in technical language that is useful for architecture and design: unambiguous, consistent, coherent, exhaustive, and verifiable. Of course, close coordination with the stakeholders is necessary to ensure the translation is accurate and traceability is maintained. This results in a set of system functions and requirements specifying measurable characteristics which can form the basis for [[System Realization (glossary)|system realization]].<br />
<br />
The [[Logical Architecture (glossary)]] defines system boundary and functions, from which more detailed system requirements can be derived. The starting point for this process may be to identify functional requirements from the stakeholder requirements and to use this to start the architectural definition, or to begin with a high level functional architecture view and use this as the basis for structuring system requirements. The exact approach taken will often depend on whether the system is an evolution of an already understood product or service, or a new and unprecedented solution (see [[Synthesizing Possible Solutions]]). However, when the process is initiated it is important that the stakeholder requirements, system requirements, and logical architecture are all complete, consistent with each other, and assessed together at the appropriate points in the systems [[Life Cycle Model (glossary)]].<br />
<br />
====Traceability and the Assignment of System Requirements during Architecture and Design====<br />
Requirements traceability provides the ability to track information from the origin of the stakeholder requirements, to the top level of requirements and other system definition elements at all levels of the system hierarchy (see section "Top-down and Recursive Approach to System Decomposition" in the [[System Definition]] article). Traceability is also used to provide an understanding as to the extent of a change as an input when impact analyses is performed in cases of proposed engineering improvements or requests for change.<br />
<br />
During [[Architecture (glossary) |architecture]] definition and [[Design (glossary) |design]], the assignment of requirements from one level to lower levels in the system hierarchy can be accomplished using several methods, as appropriate - see Table 1.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 1. Assessment Types for a System Requirement.''' (SEBoK Original)<br />
!Assignment Type for a System Requirement<br />
!Description<br />
|-<br />
|'''Direct Assignment'''<br />
|The system requirement from the higher level is directly assigned to a system or a system element for a lower level (e.g. the color used to paint visible parts of the product).<br />
|-<br />
|'''Indirect Assignment (Simply Decomposed)'''<br />
|The system requirement is distributed across several systems or system elements and the sum of a more complex calculation for distribution is equal to the requirement of higher level (e.g. a mass requirement, power distribution, reliability allocation, etc.) with sufficient margin or tolerance. A documented and configuration-managed "assignment budget" for each assignment must be maintained.<br />
|-<br />
|'''Indirect Assignment (Modeled and Decomposed)'''<br />
|The system requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique. The resulting design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, in the case of a radar detection requirement that is being analyzed, these lower-level parameters for output power, beam size, frequencies, etc. will be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.<br />
|-<br />
|'''Derived Requirement (from Design)'''<br />
|Such system requirements are developed during the design activities as a result of the decision of the design team, not the stakeholder community. These requirements may include the use of commercial-off-the-shelf (COTS) items, existing systems or system elements in inventory, common components, and similar design decisions in order to produce a "best value" solution for the customer. As such, these derived requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or a constraint.<br />
|}<br />
</center><br />
<br />
===Classification of System Requirements===<br />
Several classifications of system requirements are possible, depending on the requirements definition methods and/or the architecture and design methods being applied. (ISO/IEC 2011) provides a classification which is summarized in Table 2 (see references for additional classifications).<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Example of System Requirements Classification.''' (SEBoK Original)<br />
!Types of System Requirement<br />
!Description<br />
|-<br />
|'''Functional Requirements'''<br />
|Describe qualitatively the system functions or tasks to be performed in operation.<br />
|-<br />
|'''Performance Requirements'''<br />
|Define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task. <br />
|-<br />
|'''Usability Requirements'''<br />
|Define the quality of system use (e.g. measurable effectiveness, efficiency, and satisfaction criteria).<br />
|-<br />
|'''Interface Requirements'''<br />
|Define how the system is required to interact or to exchange material, energy, or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface requirements include physical connections (physical interfaces) with external systems or internal system elements supporting interactions or exchanges.<br />
|-<br />
|'''Operational Requirements'''<br />
|Define the operational conditions or properties that are required for the system to operate or exist. This type of requirement includes: human factors, ergonomics, availability, maintainability, reliability, and security.<br />
|-<br />
|'''Modes and/or States Requirements'''<br />
|Define the various operational modes of the system in use and events conducting to transitions of modes.<br />
|-<br />
|'''Adaptability Requirements'''<br />
|Define potential extension, growth, or scalability during the life of the system.<br />
|-<br />
|'''Physical Constraints'''<br />
|Define constraints on weight, volume, and dimension applicable to the system elements that compose the system.<br />
|-<br />
|'''Design Constraints'''<br />
|Define the limits on the options that are available to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an online repository).<br />
|-<br />
|'''Environmental Conditions'''<br />
|Define the environmental conditions to be encountered by the system in its different operational modes. This should address the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-induced environmental effects (e.g. motion, shock, noise, electromagnetism, thermal, etc.), and threats to societal environment (e.g. legal, political, economic, social, business, etc.).<br />
|-<br />
|'''Logistical Requirements'''<br />
|Define the logistical conditions needed by the continuous utilization of the system. These requirements include sustainment (provision of facilities, level support, support personnel, spare parts, training, technical documentation, etc.), packaging, handling, shipping, transportation.<br />
|-<br />
|'''Policies and Regulations'''<br />
|Define relevant and applicable organizational policies or regulatory requirements that could affect the operation or performance of the system (e.g. labor policies, reports to regulatory agony, health or safety criteria, etc.).<br />
|-<br />
|'''Cost and Schedule Constraints'''<br />
|Define, for example, the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc.<br />
|}<br />
</center><br />
<br />
===Requirements Management===<br />
Requirements management is performed to ensure alignment of the system and system element requirements with other representations, analysis, and artifacts of the system. It includes providing an understanding of the requirements, obtaining commitment, managing changes, maintaining bi-directional traceability among the requirements and with the rest of the system definition, and alignment with project resources and schedule. <br />
<br />
There are many tools available to provide a supporting infrastructure for requirements management; the best choice is the one that matches the processes of the project or enterprise. Requirements management is also closely tied to [[Configuration Management|configuration management]] for baseline management and control. When the requirements have been defined, documented, and approved, they need to be put under baseline management and control. The baseline allows the project to analyze and understand the impact (technical, cost, and schedule) of ongoing proposed changes.<br />
<br />
==Process Approach==<br />
===Purpose and Principle of the Approach===<br />
The purpose of the system requirements analysis process is to transform the stakeholder, user-oriented view of desired services and properties into a technical view of the product that meets the operational needs of the user. This process builds a representation of the system that will meet stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable system requirements that specify, from the supplier’s perspective, what performance and non-performance characteristics it must possess in order to satisfy stakeholders' requirements (ISO/IEC 2008).<br />
<br />
===Activities of the Process===<br />
Major activities and tasks during this process include:<br />
# Analyzing the stakeholder requirements to check completeness of expected services and [[Operational Scenario (glossary)|operational scenarios]], conditions, operational modes, and constraints.<br />
# Defining the system requirements and their [[Rationale (glossary)|rationale]].<br />
# Classifying the system requirements using suggested classifications (see examples above).<br />
# Incorporating the derived requirements (coming from architecture and design) into the system requirements baseline.<br />
# Establishing the upward traceability with the stakeholder needs and requirements. <br />
# Establishing bi-directional traceability between requirements at adjacent levels of the system hierarchy. <br />
# Verifying the quality and completeness of each system requirement and the consistency of the set of system requirements.<br />
# Validating the content and relevance of each system requirement against the set of stakeholder requirements.<br />
# Identifying potential [[Risk (glossary)|risks]] (or threats and hazards) that could be generated by the system requirements.<br />
# Synthesizing, recording, and managing the system requirements and potential associated risks.<br />
# Upon approval of the requirements, establishing control baselines along with the other system definition elements in conjunction with established configuration management practices.<br />
<br />
===Checking Correctness of System Requirements===<br />
System requirements should be checked to gauge whether they are well expressed and appropriate. There are a number of characteristics that can be used to check system requirements, such as standard peer review techniques and comparison of each requirement against the set of requirements characteristics, which are listed in Table 2 and Table 3 of the "Presentation and Quality of Requirements" section (below). Requirements can be further validated using the requirements elicitation and rationale capture described in the section "Methods and Modeling Techniques" (below).<br />
<br />
===Methods and Modeling Techniques===<br />
====Requirements Elicitation and Prototyping====<br />
Requirements elicitation requires user involvement and can be effective in gaining stakeholder involvement and buy-in. Quality Function Deployment (QFD) and prototyping are two common techniques that can be applied and are defined in this section. In addition, interviews, focus groups, and Delphi techniques are often applied to elicit requirements.<br />
<br />
QFD is a powerful technique to elicit requirements and compare design characteristics against user needs (Hauser and Clausing 1988). The inputs to the QFD application are user needs and operational concepts, so it is essential that the users participate. Users from across the life cycle should be included to ensure that all aspects of user needs are accounted for and prioritized.<br />
<br />
Early prototyping can help the users and developers interactively identify functional and operational requirements as well as user interface constraints. This enables realistic user interaction, discovery, and feedback, as well as some sensitivity analysis. This improves the users' understanding of the requirements and increases the probability of satisfying their actual needs.<br />
<br />
====Capturing Requirements Rationale====<br />
One powerful and cost-effective technique to translate stakeholder requirements to system requirements is to capture the rationale for each requirement. Requirements rationale is merely a statement as to why the requirement exists, any assumptions made, the results of related design studies, or any other related supporting information. This supports further requirements analysis and decomposition. The rationale can be captured directly in a requirements database (Hull, Jackson, and Dick 2010).<br />
<br />
Some of the benefits of this approach include:<br />
* '''Reducing the total number of requirements''' - The process aids in identifying duplicates. Reducing requirements count will reduce project cost and risk.<br />
* '''Early exposure of bad assumptions'''<br />
* '''Removes design implementation''' - Many poorly written stakeholder requirements are design requirements in disguise, in that the customer is intentionally or unintentionally specifying a candidate implementation. <br />
* '''Improves communication with the stakeholder community''' - By capturing the requirements rationale for all stakeholder requirements, the line of communication between the users and the designers is greatly improved. (Adapted from Chapter 8 of (Hooks and Farry 2000)).<br />
<br />
====Modeling Techniques====<br />
Modeling techniques that can be used when requirements must be detailed or refined, or in cases in which they address topics not considered during the stakeholder requirements definition and mission analysis, include:<br />
* State-charts models (ISO/IEC 2011, Section 8.4)<br />
* Scenarios modeling (ISO/IEC 2011, Section 6.2.3.1)<br />
* Simulations, prototyping (ISO/IEC 2011, Section 6.3.3.2)<br />
* Quality Function Deployment (INCOSE. 2010, p. 83)<br />
* Sequence diagrams, activity diagrams, use cases, state machine diagrams, Systems Modeling Language (SysML) requirements diagrams<br />
* Functional Flow Block Diagram for operational scenarios<br />
<br />
====Presentation and Quality of Requirements====<br />
Generally, requirements are provided in a textual form. Guidelines exist for writing good requirements; they include recommendations about the syntax of requirements statements, wording (exclusions, representation of concepts, etc.), and characteristics (specific, measurable, achievable, feasible, testable, etc.). Refer to INCOSE (2010, Section 4.2.2.2) and ISO/IEC (2011).<br />
<br />
There are several characteristics of both requirements and sets of requirements that are used to aid their development and to verify the implementation of requirements into the solution. Table 3 provides a list and descriptions of the characteristics for individual requirements and Table 4 provides a list and descriptions of characteristics for a set of requirements, as adapted from ISO/IEC (2011, Sections 5.2.5 and 5.2.6).<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 3. Characteristics of Individual Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Necessary'''<br />
|The requirement defines an essential capability, characteristic, constant, and/or quality factor. If it is removed or deleted, a deficiency will exist which cannot be fulfilled by other capabilities of the product or process.<br />
|-<br />
|'''Implementation Independent'''<br />
|The requirement, while addressing what is necessary and sufficient in the system, avoids placing unnecessary constraints on the architectural design. The objective is to be implementation-independent. The requirement states what is required, not how the requirement should be met.<br />
|-<br />
|'''Unambiguous'''<br />
|The requirement is stated in such a way so that it can be interpreted in only one way. The requirement is stated simply and is easy to understand.<br />
|-<br />
|'''Complete'''<br />
|The stated requirement needs no further amplification because it is measurable and sufficiently describes the capability and characteristics to meet the identified business, mission, and stakeholder needs. <br />
|-<br />
|'''Singular'''<br />
|The requirement statement includes only one requirement with no use of conjunctions.<br />
|-<br />
|'''Achievable'''<br />
|The requirement must be technically achievable within constraints and requires advances in technology within acceptable risk.<br />
|-<br />
|'''Verifiable'''<br />
|The requirement has the means to prove that the system satisfies the specified requirement. Verifiability is enhanced when the requirement is measurable.<br />
|-<br />
|'''Conforming'''<br />
|In many instances, there are applicable government, industry, and product standards, specifications, and interfaces with which compliance is required. The requirement may also need to conform to an organizational template for its sentence structure.<br />
|}<br />
</center><br />
<br />
Note: Traceability is considered by some sources as a characteristic (ISO/IEC (2011)). However, a ercent viewpoint is that Traceability is actually an attribute of a requirement; that is, something that is appended to the requirement, not an intrinsic characteristic of a requirement (INCOSE (2010)). The traceability charteristic or attribute is defined as: The requirement is upwards traceable to specific documented stakeholder statement(s) of need, higher tier requirement, or another source (e.g., a trade or design study). The requirement is also downwards traceable to the specific requirements in the lower tier requirements specifications or other system definition artifacts. That is, all parent-child relationships for the requirement are identified in tracing such that the requirement traces to its source and implementation. <br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 4. Characteristics of a Set of Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Complete'''<br />
|The set of requirements needs no further amplification because it contains everything pertinent to the definition of the system or system element being specified. In addition, the set does not contain any to be defined (TBD), to be specified (TBS), or to be resolved (TBR) clauses. Resolution of the TBx designations may be iterative and there is an acceptable time frame for TBx items, determined by risks and dependencies. Note - Some practices are recommended to improve completeness: include all requirement types, account for requirements in all stages of the life cycle, and involve all stakeholders in the requirements elicitation activity.<br />
|-<br />
|'''Consistent'''<br />
|The set of requirements does not have individual requirements which are contradictory. Requirements are not duplicated. The same term is used for the same item in all requirements. There is nothing in the set of requirements as a whole to invalidate individual requirement traceability or verification.<br />
|-<br />
|'''Feasible'''<br />
|The set of requirements are technically achievable and fits within system and life cycle constraints (e.g., cost, schedule, technical, legal, regulatory, etc.). (Note: Feasible includes the concept of "affordable".)<br />
|-<br />
|'''Bounded'''<br />
|The set of requirements maintains the identified scope for the intended solution without increasing beyond what is necessary to satisfy user needs.<br />
|}<br />
</center><br />
<br />
====Requirements in Tables====<br />
Requirements may be provided in a table, especially when specifying a set of parameters for the system or a system element. It is good practice to make standard table templates available. For tables, the following conventions apply: <br />
* Invoke each requirements table in the requirements set that clearly points to the table.<br />
* Identify each table with a unique title and table number.<br />
* Include the word “requirements” in the table title.<br />
* Identify the purpose of the table in the text immediately preceding it and include an explanation of how to read and use the table, including context and units.<br />
* For independent-dependent variable situations, organize the table in a way that best accommodates the use of the information.<br />
* Each cell should contain, at most, a single requirement.<br />
<br />
====Requirements in Flow Charts====<br />
Flow charts often contain requirements in a graphical form. These requirements may include logic that must be incorporated into the system, operational requirements, process or procedural requirements, or other situations that are best defined graphically by a sequence of interrelated steps. For flow charts, the following conventions apply:<br />
* Invoke flow charts in the requirements set that clearly points to the flow chart.<br />
* Identify each flow chart with a unique title and figure number.<br />
* Include the word “requirements” in the title of the flow chart.<br />
* Clearly indicate and explain unique symbols that represent requirements in the flow chart.<br />
<br />
====Requirements in Drawings====<br />
Drawings also provide a graphical means to define requirements. The type of requirement defined in a drawing depends on the type of drawing. The following conventions apply:<br />
* Drawings are used when they can aid in the description of the following:<br />
** Spatial Requirements<br />
** Interface Requirements<br />
** Layout Requirements<br />
* Invoke drawings in the requirements set that clearly point to the drawing.<br />
<br />
===Artifacts===<br />
This process may create several artifacts, such as:<br />
* System Requirements Document<br />
* System Requirements Justification Document (for traceability purpose)<br />
* System Requirements Database, including traceability, analysis, rationale, decisions, and attributes, where appropriate.<br />
* System External Interface Requirements Document (this document describes the interfaces of the system with external elements of its context of use; the interface requirements can be integrated or not to the system requirements document.<br />
<br />
The content, format, layout and ownership of these artifacts will vary depending on who is creating them as well as in which domain they will be utilized. Between them and the outputs of the process, activities should cover the information identified in the first part of this article.<br />
<br />
==Practical Considerations about System Requirements==<br />
There are several '''pitfalls''' that will inhibit the generation and management of an optimal set of system requirements, as discussed in Table 5.<br />
<br />
<center><br />
{|<br />
|+'''Table 5. Major Pitfalls with Definition of System Requirements.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|'''Insufficient Analysis of Stakeholder Requirements'''<br />
|If he receivers of the stakeholder requirements do not perform a sufficient critical analysis of them, the consequence could be difficulties translating them into system requirements and the obligation to come back to the stakeholders, losing time.<br />
|-<br />
|'''Insufficient Analysis of Operational Modes and Scenarios'''<br />
|The operational modes and operational scenarios are not sufficiently analyzed or defined by the person in charge of writing the system requirements. Those elements allow the structuring of the system and its use early in the engineering process and help the designer to remember functions and interfaces.<br />
|-<br />
|'''Incomplete Set of System Requirements'''<br />
|If the system requirements are not sufficiently precise and complete, there is a great risk that the design will not have the expected level of quality and that the verification and validation of the system will be delayed.<br />
|-<br />
|'''Lack of Verification Method'''<br />
|Delaying the capture of verification methods and events for each system requirement; identification of the verification approach for each requirement often provides additional insight as to the correctness and necessity of the requirement itself.<br />
|-<br />
|'''Missing traceability'''<br />
|Incorrect or missing traceability of each requirement, both to an upper-level "parent" requirement as well as allocation to an inappropriate system or system element.<br />
|}<br />
</center><br />
<br />
<br />
The '''proven practices''' in Table 6 have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development.<br />
<br />
<center><br />
{|<br />
|+'''Table 6. Proven Practices for System Requirements.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|'''Involve Stakeholders'''<br />
|Involve the stakeholders as early as possible in the system requirements development process.<br />
|-<br />
|'''Presence of Rationale'''<br />
|Capture the rationale for each system requirement.<br />
|-<br />
|'''Always Complete before Starting'''<br />
|Check that stakeholder requirements are complete as much as possible before starting the definition of the system requirements.<br />
|-<br />
|'''Peer Reviews'''<br />
|Organize peer reviews of system requirements with applicable subject matter experts.<br />
|-<br />
|'''Modeling Techniques'''<br />
|Use modeling techniques as indicated in sections above.<br />
|-<br />
|'''Requirements Management Tool'''<br />
|Consider using a requirements management tool, especially for more complex projects. This tool should have the capability to trace linkages between system requirements to display relationships. A requirements management tool is intended to facilitate and support the systematic managing of system requirements throughout the project life cycle.<br />
|-<br />
|'''Measures for Requirement Engineering'''<br />
|Use typical measures for requirement engineering; for further information, refer to the ''Systems Engineering Leading Indicators Guide'' (Roedler et al. 2010). Both process and product measures should be used for requirements engineering. To get the desired insight to facilitate risk-managed requirements engineering, it may be necessary to use more than one measure based on the information needs (risks, objectives, issues) for the requirements. Useful measures include:<br />
* Requirements Volatility<br />
* Requirements Trends<br />
* Requirements Verification Progress (plan vs. actual)<br />
* Requirements Validation Progress (plan vs. actual)<br />
* TBD and TBR Closure Per Plan<br />
* Peer Review Defects<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Hauser, J. and D. Clausing. 1988. "The House of Quality." ''Harvard Business Review.'' (May - June 1988). <br />
<br />
Hooks, I.F. and K.A. Farry. 2000. ''Customer-centered products: Creating successful products through smart requirements management''. New York, NY, USA: American Management Association.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering,'' 3rd ed. London, UK: Springer.<br />
<br />
INCOSE. 2011. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities,'' version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ISO/IEC. 2007. ''Systems and Software Engineering -- Recommended Practice for Architectural Description of Software-Intensive Systems''. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 42010:2007.<br />
<br />
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. <br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
Martin, J.N. 1997. ''Systems Engineering Guidebook: A Process for Developing Systems and Products,'' 1st ed. Boca Raton, FL, USA: CRC Press.<br />
<br />
===Primary References===<br />
<br />
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]].<br />
<br />
ISO/IEC/IEEE. 2008. ''[[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]]:2008 (E).<br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities,'' version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]: From System Goals to UML Models to Software Specifications''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com. <br />
<br />
Hooks, I.F. and K.A. Farry. 2000. ''Customer-Centered Products: Creating Successful Products through Smart Requirements Management.'' New York, NY, USA: American Management Association. <br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering,'' 3rd ed. London, UK: Springer.<br />
<br />
Roedler, G., D. Rhodes, C. Jones, and H. Schimmoller. 2010. ''Systems Engineering Leading Indicators Guide,'' version 2.0. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2005-001-03.<br />
<br />
SEI. 2007. "Requirements Management Process Area" and "Requirements Development Process Area." in ''Capability Maturity Model Integrated (CMMI) for Development'', version 1.2. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU). <br />
<br />
----<br />
<br />
<center>[[System Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Logical Architecture Design|Next Article >]]</center><br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Stakeholder_Requirements_Definition&diff=48835Stakeholder Requirements Definition2013-10-23T22:36:24Z<p>Groedler: /* Presentation and Quality of Requirements */</p>
<hr />
<div>[[System Requirement (glossary)|System requirements]] are all of the [[Requirement (glossary)|requirements]] at the ''system level'' that describe the functions which the system as a whole should fulfill to satisfy the [[Stakeholder Requirement (glossary)|stakeholder needs and requirements]], and is expressed in an appropriate combination of textual statements, views, and non-functional requirements; the latter expressing the levels of safety, security, reliability, etc., that will be necessary. <br />
<br />
System requirements play major roles in systems engineering, as they: <br />
* Form the basis of system [[Architecture (glossary)|architecture]] and [[Design (glossary)|design]] activities.<br />
*Form the basis of system [[Integration (glossary)]] and [[Verification (glossary)|verification]] activities.<br />
* Act as reference for [[Validation (glossary)|validation]] and stakeholder acceptance.<br />
* Provide a means of communication between the various technical staff that interact throughout the project.<br />
<br />
Elicitation of stakeholder requirements starts in [[Concept Definition|Concept Definition]], and will be initially developed though interview and mission analysis. System requirements are considered in detail during [[System Definition|System Definition]]. Neither 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. <br />
<br />
==Definition and Purpose of Requirements==<br />
A requirement is a statement that identifies a product or processes operational, functional, or design characteristic or constraint, which is unambiguous, testable, or measurable and necessary for product or process acceptability (ISO/IEC 2007).<br />
<br />
To avoid confusion in the multitude of terms pertaining to ''[[Requirement (glossary)|requirements]]'', consider the following classifications:<br />
* '''Process Role or State''': The role the requirement plays in the definition process; for instance, its position in the system block (e.g. translated, derived, satisfied) or its state of agreement (e.g. proposed, approved, cancelled). <br />
* '''Level of Abstraction''': The level within the definition process that the requirement stands; for instance, stakeholder requirement, system requirement, system element requirement.<br />
* '''Type of Requirement''': The nature of the requirement itself; for instance, functional, performance, constraint, etc.<br />
<br />
Any single requirement may simultaneously be in a particular state, at a particular level abstraction, and of a particular type. For additional explanations about differences between the types of requirements, refer to Chapter 2 of Martin (1997).<br />
<br />
==Principles Governing System Requirements==<br />
===Relationship to Stakeholder Requirements and Logical Architecture===<br />
A set of [[Stakeholder Requirement (glossary)|stakeholder requirements]] are clarified and translated from statements of need into ''engineering-oriented'' language in order to enable proper architecture definition, design, and verification activities that are needed as the basis for system requirements analysis. <br />
<br />
The system requirements are based around identification and synthesis of the functions required of any solution system associated with performance and other quality measures and provide the basis for the assessment candidate solutions and verification of the completed system. The [[System Requirement (glossary)|system requirements]] are expressed in technical language that is useful for architecture and design: unambiguous, consistent, coherent, exhaustive, and verifiable. Of course, close coordination with the stakeholders is necessary to ensure the translation is accurate and traceability is maintained. This results in a set of system functions and requirements specifying measurable characteristics which can form the basis for [[System Realization (glossary)|system realization]].<br />
<br />
The [[Logical Architecture (glossary)]] defines system boundary and functions, from which more detailed system requirements can be derived. The starting point for this process may be to identify functional requirements from the stakeholder requirements and to use this to start the architectural definition, or to begin with a high level functional architecture view and use this as the basis for structuring system requirements. The exact approach taken will often depend on whether the system is an evolution of an already understood product or service, or a new and unprecedented solution (see [[Synthesizing Possible Solutions]]). However, when the process is initiated it is important that the stakeholder requirements, system requirements, and logical architecture are all complete, consistent with each other, and assessed together at the appropriate points in the systems [[Life Cycle Model (glossary)]].<br />
<br />
====Traceability and the Assignment of System Requirements during Architecture and Design====<br />
Requirements traceability provides the ability to track information from the origin of the stakeholder requirements, to the top level of requirements and other system definition elements at all levels of the system hierarchy (see section "Top-down and Recursive Approach to System Decomposition" in the [[System Definition]] article). Traceability is also used to provide an understanding as to the extent of a change as an input when impact analyses is performed in cases of proposed engineering improvements or requests for change.<br />
<br />
During [[Architecture (glossary) |architecture]] definition and [[Design (glossary) |design]], the assignment of requirements from one level to lower levels in the system hierarchy can be accomplished using several methods, as appropriate - see Table 1.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 1. Assessment Types for a System Requirement.''' (SEBoK Original)<br />
!Assignment Type for a System Requirement<br />
!Description<br />
|-<br />
|'''Direct Assignment'''<br />
|The system requirement from the higher level is directly assigned to a system or a system element for a lower level (e.g. the color used to paint visible parts of the product).<br />
|-<br />
|'''Indirect Assignment (Simply Decomposed)'''<br />
|The system requirement is distributed across several systems or system elements and the sum of a more complex calculation for distribution is equal to the requirement of higher level (e.g. a mass requirement, power distribution, reliability allocation, etc.) with sufficient margin or tolerance. A documented and configuration-managed "assignment budget" for each assignment must be maintained.<br />
|-<br />
|'''Indirect Assignment (Modeled and Decomposed)'''<br />
|The system requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique. The resulting design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, in the case of a radar detection requirement that is being analyzed, these lower-level parameters for output power, beam size, frequencies, etc. will be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.<br />
|-<br />
|'''Derived Requirement (from Design)'''<br />
|Such system requirements are developed during the design activities as a result of the decision of the design team, not the stakeholder community. These requirements may include the use of commercial-off-the-shelf (COTS) items, existing systems or system elements in inventory, common components, and similar design decisions in order to produce a "best value" solution for the customer. As such, these derived requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or a constraint.<br />
|}<br />
</center><br />
<br />
===Classification of System Requirements===<br />
Several classifications of system requirements are possible, depending on the requirements definition methods and/or the architecture and design methods being applied. (ISO/IEC 2011) provides a classification which is summarized in Table 2 (see references for additional classifications).<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Example of System Requirements Classification.''' (SEBoK Original)<br />
!Types of System Requirement<br />
!Description<br />
|-<br />
|'''Functional Requirements'''<br />
|Describe qualitatively the system functions or tasks to be performed in operation.<br />
|-<br />
|'''Performance Requirements'''<br />
|Define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task. <br />
|-<br />
|'''Usability Requirements'''<br />
|Define the quality of system use (e.g. measurable effectiveness, efficiency, and satisfaction criteria).<br />
|-<br />
|'''Interface Requirements'''<br />
|Define how the system is required to interact or to exchange material, energy, or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface requirements include physical connections (physical interfaces) with external systems or internal system elements supporting interactions or exchanges.<br />
|-<br />
|'''Operational Requirements'''<br />
|Define the operational conditions or properties that are required for the system to operate or exist. This type of requirement includes: human factors, ergonomics, availability, maintainability, reliability, and security.<br />
|-<br />
|'''Modes and/or States Requirements'''<br />
|Define the various operational modes of the system in use and events conducting to transitions of modes.<br />
|-<br />
|'''Adaptability Requirements'''<br />
|Define potential extension, growth, or scalability during the life of the system.<br />
|-<br />
|'''Physical Constraints'''<br />
|Define constraints on weight, volume, and dimension applicable to the system elements that compose the system.<br />
|-<br />
|'''Design Constraints'''<br />
|Define the limits on the options that are available to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an online repository).<br />
|-<br />
|'''Environmental Conditions'''<br />
|Define the environmental conditions to be encountered by the system in its different operational modes. This should address the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-induced environmental effects (e.g. motion, shock, noise, electromagnetism, thermal, etc.), and threats to societal environment (e.g. legal, political, economic, social, business, etc.).<br />
|-<br />
|'''Logistical Requirements'''<br />
|Define the logistical conditions needed by the continuous utilization of the system. These requirements include sustainment (provision of facilities, level support, support personnel, spare parts, training, technical documentation, etc.), packaging, handling, shipping, transportation.<br />
|-<br />
|'''Policies and Regulations'''<br />
|Define relevant and applicable organizational policies or regulatory requirements that could affect the operation or performance of the system (e.g. labor policies, reports to regulatory agony, health or safety criteria, etc.).<br />
|-<br />
|'''Cost and Schedule Constraints'''<br />
|Define, for example, the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc.<br />
|}<br />
</center><br />
<br />
===Requirements Management===<br />
Requirements management is performed to ensure alignment of the system and system element requirements with other representations, analysis, and artifacts of the system. It includes providing an understanding of the requirements, obtaining commitment, managing changes, maintaining bi-directional traceability among the requirements and with the rest of the system definition, and alignment with project resources and schedule. <br />
<br />
There are many tools available to provide a supporting infrastructure for requirements management; the best choice is the one that matches the processes of the project or enterprise. Requirements management is also closely tied to [[Configuration Management|configuration management]] for baseline management and control. When the requirements have been defined, documented, and approved, they need to be put under baseline management and control. The baseline allows the project to analyze and understand the impact (technical, cost, and schedule) of ongoing proposed changes.<br />
<br />
==Process Approach==<br />
===Purpose and Principle of the Approach===<br />
The purpose of the system requirements analysis process is to transform the stakeholder, user-oriented view of desired services and properties into a technical view of the product that meets the operational needs of the user. This process builds a representation of the system that will meet stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable system requirements that specify, from the supplier’s perspective, what performance and non-performance characteristics it must possess in order to satisfy stakeholders' requirements (ISO/IEC 2008).<br />
<br />
===Activities of the Process===<br />
Major activities and tasks during this process include:<br />
# Analyzing the stakeholder requirements to check completeness of expected services and [[Operational Scenario (glossary)|operational scenarios]], conditions, operational modes, and constraints.<br />
# Defining the system requirements and their [[Rationale (glossary)|rationale]].<br />
# Classifying the system requirements using suggested classifications (see examples above).<br />
# Incorporating the derived requirements (coming from architecture and design) into the system requirements baseline.<br />
# Establishing the upward traceability with the stakeholder needs and requirements. <br />
# Establishing bi-directional traceability between requirements at adjacent levels of the system hierarchy. <br />
# Verifying the quality and completeness of each system requirement and the consistency of the set of system requirements.<br />
# Validating the content and relevance of each system requirement against the set of stakeholder requirements.<br />
# Identifying potential [[Risk (glossary)|risks]] (or threats and hazards) that could be generated by the system requirements.<br />
# Synthesizing, recording, and managing the system requirements and potential associated risks.<br />
# Upon approval of the requirements, establishing control baselines along with the other system definition elements in conjunction with established configuration management practices.<br />
<br />
===Checking Correctness of System Requirements===<br />
System requirements should be checked to gauge whether they are well expressed and appropriate. There are a number of characteristics that can be used to check system requirements, such as standard peer review techniques and comparison of each requirement against the set of requirements characteristics, which are listed in Table 2 and Table 3 of the "Presentation and Quality of Requirements" section (below). Requirements can be further validated using the requirements elicitation and rationale capture described in the section "Methods and Modeling Techniques" (below).<br />
<br />
===Methods and Modeling Techniques===<br />
====Requirements Elicitation and Prototyping====<br />
Requirements elicitation requires user involvement and can be effective in gaining stakeholder involvement and buy-in. Quality Function Deployment (QFD) and prototyping are two common techniques that can be applied and are defined in this section. In addition, interviews, focus groups, and Delphi techniques are often applied to elicit requirements.<br />
<br />
QFD is a powerful technique to elicit requirements and compare design characteristics against user needs (Hauser and Clausing 1988). The inputs to the QFD application are user needs and operational concepts, so it is essential that the users participate. Users from across the life cycle should be included to ensure that all aspects of user needs are accounted for and prioritized.<br />
<br />
Early prototyping can help the users and developers interactively identify functional and operational requirements as well as user interface constraints. This enables realistic user interaction, discovery, and feedback, as well as some sensitivity analysis. This improves the users' understanding of the requirements and increases the probability of satisfying their actual needs.<br />
<br />
====Capturing Requirements Rationale====<br />
One powerful and cost-effective technique to translate stakeholder requirements to system requirements is to capture the rationale for each requirement. Requirements rationale is merely a statement as to why the requirement exists, any assumptions made, the results of related design studies, or any other related supporting information. This supports further requirements analysis and decomposition. The rationale can be captured directly in a requirements database (Hull, Jackson, and Dick 2010).<br />
<br />
Some of the benefits of this approach include:<br />
* '''Reducing the total number of requirements''' - The process aids in identifying duplicates. Reducing requirements count will reduce project cost and risk.<br />
* '''Early exposure of bad assumptions'''<br />
* '''Removes design implementation''' - Many poorly written stakeholder requirements are design requirements in disguise, in that the customer is intentionally or unintentionally specifying a candidate implementation. <br />
* '''Improves communication with the stakeholder community''' - By capturing the requirements rationale for all stakeholder requirements, the line of communication between the users and the designers is greatly improved. (Adapted from Chapter 8 of (Hooks and Farry 2000)).<br />
<br />
====Modeling Techniques====<br />
Modeling techniques that can be used when requirements must be detailed or refined, or in cases in which they address topics not considered during the stakeholder requirements definition and mission analysis, include:<br />
* State-charts models (ISO/IEC 2011, Section 8.4)<br />
* Scenarios modeling (ISO/IEC 2011, Section 6.2.3.1)<br />
* Simulations, prototyping (ISO/IEC 2011, Section 6.3.3.2)<br />
* Quality Function Deployment (INCOSE. 2010, p. 83)<br />
* Sequence diagrams, activity diagrams, use cases, state machine diagrams, Systems Modeling Language (SysML) requirements diagrams<br />
* Functional Flow Block Diagram for operational scenarios<br />
<br />
====Presentation and Quality of Requirements====<br />
Generally, requirements are provided in a textual form. Guidelines exist for writing good requirements; they include recommendations about the syntax of requirements statements, wording (exclusions, representation of concepts, etc.), and characteristics (specific, measurable, achievable, feasible, testable, etc.). Refer to INCOSE (2010, Section 4.2.2.2) and ISO/IEC (2011).<br />
<br />
There are several characteristics of both requirements and sets of requirements that are used to aid their development and to verify the implementation of requirements into the solution. Table 3 provides a list and descriptions of the characteristics for individual requirements and Table 4 provides a list and descriptions of characteristics for a set of requirements, as adapted from ISO/IEC (2011, Sections 5.2.5 and 5.2.6).<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 3. Characteristics of Individual Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Necessary'''<br />
|The requirement defines an essential capability, characteristic, constant, and/or quality factor. If it is removed or deleted, a deficiency will exist which cannot be fulfilled by other capabilities of the product or process.<br />
|-<br />
|'''Implementation Independent'''<br />
|The requirement, while addressing what is necessary and sufficient in the system, avoids placing unnecessary constraints on the architectural design. The objective is to be implementation-independent. The requirement states what is required, not how the requirement should be met.<br />
|-<br />
|'''Unambiguous'''<br />
|The requirement is stated in such a way so that it can be interpreted in only one way. The requirement is stated simply and is easy to understand.<br />
|-<br />
|'''Complete'''<br />
|The stated requirement needs no further amplification because it is measurable and sufficiently describes the capability and characteristics to meet the identified business, mission, and stakeholder needs. <br />
|-<br />
|'''Singular'''<br />
|The requirement statement includes only one requirement with no use of conjunctions.<br />
|-<br />
|'''Achievable'''<br />
|The requirement must be technically achievable within constraints and requires advances in technology within acceptable risk.<br />
|-<br />
|'''Verifiable'''<br />
|The requirement has the means to prove that the system satisfies the specified requirement. Verifiability is enhanced when the requirement is measurable.<br />
|-<br />
|'''Conforming'''<br />
|In many instances, there are applicable government, industry, and product standards, specifications, and interfaces with which compliance is required. The requirement may also need to conform to an organizational template for its sentence structure.<br />
|}<br />
</center><br />
<br />
Note: Traceability is considered by some sources as a characteristic. However, a ercent viewpoint is that Traceability is actually an attribute of a requirement (that is, something that is appended to the requirement, not an intrinsic characteristic of a requirement). The traceability charteristic or attribute is defined as: The requirement is upwards traceable to specific documented stakeholder statement(s) of need, higher tier requirement, or another source (e.g., a trade or design study). The requirement is also downwards traceable to the specific requirements in the lower tier requirements specifications or other system definition artifacts. That is, all parent-child relationships for the requirement are identified in tracing such that the requirement traces to its source and implementation. <br />
<br />
<center><br />
{|<br />
|+'''Table 4. Characteristics of a Set of Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Complete'''<br />
|The set of requirements needs no further amplification because it contains everything pertinent to the definition of the system or system element being specified. In addition, the set does not contain any to be defined (TBD), to be specified (TBS), or to be resolved (TBR) clauses. Resolution of the TBx designations may be iterative and there is an acceptable time frame for TBx items, determined by risks and dependencies. Note - Some practices are recommended to improve completeness: include all requirement types, account for requirements in all stages of the life cycle, and involve all stakeholders in the requirements elicitation activity.<br />
|-<br />
|'''Consistent'''<br />
|The set of requirements does not have individual requirements which are contradictory. Requirements are not duplicated. The same term is used for the same item in all requirements. There is nothing in the set of requirements as a whole to invalidate individual requirement traceability or verification.<br />
|-<br />
|'''Feasible'''<br />
|The set of requirements are technically achievable and fits within system and life cycle constraints (e.g., cost, schedule, technical, legal, regulatory, etc.). (Note: Also, known as "affordable".)<br />
|-<br />
|'''Bounded'''<br />
|The set of requirements maintains the identified scope for the intended solution without increasing beyond what is necessary to satisfy user needs.<br />
|}<br />
</center><br />
<br />
====Requirements in Tables====<br />
Requirements may be provided in a table, especially when specifying a set of parameters for the system or a system element. It is good practice to make standard table templates available. For tables, the following conventions apply: <br />
* Invoke each requirements table in the requirements set that clearly points to the table.<br />
* Identify each table with a unique title and table number.<br />
* Include the word “requirements” in the table title.<br />
* Identify the purpose of the table in the text immediately preceding it and include an explanation of how to read and use the table, including context and units.<br />
* For independent-dependent variable situations, organize the table in a way that best accommodates the use of the information.<br />
* Each cell should contain, at most, a single requirement.<br />
<br />
====Requirements in Flow Charts====<br />
Flow charts often contain requirements in a graphical form. These requirements may include logic that must be incorporated into the system, operational requirements, process or procedural requirements, or other situations that are best defined graphically by a sequence of interrelated steps. For flow charts, the following conventions apply:<br />
* Invoke flow charts in the requirements set that clearly points to the flow chart.<br />
* Identify each flow chart with a unique title and figure number.<br />
* Include the word “requirements” in the title of the flow chart.<br />
* Clearly indicate and explain unique symbols that represent requirements in the flow chart.<br />
<br />
====Requirements in Drawings====<br />
Drawings also provide a graphical means to define requirements. The type of requirement defined in a drawing depends on the type of drawing. The following conventions apply:<br />
* Drawings are used when they can aid in the description of the following:<br />
** Spatial Requirements<br />
** Interface Requirements<br />
** Layout Requirements<br />
* Invoke drawings in the requirements set that clearly point to the drawing.<br />
<br />
===Artifacts===<br />
This process may create several artifacts, such as:<br />
* System Requirements Document<br />
* System Requirements Justification Document (for traceability purpose)<br />
* System Requirements Database, including traceability, analysis, rationale, decisions, and attributes, where appropriate.<br />
* System External Interface Requirements Document (this document describes the interfaces of the system with external elements of its context of use; the interface requirements can be integrated or not to the system requirements document.<br />
<br />
The content, format, layout and ownership of these artifacts will vary depending on who is creating them as well as in which domain they will be utilized. Between them and the outputs of the process, activities should cover the information identified in the first part of this article.<br />
<br />
==Practical Considerations about System Requirements==<br />
There are several '''pitfalls''' that will inhibit the generation and management of an optimal set of system requirements, as discussed in Table 5.<br />
<br />
<center><br />
{|<br />
|+'''Table 5. Major Pitfalls with Definition of System Requirements.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|'''Insufficient Analysis of Stakeholder Requirements'''<br />
|If he receivers of the stakeholder requirements do not perform a sufficient critical analysis of them, the consequence could be difficulties translating them into system requirements and the obligation to come back to the stakeholders, losing time.<br />
|-<br />
|'''Insufficient Analysis of Operational Modes and Scenarios'''<br />
|The operational modes and operational scenarios are not sufficiently analyzed or defined by the person in charge of writing the system requirements. Those elements allow the structuring of the system and its use early in the engineering process and help the designer to remember functions and interfaces.<br />
|-<br />
|'''Incomplete Set of System Requirements'''<br />
|If the system requirements are not sufficiently precise and complete, there is a great risk that the design will not have the expected level of quality and that the verification and validation of the system will be delayed.<br />
|-<br />
|'''Lack of Verification Method'''<br />
|Delaying the capture of verification methods and events for each system requirement; identification of the verification approach for each requirement often provides additional insight as to the correctness and necessity of the requirement itself.<br />
|-<br />
|'''Missing traceability'''<br />
|Incorrect or missing traceability of each requirement, both to an upper-level "parent" requirement as well as allocation to an inappropriate system or system element.<br />
|}<br />
</center><br />
<br />
<br />
The '''proven practices''' in Table 6 have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development.<br />
<br />
<center><br />
{|<br />
|+'''Table 6. Proven Practices for System Requirements.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|'''Involve Stakeholders'''<br />
|Involve the stakeholders as early as possible in the system requirements development process.<br />
|-<br />
|'''Presence of Rationale'''<br />
|Capture the rationale for each system requirement.<br />
|-<br />
|'''Always Complete before Starting'''<br />
|Check that stakeholder requirements are complete as much as possible before starting the definition of the system requirements.<br />
|-<br />
|'''Peer Reviews'''<br />
|Organize peer reviews of system requirements with applicable subject matter experts.<br />
|-<br />
|'''Modeling Techniques'''<br />
|Use modeling techniques as indicated in sections above.<br />
|-<br />
|'''Requirements Management Tool'''<br />
|Consider using a requirements management tool, especially for more complex projects. This tool should have the capability to trace linkages between system requirements to display relationships. A requirements management tool is intended to facilitate and support the systematic managing of system requirements throughout the project life cycle.<br />
|-<br />
|'''Measures for Requirement Engineering'''<br />
|Use typical measures for requirement engineering; for further information, refer to the ''Systems Engineering Leading Indicators Guide'' (Roedler et al. 2010). Both process and product measures should be used for requirements engineering. To get the desired insight to facilitate risk-managed requirements engineering, it may be necessary to use more than one measure based on the information needs (risks, objectives, issues) for the requirements. Useful measures include:<br />
* Requirements Volatility<br />
* Requirements Trends<br />
* Requirements Verification Progress (plan vs. actual)<br />
* Requirements Validation Progress (plan vs. actual)<br />
* TBD and TBR Closure Per Plan<br />
* Peer Review Defects<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Hauser, J. and D. Clausing. 1988. "The House of Quality." ''Harvard Business Review.'' (May - June 1988). <br />
<br />
Hooks, I.F. and K.A. Farry. 2000. ''Customer-centered products: Creating successful products through smart requirements management''. New York, NY, USA: American Management Association.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering,'' 3rd ed. London, UK: Springer.<br />
<br />
INCOSE. 2011. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities,'' version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ISO/IEC. 2007. ''Systems and Software Engineering -- Recommended Practice for Architectural Description of Software-Intensive Systems''. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 42010:2007.<br />
<br />
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. <br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
Martin, J.N. 1997. ''Systems Engineering Guidebook: A Process for Developing Systems and Products,'' 1st ed. Boca Raton, FL, USA: CRC Press.<br />
<br />
===Primary References===<br />
<br />
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]].<br />
<br />
ISO/IEC/IEEE. 2008. ''[[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]]:2008 (E).<br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities,'' version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]: From System Goals to UML Models to Software Specifications''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com. <br />
<br />
Hooks, I.F. and K.A. Farry. 2000. ''Customer-Centered Products: Creating Successful Products through Smart Requirements Management.'' New York, NY, USA: American Management Association. <br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering,'' 3rd ed. London, UK: Springer.<br />
<br />
Roedler, G., D. Rhodes, C. Jones, and H. Schimmoller. 2010. ''Systems Engineering Leading Indicators Guide,'' version 2.0. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2005-001-03.<br />
<br />
SEI. 2007. "Requirements Management Process Area" and "Requirements Development Process Area." in ''Capability Maturity Model Integrated (CMMI) for Development'', version 1.2. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU). <br />
<br />
----<br />
<br />
<center>[[System Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Logical Architecture Design|Next Article >]]</center><br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Stakeholder_Requirements_Definition&diff=48834Stakeholder Requirements Definition2013-10-23T22:11:41Z<p>Groedler: /* Presentation and Quality of Requirements */</p>
<hr />
<div>[[System Requirement (glossary)|System requirements]] are all of the [[Requirement (glossary)|requirements]] at the ''system level'' that describe the functions which the system as a whole should fulfill to satisfy the [[Stakeholder Requirement (glossary)|stakeholder needs and requirements]], and is expressed in an appropriate combination of textual statements, views, and non-functional requirements; the latter expressing the levels of safety, security, reliability, etc., that will be necessary. <br />
<br />
System requirements play major roles in systems engineering, as they: <br />
* Form the basis of system [[Architecture (glossary)|architecture]] and [[Design (glossary)|design]] activities.<br />
*Form the basis of system [[Integration (glossary)]] and [[Verification (glossary)|verification]] activities.<br />
* Act as reference for [[Validation (glossary)|validation]] and stakeholder acceptance.<br />
* Provide a means of communication between the various technical staff that interact throughout the project.<br />
<br />
Elicitation of stakeholder requirements starts in [[Concept Definition|Concept Definition]], and will be initially developed though interview and mission analysis. System requirements are considered in detail during [[System Definition|System Definition]]. Neither 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. <br />
<br />
==Definition and Purpose of Requirements==<br />
A requirement is a statement that identifies a product or processes operational, functional, or design characteristic or constraint, which is unambiguous, testable, or measurable and necessary for product or process acceptability (ISO/IEC 2007).<br />
<br />
To avoid confusion in the multitude of terms pertaining to ''[[Requirement (glossary)|requirements]]'', consider the following classifications:<br />
* '''Process Role or State''': The role the requirement plays in the definition process; for instance, its position in the system block (e.g. translated, derived, satisfied) or its state of agreement (e.g. proposed, approved, cancelled). <br />
* '''Level of Abstraction''': The level within the definition process that the requirement stands; for instance, stakeholder requirement, system requirement, system element requirement.<br />
* '''Type of Requirement''': The nature of the requirement itself; for instance, functional, performance, constraint, etc.<br />
<br />
Any single requirement may simultaneously be in a particular state, at a particular level abstraction, and of a particular type. For additional explanations about differences between the types of requirements, refer to Chapter 2 of Martin (1997).<br />
<br />
==Principles Governing System Requirements==<br />
===Relationship to Stakeholder Requirements and Logical Architecture===<br />
A set of [[Stakeholder Requirement (glossary)|stakeholder requirements]] are clarified and translated from statements of need into ''engineering-oriented'' language in order to enable proper architecture definition, design, and verification activities that are needed as the basis for system requirements analysis. <br />
<br />
The system requirements are based around identification and synthesis of the functions required of any solution system associated with performance and other quality measures and provide the basis for the assessment candidate solutions and verification of the completed system. The [[System Requirement (glossary)|system requirements]] are expressed in technical language that is useful for architecture and design: unambiguous, consistent, coherent, exhaustive, and verifiable. Of course, close coordination with the stakeholders is necessary to ensure the translation is accurate and traceability is maintained. This results in a set of system functions and requirements specifying measurable characteristics which can form the basis for [[System Realization (glossary)|system realization]].<br />
<br />
The [[Logical Architecture (glossary)]] defines system boundary and functions, from which more detailed system requirements can be derived. The starting point for this process may be to identify functional requirements from the stakeholder requirements and to use this to start the architectural definition, or to begin with a high level functional architecture view and use this as the basis for structuring system requirements. The exact approach taken will often depend on whether the system is an evolution of an already understood product or service, or a new and unprecedented solution (see [[Synthesizing Possible Solutions]]). However, when the process is initiated it is important that the stakeholder requirements, system requirements, and logical architecture are all complete, consistent with each other, and assessed together at the appropriate points in the systems [[Life Cycle Model (glossary)]].<br />
<br />
====Traceability and the Assignment of System Requirements during Architecture and Design====<br />
Requirements traceability provides the ability to track information from the origin of the stakeholder requirements, to the top level of requirements and other system definition elements at all levels of the system hierarchy (see section "Top-down and Recursive Approach to System Decomposition" in the [[System Definition]] article). Traceability is also used to provide an understanding as to the extent of a change as an input when impact analyses is performed in cases of proposed engineering improvements or requests for change.<br />
<br />
During [[Architecture (glossary) |architecture]] definition and [[Design (glossary) |design]], the assignment of requirements from one level to lower levels in the system hierarchy can be accomplished using several methods, as appropriate - see Table 1.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 1. Assessment Types for a System Requirement.''' (SEBoK Original)<br />
!Assignment Type for a System Requirement<br />
!Description<br />
|-<br />
|'''Direct Assignment'''<br />
|The system requirement from the higher level is directly assigned to a system or a system element for a lower level (e.g. the color used to paint visible parts of the product).<br />
|-<br />
|'''Indirect Assignment (Simply Decomposed)'''<br />
|The system requirement is distributed across several systems or system elements and the sum of a more complex calculation for distribution is equal to the requirement of higher level (e.g. a mass requirement, power distribution, reliability allocation, etc.) with sufficient margin or tolerance. A documented and configuration-managed "assignment budget" for each assignment must be maintained.<br />
|-<br />
|'''Indirect Assignment (Modeled and Decomposed)'''<br />
|The system requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique. The resulting design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, in the case of a radar detection requirement that is being analyzed, these lower-level parameters for output power, beam size, frequencies, etc. will be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.<br />
|-<br />
|'''Derived Requirement (from Design)'''<br />
|Such system requirements are developed during the design activities as a result of the decision of the design team, not the stakeholder community. These requirements may include the use of commercial-off-the-shelf (COTS) items, existing systems or system elements in inventory, common components, and similar design decisions in order to produce a "best value" solution for the customer. As such, these derived requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or a constraint.<br />
|}<br />
</center><br />
<br />
===Classification of System Requirements===<br />
Several classifications of system requirements are possible, depending on the requirements definition methods and/or the architecture and design methods being applied. (ISO/IEC 2011) provides a classification which is summarized in Table 2 (see references for additional classifications).<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Example of System Requirements Classification.''' (SEBoK Original)<br />
!Types of System Requirement<br />
!Description<br />
|-<br />
|'''Functional Requirements'''<br />
|Describe qualitatively the system functions or tasks to be performed in operation.<br />
|-<br />
|'''Performance Requirements'''<br />
|Define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task. <br />
|-<br />
|'''Usability Requirements'''<br />
|Define the quality of system use (e.g. measurable effectiveness, efficiency, and satisfaction criteria).<br />
|-<br />
|'''Interface Requirements'''<br />
|Define how the system is required to interact or to exchange material, energy, or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface requirements include physical connections (physical interfaces) with external systems or internal system elements supporting interactions or exchanges.<br />
|-<br />
|'''Operational Requirements'''<br />
|Define the operational conditions or properties that are required for the system to operate or exist. This type of requirement includes: human factors, ergonomics, availability, maintainability, reliability, and security.<br />
|-<br />
|'''Modes and/or States Requirements'''<br />
|Define the various operational modes of the system in use and events conducting to transitions of modes.<br />
|-<br />
|'''Adaptability Requirements'''<br />
|Define potential extension, growth, or scalability during the life of the system.<br />
|-<br />
|'''Physical Constraints'''<br />
|Define constraints on weight, volume, and dimension applicable to the system elements that compose the system.<br />
|-<br />
|'''Design Constraints'''<br />
|Define the limits on the options that are available to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an online repository).<br />
|-<br />
|'''Environmental Conditions'''<br />
|Define the environmental conditions to be encountered by the system in its different operational modes. This should address the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-induced environmental effects (e.g. motion, shock, noise, electromagnetism, thermal, etc.), and threats to societal environment (e.g. legal, political, economic, social, business, etc.).<br />
|-<br />
|'''Logistical Requirements'''<br />
|Define the logistical conditions needed by the continuous utilization of the system. These requirements include sustainment (provision of facilities, level support, support personnel, spare parts, training, technical documentation, etc.), packaging, handling, shipping, transportation.<br />
|-<br />
|'''Policies and Regulations'''<br />
|Define relevant and applicable organizational policies or regulatory requirements that could affect the operation or performance of the system (e.g. labor policies, reports to regulatory agony, health or safety criteria, etc.).<br />
|-<br />
|'''Cost and Schedule Constraints'''<br />
|Define, for example, the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc.<br />
|}<br />
</center><br />
<br />
===Requirements Management===<br />
Requirements management is performed to ensure alignment of the system and system element requirements with other representations, analysis, and artifacts of the system. It includes providing an understanding of the requirements, obtaining commitment, managing changes, maintaining bi-directional traceability among the requirements and with the rest of the system definition, and alignment with project resources and schedule. <br />
<br />
There are many tools available to provide a supporting infrastructure for requirements management; the best choice is the one that matches the processes of the project or enterprise. Requirements management is also closely tied to [[Configuration Management|configuration management]] for baseline management and control. When the requirements have been defined, documented, and approved, they need to be put under baseline management and control. The baseline allows the project to analyze and understand the impact (technical, cost, and schedule) of ongoing proposed changes.<br />
<br />
==Process Approach==<br />
===Purpose and Principle of the Approach===<br />
The purpose of the system requirements analysis process is to transform the stakeholder, user-oriented view of desired services and properties into a technical view of the product that meets the operational needs of the user. This process builds a representation of the system that will meet stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable system requirements that specify, from the supplier’s perspective, what performance and non-performance characteristics it must possess in order to satisfy stakeholders' requirements (ISO/IEC 2008).<br />
<br />
===Activities of the Process===<br />
Major activities and tasks during this process include:<br />
# Analyzing the stakeholder requirements to check completeness of expected services and [[Operational Scenario (glossary)|operational scenarios]], conditions, operational modes, and constraints.<br />
# Defining the system requirements and their [[Rationale (glossary)|rationale]].<br />
# Classifying the system requirements using suggested classifications (see examples above).<br />
# Incorporating the derived requirements (coming from architecture and design) into the system requirements baseline.<br />
# Establishing the upward traceability with the stakeholder needs and requirements. <br />
# Establishing bi-directional traceability between requirements at adjacent levels of the system hierarchy. <br />
# Verifying the quality and completeness of each system requirement and the consistency of the set of system requirements.<br />
# Validating the content and relevance of each system requirement against the set of stakeholder requirements.<br />
# Identifying potential [[Risk (glossary)|risks]] (or threats and hazards) that could be generated by the system requirements.<br />
# Synthesizing, recording, and managing the system requirements and potential associated risks.<br />
# Upon approval of the requirements, establishing control baselines along with the other system definition elements in conjunction with established configuration management practices.<br />
<br />
===Checking Correctness of System Requirements===<br />
System requirements should be checked to gauge whether they are well expressed and appropriate. There are a number of characteristics that can be used to check system requirements, such as standard peer review techniques and comparison of each requirement against the set of requirements characteristics, which are listed in Table 2 and Table 3 of the "Presentation and Quality of Requirements" section (below). Requirements can be further validated using the requirements elicitation and rationale capture described in the section "Methods and Modeling Techniques" (below).<br />
<br />
===Methods and Modeling Techniques===<br />
====Requirements Elicitation and Prototyping====<br />
Requirements elicitation requires user involvement and can be effective in gaining stakeholder involvement and buy-in. Quality Function Deployment (QFD) and prototyping are two common techniques that can be applied and are defined in this section. In addition, interviews, focus groups, and Delphi techniques are often applied to elicit requirements.<br />
<br />
QFD is a powerful technique to elicit requirements and compare design characteristics against user needs (Hauser and Clausing 1988). The inputs to the QFD application are user needs and operational concepts, so it is essential that the users participate. Users from across the life cycle should be included to ensure that all aspects of user needs are accounted for and prioritized.<br />
<br />
Early prototyping can help the users and developers interactively identify functional and operational requirements as well as user interface constraints. This enables realistic user interaction, discovery, and feedback, as well as some sensitivity analysis. This improves the users' understanding of the requirements and increases the probability of satisfying their actual needs.<br />
<br />
====Capturing Requirements Rationale====<br />
One powerful and cost-effective technique to translate stakeholder requirements to system requirements is to capture the rationale for each requirement. Requirements rationale is merely a statement as to why the requirement exists, any assumptions made, the results of related design studies, or any other related supporting information. This supports further requirements analysis and decomposition. The rationale can be captured directly in a requirements database (Hull, Jackson, and Dick 2010).<br />
<br />
Some of the benefits of this approach include:<br />
* '''Reducing the total number of requirements''' - The process aids in identifying duplicates. Reducing requirements count will reduce project cost and risk.<br />
* '''Early exposure of bad assumptions'''<br />
* '''Removes design implementation''' - Many poorly written stakeholder requirements are design requirements in disguise, in that the customer is intentionally or unintentionally specifying a candidate implementation. <br />
* '''Improves communication with the stakeholder community''' - By capturing the requirements rationale for all stakeholder requirements, the line of communication between the users and the designers is greatly improved. (Adapted from Chapter 8 of (Hooks and Farry 2000)).<br />
<br />
====Modeling Techniques====<br />
Modeling techniques that can be used when requirements must be detailed or refined, or in cases in which they address topics not considered during the stakeholder requirements definition and mission analysis, include:<br />
* State-charts models (ISO/IEC 2011, Section 8.4)<br />
* Scenarios modeling (ISO/IEC 2011, Section 6.2.3.1)<br />
* Simulations, prototyping (ISO/IEC 2011, Section 6.3.3.2)<br />
* Quality Function Deployment (INCOSE. 2010, p. 83)<br />
* Sequence diagrams, activity diagrams, use cases, state machine diagrams, Systems Modeling Language (SysML) requirements diagrams<br />
* Functional Flow Block Diagram for operational scenarios<br />
<br />
====Presentation and Quality of Requirements====<br />
Generally, requirements are provided in a textual form. Guidelines exist for writing good requirements; they include recommendations about the syntax of requirements statements, wording (exclusions, representation of concepts, etc.), and characteristics (specific, measurable, achievable, feasible, testable, etc.). Refer to INCOSE (2010, Section 4.2.2.2) and ISO/IEC (2011).<br />
<br />
There are several characteristics of both requirements and sets of requirements that are used to aid their development and to verify the implementation of requirements into the solution. Table 3 provides a list and descriptions of the characteristics for individual requirements and Table 4 provides a list and descriptions of characteristics for a set of requirements, as adapted from ISO/IEC (2011, Sections 5.2.5 and 5.2.6).<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 3. Characteristics of Individual Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Necessary'''<br />
|The requirement defines an essential capability, characteristic, constant, and/or quality factor. If it is removed or deleted, a deficiency will exist which cannot be fulfilled by other capabilities of the product or process.<br />
|-<br />
|'''Implementation Independent'''<br />
|The requirement, while addressing what is necessary and sufficient in the system, avoids placing unnecessary constraints on the architectural design. The objective is to be implementation-independent. The requirement states what is required, not how the requirement should be met.<br />
|-<br />
|'''Unambiguous'''<br />
|The requirement is stated in such a way so that it can be interpreted in only one way. The requirement is stated simply and is easy to understand.<br />
|-<br />
|'''Complete'''<br />
|The stated requirement needs no further amplification because it is measurable and sufficiently describes the capability and characteristics to meet the identified business, mission, and stakeholder needs. <br />
|-<br />
|'''Singular'''<br />
|The requirement statement includes only one requirement with no use of conjunctions.<br />
|-<br />
|'''Traceable'''<br />
|The requirement is upwards traceable to specific documented stakeholder statement(s) of need, higher tier requirement, or another source (e.g., a trade or design study). The requirement is also downwards traceable to the specific requirements in the lower tier requirements specifications or other system definition artifacts. That is, all parent-child relationships for the requirement are identified in tracing such that the requirement traces to its source and implementation.<br />
|-<br />
|'''Verifiable'''<br />
|The requirement has the means to prove that the system satisfies the specified requirement. Verifiability is enhanced when the requirement is measurable.<br />
|}<br />
</center><br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 4. Characteristics of a Set of Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Complete'''<br />
|The set of requirements needs no further amplification because it contains everything pertinent to the definition of the system or system element being specified. In addition, the set does not contain any to be defined (TBD), to be specified (TBS), or to be resolved (TBR) clauses. Resolution of the TBx designations may be iterative and there is an acceptable time frame for TBx items, determined by risks and dependencies. Note - Some practices are recommended to improve completeness: include all requirement types, account for requirements in all stages of the life cycle, and involve all stakeholders in the requirements elicitation activity.<br />
|-<br />
|'''Consistent'''<br />
|The set of requirements does not have individual requirements which are contradictory. Requirements are not duplicated. The same term is used for the same item in all requirements. There is nothing in the set of requirements as a whole to invalidate individual requirement traceability or verification.<br />
|-<br />
|'''Feasible'''<br />
|The set of requirements are technically achievable and fits within system constraints (e.g., cost, schedule, technical, lethal, regulatory, etc.). <br />
|-<br />
|'''Affordable'''<br />
|The complete set of requirements can be satisfied by a solution that is obtainable/feasible within life cycle constraints (e.g. cost, schedule, technical, legal, regulatory, etc.).<br />
|-<br />
|'''Bounded'''<br />
|The set of requirements maintains the identified scope for the intended solution without increasing beyond what is necessary to satisfy user needs.<br />
|}<br />
</center><br />
<br />
====Requirements in Tables====<br />
Requirements may be provided in a table, especially when specifying a set of parameters for the system or a system element. It is good practice to make standard table templates available. For tables, the following conventions apply: <br />
* Invoke each requirements table in the requirements set that clearly points to the table.<br />
* Identify each table with a unique title and table number.<br />
* Include the word “requirements” in the table title.<br />
* Identify the purpose of the table in the text immediately preceding it and include an explanation of how to read and use the table, including context and units.<br />
* For independent-dependent variable situations, organize the table in a way that best accommodates the use of the information.<br />
* Each cell should contain, at most, a single requirement.<br />
<br />
====Requirements in Flow Charts====<br />
Flow charts often contain requirements in a graphical form. These requirements may include logic that must be incorporated into the system, operational requirements, process or procedural requirements, or other situations that are best defined graphically by a sequence of interrelated steps. For flow charts, the following conventions apply:<br />
* Invoke flow charts in the requirements set that clearly points to the flow chart.<br />
* Identify each flow chart with a unique title and figure number.<br />
* Include the word “requirements” in the title of the flow chart.<br />
* Clearly indicate and explain unique symbols that represent requirements in the flow chart.<br />
<br />
====Requirements in Drawings====<br />
Drawings also provide a graphical means to define requirements. The type of requirement defined in a drawing depends on the type of drawing. The following conventions apply:<br />
* Drawings are used when they can aid in the description of the following:<br />
** Spatial Requirements<br />
** Interface Requirements<br />
** Layout Requirements<br />
* Invoke drawings in the requirements set that clearly point to the drawing.<br />
<br />
===Artifacts===<br />
This process may create several artifacts, such as:<br />
* System Requirements Document<br />
* System Requirements Justification Document (for traceability purpose)<br />
* System Requirements Database, including traceability, analysis, rationale, decisions, and attributes, where appropriate.<br />
* System External Interface Requirements Document (this document describes the interfaces of the system with external elements of its context of use; the interface requirements can be integrated or not to the system requirements document.<br />
<br />
The content, format, layout and ownership of these artifacts will vary depending on who is creating them as well as in which domain they will be utilized. Between them and the outputs of the process, activities should cover the information identified in the first part of this article.<br />
<br />
==Practical Considerations about System Requirements==<br />
There are several '''pitfalls''' that will inhibit the generation and management of an optimal set of system requirements, as discussed in Table 5.<br />
<br />
<center><br />
{|<br />
|+'''Table 5. Major Pitfalls with Definition of System Requirements.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|'''Insufficient Analysis of Stakeholder Requirements'''<br />
|If he receivers of the stakeholder requirements do not perform a sufficient critical analysis of them, the consequence could be difficulties translating them into system requirements and the obligation to come back to the stakeholders, losing time.<br />
|-<br />
|'''Insufficient Analysis of Operational Modes and Scenarios'''<br />
|The operational modes and operational scenarios are not sufficiently analyzed or defined by the person in charge of writing the system requirements. Those elements allow the structuring of the system and its use early in the engineering process and help the designer to remember functions and interfaces.<br />
|-<br />
|'''Incomplete Set of System Requirements'''<br />
|If the system requirements are not sufficiently precise and complete, there is a great risk that the design will not have the expected level of quality and that the verification and validation of the system will be delayed.<br />
|-<br />
|'''Lack of Verification Method'''<br />
|Delaying the capture of verification methods and events for each system requirement; identification of the verification approach for each requirement often provides additional insight as to the correctness and necessity of the requirement itself.<br />
|-<br />
|'''Missing traceability'''<br />
|Incorrect or missing traceability of each requirement, both to an upper-level "parent" requirement as well as allocation to an inappropriate system or system element.<br />
|}<br />
</center><br />
<br />
<br />
The '''proven practices''' in Table 6 have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development.<br />
<br />
<center><br />
{|<br />
|+'''Table 6. Proven Practices for System Requirements.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|'''Involve Stakeholders'''<br />
|Involve the stakeholders as early as possible in the system requirements development process.<br />
|-<br />
|'''Presence of Rationale'''<br />
|Capture the rationale for each system requirement.<br />
|-<br />
|'''Always Complete before Starting'''<br />
|Check that stakeholder requirements are complete as much as possible before starting the definition of the system requirements.<br />
|-<br />
|'''Peer Reviews'''<br />
|Organize peer reviews of system requirements with applicable subject matter experts.<br />
|-<br />
|'''Modeling Techniques'''<br />
|Use modeling techniques as indicated in sections above.<br />
|-<br />
|'''Requirements Management Tool'''<br />
|Consider using a requirements management tool, especially for more complex projects. This tool should have the capability to trace linkages between system requirements to display relationships. A requirements management tool is intended to facilitate and support the systematic managing of system requirements throughout the project life cycle.<br />
|-<br />
|'''Measures for Requirement Engineering'''<br />
|Use typical measures for requirement engineering; for further information, refer to the ''Systems Engineering Leading Indicators Guide'' (Roedler et al. 2010). Both process and product measures should be used for requirements engineering. To get the desired insight to facilitate risk-managed requirements engineering, it may be necessary to use more than one measure based on the information needs (risks, objectives, issues) for the requirements. Useful measures include:<br />
* Requirements Volatility<br />
* Requirements Trends<br />
* Requirements Verification Progress (plan vs. actual)<br />
* Requirements Validation Progress (plan vs. actual)<br />
* TBD and TBR Closure Per Plan<br />
* Peer Review Defects<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Hauser, J. and D. Clausing. 1988. "The House of Quality." ''Harvard Business Review.'' (May - June 1988). <br />
<br />
Hooks, I.F. and K.A. Farry. 2000. ''Customer-centered products: Creating successful products through smart requirements management''. New York, NY, USA: American Management Association.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering,'' 3rd ed. London, UK: Springer.<br />
<br />
INCOSE. 2011. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities,'' version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ISO/IEC. 2007. ''Systems and Software Engineering -- Recommended Practice for Architectural Description of Software-Intensive Systems''. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 42010:2007.<br />
<br />
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. <br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
Martin, J.N. 1997. ''Systems Engineering Guidebook: A Process for Developing Systems and Products,'' 1st ed. Boca Raton, FL, USA: CRC Press.<br />
<br />
===Primary References===<br />
<br />
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]].<br />
<br />
ISO/IEC/IEEE. 2008. ''[[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]]:2008 (E).<br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities,'' version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]: From System Goals to UML Models to Software Specifications''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com. <br />
<br />
Hooks, I.F. and K.A. Farry. 2000. ''Customer-Centered Products: Creating Successful Products through Smart Requirements Management.'' New York, NY, USA: American Management Association. <br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering,'' 3rd ed. London, UK: Springer.<br />
<br />
Roedler, G., D. Rhodes, C. Jones, and H. Schimmoller. 2010. ''Systems Engineering Leading Indicators Guide,'' version 2.0. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2005-001-03.<br />
<br />
SEI. 2007. "Requirements Management Process Area" and "Requirements Development Process Area." in ''Capability Maturity Model Integrated (CMMI) for Development'', version 1.2. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU). <br />
<br />
----<br />
<br />
<center>[[System Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Logical Architecture Design|Next Article >]]</center><br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Stakeholder_Requirements_Definition&diff=48833Stakeholder Requirements Definition2013-10-23T21:57:57Z<p>Groedler: </p>
<hr />
<div>[[System Requirement (glossary)|System requirements]] are all of the [[Requirement (glossary)|requirements]] at the ''system level'' that describe the functions which the system as a whole should fulfill to satisfy the [[Stakeholder Requirement (glossary)|stakeholder needs and requirements]], and is expressed in an appropriate combination of textual statements, views, and non-functional requirements; the latter expressing the levels of safety, security, reliability, etc., that will be necessary. <br />
<br />
System requirements play major roles in systems engineering, as they: <br />
* Form the basis of system [[Architecture (glossary)|architecture]] and [[Design (glossary)|design]] activities.<br />
*Form the basis of system [[Integration (glossary)]] and [[Verification (glossary)|verification]] activities.<br />
* Act as reference for [[Validation (glossary)|validation]] and stakeholder acceptance.<br />
* Provide a means of communication between the various technical staff that interact throughout the project.<br />
<br />
Elicitation of stakeholder requirements starts in [[Concept Definition|Concept Definition]], and will be initially developed though interview and mission analysis. System requirements are considered in detail during [[System Definition|System Definition]]. Neither 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. <br />
<br />
==Definition and Purpose of Requirements==<br />
A requirement is a statement that identifies a product or processes operational, functional, or design characteristic or constraint, which is unambiguous, testable, or measurable and necessary for product or process acceptability (ISO/IEC 2007).<br />
<br />
To avoid confusion in the multitude of terms pertaining to ''[[Requirement (glossary)|requirements]]'', consider the following classifications:<br />
* '''Process Role or State''': The role the requirement plays in the definition process; for instance, its position in the system block (e.g. translated, derived, satisfied) or its state of agreement (e.g. proposed, approved, cancelled). <br />
* '''Level of Abstraction''': The level within the definition process that the requirement stands; for instance, stakeholder requirement, system requirement, system element requirement.<br />
* '''Type of Requirement''': The nature of the requirement itself; for instance, functional, performance, constraint, etc.<br />
<br />
Any single requirement may simultaneously be in a particular state, at a particular level abstraction, and of a particular type. For additional explanations about differences between the types of requirements, refer to Chapter 2 of Martin (1997).<br />
<br />
==Principles Governing System Requirements==<br />
===Relationship to Stakeholder Requirements and Logical Architecture===<br />
A set of [[Stakeholder Requirement (glossary)|stakeholder requirements]] are clarified and translated from statements of need into ''engineering-oriented'' language in order to enable proper architecture definition, design, and verification activities that are needed as the basis for system requirements analysis. <br />
<br />
The system requirements are based around identification and synthesis of the functions required of any solution system associated with performance and other quality measures and provide the basis for the assessment candidate solutions and verification of the completed system. The [[System Requirement (glossary)|system requirements]] are expressed in technical language that is useful for architecture and design: unambiguous, consistent, coherent, exhaustive, and verifiable. Of course, close coordination with the stakeholders is necessary to ensure the translation is accurate and traceability is maintained. This results in a set of system functions and requirements specifying measurable characteristics which can form the basis for [[System Realization (glossary)|system realization]].<br />
<br />
The [[Logical Architecture (glossary)]] defines system boundary and functions, from which more detailed system requirements can be derived. The starting point for this process may be to identify functional requirements from the stakeholder requirements and to use this to start the architectural definition, or to begin with a high level functional architecture view and use this as the basis for structuring system requirements. The exact approach taken will often depend on whether the system is an evolution of an already understood product or service, or a new and unprecedented solution (see [[Synthesizing Possible Solutions]]). However, when the process is initiated it is important that the stakeholder requirements, system requirements, and logical architecture are all complete, consistent with each other, and assessed together at the appropriate points in the systems [[Life Cycle Model (glossary)]].<br />
<br />
====Traceability and the Assignment of System Requirements during Architecture and Design====<br />
Requirements traceability provides the ability to track information from the origin of the stakeholder requirements, to the top level of requirements and other system definition elements at all levels of the system hierarchy (see section "Top-down and Recursive Approach to System Decomposition" in the [[System Definition]] article). Traceability is also used to provide an understanding as to the extent of a change as an input when impact analyses is performed in cases of proposed engineering improvements or requests for change.<br />
<br />
During [[Architecture (glossary) |architecture]] definition and [[Design (glossary) |design]], the assignment of requirements from one level to lower levels in the system hierarchy can be accomplished using several methods, as appropriate - see Table 1.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 1. Assessment Types for a System Requirement.''' (SEBoK Original)<br />
!Assignment Type for a System Requirement<br />
!Description<br />
|-<br />
|'''Direct Assignment'''<br />
|The system requirement from the higher level is directly assigned to a system or a system element for a lower level (e.g. the color used to paint visible parts of the product).<br />
|-<br />
|'''Indirect Assignment (Simply Decomposed)'''<br />
|The system requirement is distributed across several systems or system elements and the sum of a more complex calculation for distribution is equal to the requirement of higher level (e.g. a mass requirement, power distribution, reliability allocation, etc.) with sufficient margin or tolerance. A documented and configuration-managed "assignment budget" for each assignment must be maintained.<br />
|-<br />
|'''Indirect Assignment (Modeled and Decomposed)'''<br />
|The system requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique. The resulting design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, in the case of a radar detection requirement that is being analyzed, these lower-level parameters for output power, beam size, frequencies, etc. will be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.<br />
|-<br />
|'''Derived Requirement (from Design)'''<br />
|Such system requirements are developed during the design activities as a result of the decision of the design team, not the stakeholder community. These requirements may include the use of commercial-off-the-shelf (COTS) items, existing systems or system elements in inventory, common components, and similar design decisions in order to produce a "best value" solution for the customer. As such, these derived requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or a constraint.<br />
|}<br />
</center><br />
<br />
===Classification of System Requirements===<br />
Several classifications of system requirements are possible, depending on the requirements definition methods and/or the architecture and design methods being applied. (ISO/IEC 2011) provides a classification which is summarized in Table 2 (see references for additional classifications).<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Example of System Requirements Classification.''' (SEBoK Original)<br />
!Types of System Requirement<br />
!Description<br />
|-<br />
|'''Functional Requirements'''<br />
|Describe qualitatively the system functions or tasks to be performed in operation.<br />
|-<br />
|'''Performance Requirements'''<br />
|Define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task. <br />
|-<br />
|'''Usability Requirements'''<br />
|Define the quality of system use (e.g. measurable effectiveness, efficiency, and satisfaction criteria).<br />
|-<br />
|'''Interface Requirements'''<br />
|Define how the system is required to interact or to exchange material, energy, or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface requirements include physical connections (physical interfaces) with external systems or internal system elements supporting interactions or exchanges.<br />
|-<br />
|'''Operational Requirements'''<br />
|Define the operational conditions or properties that are required for the system to operate or exist. This type of requirement includes: human factors, ergonomics, availability, maintainability, reliability, and security.<br />
|-<br />
|'''Modes and/or States Requirements'''<br />
|Define the various operational modes of the system in use and events conducting to transitions of modes.<br />
|-<br />
|'''Adaptability Requirements'''<br />
|Define potential extension, growth, or scalability during the life of the system.<br />
|-<br />
|'''Physical Constraints'''<br />
|Define constraints on weight, volume, and dimension applicable to the system elements that compose the system.<br />
|-<br />
|'''Design Constraints'''<br />
|Define the limits on the options that are available to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an online repository).<br />
|-<br />
|'''Environmental Conditions'''<br />
|Define the environmental conditions to be encountered by the system in its different operational modes. This should address the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-induced environmental effects (e.g. motion, shock, noise, electromagnetism, thermal, etc.), and threats to societal environment (e.g. legal, political, economic, social, business, etc.).<br />
|-<br />
|'''Logistical Requirements'''<br />
|Define the logistical conditions needed by the continuous utilization of the system. These requirements include sustainment (provision of facilities, level support, support personnel, spare parts, training, technical documentation, etc.), packaging, handling, shipping, transportation.<br />
|-<br />
|'''Policies and Regulations'''<br />
|Define relevant and applicable organizational policies or regulatory requirements that could affect the operation or performance of the system (e.g. labor policies, reports to regulatory agony, health or safety criteria, etc.).<br />
|-<br />
|'''Cost and Schedule Constraints'''<br />
|Define, for example, the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc.<br />
|}<br />
</center><br />
<br />
===Requirements Management===<br />
Requirements management is performed to ensure alignment of the system and system element requirements with other representations, analysis, and artifacts of the system. It includes providing an understanding of the requirements, obtaining commitment, managing changes, maintaining bi-directional traceability among the requirements and with the rest of the system definition, and alignment with project resources and schedule. <br />
<br />
There are many tools available to provide a supporting infrastructure for requirements management; the best choice is the one that matches the processes of the project or enterprise. Requirements management is also closely tied to [[Configuration Management|configuration management]] for baseline management and control. When the requirements have been defined, documented, and approved, they need to be put under baseline management and control. The baseline allows the project to analyze and understand the impact (technical, cost, and schedule) of ongoing proposed changes.<br />
<br />
==Process Approach==<br />
===Purpose and Principle of the Approach===<br />
The purpose of the system requirements analysis process is to transform the stakeholder, user-oriented view of desired services and properties into a technical view of the product that meets the operational needs of the user. This process builds a representation of the system that will meet stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable system requirements that specify, from the supplier’s perspective, what performance and non-performance characteristics it must possess in order to satisfy stakeholders' requirements (ISO/IEC 2008).<br />
<br />
===Activities of the Process===<br />
Major activities and tasks during this process include:<br />
# Analyzing the stakeholder requirements to check completeness of expected services and [[Operational Scenario (glossary)|operational scenarios]], conditions, operational modes, and constraints.<br />
# Defining the system requirements and their [[Rationale (glossary)|rationale]].<br />
# Classifying the system requirements using suggested classifications (see examples above).<br />
# Incorporating the derived requirements (coming from architecture and design) into the system requirements baseline.<br />
# Establishing the upward traceability with the stakeholder needs and requirements. <br />
# Establishing bi-directional traceability between requirements at adjacent levels of the system hierarchy. <br />
# Verifying the quality and completeness of each system requirement and the consistency of the set of system requirements.<br />
# Validating the content and relevance of each system requirement against the set of stakeholder requirements.<br />
# Identifying potential [[Risk (glossary)|risks]] (or threats and hazards) that could be generated by the system requirements.<br />
# Synthesizing, recording, and managing the system requirements and potential associated risks.<br />
# Upon approval of the requirements, establishing control baselines along with the other system definition elements in conjunction with established configuration management practices.<br />
<br />
===Checking Correctness of System Requirements===<br />
System requirements should be checked to gauge whether they are well expressed and appropriate. There are a number of characteristics that can be used to check system requirements, such as standard peer review techniques and comparison of each requirement against the set of requirements characteristics, which are listed in Table 2 and Table 3 of the "Presentation and Quality of Requirements" section (below). Requirements can be further validated using the requirements elicitation and rationale capture described in the section "Methods and Modeling Techniques" (below).<br />
<br />
===Methods and Modeling Techniques===<br />
====Requirements Elicitation and Prototyping====<br />
Requirements elicitation requires user involvement and can be effective in gaining stakeholder involvement and buy-in. Quality Function Deployment (QFD) and prototyping are two common techniques that can be applied and are defined in this section. In addition, interviews, focus groups, and Delphi techniques are often applied to elicit requirements.<br />
<br />
QFD is a powerful technique to elicit requirements and compare design characteristics against user needs (Hauser and Clausing 1988). The inputs to the QFD application are user needs and operational concepts, so it is essential that the users participate. Users from across the life cycle should be included to ensure that all aspects of user needs are accounted for and prioritized.<br />
<br />
Early prototyping can help the users and developers interactively identify functional and operational requirements as well as user interface constraints. This enables realistic user interaction, discovery, and feedback, as well as some sensitivity analysis. This improves the users' understanding of the requirements and increases the probability of satisfying their actual needs.<br />
<br />
====Capturing Requirements Rationale====<br />
One powerful and cost-effective technique to translate stakeholder requirements to system requirements is to capture the rationale for each requirement. Requirements rationale is merely a statement as to why the requirement exists, any assumptions made, the results of related design studies, or any other related supporting information. This supports further requirements analysis and decomposition. The rationale can be captured directly in a requirements database (Hull, Jackson, and Dick 2010).<br />
<br />
Some of the benefits of this approach include:<br />
* '''Reducing the total number of requirements''' - The process aids in identifying duplicates. Reducing requirements count will reduce project cost and risk.<br />
* '''Early exposure of bad assumptions'''<br />
* '''Removes design implementation''' - Many poorly written stakeholder requirements are design requirements in disguise, in that the customer is intentionally or unintentionally specifying a candidate implementation. <br />
* '''Improves communication with the stakeholder community''' - By capturing the requirements rationale for all stakeholder requirements, the line of communication between the users and the designers is greatly improved. (Adapted from Chapter 8 of (Hooks and Farry 2000)).<br />
<br />
====Modeling Techniques====<br />
Modeling techniques that can be used when requirements must be detailed or refined, or in cases in which they address topics not considered during the stakeholder requirements definition and mission analysis, include:<br />
* State-charts models (ISO/IEC 2011, Section 8.4)<br />
* Scenarios modeling (ISO/IEC 2011, Section 6.2.3.1)<br />
* Simulations, prototyping (ISO/IEC 2011, Section 6.3.3.2)<br />
* Quality Function Deployment (INCOSE. 2010, p. 83)<br />
* Sequence diagrams, activity diagrams, use cases, state machine diagrams, Systems Modeling Language (SysML) requirements diagrams<br />
* Functional Flow Block Diagram for operational scenarios<br />
<br />
====Presentation and Quality of Requirements====<br />
Generally, requirements are provided in a textual form. Guidelines exist for writing good requirements; they include recommendations about the syntax of requirements statements, wording (exclusions, representation of concepts, etc.), and characteristics (specific, measurable, achievable, feasible, testable, etc.). Refer to INCOSE (2010, Section 4.2.2.2) and ISO/IEC (2011).<br />
<br />
There are several characteristics of both requirements and sets of requirements that are used to aid their development and to verify the implementation of requirements into the solution. Table 3 provides a list and descriptions of the characteristics for individual requirements and Table 4 provides a list and descriptions of characteristics for a set of requirements, as adapted from ISO/IEC (2011, Sections 5.2.5 and 5.2.6).<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 3. Characteristics of Individual Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Necessary'''<br />
|The requirement defines an essential capability, characteristic, constant, and/or quality factor. If it is removed or deleted, a deficiency will exist which cannot be fulfilled by other capabilities of the product or process.<br />
|-<br />
|'''Implementation Free'''<br />
|The requirement, while addressing what is necessary and sufficient in the system, avoids placing unnecessary constraints on the architectural design. The objective is to be implementation-independent. The requirement states what is required, not how the requirement should be met.<br />
|-<br />
|'''Unambiguous'''<br />
|The requirement is stated in such a way so that it can be interpreted in only one way. The requirement is stated simply and is easy to understand.<br />
|-<br />
|'''Complete'''<br />
|The stated requirement needs no further amplification because it is measurable and sufficiently describes the capability and characteristics to meet the stakeholders' needs. <br />
|-<br />
|'''Singular'''<br />
|The requirement statement includes only one requirement with no use of conjunctions.<br />
|-<br />
|'''Traceable'''<br />
|The requirement is upwards traceable to specific documented stakeholder statement(s) of need, higher tier requirement, or another source (e.g., a trade or design study). The requirement is also downwards traceable to the specific requirements in the lower tier requirements specifications or other system definition artifacts. That is, all parent-child relationships for the requirement are identified in tracing such that the requirement traces to its source and implementation.<br />
|-<br />
|'''Verifiable'''<br />
|The requirement has the means to prove that the system satisfies the specified requirement. Verifiability is enhanced when the requirement is measurable.<br />
|}<br />
</center><br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 4. Characteristics of a Set of Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Complete'''<br />
|The set of requirements needs no further amplification because it contains everything pertinent to the definition of the system or system element being specified. In addition, the set does not contain any to be defined (TBD), to be specified (TBS), or to be resolved (TBR) clauses. Resolution of the TBx designations may be iterative and there is an acceptable time frame for TBx items, determined by risks and dependencies. Note - Some practices are recommended to improve completeness: include all requirement types, account for requirements in all stages of the life cycle, and involve all stakeholders in the requirements elicitation activity.<br />
|-<br />
|'''Consistent'''<br />
|The set of requirements does not have individual requirements which are contradictory. Requirements are not duplicated. The same term is used for the same item in all requirements. There is nothing in the set of requirements as a whole to invalidate individual requirement traceability or verification.<br />
|-<br />
|'''Feasible'''<br />
|The set of requirements are technically achievable and fits within system constraints (e.g., cost, schedule, technical, lethal, regulatory, etc.). <br />
|-<br />
|'''Affordable'''<br />
|The complete set of requirements can be satisfied by a solution that is obtainable/feasible within life cycle constraints (e.g. cost, schedule, technical, legal, regulatory, etc.).<br />
|-<br />
|'''Bounded'''<br />
|The set of requirements maintains the identified scope for the intended solution without increasing beyond what is necessary to satisfy user needs.<br />
|}<br />
</center><br />
<br />
====Requirements in Tables====<br />
Requirements may be provided in a table, especially when specifying a set of parameters for the system or a system element. It is good practice to make standard table templates available. For tables, the following conventions apply: <br />
* Invoke each requirements table in the requirements set that clearly points to the table.<br />
* Identify each table with a unique title and table number.<br />
* Include the word “requirements” in the table title.<br />
* Identify the purpose of the table in the text immediately preceding it and include an explanation of how to read and use the table, including context and units.<br />
* For independent-dependent variable situations, organize the table in a way that best accommodates the use of the information.<br />
* Each cell should contain, at most, a single requirement.<br />
<br />
====Requirements in Flow Charts====<br />
Flow charts often contain requirements in a graphical form. These requirements may include logic that must be incorporated into the system, operational requirements, process or procedural requirements, or other situations that are best defined graphically by a sequence of interrelated steps. For flow charts, the following conventions apply:<br />
* Invoke flow charts in the requirements set that clearly points to the flow chart.<br />
* Identify each flow chart with a unique title and figure number.<br />
* Include the word “requirements” in the title of the flow chart.<br />
* Clearly indicate and explain unique symbols that represent requirements in the flow chart.<br />
<br />
====Requirements in Drawings====<br />
Drawings also provide a graphical means to define requirements. The type of requirement defined in a drawing depends on the type of drawing. The following conventions apply:<br />
* Drawings are used when they can aid in the description of the following:<br />
** Spatial Requirements<br />
** Interface Requirements<br />
** Layout Requirements<br />
* Invoke drawings in the requirements set that clearly point to the drawing.<br />
<br />
===Artifacts===<br />
This process may create several artifacts, such as:<br />
* System Requirements Document<br />
* System Requirements Justification Document (for traceability purpose)<br />
* System Requirements Database, including traceability, analysis, rationale, decisions, and attributes, where appropriate.<br />
* System External Interface Requirements Document (this document describes the interfaces of the system with external elements of its context of use; the interface requirements can be integrated or not to the system requirements document.<br />
<br />
The content, format, layout and ownership of these artifacts will vary depending on who is creating them as well as in which domain they will be utilized. Between them and the outputs of the process, activities should cover the information identified in the first part of this article.<br />
<br />
==Practical Considerations about System Requirements==<br />
There are several '''pitfalls''' that will inhibit the generation and management of an optimal set of system requirements, as discussed in Table 5.<br />
<br />
<center><br />
{|<br />
|+'''Table 5. Major Pitfalls with Definition of System Requirements.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|'''Insufficient Analysis of Stakeholder Requirements'''<br />
|If he receivers of the stakeholder requirements do not perform a sufficient critical analysis of them, the consequence could be difficulties translating them into system requirements and the obligation to come back to the stakeholders, losing time.<br />
|-<br />
|'''Insufficient Analysis of Operational Modes and Scenarios'''<br />
|The operational modes and operational scenarios are not sufficiently analyzed or defined by the person in charge of writing the system requirements. Those elements allow the structuring of the system and its use early in the engineering process and help the designer to remember functions and interfaces.<br />
|-<br />
|'''Incomplete Set of System Requirements'''<br />
|If the system requirements are not sufficiently precise and complete, there is a great risk that the design will not have the expected level of quality and that the verification and validation of the system will be delayed.<br />
|-<br />
|'''Lack of Verification Method'''<br />
|Delaying the capture of verification methods and events for each system requirement; identification of the verification approach for each requirement often provides additional insight as to the correctness and necessity of the requirement itself.<br />
|-<br />
|'''Missing traceability'''<br />
|Incorrect or missing traceability of each requirement, both to an upper-level "parent" requirement as well as allocation to an inappropriate system or system element.<br />
|}<br />
</center><br />
<br />
<br />
The '''proven practices''' in Table 6 have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development.<br />
<br />
<center><br />
{|<br />
|+'''Table 6. Proven Practices for System Requirements.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|'''Involve Stakeholders'''<br />
|Involve the stakeholders as early as possible in the system requirements development process.<br />
|-<br />
|'''Presence of Rationale'''<br />
|Capture the rationale for each system requirement.<br />
|-<br />
|'''Always Complete before Starting'''<br />
|Check that stakeholder requirements are complete as much as possible before starting the definition of the system requirements.<br />
|-<br />
|'''Peer Reviews'''<br />
|Organize peer reviews of system requirements with applicable subject matter experts.<br />
|-<br />
|'''Modeling Techniques'''<br />
|Use modeling techniques as indicated in sections above.<br />
|-<br />
|'''Requirements Management Tool'''<br />
|Consider using a requirements management tool, especially for more complex projects. This tool should have the capability to trace linkages between system requirements to display relationships. A requirements management tool is intended to facilitate and support the systematic managing of system requirements throughout the project life cycle.<br />
|-<br />
|'''Measures for Requirement Engineering'''<br />
|Use typical measures for requirement engineering; for further information, refer to the ''Systems Engineering Leading Indicators Guide'' (Roedler et al. 2010). Both process and product measures should be used for requirements engineering. To get the desired insight to facilitate risk-managed requirements engineering, it may be necessary to use more than one measure based on the information needs (risks, objectives, issues) for the requirements. Useful measures include:<br />
* Requirements Volatility<br />
* Requirements Trends<br />
* Requirements Verification Progress (plan vs. actual)<br />
* Requirements Validation Progress (plan vs. actual)<br />
* TBD and TBR Closure Per Plan<br />
* Peer Review Defects<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Hauser, J. and D. Clausing. 1988. "The House of Quality." ''Harvard Business Review.'' (May - June 1988). <br />
<br />
Hooks, I.F. and K.A. Farry. 2000. ''Customer-centered products: Creating successful products through smart requirements management''. New York, NY, USA: American Management Association.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering,'' 3rd ed. London, UK: Springer.<br />
<br />
INCOSE. 2011. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities,'' version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ISO/IEC. 2007. ''Systems and Software Engineering -- Recommended Practice for Architectural Description of Software-Intensive Systems''. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 42010:2007.<br />
<br />
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. <br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
Martin, J.N. 1997. ''Systems Engineering Guidebook: A Process for Developing Systems and Products,'' 1st ed. Boca Raton, FL, USA: CRC Press.<br />
<br />
===Primary References===<br />
<br />
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]].<br />
<br />
ISO/IEC/IEEE. 2008. ''[[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]]:2008 (E).<br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities,'' version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]: From System Goals to UML Models to Software Specifications''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com. <br />
<br />
Hooks, I.F. and K.A. Farry. 2000. ''Customer-Centered Products: Creating Successful Products through Smart Requirements Management.'' New York, NY, USA: American Management Association. <br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering,'' 3rd ed. London, UK: Springer.<br />
<br />
Roedler, G., D. Rhodes, C. Jones, and H. Schimmoller. 2010. ''Systems Engineering Leading Indicators Guide,'' version 2.0. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2005-001-03.<br />
<br />
SEI. 2007. "Requirements Management Process Area" and "Requirements Development Process Area." in ''Capability Maturity Model Integrated (CMMI) for Development'', version 1.2. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU). <br />
<br />
----<br />
<br />
<center>[[System Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Logical Architecture Design|Next Article >]]</center><br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=System_Definition&diff=48832System Definition2013-10-23T21:35:56Z<p>Groedler: /* Top-Down and Recursive Approach to System Decomposition */</p>
<hr />
<div>[[System Definition (glossary)|System definition]] activities are conducted to describe in detail a system to satisfy an identified need. The activities are grouped and described as generic processes that are performed concurrently and/or iteratively depending on the selected [[Life Cycle Models|life cycle model.]] These consist of [[System Requirements|system requirements]], [[Logical Architecture Design|logical architecture]], [[Physical Architecture Design | physical architecture]], and [[System Analysis|system analysis]]. During and/or at the end of any iteration, gap analysis is performed to ensure that all system requirements have been mapped to the architecture and design.<br />
<br />
System definition activities build on the artifacts and decisions from [[Concept Definition (glossary) | concept definition]], primarily the articulation of the [[Mission (glossary) | mission]] of the [[System-of-Interest (glossary)|system-of-interest]] (SoI), the [[Stakeholder Requirement (glossary)|needs and requirements of stakeholders]], and preliminary operational concepts. The products of system definition activities (system requirements, architecture, etc.) are inputs to [[System Realization (glossary) |system realization]]. The specific activities and sequence of system definition activities will be dependent upon the type of life cycle model being utilized.<br />
<br />
==Topics==<br />
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: <br />
*[[System Requirements]]<br />
*[[Logical Architecture Design]]<br />
*[[Physical Architecture Design]]<br />
*[[System Analysis]]<br />
See the article [[Matrix of Implementation Examples]] for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.<br />
<br />
==System Views and System Elements ==<br />
An [[Engineered System (glossary)]] solution to a defined concept includes a defined set of engineering elements, characteristics, and properties. These elements are grouped in two ways: <br />
* Needs and requirements views<br />
* Architecture views<br />
<br />
Architecture views include the identification of the boundary and interfaces of a system-of-interest (SoI), which may then be further refined as a collection of [[System Element (glossary)|system elements]] and their relationships.<br />
<br />
===Requirements Views===<br />
<br />
Requirements provide an overall view of the [[Purpose (glossary)|purpose]] and [[Mission (glossary)|mission]] which the system as a whole is intended to satisfy, as well as a technology-independent view of that the system solutions(s) should do. They are conventionally organized into two types:<br />
<br />
*Business or mission requirements and [[Stakeholder Requirement (glossary)|Stakeholder requirements]] are defined and discussed in the [[Concept Definition]] KA.<br />
<br />
*[[System Requirement (glossary)|System requirements]], which describe the functions which the system as a whole should fulfill in order to satisfy the stakeholder requirements and are expressed in an appropriate set of views, and non-functional requirements expressing the levels of safety, security, reliability, etc., which are called for. These collectively form the basis for [[Verification (glossary)|verification]] later in the life cycle.<br />
<br />
System requirements and stakeholder requirements are closely related. Neither 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.<br />
<br />
The process activities that are used to identify, engineer and manage system requirements are described further in the [[System Requirements]] article in the KA.<br />
<br />
===Architecture Views===<br />
There are several architectural representations or views/models of the system. A couple common representations follow:<br />
* The '''[[Logical Architecture (glossary)|logical view of the architecture]]''' supports the logical operation of the system all along its life cycle, and may include functional, behavioral, and temporal views/models. Operational scenarios refine the mission into a collection of [[Function (glossary)|functions]] and dynamic structures that describe how the mission is performed (behavior).<br />
<br />
* The '''[[Physical Architecture (glossary)|physical view of the architecture]]''' is a set of [[System Element (glossary)|system elements]] performing the functions of the system. Those system elements can be either material or immaterial (e.g., equipment made of hardware, software and/or human roles).<br />
<br />
The boundary of the system architecture depends on what engineers include within the scope of the SoI and outside of it. This decision marks the transition from the characterization of the problem context to the beginnings of solution definition.<br />
<br />
Facing the potential number of system elements that constitute the physical architecture, sets of system elements can be grouped to form systems. The decomposition of the SoI (highest level) may include the decomposition of several layers of systems (intermediate levels of systems) until technological system elements (lowest level) are defined. Any layer of the decomposition may include systems and non-decomposable technological system elements.<br />
<br />
Because a system element is primarily an engineered system, it can be characterized in its turn using the previous views in its own context. The notion of system as described and defined here is recursive, see the discussion of systems and engineered system contexts in [[What is a System?]] article. <br />
<br />
The logical and physical representations of the system architecture are mapped onto each other. The interactions between system elements are defined by interfaces whose complexity strongly depends on the way the system architecture is defined. The relationships between the outputs of concept definition and the system solution, as well as the range of other views of a system that are available to describe a more complete set of characteristics between the system elements are discussed further in the [[Logical Architecture Design|logical architecture]] and [[Physical Architecture Design|physical architecture]] sections of the KA.<br />
<br />
==Top-Down and Recursive Approach to System Decomposition==<br />
<br />
System definition is managed through methodical top-down decomposition of the SoI into systems and system elements. As the system architecture definition advances, emerging systems and system elements form a system breakdown structure (SBS). For project management purposes, every system of the SBS may be included in a ''building block'', a notion introduced in (ANSI/EIA 1998), also called ''system block''. <br />
<br />
[[Stakeholder Requirement (glossary)|Stakeholder requirements]] and [[System Requirement (glossary)|system requirements]] exist at all layers of the SBS. In ISO/IEC/IEEE (2011), these layers are known as levels of abstraction. Along with systematically introducing layers of systems, the architecture and design process manages the transformation of the [[System Requirements|system requirements]] through levels of abstraction. Figure 1 illustrates this approach.<br />
<br />
[[File:SEBoKv05_KA-SystDef_Top-down_development_of_design_and_requirements.png|thumb|center|500px|center|'''Figure 1. Top-down Development of Architecture and Design, and Requirements (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
As shown in Figure 1<br />
* The white ovals represent requirements at decreasing levels of abstraction, and the arrows represent the transformation of those requirements through the levels using the architecture and design process. Stakeholder expressions of needs, expectations, and constraints are transformed into stakeholder requirements.<br />
* The next transformation crosses the boundary between the problem and solution areas by converting stakeholder requirements into system requirements, reflecting the bounded solution space.<br />
* At the SoI level, the system architecture is developed which serves to identify systems and system elements and establishes how they operate together to address the SoI requirements. <br />
<br />
This approach is applied recursively for each level of abstraction/decomposition recognizing that the same generic processes are applied at multiple levels of abstraction. Figure 2 below portrays the engineering that occurs in each system block. As necessary, system elements are defined through sets of system element requirements, which become inputs to other system blocks (''level n+1''). The approach is then recursively applied using the system definition processes.<br />
<br />
[[File:Recursive_Instantiation_of_Def_Process_AF_071112.png|thumb|center|700px|center|'''Figure 2. Recursive Instantiation of Definition Processes (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
At the ''n+1'' level, the systems or system elements may also collect other stakeholder requirements that are directly pertinent to this level of architecture and design. Processes within each system are generic, but unique in local purpose, scope and context.<br />
<br />
==System Architecture==<br />
Within the SE community, notions of architecture have been heavily influenced by ISO/IEC 15288 (2008), which even today presents a somewhat implicit view of architecture, conflating it with [[Design (glossary) |design]] as part of a single system life cycle process called ''architectural design''. Although there are diverse viewpoints on architecture, the different perspectives have much in common. The SEBoK considers systems engineering to cover all aspects of the creation of a system, including system architecture.<br />
<br />
The majority of interpretations of system architecture are based on the fairly intangible notion of ''structure'' (i.e. relationships between elements). <br />
<br />
Some authors limit the types of structure considered to be architectural; for example, restricting themselves to ''functional'' and ''physical'' structure. Recent practice has extended consideration to include ''temporal'' and other dimensions of structure within specified architectural frameworks (DoDAF (DoD 2010) and MODAF (MOD 2010)).<br />
<br />
ISO/IEC/IEEE 42010 (2011) provides a useful description of the architecture considering the stakeholder concerns, architecture viewpoints, architecture views, architecture models, architecture descriptions, and architecting throughout the life cycle. A discussion of the features of systems architectures can be found in Maier and Rechtin (2009).<br />
<br />
While architectural concepts are very useful and widely used in SE, there is a lack of consistency across communities of practice that creates the potential for confusion. An attempt to develop and apply a systematic approach to characterizing architecture belief systems in systems engineering has been described by the INCOSE UK Architecture Working Group (Wilkinson et al.2010, Wilkinson 2010).<br />
<br />
==System Design==<br />
<br />
In industrial practices, the term ''design'' is often used to mean both [[Architecture (glossary)]] and [[Design (glossary)]] as defined in the SEBoK. In the recent past, professionals used the term ''design'' when they dealt with simpler technological products - ones that do not include several different and interconnected technological components such as hardware, software, operators, services, etc. In the development of new multi-technology products and services, professionals have recognized the usefulness of the notion of ''system'' in dealing with [[Complexity (glossary)]] (interconnections level, multi-techno, emergence, etc.). <br />
<br />
It was due to complexity that structuring the elements that comprise a system became necessary. This structure explains the functional, behavioral, temporal, physical, and other aspects of a system as previously described. Practitioners found the term ''structure'' inadequate to describe all of these aspects of a system. The terms ''architecture'' and ''architectural design'' have been used for approximately 30 years, especially in software intensive systems and other domains, such as the space industry. The set of different types and interrelated structures can be understood as the architecture of the system.<br />
<br />
The trend today is to consider system architecture and system design as different sets of activities. Attempts are made to define separate concurrent processes, but they are strongly intertwined:<br />
<br />
* System design includes activities to conceive a system that answers a specific, intended purpose, using principles and concepts; it includes assessments and decisions to select elements that compose the system, fit the architecture of the system, and comply with traded-off system requirements. It is the complete set of detailed models, properties, and/or characteristics described into a form suitable for implementation. <br />
* System architecture is more abstract, conceptualization-oriented, global, and focused on mission success and on high level structure in (sub)systems. It may also be applied to more than one system, in some cases forming the common structure, pattern, and set of requirements for classes or families of similar or related systems.<br />
<br />
System design is intended to be the link between the system architecture (at whatever point this milestone is defined in the specific application of the systems engineering process) and the implementation of technological system elements that compose the physical architecture of the system.<br />
<br />
These related processes are presented together in the present version of the SEBoK, though effort has been made to distinguish between the corresponding activities.<br />
<br />
==General System Architecture and Design Principles and Concepts==<br />
<br />
===Classification of Principles and Heuristics===<br />
<br />
Engineers and architects use a mixture of mathematical principles and heuristics that are learned through experience. When an issue is identified through system requirements, principles and heuristics may or may not be able to address it. Principles and heuristics that are used in system views/models can be classified according to the domains in which those system views/models are used, as follows:<br />
<br />
# '''Static domain''' relates to physical structure or organization of the SoI broken down into systems and [[System Element (glossary)|system elements]]. It deals with partitioning systems, system elements, and physical interfaces.<br />
# '''Dynamic domain''' relates to logical architecture models; in particular, to the representation of the behavior of the system. It includes a description of functions (i.e. transformations of input/output flows) and interactions between functions of the system and between those of the external objects or systems. It takes into account reactions to events that launch or stop the execution of functions of the system. It also deals with the effectiveness (i.e. performances, operational conditions) of the system.<br />
# '''Temporal domain''' relates to temporal invariance levels of the execution of functions of the system. This means that every function is executed according to cyclic or synchronous characteristics. It includes decisional levels that are asynchronous characteristics of the behavior of some functions.<br />
# '''Environmental domain''' relates to enablers (production, logistics support, etc.), but also to the [[Survivability (glossary)|survivability]] of the system in reaction to natural hazards or threats and to the [[Integrity (glossary)|integrity]] of the system in reaction to internal potential hazards. This includes, for example, climatic, mechanical, electromagnetic, and biological aspects.<br />
<br />
More detailed classification can be found in Maier and Rechtin (2009).<br />
<br />
===Transition from System Requirements to Physical Architecture===<br />
<br />
The aim of the approach is to progress from system requirements (representing the problem from a supplier/designer point of view, as independent of technology as possible) to an intermediate model of [[Logical Architecture (glossary)|logical architecture]], then to allocate the elements of the logical architecture to system elements of candidate [[Physical Architecture (glossary)|physical architectures]]. <br />
<br />
(System requirements and logical architecture share many characteristics, as they are both organized on functional lines, independently of the implementation. Some authors (Stevens et al 1998) go so far as to conflate the two, which simplifies the handling of multiple simultaneous views. Whether this approach is adopted depends on the specific practices of the development organization and where contractual boundaries are drawn.) <br />
<br />
Design decisions and technological solutions are selected according to performance criteria and non-functional requirements, such as operational conditions and life cycle constraints (e.g., environmental conditions, maintenance constraints, realization constraints, etc.), as illustrated in Figure 3. Creating intermediate models, such as logical architecture models, facilitates the validation of functional, behavioral, and temporal properties of the system against the system requirements that have no major technological influence impacts during the life of the system, the physical interfaces, or the technological layer without completely questioning the logical functioning of the system.<br />
<br />
[[File:SEBoKv075_KA-SystDef_Progressive_Approach_for_Designing.png|600px|thumb|center|'''Figure 3. Usage of Intermediate Logical Architecture Models During Architecture and Design (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
===Iterations between Logical and Physical Architecture Definition===<br />
<br />
Architecture and design activities require spending several iterations from logical architecture models definitions to physical architecture models definitions and vice versa, until both logical and physical architecture models are exhaustive and consistent. The first architecture and design activity is the creation of a logical architecture model based on nominal scenarios (of functions). Physical architecture is used to determine main system elements that could perform system functions and to organize them into a physical architecture model.<br />
<br />
A second logical architecture iteration can take into account allocations of functions to system elements and derived functions coming from physical solution choices. It also supplements the initial logical architecture model by introducing other scenarios, failure analyses, and every operational requirement not previously considered. Derived functions must be allocated to system elements; in turn, this affects the physical architecture models.<br />
<br />
Additional architecture and design iterations can produce a through and consistent logical and physical solution. During system design, technological choices can potentially lead to new functions, new input/output and control flows, and new physical interfaces. These new elements can lead to creation of new system requirements, called ''derived requirements''.<br />
<br />
===Concept of Interface===<br />
<br />
The concept of [[Interface (glossary)|interface]] is one of the most important to consider when defining the architecture of a system. The fundamental aspect of an interface is functional and is defined as inputs and outputs of functions. As functions are performed by physical elements (system elements), inputs/outputs of functions are also carried by physical elements; these are called physical interfaces. Consequentially, both functional and physical aspects are considered in the notion of interface. A detailed analysis of an interface shows the function ''“send”'' located in one system element, the function ''“receive”'' located in the other one, and the function ''“carry"'' as being performed by the physical interface that supports the input/output flow (see Figure 5).<br />
<br />
[[File:SEBoKv075_KA-SystDef_Complete_Interface_Representation.png|400px|thumb|center|'''Figure 4. Complete Interface Representation (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]] <br />
<br />
In the context of complex exchanges between system elements, particularly in software-intensive systems, a protocol is seen as a physical interface that carries exchanges of data.<br />
<br />
===Reuse of System Elements===<br />
Systems engineers frequently utilize existing system elements. This reuse constraint has to be identified as a system requirement and carefully taken into account during architecture and design. One can distinguish three general cases involving system element reuse, as shown in Table 1.<br />
<br />
<center><br />
{|<br />
|+'''Table 1. System Element Re-use Cases (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.<br />
!Re-use Case<br />
!Actions and Comments<br />
|-<br />
|'''Case 1:''' The requirements of the system element are up-to-date and it will be re-used with no modification required.<br />
|<br />
* The system architecture to be designed will have to adapt to the boundaries, interfaces, functions, effectiveness, and behavior of the re-used system element.<br />
* If the system element is not adapted, it is probable that costs, complexity, and risks will increase.<br />
|-<br />
|'''Case 2:''' The requirements of the system element are up-to-date and it will be re-used with possible modifications.<br />
|<br />
* The system architecture to be designed is flexible enough to accommodate the boundaries, interfaces, functions, effectiveness, and behavior of the re-used system element.<br />
* The design of the reused system element, including its test reports and other documentation, will be evaluated and potentially redesigned.<br />
|-<br />
|'''Case 3:''' The requirements are not up-to-date or do not exist.<br />
|<br />
* It is necessary to reverse engineer the system element to identify its boundaries, interfaces, functions, performances, and behavior.<br />
* This is a difficult activity, since the extant documentation for the re-used system element is likely unavailable or insufficient.<br />
* Reverse engineering is expensive in terms of both time and money, and brings with it increased risk.<br />
|}<br />
</center><br />
<br />
<br />
There is a common idea that reuse is ''free''; however, if not approached correctly, reuse may introduce risks that can be significant for the project (costs, deadlines, complexity).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
ANSI/IEEE. 2000. ''Recommended Practice for Architectural Description for Software-Intensive Systems''. New York, NY, USA: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/IEEE 1471-2000.<br />
<br />
ANSI/EIA. 1998. ''Processes for Engineering a System''. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA-632-1998. <br />
<br />
DOD. 2010. ''DOD Architecture Framework.'' Version 2.02. Arlington, VA, USA: US Department of Defense. Available at: http://cio-nii.defense.gov/sites/dodaf20/<br />
<br />
Faisandier, A. 2012. ''Systems Architecture and Design.'' Belberaud, France: Sinergy'Com.<br />
<br />
INCOSE. 2012. ''INCOSE Systems Engineering Handbook,'' Version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.<br />
<br />
ISO/IEC 2008. ''Systems and Software Engineering -- System Life Cycle Processes.'' Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008 (E).<br />
<br />
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.<br />
<br />
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.<br />
<br />
Maier, M., and E. Rechtin. 2009. ''The Art of Systems Architecting.'' 3rd ed. Boca Raton, FL, USA: CRC Press. <br />
<br />
MOD. 2010. ''MOD Architecture Framework.'' Version 1.2.004. UK Ministry of Defence. Available at: http://www.mod.uk/DefenceInternet/AboutDefence/WhatWeDo/InformationManagement/MODAF/.<br />
<br />
Stevens, R., P. Brook, K. Jackson, and S. Arnold. 1998. ''Systems Engineering - Coping with Complexity''. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Wilkinson, M., A. James, M. Emes, P. King, P. Bryant. 2010. “Belief Systems in Systems Architecting: Method and Preliminary Applications." Presented at the IEEE SMC Society’s 5th International Conference on System of Systems Engineering (SoSE). 22nd-24th June 2010. Loughborough University, UK.<br />
<br />
Wilkinson, M.K. 2010. “Z8: Systems Architecture”, in Z-guide series. INCOSE UK, available from INCOSE UK at: http://www.incoseonline.org.uk/Program_Files/Publications/zGuides.aspx?CatID=Publications.<br />
<br />
===Primary References===<br />
<br />
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. <br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2005. ''[[Systems Engineering and Analysis]].'' 4th ed. Prentice-Hall International Series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall. <br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.<br />
<br />
ISO/IEC. 2007. ''[[ISO/IEC 26702|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.<br />
<br />
ISO/IEC/IEEE. 2008. ''[[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]]:2008 (E).<br />
<br />
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]].<br />
<br />
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]].<br />
<br />
Martin, J.N. 1997. ''[[Systems Engineering Guidebook]]: A process for developing systems and products,'' 1st ed. Boca Raton, FL, USA: CRC Press.<br />
<br />
NASA. 2007. ''[[NASA Systems Engineering Handbook|Systems Engineering Handbook]].'' Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.<br />
<br />
===Additional References===<br />
Baldwin, C.Y. and K.B. Clark. 2000. ''Design Rules''. Cambridge, Mass: MIT Press.<br />
<br />
Buede, D.M. 2009. ''The Engineering Design of Systems: Models and Methods''. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc. <br />
<br />
DoD. 2010. ''DOD Architecture Framework.'' Version 2.02. Arlington, VA, USA: US Department of Defense. Available at: http://cio-nii.defense.gov/sites/dodaf20/<br />
<br />
Faisandier, A. 2012. ''Systems Architecture and Design''. Belberaud, France: Sinergy'Com.<br />
<br />
Hatley, D.J., and I.A. Pirbhai. 1987. ''Strategies for Real-Time System Specification''. New York, NY: Dorset House Pub.<br />
<br />
MOD. 2010. ''MOD Architecture Framework,'' Version 1.2.004. UK Ministry of Defence. Available at: http://www.mod.uk/DefenceInternet/AboutDefence/WhatWeDo/InformationManagement/MODAF/.<br />
<br />
Stevens, R., P. Brook, K. Jackson, S. Arnold. 1998. ''Systems Engineering - Coping with Complexity''. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Wilkinson, M., A. James, M. Emes, P. King, P. Bryant. 2010. ''Belief Systems in Systems Architecting: Method and Preliminary Applications''. paper presented at the IEEE SMC Society’s 5th International Conference on System of Systems Engineering (SoSE). 22nd-24th June 2010. Loughborough University, UK.<br />
<br />
----<br />
<center>[[Stakeholder Needs and Requirements|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[System Requirements|Next Article >]]</center><br />
<br />
[[Category: Part 3]][[Category:Knowledge Area]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=System_Definition&diff=48831System Definition2013-10-23T21:25:20Z<p>Groedler: /* Architecture Views */</p>
<hr />
<div>[[System Definition (glossary)|System definition]] activities are conducted to describe in detail a system to satisfy an identified need. The activities are grouped and described as generic processes that are performed concurrently and/or iteratively depending on the selected [[Life Cycle Models|life cycle model.]] These consist of [[System Requirements|system requirements]], [[Logical Architecture Design|logical architecture]], [[Physical Architecture Design | physical architecture]], and [[System Analysis|system analysis]]. During and/or at the end of any iteration, gap analysis is performed to ensure that all system requirements have been mapped to the architecture and design.<br />
<br />
System definition activities build on the artifacts and decisions from [[Concept Definition (glossary) | concept definition]], primarily the articulation of the [[Mission (glossary) | mission]] of the [[System-of-Interest (glossary)|system-of-interest]] (SoI), the [[Stakeholder Requirement (glossary)|needs and requirements of stakeholders]], and preliminary operational concepts. The products of system definition activities (system requirements, architecture, etc.) are inputs to [[System Realization (glossary) |system realization]]. The specific activities and sequence of system definition activities will be dependent upon the type of life cycle model being utilized.<br />
<br />
==Topics==<br />
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: <br />
*[[System Requirements]]<br />
*[[Logical Architecture Design]]<br />
*[[Physical Architecture Design]]<br />
*[[System Analysis]]<br />
See the article [[Matrix of Implementation Examples]] for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.<br />
<br />
==System Views and System Elements ==<br />
An [[Engineered System (glossary)]] solution to a defined concept includes a defined set of engineering elements, characteristics, and properties. These elements are grouped in two ways: <br />
* Needs and requirements views<br />
* Architecture views<br />
<br />
Architecture views include the identification of the boundary and interfaces of a system-of-interest (SoI), which may then be further refined as a collection of [[System Element (glossary)|system elements]] and their relationships.<br />
<br />
===Requirements Views===<br />
<br />
Requirements provide an overall view of the [[Purpose (glossary)|purpose]] and [[Mission (glossary)|mission]] which the system as a whole is intended to satisfy, as well as a technology-independent view of that the system solutions(s) should do. They are conventionally organized into two types:<br />
<br />
*Business or mission requirements and [[Stakeholder Requirement (glossary)|Stakeholder requirements]] are defined and discussed in the [[Concept Definition]] KA.<br />
<br />
*[[System Requirement (glossary)|System requirements]], which describe the functions which the system as a whole should fulfill in order to satisfy the stakeholder requirements and are expressed in an appropriate set of views, and non-functional requirements expressing the levels of safety, security, reliability, etc., which are called for. These collectively form the basis for [[Verification (glossary)|verification]] later in the life cycle.<br />
<br />
System requirements and stakeholder requirements are closely related. Neither 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.<br />
<br />
The process activities that are used to identify, engineer and manage system requirements are described further in the [[System Requirements]] article in the KA.<br />
<br />
===Architecture Views===<br />
There are several architectural representations or views/models of the system. A couple common representations follow:<br />
* The '''[[Logical Architecture (glossary)|logical view of the architecture]]''' supports the logical operation of the system all along its life cycle, and may include functional, behavioral, and temporal views/models. Operational scenarios refine the mission into a collection of [[Function (glossary)|functions]] and dynamic structures that describe how the mission is performed (behavior).<br />
<br />
* The '''[[Physical Architecture (glossary)|physical view of the architecture]]''' is a set of [[System Element (glossary)|system elements]] performing the functions of the system. Those system elements can be either material or immaterial (e.g., equipment made of hardware, software and/or human roles).<br />
<br />
The boundary of the system architecture depends on what engineers include within the scope of the SoI and outside of it. This decision marks the transition from the characterization of the problem context to the beginnings of solution definition.<br />
<br />
Facing the potential number of system elements that constitute the physical architecture, sets of system elements can be grouped to form systems. The decomposition of the SoI (highest level) may include the decomposition of several layers of systems (intermediate levels of systems) until technological system elements (lowest level) are defined. Any layer of the decomposition may include systems and non-decomposable technological system elements.<br />
<br />
Because a system element is primarily an engineered system, it can be characterized in its turn using the previous views in its own context. The notion of system as described and defined here is recursive, see the discussion of systems and engineered system contexts in [[What is a System?]] article. <br />
<br />
The logical and physical representations of the system architecture are mapped onto each other. The interactions between system elements are defined by interfaces whose complexity strongly depends on the way the system architecture is defined. The relationships between the outputs of concept definition and the system solution, as well as the range of other views of a system that are available to describe a more complete set of characteristics between the system elements are discussed further in the [[Logical Architecture Design|logical architecture]] and [[Physical Architecture Design|physical architecture]] sections of the KA.<br />
<br />
==Top-Down and Recursive Approach to System Decomposition==<br />
<br />
System definition is managed through methodical top-down decomposition of the SoI into systems and system elements. As the system architecture definition advances, emerging systems and system elements form a system breakdown structure (SBS). For project management purposes, every system of the SBS may be included in a ''building block'', a notion introduced in (ANSI/EIA 1998), also called ''system block''. <br />
<br />
[[Stakeholder Requirement (glossary)|Stakeholder requirements]] and [[System Requirement (glossary)|system requirements]] exist at all layers of the SBS. In ISO/IEC/IEEE (2011), these layers are known as levels of abstraction. Along with systematically introducing layers of systems, the architecture and design process manages the transformation of the [[System Requirements|system requirements]] through levels of abstraction. Figure 1 illlustrates this approach.<br />
<br />
[[File:SEBoKv05_KA-SystDef_Top-down_development_of_design_and_requirements.png|thumb|center|500px|center|'''Figure 1. Top-down Development of Architecture and Design, and Requirements (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
As shown in Figure 1<br />
* The white ovals represent requirements at decreasing levels of abstraction, and the arrows represent the transformation of those requirements through the levels using the architecture and design process. Stakeholder expressions of needs, expectations, and constraints are transformed into stakeholder requirements.<br />
* The next transformation crosses the boundary between the problem and solution areas by converting stakeholder requirements into system requirements, reflecting the bounded solution space.<br />
* At the SoI level, the system architecture is developed which serves to identify systems and system elements and establishes how they operate together to address the SoI requirements. <br />
<br />
This approach is applied recursively for each level of abstraction/decomposition recognizing that the same generic processes are applied at multiple levels of abstraction. Figure 2 below portrays the engineering that occurs in each system block. As necessary, system elements are defined through sets of system element requirements, which become inputs to other system blocks (''level n+1''). The approach is then recursively applied using the system definition processes.<br />
<br />
[[File:Recursive_Instantiation_of_Def_Process_AF_071112.png|thumb|center|700px|center|'''Figure 2. Recursive Instantiation of Definition Processes (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
At the ''n+1'' level, the systems or system elements may also collect other stakeholder requirements that are directly pertinent to this level of architecture and design. Processes within each system are generic, but unique in local purpose, scope and context.<br />
<br />
==System Architecture==<br />
Within the SE community, notions of architecture have been heavily influenced by ISO/IEC 15288 (2008), which even today presents a somewhat implicit view of architecture, conflating it with [[Design (glossary) |design]] as part of a single system life cycle process called ''architectural design''. Although there are diverse viewpoints on architecture, the different perspectives have much in common. The SEBoK considers systems engineering to cover all aspects of the creation of a system, including system architecture.<br />
<br />
The majority of interpretations of system architecture are based on the fairly intangible notion of ''structure'' (i.e. relationships between elements). <br />
<br />
Some authors limit the types of structure considered to be architectural; for example, restricting themselves to ''functional'' and ''physical'' structure. Recent practice has extended consideration to include ''temporal'' and other dimensions of structure within specified architectural frameworks (DoDAF (DoD 2010) and MODAF (MOD 2010)).<br />
<br />
ISO/IEC/IEEE 42010 (2011) provides a useful description of the architecture considering the stakeholder concerns, architecture viewpoints, architecture views, architecture models, architecture descriptions, and architecting throughout the life cycle. A discussion of the features of systems architectures can be found in Maier and Rechtin (2009).<br />
<br />
While architectural concepts are very useful and widely used in SE, there is a lack of consistency across communities of practice that creates the potential for confusion. An attempt to develop and apply a systematic approach to characterizing architecture belief systems in systems engineering has been described by the INCOSE UK Architecture Working Group (Wilkinson et al.2010, Wilkinson 2010).<br />
<br />
==System Design==<br />
<br />
In industrial practices, the term ''design'' is often used to mean both [[Architecture (glossary)]] and [[Design (glossary)]] as defined in the SEBoK. In the recent past, professionals used the term ''design'' when they dealt with simpler technological products - ones that do not include several different and interconnected technological components such as hardware, software, operators, services, etc. In the development of new multi-technology products and services, professionals have recognized the usefulness of the notion of ''system'' in dealing with [[Complexity (glossary)]] (interconnections level, multi-techno, emergence, etc.). <br />
<br />
It was due to complexity that structuring the elements that comprise a system became necessary. This structure explains the functional, behavioral, temporal, physical, and other aspects of a system as previously described. Practitioners found the term ''structure'' inadequate to describe all of these aspects of a system. The terms ''architecture'' and ''architectural design'' have been used for approximately 30 years, especially in software intensive systems and other domains, such as the space industry. The set of different types and interrelated structures can be understood as the architecture of the system.<br />
<br />
The trend today is to consider system architecture and system design as different sets of activities. Attempts are made to define separate concurrent processes, but they are strongly intertwined:<br />
<br />
* System design includes activities to conceive a system that answers a specific, intended purpose, using principles and concepts; it includes assessments and decisions to select elements that compose the system, fit the architecture of the system, and comply with traded-off system requirements. It is the complete set of detailed models, properties, and/or characteristics described into a form suitable for implementation. <br />
* System architecture is more abstract, conceptualization-oriented, global, and focused on mission success and on high level structure in (sub)systems. It may also be applied to more than one system, in some cases forming the common structure, pattern, and set of requirements for classes or families of similar or related systems.<br />
<br />
System design is intended to be the link between the system architecture (at whatever point this milestone is defined in the specific application of the systems engineering process) and the implementation of technological system elements that compose the physical architecture of the system.<br />
<br />
These related processes are presented together in the present version of the SEBoK, though effort has been made to distinguish between the corresponding activities.<br />
<br />
==General System Architecture and Design Principles and Concepts==<br />
<br />
===Classification of Principles and Heuristics===<br />
<br />
Engineers and architects use a mixture of mathematical principles and heuristics that are learned through experience. When an issue is identified through system requirements, principles and heuristics may or may not be able to address it. Principles and heuristics that are used in system views/models can be classified according to the domains in which those system views/models are used, as follows:<br />
<br />
# '''Static domain''' relates to physical structure or organization of the SoI broken down into systems and [[System Element (glossary)|system elements]]. It deals with partitioning systems, system elements, and physical interfaces.<br />
# '''Dynamic domain''' relates to logical architecture models; in particular, to the representation of the behavior of the system. It includes a description of functions (i.e. transformations of input/output flows) and interactions between functions of the system and between those of the external objects or systems. It takes into account reactions to events that launch or stop the execution of functions of the system. It also deals with the effectiveness (i.e. performances, operational conditions) of the system.<br />
# '''Temporal domain''' relates to temporal invariance levels of the execution of functions of the system. This means that every function is executed according to cyclic or synchronous characteristics. It includes decisional levels that are asynchronous characteristics of the behavior of some functions.<br />
# '''Environmental domain''' relates to enablers (production, logistics support, etc.), but also to the [[Survivability (glossary)|survivability]] of the system in reaction to natural hazards or threats and to the [[Integrity (glossary)|integrity]] of the system in reaction to internal potential hazards. This includes, for example, climatic, mechanical, electromagnetic, and biological aspects.<br />
<br />
More detailed classification can be found in Maier and Rechtin (2009).<br />
<br />
===Transition from System Requirements to Physical Architecture===<br />
<br />
The aim of the approach is to progress from system requirements (representing the problem from a supplier/designer point of view, as independent of technology as possible) to an intermediate model of [[Logical Architecture (glossary)|logical architecture]], then to allocate the elements of the logical architecture to system elements of candidate [[Physical Architecture (glossary)|physical architectures]]. <br />
<br />
(System requirements and logical architecture share many characteristics, as they are both organized on functional lines, independently of the implementation. Some authors (Stevens et al 1998) go so far as to conflate the two, which simplifies the handling of multiple simultaneous views. Whether this approach is adopted depends on the specific practices of the development organization and where contractual boundaries are drawn.) <br />
<br />
Design decisions and technological solutions are selected according to performance criteria and non-functional requirements, such as operational conditions and life cycle constraints (e.g., environmental conditions, maintenance constraints, realization constraints, etc.), as illustrated in Figure 3. Creating intermediate models, such as logical architecture models, facilitates the validation of functional, behavioral, and temporal properties of the system against the system requirements that have no major technological influence impacts during the life of the system, the physical interfaces, or the technological layer without completely questioning the logical functioning of the system.<br />
<br />
[[File:SEBoKv075_KA-SystDef_Progressive_Approach_for_Designing.png|600px|thumb|center|'''Figure 3. Usage of Intermediate Logical Architecture Models During Architecture and Design (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
===Iterations between Logical and Physical Architecture Definition===<br />
<br />
Architecture and design activities require spending several iterations from logical architecture models definitions to physical architecture models definitions and vice versa, until both logical and physical architecture models are exhaustive and consistent. The first architecture and design activity is the creation of a logical architecture model based on nominal scenarios (of functions). Physical architecture is used to determine main system elements that could perform system functions and to organize them into a physical architecture model.<br />
<br />
A second logical architecture iteration can take into account allocations of functions to system elements and derived functions coming from physical solution choices. It also supplements the initial logical architecture model by introducing other scenarios, failure analyses, and every operational requirement not previously considered. Derived functions must be allocated to system elements; in turn, this affects the physical architecture models.<br />
<br />
Additional architecture and design iterations can produce a through and consistent logical and physical solution. During system design, technological choices can potentially lead to new functions, new input/output and control flows, and new physical interfaces. These new elements can lead to creation of new system requirements, called ''derived requirements''.<br />
<br />
===Concept of Interface===<br />
<br />
The concept of [[Interface (glossary)|interface]] is one of the most important to consider when defining the architecture of a system. The fundamental aspect of an interface is functional and is defined as inputs and outputs of functions. As functions are performed by physical elements (system elements), inputs/outputs of functions are also carried by physical elements; these are called physical interfaces. Consequentially, both functional and physical aspects are considered in the notion of interface. A detailed analysis of an interface shows the function ''“send”'' located in one system element, the function ''“receive”'' located in the other one, and the function ''“carry"'' as being performed by the physical interface that supports the input/output flow (see Figure 5).<br />
<br />
[[File:SEBoKv075_KA-SystDef_Complete_Interface_Representation.png|400px|thumb|center|'''Figure 4. Complete Interface Representation (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]] <br />
<br />
In the context of complex exchanges between system elements, particularly in software-intensive systems, a protocol is seen as a physical interface that carries exchanges of data.<br />
<br />
===Reuse of System Elements===<br />
Systems engineers frequently utilize existing system elements. This reuse constraint has to be identified as a system requirement and carefully taken into account during architecture and design. One can distinguish three general cases involving system element reuse, as shown in Table 1.<br />
<br />
<center><br />
{|<br />
|+'''Table 1. System Element Re-use Cases (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.<br />
!Re-use Case<br />
!Actions and Comments<br />
|-<br />
|'''Case 1:''' The requirements of the system element are up-to-date and it will be re-used with no modification required.<br />
|<br />
* The system architecture to be designed will have to adapt to the boundaries, interfaces, functions, effectiveness, and behavior of the re-used system element.<br />
* If the system element is not adapted, it is probable that costs, complexity, and risks will increase.<br />
|-<br />
|'''Case 2:''' The requirements of the system element are up-to-date and it will be re-used with possible modifications.<br />
|<br />
* The system architecture to be designed is flexible enough to accommodate the boundaries, interfaces, functions, effectiveness, and behavior of the re-used system element.<br />
* The design of the reused system element, including its test reports and other documentation, will be evaluated and potentially redesigned.<br />
|-<br />
|'''Case 3:''' The requirements are not up-to-date or do not exist.<br />
|<br />
* It is necessary to reverse engineer the system element to identify its boundaries, interfaces, functions, performances, and behavior.<br />
* This is a difficult activity, since the extant documentation for the re-used system element is likely unavailable or insufficient.<br />
* Reverse engineering is expensive in terms of both time and money, and brings with it increased risk.<br />
|}<br />
</center><br />
<br />
<br />
There is a common idea that reuse is ''free''; however, if not approached correctly, reuse may introduce risks that can be significant for the project (costs, deadlines, complexity).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
ANSI/IEEE. 2000. ''Recommended Practice for Architectural Description for Software-Intensive Systems''. New York, NY, USA: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/IEEE 1471-2000.<br />
<br />
ANSI/EIA. 1998. ''Processes for Engineering a System''. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA-632-1998. <br />
<br />
DOD. 2010. ''DOD Architecture Framework.'' Version 2.02. Arlington, VA, USA: US Department of Defense. Available at: http://cio-nii.defense.gov/sites/dodaf20/<br />
<br />
Faisandier, A. 2012. ''Systems Architecture and Design.'' Belberaud, France: Sinergy'Com.<br />
<br />
INCOSE. 2012. ''INCOSE Systems Engineering Handbook,'' Version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.<br />
<br />
ISO/IEC 2008. ''Systems and Software Engineering -- System Life Cycle Processes.'' Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008 (E).<br />
<br />
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.<br />
<br />
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.<br />
<br />
Maier, M., and E. Rechtin. 2009. ''The Art of Systems Architecting.'' 3rd ed. Boca Raton, FL, USA: CRC Press. <br />
<br />
MOD. 2010. ''MOD Architecture Framework.'' Version 1.2.004. UK Ministry of Defence. Available at: http://www.mod.uk/DefenceInternet/AboutDefence/WhatWeDo/InformationManagement/MODAF/.<br />
<br />
Stevens, R., P. Brook, K. Jackson, and S. Arnold. 1998. ''Systems Engineering - Coping with Complexity''. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Wilkinson, M., A. James, M. Emes, P. King, P. Bryant. 2010. “Belief Systems in Systems Architecting: Method and Preliminary Applications." Presented at the IEEE SMC Society’s 5th International Conference on System of Systems Engineering (SoSE). 22nd-24th June 2010. Loughborough University, UK.<br />
<br />
Wilkinson, M.K. 2010. “Z8: Systems Architecture”, in Z-guide series. INCOSE UK, available from INCOSE UK at: http://www.incoseonline.org.uk/Program_Files/Publications/zGuides.aspx?CatID=Publications.<br />
<br />
===Primary References===<br />
<br />
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. <br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2005. ''[[Systems Engineering and Analysis]].'' 4th ed. Prentice-Hall International Series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall. <br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.<br />
<br />
ISO/IEC. 2007. ''[[ISO/IEC 26702|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.<br />
<br />
ISO/IEC/IEEE. 2008. ''[[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]]:2008 (E).<br />
<br />
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]].<br />
<br />
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]].<br />
<br />
Martin, J.N. 1997. ''[[Systems Engineering Guidebook]]: A process for developing systems and products,'' 1st ed. Boca Raton, FL, USA: CRC Press.<br />
<br />
NASA. 2007. ''[[NASA Systems Engineering Handbook|Systems Engineering Handbook]].'' Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.<br />
<br />
===Additional References===<br />
Baldwin, C.Y. and K.B. Clark. 2000. ''Design Rules''. Cambridge, Mass: MIT Press.<br />
<br />
Buede, D.M. 2009. ''The Engineering Design of Systems: Models and Methods''. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc. <br />
<br />
DoD. 2010. ''DOD Architecture Framework.'' Version 2.02. Arlington, VA, USA: US Department of Defense. Available at: http://cio-nii.defense.gov/sites/dodaf20/<br />
<br />
Faisandier, A. 2012. ''Systems Architecture and Design''. Belberaud, France: Sinergy'Com.<br />
<br />
Hatley, D.J., and I.A. Pirbhai. 1987. ''Strategies for Real-Time System Specification''. New York, NY: Dorset House Pub.<br />
<br />
MOD. 2010. ''MOD Architecture Framework,'' Version 1.2.004. UK Ministry of Defence. Available at: http://www.mod.uk/DefenceInternet/AboutDefence/WhatWeDo/InformationManagement/MODAF/.<br />
<br />
Stevens, R., P. Brook, K. Jackson, S. Arnold. 1998. ''Systems Engineering - Coping with Complexity''. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Wilkinson, M., A. James, M. Emes, P. King, P. Bryant. 2010. ''Belief Systems in Systems Architecting: Method and Preliminary Applications''. paper presented at the IEEE SMC Society’s 5th International Conference on System of Systems Engineering (SoSE). 22nd-24th June 2010. Loughborough University, UK.<br />
<br />
----<br />
<center>[[Stakeholder Needs and Requirements|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[System Requirements|Next Article >]]</center><br />
<br />
[[Category: Part 3]][[Category:Knowledge Area]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=System_Definition&diff=48830System Definition2013-10-23T21:19:54Z<p>Groedler: /* Requirements Views */</p>
<hr />
<div>[[System Definition (glossary)|System definition]] activities are conducted to describe in detail a system to satisfy an identified need. The activities are grouped and described as generic processes that are performed concurrently and/or iteratively depending on the selected [[Life Cycle Models|life cycle model.]] These consist of [[System Requirements|system requirements]], [[Logical Architecture Design|logical architecture]], [[Physical Architecture Design | physical architecture]], and [[System Analysis|system analysis]]. During and/or at the end of any iteration, gap analysis is performed to ensure that all system requirements have been mapped to the architecture and design.<br />
<br />
System definition activities build on the artifacts and decisions from [[Concept Definition (glossary) | concept definition]], primarily the articulation of the [[Mission (glossary) | mission]] of the [[System-of-Interest (glossary)|system-of-interest]] (SoI), the [[Stakeholder Requirement (glossary)|needs and requirements of stakeholders]], and preliminary operational concepts. The products of system definition activities (system requirements, architecture, etc.) are inputs to [[System Realization (glossary) |system realization]]. The specific activities and sequence of system definition activities will be dependent upon the type of life cycle model being utilized.<br />
<br />
==Topics==<br />
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: <br />
*[[System Requirements]]<br />
*[[Logical Architecture Design]]<br />
*[[Physical Architecture Design]]<br />
*[[System Analysis]]<br />
See the article [[Matrix of Implementation Examples]] for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.<br />
<br />
==System Views and System Elements ==<br />
An [[Engineered System (glossary)]] solution to a defined concept includes a defined set of engineering elements, characteristics, and properties. These elements are grouped in two ways: <br />
* Needs and requirements views<br />
* Architecture views<br />
<br />
Architecture views include the identification of the boundary and interfaces of a system-of-interest (SoI), which may then be further refined as a collection of [[System Element (glossary)|system elements]] and their relationships.<br />
<br />
===Requirements Views===<br />
<br />
Requirements provide an overall view of the [[Purpose (glossary)|purpose]] and [[Mission (glossary)|mission]] which the system as a whole is intended to satisfy, as well as a technology-independent view of that the system solutions(s) should do. They are conventionally organized into two types:<br />
<br />
*Business or mission requirements and [[Stakeholder Requirement (glossary)|Stakeholder requirements]] are defined and discussed in the [[Concept Definition]] KA.<br />
<br />
*[[System Requirement (glossary)|System requirements]], which describe the functions which the system as a whole should fulfill in order to satisfy the stakeholder requirements and are expressed in an appropriate set of views, and non-functional requirements expressing the levels of safety, security, reliability, etc., which are called for. These collectively form the basis for [[Verification (glossary)|verification]] later in the life cycle.<br />
<br />
System requirements and stakeholder requirements are closely related. Neither 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.<br />
<br />
The process activities that are used to identify, engineer and manage system requirements are described further in the [[System Requirements]] article in the KA.<br />
<br />
===Architecture Views===<br />
There are several architectural representations or views/models of the system:<br />
* The '''[[Logical Architecture (glossary)|logical architecture]]''' supports the logical operation of the system all along its life cycle, and may include functional, behavioral, and temporal views/models. Operational scenarios refine the mission into a collection of [[Function (glossary)|functions]] and dynamic structures that describe how the mission is performed (behavior).<br />
<br />
* The '''[[Physical Architecture (glossary)|physical architecture]]''' is a set of [[System Element (glossary)|system elements]] performing the functions of the system. Those system elements can be either material or immaterial (e.g., equipments made of hardware, software and/or human roles).<br />
<br />
The boundary of the system architectures depends on what engineers include within the scope of the SoI and outside of it. This decision marks the transition from the characterization of the problem context to the beginnings of solution definition.<br />
<br />
Facing the potential number of system elements that constitute the physical architecture, sets of system elements can be grouped to form systems. The decomposition of the SoI (highest level) may include the decomposition of several layers of systems (intermediate levels of systems) until technological system elements (lowest level) are defined. Any layer of the decomposition may include systems and non-decomposable technological system elements.<br />
<br />
Because a system element is primarily an engineered system, it can be characterized in its turn using the previous views in its own context. The notion of system as described and defined here is recursive, see the discussion of systems and engineered system contexts in [[What is a System?]] article. <br />
<br />
The logical and physical representations of the system architecture are mapped onto each other. The interactions between system elements are defined by interfaces whose complexity strongly depends on the way the system architecture is defined. The relationships between the outputs of concept definition and the system solution, as well as the range of other views of a system that are available to describe a more complete set of characteristics between the system elements are discussed further in the [[Logical Architecture Design|logical architecture]] and [[Physical Architecture Design|physical architecture]] sections of the KA.<br />
<br />
==Top-Down and Recursive Approach to System Decomposition==<br />
<br />
System definition is managed through methodical top-down decomposition of the SoI into systems and system elements. As the system architecture definition advances, emerging systems and system elements form a system breakdown structure (SBS). For project management purposes, every system of the SBS may be included in a ''building block'', a notion introduced in (ANSI/EIA 1998), also called ''system block''. <br />
<br />
[[Stakeholder Requirement (glossary)|Stakeholder requirements]] and [[System Requirement (glossary)|system requirements]] exist at all layers of the SBS. In ISO/IEC/IEEE (2011), these layers are known as levels of abstraction. Along with systematically introducing layers of systems, the architecture and design process manages the transformation of the [[System Requirements|system requirements]] through levels of abstraction. Figure 1 illlustrates this approach.<br />
<br />
[[File:SEBoKv05_KA-SystDef_Top-down_development_of_design_and_requirements.png|thumb|center|500px|center|'''Figure 1. Top-down Development of Architecture and Design, and Requirements (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
As shown in Figure 1<br />
* The white ovals represent requirements at decreasing levels of abstraction, and the arrows represent the transformation of those requirements through the levels using the architecture and design process. Stakeholder expressions of needs, expectations, and constraints are transformed into stakeholder requirements.<br />
* The next transformation crosses the boundary between the problem and solution areas by converting stakeholder requirements into system requirements, reflecting the bounded solution space.<br />
* At the SoI level, the system architecture is developed which serves to identify systems and system elements and establishes how they operate together to address the SoI requirements. <br />
<br />
This approach is applied recursively for each level of abstraction/decomposition recognizing that the same generic processes are applied at multiple levels of abstraction. Figure 2 below portrays the engineering that occurs in each system block. As necessary, system elements are defined through sets of system element requirements, which become inputs to other system blocks (''level n+1''). The approach is then recursively applied using the system definition processes.<br />
<br />
[[File:Recursive_Instantiation_of_Def_Process_AF_071112.png|thumb|center|700px|center|'''Figure 2. Recursive Instantiation of Definition Processes (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
At the ''n+1'' level, the systems or system elements may also collect other stakeholder requirements that are directly pertinent to this level of architecture and design. Processes within each system are generic, but unique in local purpose, scope and context.<br />
<br />
==System Architecture==<br />
Within the SE community, notions of architecture have been heavily influenced by ISO/IEC 15288 (2008), which even today presents a somewhat implicit view of architecture, conflating it with [[Design (glossary) |design]] as part of a single system life cycle process called ''architectural design''. Although there are diverse viewpoints on architecture, the different perspectives have much in common. The SEBoK considers systems engineering to cover all aspects of the creation of a system, including system architecture.<br />
<br />
The majority of interpretations of system architecture are based on the fairly intangible notion of ''structure'' (i.e. relationships between elements). <br />
<br />
Some authors limit the types of structure considered to be architectural; for example, restricting themselves to ''functional'' and ''physical'' structure. Recent practice has extended consideration to include ''temporal'' and other dimensions of structure within specified architectural frameworks (DoDAF (DoD 2010) and MODAF (MOD 2010)).<br />
<br />
ISO/IEC/IEEE 42010 (2011) provides a useful description of the architecture considering the stakeholder concerns, architecture viewpoints, architecture views, architecture models, architecture descriptions, and architecting throughout the life cycle. A discussion of the features of systems architectures can be found in Maier and Rechtin (2009).<br />
<br />
While architectural concepts are very useful and widely used in SE, there is a lack of consistency across communities of practice that creates the potential for confusion. An attempt to develop and apply a systematic approach to characterizing architecture belief systems in systems engineering has been described by the INCOSE UK Architecture Working Group (Wilkinson et al.2010, Wilkinson 2010).<br />
<br />
==System Design==<br />
<br />
In industrial practices, the term ''design'' is often used to mean both [[Architecture (glossary)]] and [[Design (glossary)]] as defined in the SEBoK. In the recent past, professionals used the term ''design'' when they dealt with simpler technological products - ones that do not include several different and interconnected technological components such as hardware, software, operators, services, etc. In the development of new multi-technology products and services, professionals have recognized the usefulness of the notion of ''system'' in dealing with [[Complexity (glossary)]] (interconnections level, multi-techno, emergence, etc.). <br />
<br />
It was due to complexity that structuring the elements that comprise a system became necessary. This structure explains the functional, behavioral, temporal, physical, and other aspects of a system as previously described. Practitioners found the term ''structure'' inadequate to describe all of these aspects of a system. The terms ''architecture'' and ''architectural design'' have been used for approximately 30 years, especially in software intensive systems and other domains, such as the space industry. The set of different types and interrelated structures can be understood as the architecture of the system.<br />
<br />
The trend today is to consider system architecture and system design as different sets of activities. Attempts are made to define separate concurrent processes, but they are strongly intertwined:<br />
<br />
* System design includes activities to conceive a system that answers a specific, intended purpose, using principles and concepts; it includes assessments and decisions to select elements that compose the system, fit the architecture of the system, and comply with traded-off system requirements. It is the complete set of detailed models, properties, and/or characteristics described into a form suitable for implementation. <br />
* System architecture is more abstract, conceptualization-oriented, global, and focused on mission success and on high level structure in (sub)systems. It may also be applied to more than one system, in some cases forming the common structure, pattern, and set of requirements for classes or families of similar or related systems.<br />
<br />
System design is intended to be the link between the system architecture (at whatever point this milestone is defined in the specific application of the systems engineering process) and the implementation of technological system elements that compose the physical architecture of the system.<br />
<br />
These related processes are presented together in the present version of the SEBoK, though effort has been made to distinguish between the corresponding activities.<br />
<br />
==General System Architecture and Design Principles and Concepts==<br />
<br />
===Classification of Principles and Heuristics===<br />
<br />
Engineers and architects use a mixture of mathematical principles and heuristics that are learned through experience. When an issue is identified through system requirements, principles and heuristics may or may not be able to address it. Principles and heuristics that are used in system views/models can be classified according to the domains in which those system views/models are used, as follows:<br />
<br />
# '''Static domain''' relates to physical structure or organization of the SoI broken down into systems and [[System Element (glossary)|system elements]]. It deals with partitioning systems, system elements, and physical interfaces.<br />
# '''Dynamic domain''' relates to logical architecture models; in particular, to the representation of the behavior of the system. It includes a description of functions (i.e. transformations of input/output flows) and interactions between functions of the system and between those of the external objects or systems. It takes into account reactions to events that launch or stop the execution of functions of the system. It also deals with the effectiveness (i.e. performances, operational conditions) of the system.<br />
# '''Temporal domain''' relates to temporal invariance levels of the execution of functions of the system. This means that every function is executed according to cyclic or synchronous characteristics. It includes decisional levels that are asynchronous characteristics of the behavior of some functions.<br />
# '''Environmental domain''' relates to enablers (production, logistics support, etc.), but also to the [[Survivability (glossary)|survivability]] of the system in reaction to natural hazards or threats and to the [[Integrity (glossary)|integrity]] of the system in reaction to internal potential hazards. This includes, for example, climatic, mechanical, electromagnetic, and biological aspects.<br />
<br />
More detailed classification can be found in Maier and Rechtin (2009).<br />
<br />
===Transition from System Requirements to Physical Architecture===<br />
<br />
The aim of the approach is to progress from system requirements (representing the problem from a supplier/designer point of view, as independent of technology as possible) to an intermediate model of [[Logical Architecture (glossary)|logical architecture]], then to allocate the elements of the logical architecture to system elements of candidate [[Physical Architecture (glossary)|physical architectures]]. <br />
<br />
(System requirements and logical architecture share many characteristics, as they are both organized on functional lines, independently of the implementation. Some authors (Stevens et al 1998) go so far as to conflate the two, which simplifies the handling of multiple simultaneous views. Whether this approach is adopted depends on the specific practices of the development organization and where contractual boundaries are drawn.) <br />
<br />
Design decisions and technological solutions are selected according to performance criteria and non-functional requirements, such as operational conditions and life cycle constraints (e.g., environmental conditions, maintenance constraints, realization constraints, etc.), as illustrated in Figure 3. Creating intermediate models, such as logical architecture models, facilitates the validation of functional, behavioral, and temporal properties of the system against the system requirements that have no major technological influence impacts during the life of the system, the physical interfaces, or the technological layer without completely questioning the logical functioning of the system.<br />
<br />
[[File:SEBoKv075_KA-SystDef_Progressive_Approach_for_Designing.png|600px|thumb|center|'''Figure 3. Usage of Intermediate Logical Architecture Models During Architecture and Design (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
===Iterations between Logical and Physical Architecture Definition===<br />
<br />
Architecture and design activities require spending several iterations from logical architecture models definitions to physical architecture models definitions and vice versa, until both logical and physical architecture models are exhaustive and consistent. The first architecture and design activity is the creation of a logical architecture model based on nominal scenarios (of functions). Physical architecture is used to determine main system elements that could perform system functions and to organize them into a physical architecture model.<br />
<br />
A second logical architecture iteration can take into account allocations of functions to system elements and derived functions coming from physical solution choices. It also supplements the initial logical architecture model by introducing other scenarios, failure analyses, and every operational requirement not previously considered. Derived functions must be allocated to system elements; in turn, this affects the physical architecture models.<br />
<br />
Additional architecture and design iterations can produce a through and consistent logical and physical solution. During system design, technological choices can potentially lead to new functions, new input/output and control flows, and new physical interfaces. These new elements can lead to creation of new system requirements, called ''derived requirements''.<br />
<br />
===Concept of Interface===<br />
<br />
The concept of [[Interface (glossary)|interface]] is one of the most important to consider when defining the architecture of a system. The fundamental aspect of an interface is functional and is defined as inputs and outputs of functions. As functions are performed by physical elements (system elements), inputs/outputs of functions are also carried by physical elements; these are called physical interfaces. Consequentially, both functional and physical aspects are considered in the notion of interface. A detailed analysis of an interface shows the function ''“send”'' located in one system element, the function ''“receive”'' located in the other one, and the function ''“carry"'' as being performed by the physical interface that supports the input/output flow (see Figure 5).<br />
<br />
[[File:SEBoKv075_KA-SystDef_Complete_Interface_Representation.png|400px|thumb|center|'''Figure 4. Complete Interface Representation (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]] <br />
<br />
In the context of complex exchanges between system elements, particularly in software-intensive systems, a protocol is seen as a physical interface that carries exchanges of data.<br />
<br />
===Reuse of System Elements===<br />
Systems engineers frequently utilize existing system elements. This reuse constraint has to be identified as a system requirement and carefully taken into account during architecture and design. One can distinguish three general cases involving system element reuse, as shown in Table 1.<br />
<br />
<center><br />
{|<br />
|+'''Table 1. System Element Re-use Cases (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.<br />
!Re-use Case<br />
!Actions and Comments<br />
|-<br />
|'''Case 1:''' The requirements of the system element are up-to-date and it will be re-used with no modification required.<br />
|<br />
* The system architecture to be designed will have to adapt to the boundaries, interfaces, functions, effectiveness, and behavior of the re-used system element.<br />
* If the system element is not adapted, it is probable that costs, complexity, and risks will increase.<br />
|-<br />
|'''Case 2:''' The requirements of the system element are up-to-date and it will be re-used with possible modifications.<br />
|<br />
* The system architecture to be designed is flexible enough to accommodate the boundaries, interfaces, functions, effectiveness, and behavior of the re-used system element.<br />
* The design of the reused system element, including its test reports and other documentation, will be evaluated and potentially redesigned.<br />
|-<br />
|'''Case 3:''' The requirements are not up-to-date or do not exist.<br />
|<br />
* It is necessary to reverse engineer the system element to identify its boundaries, interfaces, functions, performances, and behavior.<br />
* This is a difficult activity, since the extant documentation for the re-used system element is likely unavailable or insufficient.<br />
* Reverse engineering is expensive in terms of both time and money, and brings with it increased risk.<br />
|}<br />
</center><br />
<br />
<br />
There is a common idea that reuse is ''free''; however, if not approached correctly, reuse may introduce risks that can be significant for the project (costs, deadlines, complexity).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
ANSI/IEEE. 2000. ''Recommended Practice for Architectural Description for Software-Intensive Systems''. New York, NY, USA: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/IEEE 1471-2000.<br />
<br />
ANSI/EIA. 1998. ''Processes for Engineering a System''. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA-632-1998. <br />
<br />
DOD. 2010. ''DOD Architecture Framework.'' Version 2.02. Arlington, VA, USA: US Department of Defense. Available at: http://cio-nii.defense.gov/sites/dodaf20/<br />
<br />
Faisandier, A. 2012. ''Systems Architecture and Design.'' Belberaud, France: Sinergy'Com.<br />
<br />
INCOSE. 2012. ''INCOSE Systems Engineering Handbook,'' Version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.<br />
<br />
ISO/IEC 2008. ''Systems and Software Engineering -- System Life Cycle Processes.'' Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008 (E).<br />
<br />
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.<br />
<br />
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.<br />
<br />
Maier, M., and E. Rechtin. 2009. ''The Art of Systems Architecting.'' 3rd ed. Boca Raton, FL, USA: CRC Press. <br />
<br />
MOD. 2010. ''MOD Architecture Framework.'' Version 1.2.004. UK Ministry of Defence. Available at: http://www.mod.uk/DefenceInternet/AboutDefence/WhatWeDo/InformationManagement/MODAF/.<br />
<br />
Stevens, R., P. Brook, K. Jackson, and S. Arnold. 1998. ''Systems Engineering - Coping with Complexity''. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Wilkinson, M., A. James, M. Emes, P. King, P. Bryant. 2010. “Belief Systems in Systems Architecting: Method and Preliminary Applications." Presented at the IEEE SMC Society’s 5th International Conference on System of Systems Engineering (SoSE). 22nd-24th June 2010. Loughborough University, UK.<br />
<br />
Wilkinson, M.K. 2010. “Z8: Systems Architecture”, in Z-guide series. INCOSE UK, available from INCOSE UK at: http://www.incoseonline.org.uk/Program_Files/Publications/zGuides.aspx?CatID=Publications.<br />
<br />
===Primary References===<br />
<br />
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. <br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2005. ''[[Systems Engineering and Analysis]].'' 4th ed. Prentice-Hall International Series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall. <br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.<br />
<br />
ISO/IEC. 2007. ''[[ISO/IEC 26702|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.<br />
<br />
ISO/IEC/IEEE. 2008. ''[[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]]:2008 (E).<br />
<br />
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]].<br />
<br />
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]].<br />
<br />
Martin, J.N. 1997. ''[[Systems Engineering Guidebook]]: A process for developing systems and products,'' 1st ed. Boca Raton, FL, USA: CRC Press.<br />
<br />
NASA. 2007. ''[[NASA Systems Engineering Handbook|Systems Engineering Handbook]].'' Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.<br />
<br />
===Additional References===<br />
Baldwin, C.Y. and K.B. Clark. 2000. ''Design Rules''. Cambridge, Mass: MIT Press.<br />
<br />
Buede, D.M. 2009. ''The Engineering Design of Systems: Models and Methods''. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc. <br />
<br />
DoD. 2010. ''DOD Architecture Framework.'' Version 2.02. Arlington, VA, USA: US Department of Defense. Available at: http://cio-nii.defense.gov/sites/dodaf20/<br />
<br />
Faisandier, A. 2012. ''Systems Architecture and Design''. Belberaud, France: Sinergy'Com.<br />
<br />
Hatley, D.J., and I.A. Pirbhai. 1987. ''Strategies for Real-Time System Specification''. New York, NY: Dorset House Pub.<br />
<br />
MOD. 2010. ''MOD Architecture Framework,'' Version 1.2.004. UK Ministry of Defence. Available at: http://www.mod.uk/DefenceInternet/AboutDefence/WhatWeDo/InformationManagement/MODAF/.<br />
<br />
Stevens, R., P. Brook, K. Jackson, S. Arnold. 1998. ''Systems Engineering - Coping with Complexity''. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Wilkinson, M., A. James, M. Emes, P. King, P. Bryant. 2010. ''Belief Systems in Systems Architecting: Method and Preliminary Applications''. paper presented at the IEEE SMC Society’s 5th International Conference on System of Systems Engineering (SoSE). 22nd-24th June 2010. Loughborough University, UK.<br />
<br />
----<br />
<center>[[Stakeholder Needs and Requirements|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[System Requirements|Next Article >]]</center><br />
<br />
[[Category: Part 3]][[Category:Knowledge Area]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_or_Mission_Analysis&diff=48827Business or Mission Analysis2013-10-23T06:33:05Z<p>Groedler: </p>
<hr />
<div>The starting point of engineering any [[System-of-Interest (glossary)|system-of-interest]] (SoI) is understanding the socio-economic and technological context in which potential problems or opportunities reside. Then, the enterprise strategic goals and [[Stakeholder (glossary)| stakeholder]] needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of business or enterprise decision makers while also taking into account the views of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], and [[Customer (glossary)|customers]]. <br />
<br />
Mission Analysis (MA) is part of the larger set of [[Concept Definition (glossary)|Concept Definition]] activities - the set of systems engineering activities in which the problem space and the needs of the business or enterprise and stakeholders are closely examined; this occurs before any formal definition of the (SoI) is developed, but may need to be revisited through the life cycle. In fact, the activities of Concept Definition determine whether the enterprise strategic goals and business needs will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution. The MA activity focuses on the identification of the primary purpose(s) of the solution (its ""mission""), while [[Stakeholder Needs and Requirements]] activity explores what capabilities stakeholders desire in accomplishing the mission and may include some detail on the performance of certain aspects of the solution. MA is often performed iteratively with the [[Stakeholder Needs and Requirements]] activity to better understand the problem (or opportunity) space, as well as the solution space.<br />
<br />
== Purpose and Definition ==<br />
The purpose of MA is to understand a mission/market problem or opportunity, analyze the solution space, and initiate the life cycle of a potential solution that could address the problem or take advantage of an opportunity. MA is a type of strategic or operations analysis related to needs, capability gaps, or opportunities and solutions that can be applied to any organization that evolves its strategy for its business objectives.<br />
<br />
MA, in some domains called [[Market Analysis (glossary)|market analysis (glossary)]] or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise. The definition of a mission or business function in a problem space frames the solution, both in terms of the direct application to the mission or business function, and in terms of the context for the resulting solution. <br />
<br />
MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. MA begins with the business vision and Concept of Operations (ConOps), and other organization strategic goals and objectives including the mission (or business function). The primary products of MA are Business or Mission Needs, which are supported by preliminary life-cycle concepts—including a preliminary acquisition concept, a preliminary operational concept (OpsCon), a preliminary deployment concept, a preliminary support concept, and a preliminary retirement concept. Business or Mission Needs are then elaborated and formalized into Business or Mission Requirements. The preliminary operational concept includes the operational scenarios for the mission and the context in which the solution will exist. <br />
<br />
MA may include mathematical analysis, modeling, simulation, visualization, and other analytical tools to characterize the intended mission and determine how to best achieve the needs/objectives. MA evaluates alternative approaches to determine which best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions). Thus, MA defines the problem space and analyzes the solution space alternatives using quality attribute constraints driven by the enterprise objectives.<br />
<br />
==Principles and Concepts==<br />
===Mission Analysis and Concept of Operations===<br />
MA and the ConOps and OpsCon are broadly used in U.S. defense and aerospace organizations to analyze and define how a system is intended to operate, as well as how the major operations or operational scenarios are intended to be performed. They take into account the strategic, operational, and tactical aspects of the identified scenarios. ANSI/AIAA G-043A-2012 identifies that the terms ‘concept of operations’ and ‘operational concept’ are often used interchangeably but notes that an important distinction exists because each has a separate purpose and is used to meet different ends. The ConOps is at an organisational level, prepared by enterprise management and refined by business management:<br />
<br />
<blockquote>''The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems (as black boxes) to forward the organization's goals and objectives. The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations within the business in regards to the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of future business and systems.'' (ISO/IEC 2011) </blockquote> <br />
<br />
The ConOps informs the OpsCon, which is drafted by business management in the Mission Analysis activity and refined by stakeholders in the Stakeholder Needs and Requirements activity:<br />
<br />
<blockquote>''A system OpsCon document describes what the system will do (not how it will do it) and why (rationale). An OpsCon is a user-oriented document that describes system characteristics of the to-be-delivered system from the user's viewpoint. The OpsCon document is used to communicate overall quantitative and qualitative system characteristics to the acquirer, user, supplier and other organizational elements.'' (ISO/IEC 2011) </blockquote><br />
<br />
It should be noted that the OpsCon has an operational focus and should be supported by the development of other concepts, including a deployment concept, a support concept, and a retirement concept. <br />
<br />
In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering (SE) leaders interact with enterprise leaders and operations analysts to understand <br />
*the enterprise ConOps and future mission, business, and operational (MBO) objectives; <br />
*the characterization of the operational concept and objectives (i.e., constraints, mission or operational scenarios, tasks, resources, risks, assumptions, and related missions or operations); and<br />
*how specific missions or operations are currently conducted and what gaps exist in those areas.<br />
<br />
They then conceptually explore and select from alternative candidate solutions. This interaction ensures a full understanding of both the problem space and the solution space. The alternative candidate solutions can include a wide range of approaches to address the need, as well as variants for an approach to optimize specific characteristics (e.g., using a different distribution of satellite orbit parameters to maximize coverage or events while minimizing the number of satellites). Analysis, modeling and simulation, and trade studies are employed to select alternative approaches (NDIA 2010).<br />
<br />
The notions of mission analysis, ConOps and OpsCon are also used in industrial sectors, such as aviation administrations and aeronautic transportation, health care systems, and space with adapted definitions and/or terms, such as operational concepts, usage concepts and/or technological concepts. For example, “mission analysis” is the term used to describe the mathematical analysis of satellite orbits performed to determine how best to achieve the objectives of a space mission (ESA 2008).<br />
<br />
In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:<br />
<br />
<blockquote>''. . . studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and this in turn of the global environmental analysis. Through all these analyses, the chances, strengths, weaknesses, and risks of a company can be identified. Finally, with the help of a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm's planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company.'' (Wikipedia Contributors, 2012)</blockquote><br />
<br />
Anywhere these notions are used, it is evident that they are based on fundamental concepts, such as the [[Operational Mode (glossary)|operational mode]] (or state of the system), [[Scenario (glossary)|scenario]] (of actions), the enterprise level ConOps and the system level operational concepts, [[Function (glossary) |functions]], etc. For more explanations about the ConOps and operational concept, refer to ''Systems and Software Engineering - Requirements Engineering'' (ISO/IEC 2011); useful information can be found in Annex A, "System Operational Concept", and Annex B, "Concept of Operations" (ISO/IEC 2011).<br />
<br />
===Mission Analysis as Part of Enterprise Strategy Development===<br />
Periodically, most enterprises re-evaluate their strategy with respect to their mission, vision, and positioning to accomplish their goals. Figure 1 shows the interactions of the enterprise strategy development and the concept definition, including the MA and [[Stakeholder Needs and Requirements]] activities that are involved in an iterative manner to fully develop the strategy and define future capabilities and solutions. <br />
<br />
[[File:Enterprise_Strategy_and_Concept_Development.PNG|thumb|700px|center|'''Figure 1. Enterprise Strategy and Concept Development (Roedler 2012).''' Used with permission of Garry Roedler. All other rights are reserved by the copyright owner.]]<br />
<br />
As the enterprise evolves the strategy, it is essential to conduct the supporting MA or strategic analysis for each element of the enterprise to determine readiness to achieve future objectives. This analysis examines the current state to identify any problems or opportunities related to the objective achievement and aids the enterprise in fully understanding and defining the problem space. The analysis examines the external environment and interfaces in search of impacts and trends, as well as the internal enterprise to gauge its capabilities and value stream gaps. Additionally, a strengths, weaknesses, opportunities, and threats (SWOT) analysis may be performed. As the problem space is defined, the stakeholder needs are defined and transformed into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, the future state of core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities. Finally, MA is engaged again to examine the solution space. Candidate solutions that span the potential solution space are identified, from simple operational changes to various system developments or modifications. Various techniques are applied to analyze the candidates, understand their feasibility and value, and select the best alternative.<br />
<br />
==Process Approach==<br />
===Activities of the Process===<br />
It is necessary to perform the following major activities and tasks during the MA process: <br />
#Review and understand the enterprise mission, vision, and ConOps.<br />
#Identify and define any gaps and opportunities related to future evolution of the strategy:<br />
##Examine the current state to identify any problems or opportunities related to the objective achievement, including any deficiencies of the existing system.<br />
##Analyze the context of the actual political, economic, social, technological, environmental, and legal (PESTAL) factors, while studying sensitive factors such as cost and effectiveness, security and safety improvement, performance improvement or lack of existing systems, market opportunities, regulation changes, users' dissatisfaction, etc. External, internal, and SWOT analysis should be included as well. For the technological considerations, an appropriate architectural framework representation, such as the U.S. Department of Defense Architecture Framework (DoDAF) operations view (DoD 2010), the Zachman Framework (Rows1 and 2) (Zachman 2008), and The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM) (The Open Group 2010) Phases A and B should be included within the concept definition when performing mission analysis and stakeholders needs and requirements.<br />
##Define the mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without focusing on a solution. <br />
#Examine and evaluate the solution space.<br />
##Identify the main stakeholders (customers, users, administrations, regulations, etc.).<br />
##Identify high level operational modes or states, or potential use cases.<br />
##Identify candidate solutions that span the potential solution space, from simple operational changes to various system developments or modifications. Identify existing systems, products, and services that may address the need for operational or functional modifications. Deduce what potential expected services may be needed. The SoI is a potential and not yet existing product, service or enterprise. Additionally, the solution could be an operational change or a change to an existing product or service.<br />
#Perform appropriate modeling, simulation, and analytical techniques to understand the feasibility and value of the alternative candidate solutions. Model or simulate operational scenarios from these services and use cases, and enrich them through reviews with stakeholders and subject matter experts.<br />
#Define basic operational concept or market strategy, and/or business models.<br />
##From previous modeled operational scenarios and operational modes, deduce and express the usage of operational concepts, or technical concepts.<br />
##Collect and enrich needs, expectations, scenarios, and constraints.<br />
##Validate the mission of any potential SoI in the context of any proposed market strategy or business model.<br />
#Evaluate the set of alternatives and select the best alternative.<br />
##Perform a trade study of the alternatives to discriminate between the alternatives.<br />
#Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.<br />
#Define preliminary deployment concept, preliminary support concept, and preliminary retirement concept.<br />
<br />
===Mission Analysis Artifacts===<br />
<br />
This process may create several artifacts, such as<br />
*recommendations for revisions to the enterprise ConOps;<br />
*preliminary operational concept document or inputs;<br />
*mission analysis and definition reports (perhaps with recommendations for revisions of the mission); <br />
*a set of Business Needs<br />
*preliminary life-cycle concepts (preliminary operational concept, preliminary deployment concept, preliminary support concept, and preliminary retirement concept<br />
*[[System Analysis|system analysis]] artifacts (e.g., use case diagrams, context diagrams, sequence/activity diagrams, functional flow block diagrams);<br />
*trade study results (alternatives analysis);<br />
*market study/analysis reports; and<br />
*a set of Business (or Mission) Requirements (often captured in a Business Requirement Specification).<br />
<br />
===Methods and Modeling Techniques===<br />
<br />
MA uses several techniques, such as<br />
<br />
*use case analysis;<br />
*operational analysis; <br />
*functional analysis;<br />
*technical documentation review;<br />
*trade studies;<br />
*modeling;<br />
*simulation;<br />
*prototyping;<br />
*workshops, interviews, and questionnaires;<br />
*market competitive assessments;<br />
*benchmarking; and<br />
*organizational analysis techniques (e.g., strengths, weaknesses, opportunities, threats (SWOT analysis), and product portfolios).<br />
<br />
==Practical Considerations==<br />
Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1. <br />
<br />
<center><br />
{|<br />
|+'''Table 1. Major Pitfalls for Mission Analysis.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|Wrong level of system addressed<br />
|When delineating the boundaries of the SoI and defining the mission and purpose of the system at the very beginning of systems engineering, a classic mistake is to place the system-of-interest at the wrong level of abstraction. The level of abstraction can be too high or too low (sitting respectively in the upper-system or in a sub-system). This is the consequence of the principle stating that a system is always included in a larger system and of confusing the purpose and the mission of the SoI.<br />
|-<br />
|Operational modes or scenarios missing<br />
|In commercial products or systems, the lack or insufficient description of operational modes and scenarios (how the SoI will be used, in which situations, etc.) is often encountered.<br />
|}<br />
</center><br />
<br />
<br />
Proven practices with mission analysis and marketing analysis are presented in Table 2.<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Mission Analysis Proven Practices.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|Models of operational scenarios<br />
|Using modeling techniques as indicated in sections above for operational scenarios in any kind of SoI (including commercial systems).<br />
|-<br />
|Models of the context<br />
|Consider the context of use as a system and force oneself to use modeling techniques for main aspects of the context (functional, behavioral, physical, etc.).<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
DoD. 2010. ''DoD Architecture Framework'', version 2.02. Arlington, VA: U.S. Department of Defense. Accessed August 29, 2012. Available at: http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_v2-02_web.pdf.<br />
<br />
ESA. 2008. ''Mission Analysis: Towards a European Harmonization.'' Paris, France: European Space Agency. Accessed August 29, 2012. Available at: http://www.esa.int/esapub/bulletin/bulletin134/bul134b_schoenmaekers.pdf.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering -- Life cycle processes -- Requirements engineering.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC/IEEE 29148:2011.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and Software Engineering - Life CYcle Processes - Requirements Engineering.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 29148:2011.<br />
<br />
Kaplan, R.S. and D.P. Norton. 2008. “Developing the Strategy: Vision, Value Gaps, and Analysis,” Balanced Scorecard Report. Cambridge, MA, USA: Harvard Business School Publishing, Jan-Feb 2008.<br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A simple method for phased mission analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309.<br />
<br />
NDIA. 2010. “Mission Analysis Committee Charter”. Website of the National Defense Industrial Association, Systems Engineering Division, Mission Analysis Committee. Accessed August 29, 2012. Available at: http://www.ndia.org/Divisions/Divisions/SystemsEngineering/Documents/Committees/Mission%20Analysis%20Committee/Mission%20Analysis%20Committee%20Charter.pdf.<br />
<br />
Shupp, J.K. 2003. “The Mission Analysis Discipline: Bringing focus to the fuzziness about Attaining Good Architectures.” Proceedings of INCOSE 13th International Symposium, July 2003.<br />
<br />
The Open Group. 2011. ''TOGAF'', version 9.1. Hogeweg, The Netherlands: Van Haren Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.<br />
<br />
Wikipedia contributors, "Market analysis," Wikipedia, The Free Encyclopedia, http://en.wikipedia.org/w/index.php?title=Market_analysis&oldid=508583878 (accessed August 29, 2012).<br />
<br />
Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™." Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.<br />
<br />
===Primary References===<br />
ISO/IEC/IEEE. 2008. ''[[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]]:2008 (E).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]: From System Goals to UML Models to Software Specifications''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
Center for Quality Management. 1993. "Special Issue on Kano's Methods for Understanding Customer Defined Quality." ''Center for Quality Management Journal.'' 2(4) (Fall 1993). <br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.<br />
<br />
Freeman, R. "Chapter 27: Achieving Strategic Aims: Moving Toward a Process Based Military Enterprise," in ''Handbook of Military Industrial Engineering.'' A.B. Badiru and M.U. Thomas (eds). Boca Raton, FL, USA: Taylor & Francis Group, CRC Press.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering.'' 3rd ed. London, UK: Springer.<br />
<br />
Kano, N. 1984. "Attractive Quality and Must-Be Quality." ''Quality JSQC.'' 14(2) (October 1984). <br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309. <br />
<br />
Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques." ''Software Engineering''. New York, NY: McGraw-Hill.<br />
<br />
MITRE. 2011. "Concept Development." ''Systems Engineering Guide.'' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/]].<br />
<br />
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/]].<br />
<br />
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]].<br />
----<br />
<center>[[Concept Definition|< Previous Article]] | [[Concept Definition|Parent Article]] | [[Stakeholder Needs and Requirements|Next Article >]]</center><br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Concept Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Stakeholder_Needs_Definition&diff=48826Stakeholder Needs Definition2013-10-23T06:28:04Z<p>Groedler: </p>
<hr />
<div>[[Stakeholder Requirement (glossary)|Stakeholder needs and requirements]] represent the views of those at the business or enterprise operations level—that is, of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], [[Customer (glossary)|customers]], and other [[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 the enterprise-level ConOps and the system-level preliminary OpsCon as guidance, stakeholders from business operations are led through a structured process to elicit stakeholder needs (in the form of a refined system-level OpsCon and other life-cycle concepts). Stakeholder needs are then transformed into a defined set of Stakeholder Requirements, which are often documented in a Stakeholder Requirement Specification. <br />
<br />
Stakeholder requirements play major roles in systems engineering, as they:<br />
* Form the basis of [[System Requirement (glossary)|system requirements]] activities.<br />
* Form the basis of system [[Validation (glossary)|validation]] and stakeholder acceptance .<br />
* Act as a reference for [[Integration (glossary) | integration]] and [[Verification (glossary)|verification]] activities.<br />
* Serve as means of communication between the technical staff, management, finance department, and the stakeholder community.<br />
<br />
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) 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) | system definition]]. None of the above can be considered complete until consistency between the two has been achieved, as demonstrated by [[Traceability (glossary)|traceability]], for which a number of iterations may be needed. <br />
<br />
<br />
==Purpose and Definition==<br />
The purpose of the Stakeholder Needs and Requirements definition activity 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 stakeholder needs into clear, concise, and verifiable stakeholder requirements.<br />
<br />
The set of stakeholder needs, desires, and expectations may contain vague, ambiguous, and qualitative ''user-oriented'' need statements that are difficult to use for SE activities. These statements may need to be further clarified and translated into more ''engineering-oriented'' language to enable proper architecture definition and requirement activities. As an example, a need or an expectation such as, ''to easily maneuver a car in order to park'', will be transformed in a set of [[Stakeholder Requirement (glossary)|stakeholder requirements]] to a statement such as, ''increase the drivability of the car'', ''decrease the effort for handling'', ''assist the piloting'', ''protect the coachwork against shocks or scratch'', etc.<br />
<br />
==Principles and Concepts==<br />
<br />
===From the Capture of Stakeholder Needs to the Definition of Stakeholder Requirements===<br />
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.<br />
<br />
[[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.]]<br />
<br />
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: <br />
<br />
* '''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.<br />
* '''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 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.<br />
* '''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. <br />
* '''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 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.<br />
* '''Specified needs''', generally called [[System Requirement (glossary)|system requirements]], 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). <br />
* '''Realized needs''' are the product, service, or enterprise realized, taking into account every system requirement (and hence, the stakeholder requirements).<br />
<br />
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).<br />
<br />
===Identifying Stakeholders and theirNeeds and Requirements===<br />
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. <br />
<br />
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.<br />
<br />
<center><br />
{|<br />
|+'''Table 1. Stakeholder Identification Based on Life Cycle Stages.''' (SEBoK Original)<br />
!Life Cycle Stage<br />
!Example of Related Stakeholders<br />
|-<br />
|Engineering<br />
|Acquirer, panel of potential users, marketing division, research and development department, standardization body, suppliers, verification and validation team, production system, regulator/certification authorities, etc.<br />
|-<br />
|Development<br />
|Acquirer, suppliers (technical domains for components realization), design engineers, integration team, etc.<br />
|-<br />
|Transfer for Production or for Use<br />
|Quality control, production system, operators, etc.<br />
|-<br />
|Logistics and Maintenance<br />
|Supply chain, support services, trainers, etc.<br />
|-<br />
|Operation<br />
|Normal users, unexpected users, etc.<br />
|-<br />
|Disposal<br />
|Operators, certifying body, etc.<br />
|}<br />
</center><br />
<br />
<br />
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.<br />
<br />
===Classification of Stakeholder Requirements===<br />
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.<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Example of Stakeholder Requirements Classification.''' (SEBoK Original)<br />
!Type of Stakeholder Requirement<br />
!Description<br />
|-<br />
|'''Service or Functional'''<br />
|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.<br />
|-<br />
|'''Operational'''<br />
|This category may include:<br />
*Operational concepts that indicate the operational features to be provided without specifying design solutions.<br />
*Operational scenarios describing the sequence or series of activities supported by the system-of-interest.<br />
*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.<br />
|-<br />
|'''Interface'''<br />
|Matter, energy, or information flows exchanged between the system-of-interest and its external components in the context of its use, including physical interfaces.<br />
|-<br />
|'''Environmental'''<br />
|External conditions that affect the system when in operation.<br />
|-<br />
|'''Utilization Characteristics'''<br />
|The '-ilities' used to indicate conditions of the utilization of the system-of-interest (e.g. usability, dependability, security, etc.).<br />
|-<br />
|'''Human Factors'''<br />
|Capabilities of users and operators, ergonomics, and associated constraints.<br />
|-<br />
|'''Logistical'''<br />
|Acquisition, transportation, and storage of elements needed by the system-of-interest to perform its services (e.g. constraints for logistical support).<br />
|-<br />
|'''Design and Realization Constraints'''<br />
|Reuse of existing system elements or forbidden materials, for example.<br />
|-<br />
|'''Process Constraints'''<br />
|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 will be developed and provided. Process requirements include compliance with national, state, or local laws, such as 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.<br />
|-<br />
|'''Project Constraints'''<br />
|Constraints to performing the project and/or the end-item system within cost and schedule.<br />
|-<br />
|'''Business Model Constraints'''<br />
|Constraints related to the expected business goal achieved by the system-of-interest, when this is relevant within the context of use, which 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.<br />
|}<br />
</center><br />
<br />
==Process Approach==<br />
<br />
===Activities of the Process===<br />
Major activities and tasks performed during this process include the following:<br />
* Identify the stakeholders or classes of stakeholders across the life cycle.<br />
* Elicit, capture, or consolidate the stakeholder needs, expectations, and objectives as well as any constraints coming from the mission and business analysis processes.<br />
*Refine the OpsCon and other life-cycle concepts (acquisition concept, deployment concept, support concept, and retirement concept).<br />
*Prioritize the stakeholder needs.<br />
*Transform the prioritized and retained stakeholder needs into stakeholder requirements.<br />
* 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.<br />
* 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.<br />
* Identify potential [[Risk (glossary) |risks]] (or threats and hazards) that could be generated by the stakeholder requirements (for further information, see [[Risk Management]]).<br />
* Synthesize, record, and manage the stakeholder requirements and potential associated risks.<br />
<br />
===Artifacts, Methods and Modeling Techniques===<br />
<br />
This process may create several artifacts, such as:<br />
* Recommendations to refine the Business Requirement Specification (if necessary)<br />
* Refined life-cycle concepts (OpsCon, acquisition concept, deployment concept, support concept, and retirement concept)<br />
* Stakeholder requirements document (e.g., the Stakeholder Requirement Specification) <br />
* Stakeholder interview reports<br />
* Stakeholder requirements database<br />
* Stakeholder requirements justification documents (for traceability purposes)<br />
* Input for draft verification and validation plans<br />
<br />
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.<br />
<br />
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: <br />
* Structured brainstorming workshops<br />
* Interviews and questionnaires <br />
* Technical, operational, and/or strategy documentation review <br />
* Simulations and visualizations<br />
* Prototyping<br />
* Modeling<br />
* 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)<br />
* Use case diagrams (OMG 2010)<br />
* Activity diagrams (OMG 2010)<br />
* Functional flow block diagrams<br />
<br />
==Practical Considerations==<br />
Major pitfalls encountered with stakeholder requirements are presented in Table 3.<br />
<br />
<center><br />
{|<br />
|+'''Table 3. Major Pitfalls for Stakeholder Requirements.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|'''Operator Role Not Considered'''<br />
|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).<br />
|-<br />
|'''Exchanges with External Objects Forgotten'''<br />
|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).<br />
|-<br />
|'''Physical Connections with External Objects Forgotten'''<br />
|Within the interface issue, physical connections of the system-of-interest with external objects can be forgotten (technological constraints).<br />
|-<br />
|'''Forgotten Stakeholders'''<br />
|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.<br />
|}<br />
</center><br />
<br />
<br />
Proven practices with stakeholder requirements are presented in Table 4.<br />
<br />
<center><br />
{|<br />
|+'''Table 4. Stakeholder Requirements Proven Practices.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|'''Involve Stakeholders'''<br />
|Involve the stakeholders early in the stakeholder requirements development process.<br />
|-<br />
|'''Presence of Rationale'''<br />
|Capture the rationale for each stakeholder requirement.<br />
|-<br />
|'''Analyze Sources before Starting'''<br />
|Complete stakeholder requirements as much as possible before starting the definition of the system requirements.<br />
|-<br />
|'''Modeling Techniques'''<br />
|Use modeling techniques as indicated in sections above.<br />
|-<br />
|'''Requirements Management Tool'''<br />
|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.<br />
|}<br />
</center><br />
<br />
==References==<br />
===Works Cited===<br />
Faisandier, A. 2012. ''Systems Architecture and Design.'' Belberaud, France: Sinergy'Com.<br />
<br />
OMG. 2010. ''OMG Systems Modeling Language specification'', version 1.2, July 2010. http://www.omg.org/technology/documents/spec_catalog.htm.<br />
<br />
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.<br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
===Primary References===<br />
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.<br />
<br />
ISO/IEC/IEEE. 2008. ''[[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]]:2008 (E).<br />
<br />
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]].<br />
<br />
===Additional References===<br />
Buede, D.M. 2009. ''The engineering design of systems: Models and methods''. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc. <br />
<br />
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/.<br />
<br />
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.<br />
----<br />
<center>[[Mission Analysis|< Previous Article]] | [[Concept Definition|Parent Article]] | [[System Definition|Next Article >]]</center><br />
<br />
[[Category:Concept Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_or_Mission_Analysis&diff=48825Business or Mission Analysis2013-10-23T05:37:44Z<p>Groedler: </p>
<hr />
<div>The starting point of engineering any [[System-of-Interest (glossary)|system-of-interest]] (SoI) is understanding the socio-economic and technological context in which potential problems or opportunities reside. Then, the enterprise strategic goals and [[Stakeholder (glossary)| stakeholder]] needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of business or enterprise decision makers while also taking into account the views of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], and [[Customer (glossary)|customers]]. <br />
<br />
Mission Analysis (MA) is part of the larger set of [[Concept Definition (glossary)|Concept Definition]] activities - the set of systems engineering activities in which the problem space and the needs of the business or enterprise and stakeholders are closely examined; this occurs before any formal definition of the (SoI) is developed, but may need to be revisited through the life cycle. In fact, the activities of Concept Definition determine whether the enterprise strategic goals and business needs will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution. The MA activity focuses on the identification of the primary purpose(s) of the solution (its ""mission""), while Stakeholder Needs and Requirements activity explores what capabilities stakeholders desire in accomplishing the mission and may include some detail on the performance of certain aspects of the solution. MA is often performed iteratively with Stakeholder Needs and Requirements activity to better understand the problem (or opportunity) space, as well as the solution space.<br />
<br />
== Purpose and Definition ==<br />
The purpose of MA is to understand a mission/market problem or opportunity, analyze the solution space, and initiate the life cycle of a potential solution that could address the problem or take advantage of an opportunity. MA is a type of strategic or operations analysis related to needs, capability gaps, or opportunities and solutions that can be applied to any organization that evolves its strategy for its business objectives.<br />
<br />
MA, in some domains called [[Market Analysis (glossary)|market analysis (glossary)]] or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise. The definition of a mission or business function in a problem space frames the solution, both in terms of the direct application to the mission or business function, and in terms of the context for the resulting solution. <br />
<br />
MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. MA begins with the business vision and Concept of Operations (ConOps), and other organization strategic goals and objectives including the mission (or business function). The primary products of MA are Business or Mission Needs, which are supported by preliminary life-cycle concepts—including a preliminary acquisition concept, a preliminary operational concept (OpsCon), a preliminary deployment concept, a preliminary support concept, and a preliminary retirement concept. Business or Mission Needs are then elaborated and formalized into Business or Mission Requirements. The preliminary operational concept includes the operational scenarios for the mission and the context in which the solution will exist. <br />
<br />
MA may include mathematical analysis, modeling, simulation, visualization, and other analytical tools to characterize the intended mission and determine how to best achieve the needs/objectives. MA evaluates alternative approaches to determine which best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions). Thus, MA defines the problem space and analyzes the solution space alternatives using quality attribute constraints driven by the enterprise objectives.<br />
<br />
==Principles and Concepts==<br />
===Mission Analysis and Concept of Operations===<br />
MA and the ConOps and OpsCon are broadly used in U.S. defense and aerospace organizations to analyze and define how a system is intended to operate, as well as how the major operations or operational scenarios are intended to be performed. They take into account the strategic, operational, and tactical aspects of the identified scenarios. ANSI/AIAA G-043A-2012 identifies that the terms ‘concept of operations’ and ‘operational concept’ are often used interchangeably but notes that an important distinction exists because each has a separate purpose and is used to meet different ends. The ConOps is at an organisational level, prepared by enterprise management and refined by business management:<br />
<br />
<blockquote>''The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems (as black boxes) to forward the organization's goals and objectives. The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations within the business in regards to the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of future business and systems.'' (ISO/IEC 2011) </blockquote> <br />
<br />
The ConOps informs the OpsCon, which is drafted by business management in the Mission Analysis activity and refined by stakeholders in the Stakeholder Needs and Requirements activity:<br />
<br />
<blockquote>''A system OpsCon document describes what the system will do (not how it will do it) and why (rationale). An OpsCon is a user-oriented document that describes system characteristics of the to-be-delivered system from the user's viewpoint. The OpsCon document is used to communicate overall quantitative and qualitative system characteristics to the acquirer, user, supplier and other organizational elements.'' (ISO/IEC 2011) </blockquote><br />
<br />
It should be noted that the OpsCon has an operational focus and should be supported by the development of other concepts, including a deployment concept, a support concept, and a retirement concept. <br />
<br />
In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering (SE) leaders interact with enterprise leaders and operations analysts to understand <br />
*the enterprise ConOps and future mission, business, and operational (MBO) objectives; <br />
*the characterization of the operational concept and objectives (i.e., constraints, mission or operational scenarios, tasks, resources, risks, assumptions, and related missions or operations); and<br />
*how specific missions or operations are currently conducted and what gaps exist in those areas.<br />
<br />
They then conceptually explore and select from alternative candidate solutions. This interaction ensures a full understanding of both the problem space and the solution space. The alternative candidate solutions can include a wide range of approaches to address the need, as well as variants for an approach to optimize specific characteristics (e.g., using a different distribution of satellite orbit parameters to maximize coverage or events while minimizing the number of satellites). Analysis, modeling and simulation, and trade studies are employed to select alternative approaches (NDIA 2010).<br />
<br />
The notions of mission analysis, ConOps and OpsCon are also used in industrial sectors, such as aviation administrations and aeronautic transportation, health care systems, and space with adapted definitions and/or terms, such as operational concepts, usage concepts and/or technological concepts. For example, “mission analysis” is the term used to describe the mathematical analysis of satellite orbits performed to determine how best to achieve the objectives of a space mission (ESA 2008).<br />
<br />
In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:<br />
<br />
<blockquote>''. . . studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and this in turn of the global environmental analysis. Through all these analyses, the chances, strengths, weaknesses, and risks of a company can be identified. Finally, with the help of a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm's planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company.'' (Wikipedia Contributors, 2012)</blockquote><br />
<br />
Anywhere these notions are used, it is evident that they are based on fundamental concepts, such as the [[Operational Mode (glossary)|operational mode]] (or state of the system), [[Scenario (glossary)|scenario]] (of actions), the enterprise level ConOps and the system level operational concepts, [[Function (glossary) |functions]], etc. For more explanations about the ConOps and operational concept, refer to ''Systems and Software Engineering - Requirements Engineering'' (ISO/IEC 2011); useful information can be found in Annex A, "System Operational Concept", and Annex B, "Concept of Operations" (ISO/IEC 2011).<br />
<br />
===Mission Analysis as Part of Enterprise Strategy Development===<br />
Periodically, most enterprises re-evaluate their strategy with respect to their mission, vision, and positioning to accomplish their goals. Figure 1 shows the interactions of the enterprise strategy development and the concept definition, including the MA and Stakeholder Needs and Requirements activities that are involved in an iterative manner to fully develop the strategy and define future capabilities and solutions. <br />
<br />
[[File:Enterprise_Strategy_and_Concept_Development.PNG|thumb|700px|center|'''Figure 1. Enterprise Strategy and Concept Development (Roedler 2012).''' Used with permission of Garry Roedler. All other rights are reserved by the copyright owner.]]<br />
<br />
As the enterprise evolves the strategy, it is essential to conduct the supporting MA or strategic analysis for each element of the enterprise to determine readiness to achieve future objectives. This analysis examines the current state to identify any problems or opportunities related to the objective achievement and aids the enterprise in fully understanding and defining the problem space. The analysis examines the external environment and interfaces in search of impacts and trends, as well as the internal enterprise to gauge its capabilities and value stream gaps. Additionally, a strengths, weaknesses, opportunities, and threats (SWOT) analysis may be performed. As the problem space is defined, the stakeholder needs are defined and transformed into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, the future state of core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities. Finally, MA is engaged again to examine the solution space. Candidate solutions that span the potential solution space are identified, from simple operational changes to various system developments or modifications. Various techniques are applied to analyze the candidates, understand their feasibility and value, and select the best alternative.<br />
<br />
==Process Approach==<br />
===Activities of the Process===<br />
It is necessary to perform the following major activities and tasks during the MA process: <br />
#Review and understand the enterprise mission, vision, and ConOps.<br />
#Identify and define any gaps and opportunities related to future evolution of the strategy:<br />
##Examine the current state to identify any problems or opportunities related to the objective achievement, including any deficiencies of the existing system.<br />
##Analyze the context of the actual political, economic, social, technological, environmental, and legal (PESTAL) factors, while studying sensitive factors such as cost and effectiveness, security and safety improvement, performance improvement or lack of existing systems, market opportunities, regulation changes, users' dissatisfaction, etc. External, internal, and SWOT analysis should be included as well. For the technological considerations, an appropriate architectural framework representation, such as the U.S. Department of Defense Architecture Framework (DoDAF) operations view (DoD 2010), the Zachman Framework (Rows1 and 2) (Zachman 2008), and The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM) (The Open Group 2010) Phases A and B should be included within the concept definition when performing mission analysis and stakeholders needs and requirements.<br />
##Define the mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without focusing on a solution. <br />
#Examine and evaluate the solution space.<br />
##Identify the main stakeholders (customers, users, administrations, regulations, etc.).<br />
##Identify high level operational modes or states, or potential use cases.<br />
##Identify candidate solutions that span the potential solution space, from simple operational changes to various system developments or modifications. Identify existing systems, products, and services that may address the need for operational or functional modifications. Deduce what potential expected services may be needed. The SoI is a potential and not yet existing product, service or enterprise. Additionally, the solution could be an operational change or a change to an existing product or service.<br />
#Perform appropriate modeling, simulation, and analytical techniques to understand the feasibility and value of the alternative candidate solutions. Model or simulate operational scenarios from these services and use cases, and enrich them through reviews with stakeholders and subject matter experts.<br />
#Define basic operational concept or market strategy, and/or business models.<br />
##From previous modeled operational scenarios and operational modes, deduce and express the usage of operational concepts, or technical concepts.<br />
##Collect and enrich needs, expectations, scenarios, and constraints.<br />
##Validate the mission of any potential SoI in the context of any proposed market strategy or business model.<br />
#Evaluate the set of alternatives and select the best alternative.<br />
##Perform a trade study of the alternatives to discriminate between the alternatives.<br />
#Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.<br />
#Define preliminary deployment concept, preliminary support concept, and preliminary retirement concept.<br />
<br />
===Mission Analysis Artifacts===<br />
<br />
This process may create several artifacts, such as<br />
*recommendations for revisions to the enterprise ConOps;<br />
*preliminary operational concept document or inputs;<br />
*mission analysis and definition reports (perhaps with recommendations for revisions of the mission); <br />
*a set of Business Needs<br />
*preliminary life-cycle concepts (preliminary operational concept, preliminary deployment concept, preliminary support concept, and preliminary retirement concept<br />
*[[System Analysis|system analysis]] artifacts (e.g., use case diagrams, context diagrams, sequence/activity diagrams, functional flow block diagrams);<br />
*trade study results (alternatives analysis);<br />
*market study/analysis reports; and<br />
*a set of Business (or Mission) Requirements (often captured in a Business Requirement Specification).<br />
<br />
===Methods and Modeling Techniques===<br />
<br />
MA uses several techniques, such as<br />
<br />
*use case analysis;<br />
*operational analysis; <br />
*functional analysis;<br />
*technical documentation review;<br />
*trade studies;<br />
*modeling;<br />
*simulation;<br />
*prototyping;<br />
*workshops, interviews, and questionnaires;<br />
*market competitive assessments;<br />
*benchmarking; and<br />
*organizational analysis techniques (e.g., strengths, weaknesses, opportunities, threats (SWOT analysis), and product portfolios).<br />
<br />
==Practical Considerations==<br />
Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1. <br />
<br />
<center><br />
{|<br />
|+'''Table 1. Major Pitfalls for Mission Analysis.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|Wrong level of system addressed<br />
|When delineating the boundaries of the SoI and defining the mission and purpose of the system at the very beginning of systems engineering, a classic mistake is to place the system-of-interest at the wrong level of abstraction. The level of abstraction can be too high or too low (sitting respectively in the upper-system or in a sub-system). This is the consequence of the principle stating that a system is always included in a larger system and of confusing the purpose and the mission of the SoI.<br />
|-<br />
|Operational modes or scenarios missing<br />
|In commercial products or systems, the lack or insufficient description of operational modes and scenarios (how the SoI will be used, in which situations, etc.) is often encountered.<br />
|}<br />
</center><br />
<br />
<br />
Proven practices with mission analysis and marketing analysis are presented in Table 2.<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Mission Analysis Proven Practices.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|Models of operational scenarios<br />
|Using modeling techniques as indicated in sections above for operational scenarios in any kind of SoI (including commercial systems).<br />
|-<br />
|Models of the context<br />
|Consider the context of use as a system and force oneself to use modeling techniques for main aspects of the context (functional, behavioral, physical, etc.).<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
DoD. 2010. ''DoD Architecture Framework'', version 2.02. Arlington, VA: U.S. Department of Defense. Accessed August 29, 2012. Available at: http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_v2-02_web.pdf.<br />
<br />
ESA. 2008. ''Mission Analysis: Towards a European Harmonization.'' Paris, France: European Space Agency. Accessed August 29, 2012. Available at: http://www.esa.int/esapub/bulletin/bulletin134/bul134b_schoenmaekers.pdf.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering -- Life cycle processes -- Requirements engineering.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC/IEEE 29148:2011.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and Software Engineering - Life CYcle Processes - Requirements Engineering.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 29148:2011.<br />
<br />
Kaplan, R.S. and D.P. Norton. 2008. “Developing the Strategy: Vision, Value Gaps, and Analysis,” Balanced Scorecard Report. Cambridge, MA, USA: Harvard Business School Publishing, Jan-Feb 2008.<br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A simple method for phased mission analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309.<br />
<br />
NDIA. 2010. “Mission Analysis Committee Charter”. Website of the National Defense Industrial Association, Systems Engineering Division, Mission Analysis Committee. Accessed August 29, 2012. Available at: http://www.ndia.org/Divisions/Divisions/SystemsEngineering/Documents/Committees/Mission%20Analysis%20Committee/Mission%20Analysis%20Committee%20Charter.pdf.<br />
<br />
Shupp, J.K. 2003. “The Mission Analysis Discipline: Bringing focus to the fuzziness about Attaining Good Architectures.” Proceedings of INCOSE 13th International Symposium, July 2003.<br />
<br />
The Open Group. 2011. ''TOGAF'', version 9.1. Hogeweg, The Netherlands: Van Haren Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.<br />
<br />
Wikipedia contributors, "Market analysis," Wikipedia, The Free Encyclopedia, http://en.wikipedia.org/w/index.php?title=Market_analysis&oldid=508583878 (accessed August 29, 2012).<br />
<br />
Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™." Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.<br />
<br />
===Primary References===<br />
ISO/IEC/IEEE. 2008. ''[[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]]:2008 (E).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]: From System Goals to UML Models to Software Specifications''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
Center for Quality Management. 1993. "Special Issue on Kano's Methods for Understanding Customer Defined Quality." ''Center for Quality Management Journal.'' 2(4) (Fall 1993). <br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.<br />
<br />
Freeman, R. "Chapter 27: Achieving Strategic Aims: Moving Toward a Process Based Military Enterprise," in ''Handbook of Military Industrial Engineering.'' A.B. Badiru and M.U. Thomas (eds). Boca Raton, FL, USA: Taylor & Francis Group, CRC Press.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering.'' 3rd ed. London, UK: Springer.<br />
<br />
Kano, N. 1984. "Attractive Quality and Must-Be Quality." ''Quality JSQC.'' 14(2) (October 1984). <br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309. <br />
<br />
Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques." ''Software Engineering''. New York, NY: McGraw-Hill.<br />
<br />
MITRE. 2011. "Concept Development." ''Systems Engineering Guide.'' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/]].<br />
<br />
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/]].<br />
<br />
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]].<br />
----<br />
<center>[[Concept Definition|< Previous Article]] | [[Concept Definition|Parent Article]] | [[Stakeholder Needs and Requirements|Next Article >]]</center><br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Concept Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_or_Mission_Analysis&diff=48824Business or Mission Analysis2013-10-23T05:35:21Z<p>Groedler: </p>
<hr />
<div>The starting point of engineering any [[System-of-Interest (glossary)|system-of-interest]] (SoI) is understanding the socio-economic and technological context in which potential problems or opportunities reside. Then, the enterprise strategic goals and [[Stakeholder (glossary)| stakeholder]] needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of business or enterprise decision makers while also taking into account the views of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], and [[Customer (glossary)|customers]]. <br />
<br />
Mission Analysis (MA) is part of the larger set of [[Concept Definition (glossary)|Concept Definition]] activities - the set of systems engineering activities in which the problem space and the needs of the business or enterprise and stakeholders are closely examined; this occurs before any formal definition of the (SoI) is developed, but may need to be revisited through the life cycle. In fact, the activities of Concept Definition determine whether the enterprise strategic goals and business needs will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution. The MA activity focuses on the identification of the primary purpose(s) of the solution (its ""mission""), while Stakeholder Needs and Requirements activity explores what capabilities stakeholders desire in accomplishing the mission and may include some detail on the performance of certain aspects of the solution. MA is often performed iteratively with Stakeholder Needs and Requirements activity to better understand the problem (or opportunity) space, as well as the solution space.<br />
<br />
== Purpose and Definition ==<br />
The purpose of MA is to understand a mission/market problem or opportunity, analyze the solution space, and initiate the life cycle of a potential solution that could address the problem or take advantage of an opportunity. MA is a type of strategic or operations analysis related to needs, capability gaps, or opportunities and solutions that can be applied to any organization that evolves its strategy for its business objectives.<br />
<br />
MA, in some domains called [[Market Analysis (glossary)|market analysis (glossary)]] or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise. The definition of a mission or business function in a problem space frames the solution, both in terms of the direct application to the mission or business function, and in terms of the context for the resulting solution. <br />
<br />
MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. MA begins with the business vision and Concept of Operations (ConOps), and other organization strategic goals and objectives including the mission (or business function). The primary products of MA are Business or Mission Needs, which are supported by preliminary life-cycle concepts—including a preliminary acquisition concept, a preliminary operational concept (OpsCon), a preliminary deployment concept, a preliminary support concept, and a preliminary retirement concept. Business or Mission Needs are then elaborated and formalized into Business or Mission Requirements. The preliminary operational concept includes the operational scenarios for the mission and the context in which the solution will exist. <br />
<br />
MA may include mathematical analysis, modeling, simulation, visualization, and other analytical tools to characterize the intended mission and determine how to best achieve the needs/objectives. MA evaluates alternative approaches to determine which best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions). Thus, MA defines the problem space and analyzes the solution space alternatives using quality attribute constraints driven by the enterprise objectives.<br />
<br />
==Principles and Concepts==<br />
===Mission Analysis and Concept of Operations===<br />
MA and the ConOps and OpsCon are broadly used in U.S. defense and aerospace organizations to analyze and define how a system is intended to operate, as well as how the major operations or operational scenarios are intended to be performed. They take into account the strategic, operational, and tactical aspects of the identified scenarios. ANSI/AIAA G-043A-2012 identifies that the terms ‘concept of operations’ and ‘operational concept’ are often used interchangeably but notes that an important distinction exists because each has a separate purpose and is used to meet different ends. The ConOps is at an organisational level, prepared by enterprise management and refined by business management:<br />
<br />
<blockquote>''The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems (as black boxes) to forward the organization's goals and objectives. The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations within the business in regards to the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of future business and systems.'' (ISO/IEC 2011) </blockquote> <br />
<br />
The ConOps informs the OpsCon, which is drafted by business management in the Mission Analysis activity and refined by stakeholders in the Stakeholder Needs and Requirements activity:<br />
<br />
</blockquote> ''A system OpsCon document describes what the system will do (not how it will do it) and why (rationale). An OpsCon is a user-oriented document that describes system characteristics of the to-be-delivered system from the user's viewpoint. The OpsCon document is used to communicate overall quantitative and qualitative system characteristics to the acquirer, user, supplier and other organizational elements.'' (ISO/IEC 2011) </blockquote><br />
<br />
It should be noted that the OpsCon has an operational focus and should be supported by the development of other concepts, including a deployment concept, a support concept, and a retirement concept. <br />
<br />
In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering (SE) leaders interact with enterprise leaders and operations analysts to understand <br />
*the enterprise ConOps and future mission, business, and operational (MBO) objectives; <br />
*the characterization of the operational concept and objectives (i.e., constraints, mission or operational scenarios, tasks, resources, risks, assumptions, and related missions or operations); and<br />
*how specific missions or operations are currently conducted and what gaps exist in those areas.<br />
<br />
They then conceptually explore and select from alternative candidate solutions. This interaction ensures a full understanding of both the problem space and the solution space. The alternative candidate solutions can include a wide range of approaches to address the need, as well as variants for an approach to optimize specific characteristics (e.g., using a different distribution of satellite orbit parameters to maximize coverage or events while minimizing the number of satellites). Analysis, modeling and simulation, and trade studies are employed to select alternative approaches (NDIA 2010).<br />
<br />
The notions of mission analysis, ConOps and OpsCon are also used in industrial sectors, such as aviation administrations and aeronautic transportation, health care systems, and space with adapted definitions and/or terms, such as operational concepts, usage concepts and/or technological concepts. For example, “mission analysis” is the term used to describe the mathematical analysis of satellite orbits performed to determine how best to achieve the objectives of a space mission (ESA 2008).<br />
<br />
In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:<br />
<br />
<blockquote>''. . . studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and this in turn of the global environmental analysis. Through all these analyses, the chances, strengths, weaknesses, and risks of a company can be identified. Finally, with the help of a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm's planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company.'' (Wikipedia Contributors, 2012)</blockquote><br />
<br />
Anywhere these notions are used, it is evident that they are based on fundamental concepts, such as the [[Operational Mode (glossary)|operational mode]] (or state of the system), [[Scenario (glossary)|scenario]] (of actions), the enterprise level ConOps and the system level operational concepts, [[Function (glossary) |functions]], etc. For more explanations about the ConOps and operational concept, refer to ''Systems and Software Engineering - Requirements Engineering'' (ISO/IEC 2011); useful information can be found in Annex A, "System Operational Concept", and Annex B, "Concept of Operations" (ISO/IEC 2011).<br />
<br />
===Mission Analysis as Part of Enterprise Strategy Development===<br />
Periodically, most enterprises re-evaluate their strategy with respect to their mission, vision, and positioning to accomplish their goals. Figure 1 shows the interactions of the enterprise strategy development and the concept definition, including the MA and Stakeholder Needs and Requirements activities that are involved in an iterative manner to fully develop the strategy and define future capabilities and solutions. <br />
<br />
[[File:Enterprise_Strategy_and_Concept_Development.PNG|thumb|700px|center|'''Figure 1. Enterprise Strategy and Concept Development (Roedler 2012).''' Used with permission of Garry Roedler. All other rights are reserved by the copyright owner.]]<br />
<br />
As the enterprise evolves the strategy, it is essential to conduct the supporting MA or strategic analysis for each element of the enterprise to determine readiness to achieve future objectives. This analysis examines the current state to identify any problems or opportunities related to the objective achievement and aids the enterprise in fully understanding and defining the problem space. The analysis examines the external environment and interfaces in search of impacts and trends, as well as the internal enterprise to gauge its capabilities and value stream gaps. Additionally, a strengths, weaknesses, opportunities, and threats (SWOT) analysis may be performed. As the problem space is defined, the stakeholder needs are defined and transformed into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, the future state of core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities. Finally, MA is engaged again to examine the solution space. Candidate solutions that span the potential solution space are identified, from simple operational changes to various system developments or modifications. Various techniques are applied to analyze the candidates, understand their feasibility and value, and select the best alternative.<br />
<br />
==Process Approach==<br />
===Activities of the Process===<br />
It is necessary to perform the following major activities and tasks during the MA process: <br />
#Review and understand the enterprise mission, vision, and ConOps.<br />
#Identify and define any gaps and opportunities related to future evolution of the strategy:<br />
##Examine the current state to identify any problems or opportunities related to the objective achievement, including any deficiencies of the existing system.<br />
##Analyze the context of the actual political, economic, social, technological, environmental, and legal (PESTAL) factors, while studying sensitive factors such as cost and effectiveness, security and safety improvement, performance improvement or lack of existing systems, market opportunities, regulation changes, users' dissatisfaction, etc. External, internal, and SWOT analysis should be included as well. For the technological considerations, an appropriate architectural framework representation, such as the U.S. Department of Defense Architecture Framework (DoDAF) operations view (DoD 2010), the Zachman Framework (Rows1 and 2) (Zachman 2008), and The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM) (The Open Group 2010) Phases A and B should be included within the concept definition when performing mission analysis and stakeholders needs and requirements.<br />
##Define the mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without focusing on a solution. <br />
#Examine and evaluate the solution space.<br />
##Identify the main stakeholders (customers, users, administrations, regulations, etc.).<br />
##Identify high level operational modes or states, or potential use cases.<br />
##Identify candidate solutions that span the potential solution space, from simple operational changes to various system developments or modifications. Identify existing systems, products, and services that may address the need for operational or functional modifications. Deduce what potential expected services may be needed. The SoI is a potential and not yet existing product, service or enterprise. Additionally, the solution could be an operational change or a change to an existing product or service.<br />
#Perform appropriate modeling, simulation, and analytical techniques to understand the feasibility and value of the alternative candidate solutions. Model or simulate operational scenarios from these services and use cases, and enrich them through reviews with stakeholders and subject matter experts.<br />
#Define basic operational concept or market strategy, and/or business models.<br />
##From previous modeled operational scenarios and operational modes, deduce and express the usage of operational concepts, or technical concepts.<br />
##Collect and enrich needs, expectations, scenarios, and constraints.<br />
##Validate the mission of any potential SoI in the context of any proposed market strategy or business model.<br />
#Evaluate the set of alternatives and select the best alternative.<br />
##Perform a trade study of the alternatives to discriminate between the alternatives.<br />
#Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.<br />
#Define preliminary deployment concept, preliminary support concept, and preliminary retirement concept.<br />
<br />
===Mission Analysis Artifacts===<br />
<br />
This process may create several artifacts, such as<br />
*recommendations for revisions to the enterprise ConOps;<br />
*preliminary operational concept document or inputs;<br />
*mission analysis and definition reports (perhaps with recommendations for revisions of the mission); <br />
*a set of Business Needs<br />
*preliminary life-cycle concepts (preliminary operational concept, preliminary deployment concept, preliminary support concept, and preliminary retirement concept<br />
*[[System Analysis|system analysis]] artifacts (e.g., use case diagrams, context diagrams, sequence/activity diagrams, functional flow block diagrams);<br />
*trade study results (alternatives analysis);<br />
*market study/analysis reports; and<br />
*a set of Business (or Mission) Requirements (often captured in a Business Requirement Specification).<br />
<br />
===Methods and Modeling Techniques===<br />
<br />
MA uses several techniques, such as<br />
<br />
*use case analysis;<br />
*operational analysis; <br />
*functional analysis;<br />
*technical documentation review;<br />
*trade studies;<br />
*modeling;<br />
*simulation;<br />
*prototyping;<br />
*workshops, interviews, and questionnaires;<br />
*market competitive assessments;<br />
*benchmarking; and<br />
*organizational analysis techniques (e.g., strengths, weaknesses, opportunities, threats (SWOT analysis), and product portfolios).<br />
<br />
==Practical Considerations==<br />
Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1. <br />
<br />
<center><br />
{|<br />
|+'''Table 1. Major Pitfalls for Mission Analysis.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|Wrong level of system addressed<br />
|When delineating the boundaries of the SoI and defining the mission and purpose of the system at the very beginning of systems engineering, a classic mistake is to place the system-of-interest at the wrong level of abstraction. The level of abstraction can be too high or too low (sitting respectively in the upper-system or in a sub-system). This is the consequence of the principle stating that a system is always included in a larger system and of confusing the purpose and the mission of the SoI.<br />
|-<br />
|Operational modes or scenarios missing<br />
|In commercial products or systems, the lack or insufficient description of operational modes and scenarios (how the SoI will be used, in which situations, etc.) is often encountered.<br />
|}<br />
</center><br />
<br />
<br />
Proven practices with mission analysis and marketing analysis are presented in Table 2.<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Mission Analysis Proven Practices.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|Models of operational scenarios<br />
|Using modeling techniques as indicated in sections above for operational scenarios in any kind of SoI (including commercial systems).<br />
|-<br />
|Models of the context<br />
|Consider the context of use as a system and force oneself to use modeling techniques for main aspects of the context (functional, behavioral, physical, etc.).<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
DoD. 2010. ''DoD Architecture Framework'', version 2.02. Arlington, VA: U.S. Department of Defense. Accessed August 29, 2012. Available at: http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_v2-02_web.pdf.<br />
<br />
ESA. 2008. ''Mission Analysis: Towards a European Harmonization.'' Paris, France: European Space Agency. Accessed August 29, 2012. Available at: http://www.esa.int/esapub/bulletin/bulletin134/bul134b_schoenmaekers.pdf.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering -- Life cycle processes -- Requirements engineering.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC/IEEE 29148:2011.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and Software Engineering - Life CYcle Processes - Requirements Engineering.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 29148:2011.<br />
<br />
Kaplan, R.S. and D.P. Norton. 2008. “Developing the Strategy: Vision, Value Gaps, and Analysis,” Balanced Scorecard Report. Cambridge, MA, USA: Harvard Business School Publishing, Jan-Feb 2008.<br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A simple method for phased mission analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309.<br />
<br />
NDIA. 2010. “Mission Analysis Committee Charter”. Website of the National Defense Industrial Association, Systems Engineering Division, Mission Analysis Committee. Accessed August 29, 2012. Available at: http://www.ndia.org/Divisions/Divisions/SystemsEngineering/Documents/Committees/Mission%20Analysis%20Committee/Mission%20Analysis%20Committee%20Charter.pdf.<br />
<br />
Shupp, J.K. 2003. “The Mission Analysis Discipline: Bringing focus to the fuzziness about Attaining Good Architectures.” Proceedings of INCOSE 13th International Symposium, July 2003.<br />
<br />
The Open Group. 2011. ''TOGAF'', version 9.1. Hogeweg, The Netherlands: Van Haren Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.<br />
<br />
Wikipedia contributors, "Market analysis," Wikipedia, The Free Encyclopedia, http://en.wikipedia.org/w/index.php?title=Market_analysis&oldid=508583878 (accessed August 29, 2012).<br />
<br />
Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™." Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.<br />
<br />
===Primary References===<br />
ISO/IEC/IEEE. 2008. ''[[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]]:2008 (E).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]: From System Goals to UML Models to Software Specifications''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
Center for Quality Management. 1993. "Special Issue on Kano's Methods for Understanding Customer Defined Quality." ''Center for Quality Management Journal.'' 2(4) (Fall 1993). <br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.<br />
<br />
Freeman, R. "Chapter 27: Achieving Strategic Aims: Moving Toward a Process Based Military Enterprise," in ''Handbook of Military Industrial Engineering.'' A.B. Badiru and M.U. Thomas (eds). Boca Raton, FL, USA: Taylor & Francis Group, CRC Press.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering.'' 3rd ed. London, UK: Springer.<br />
<br />
Kano, N. 1984. "Attractive Quality and Must-Be Quality." ''Quality JSQC.'' 14(2) (October 1984). <br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309. <br />
<br />
Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques." ''Software Engineering''. New York, NY: McGraw-Hill.<br />
<br />
MITRE. 2011. "Concept Development." ''Systems Engineering Guide.'' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/]].<br />
<br />
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/]].<br />
<br />
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]].<br />
----<br />
<center>[[Concept Definition|< Previous Article]] | [[Concept Definition|Parent Article]] | [[Stakeholder Needs and Requirements|Next Article >]]</center><br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Concept Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_or_Mission_Analysis&diff=48823Business or Mission Analysis2013-10-23T00:15:05Z<p>Groedler: </p>
<hr />
<div>The starting point of engineering any [[System-of-Interest (glossary)|system-of-interest]] (SoI) is understanding the socio-economic and technological context in which potential problems or opportunities reside. Then, the enterprise strategic goals and [[Stakeholder (glossary)| stakeholder]] needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of business or enterprise decision makers while also taking into account the views of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], and [[Customer (glossary)|customers]]. <br />
<br />
Mission Analysis (MA) is part of the larger set of [[Concept Definition (glossary)|concept definition]] activities - the phase of systems engineering in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the (SoI) is developed. In fact, the activities of concept definition determine whether the enterprise strategic goals and stakeholder needs will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution. Mission analysis focuses on the identification of the primary purpose(s) of the solution, while stakeholder needs and requirements definition explores what capabilities stakeholders desire and may include some detail on the performance of certain aspects of the solution.<br />
<br />
== Purpose and Definition ==<br />
The purpose of MA is to understand a mission/market problem or opportunity, analyze the solution space, and initiate the life cycle of a potential solution that could address the problem or take advantage of an opportunity. MA is a type of strategic or operations analysis related to needs, capability gaps, or opportunities and solutions that can be applied to any organization that evolves its strategy for its business objectives.<br />
<br />
MA, in some domains called [[Market Analysis (glossary)|market analysis (glossary)]] or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise. The definition of a mission need in a problem space frames the solution, both in terms of the direct application to the mission or business function, and in terms of the context for the resulting solution. <br />
<br />
MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. It characterizes the operational need in terms of mission description/provisions and the environment/context, together with the proposed enterprise [[Concept of Operations (ConOps) (glossary)|concept of operations]] (ConOps) and operational scenarios. The primary products of MA are the revised ConOps of the enterprise, the [[Operational Concept (glossary)|operational concept]], the [[Operational Scenario (glossary)|operational scenarios]] for the mission, and the context in which the solution will exist. <br />
<br />
MA may include mathematical analysis, modeling, simulation, visualization, and other analytical tools to characterize the intended mission and determine how to best achieve the needs/objectives. MA evaluates alternative approaches to determine which best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions). Thus, MA defines the problem space and analyzes the solution space alternatives using quality attribute constraints driven by the enterprise objectives.<br />
<br />
==Principles and Concepts==<br />
===Mission Analysis and Concept of Operations===<br />
MA and the ConOps are broadly used in U.S. defense and aerospace organizations to analyze and define how a system is intended to operate, as well as how the major operations or operational scenarios are intended to be performed. They take into account the strategic, operational, and tactical aspects of the identified scenarios. <br />
<br />
In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering (SE) leaders interact with enterprise leaders and operations analysts to understand <br />
*the enterprise ConOps and future mission, business, and operational (MBO) objectives; <br />
*the characterization of the operational concept and objectives (i.e., constraints, mission or operational scenarios, tasks, resources, risks, assumptions, and related missions or operations); and<br />
*how specific missions or operations are currently conducted and what gaps exist in those areas.<br />
<br />
They then conceptually explore and select from alternative candidate solutions. This interaction ensures a full understanding of both the problem space and the solution space. The alternative candidate solutions can include a wide range of approaches to address the need, as well as variants for an approach to optimize specific characteristics (e.g., using a different distribution of satellite orbit parameters to maximize coverage or events while minimizing the number of satellites). Analysis, modeling and simulation, and trade studies are employed to select alternative approaches (NDIA 2010).<br />
<br />
<blockquote>''The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems (as black boxes) to forward the organization's goals and objectives. The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations within the business in regards to the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of future business and systems.'' (ISO/IEC 2011) </blockquote> <br />
<br />
These notions are also used in industrial sectors, such as aviation administrations and aeronautic transportation, health care systems, space, etc., with adapted definitions and/or terms, such as operational concepts, usage concepts and/or technological concepts. For example, “mission analysis” is the term used to describe the mathematical analysis of satellite orbits performed to determine how best to achieve the objectives of a space mission (ESA 2008).<br />
<br />
In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:<br />
<br />
<blockquote>''. . . studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and this in turn of the global environmental analysis. Through all these analyses, the chances, strengths, weaknesses, and risks of a company can be identified. Finally, with the help of a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm's planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company.'' (Wikipedia Contributors, 2012)</blockquote><br />
<br />
Anywhere these notions are used, it is evident that they are based on fundamental concepts, such as the [[Operational Mode (glossary)|operational mode]] (or state of the system), [[Scenario (glossary)|scenario]] (of actions), the enterprise level ConOps and the system level operational concepts, [[Function (glossary) |functions]], etc. For more explanations about the ConOps and operational concept, refer to ''Systems and Software Engineering - Requirements Engineering'' (ISO/IEC 2011); useful information can be found in Annex A, "System Operational Concept", and Annex B, "Concept of Operations" (ISO/IEC 2011).<br />
<br />
===Mission Analysis as Part of Enterprise Strategy Development===<br />
Periodically, most enterprises re-evaluate their strategy with respect to their mission, vision, and positioning to accomplish their goals. Figure 1 shows the interactions of the enterprise strategy development and the concept definition, including MA and stakeholder needs and requirements that are involved in an iterative manner to fully develop the strategy and define future capabilities and solutions. <br />
<br />
[[File:Enterprise_Strategy_and_Concept_Development.PNG|thumb|700px|center|'''Figure 1. Enterprise Strategy and Concept Development (Roedler 2012).''' Used with permission of Garry Roedler. All other rights are reserved by the copyright owner.]]<br />
<br />
As the enterprise evolves the strategy, it is essential to conduct the supporting MA or strategic analysis for each element of the enterprise to determine readiness to achieve future objectives. This analysis examines the current state to identify any problems or opportunities related to the objective achievement and aids the enterprise in fully understanding and defining the problem space. The analysis examines the external environment and interfaces in search of impacts and trends, as well as the internal enterprise to gauge its capabilities and value stream gaps. Additionally, a strengths, weaknesses, opportunities, and threats (SWOT) analysis may be performed. As the problem space is defined, the stakeholder needs are defined and transformed into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, the future state of core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities. Finally, MA is engaged again to examine the solution space. Candidate solutions that span the potential solution space are identified, from simple operational changes to various system developments or modifications. Various techniques are applied to analyze the candidates, understand their feasibility and value, and select the best alternative.<br />
<br />
==Process Approach==<br />
===Activities of the Process===<br />
It is necessary to perform the following major activities and tasks during the MA process: <br />
#Review and understand the enterprise mission, vision, and ConOps.<br />
#Identify and define any gaps and opportunities related to future evolution of the strategy:<br />
##Examine the current state to identify any problems or opportunities related to the objective achievement, including any deficiencies of the existing system.<br />
##Analyze the context of the actual political, economic, social, technological, environmental, and legal (PESTAL) factors, while studying sensitive factors such as cost and effectiveness, security and safety improvement, performance improvement or lack of existing systems, market opportunities, regulation changes, users' dissatisfaction, etc. External, internal, and SWOT analysis should be included as well. For the technological considerations, an appropriate architectural framework representation, such as the U.S. Department of Defense Architecture Framework (DoDAF) operations view (DoD 2010), the Zachman Framework (Rows1 and 2) (Zachman 2008), and The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM) (The Open Group 2010) Phases A and B should be included within the concept definition when performing mission analysis and stakeholders needs and requirements.<br />
##Define any mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without focusing on a solution. <br />
#Examine and evaluate the solution space.<br />
##Identify the main stakeholders (customers, users, administrations, regulations, etc.).<br />
##Identify high level operational modes or states, or potential use cases.<br />
##Identify candidate solutions that span the potential solution space, from simple operational changes to various system developments or modifications. Identify existing systems, products, and services that may address the need for operational or functional modifications. Deduce what potential expected services may be needed. The SoI is a potential and not yet existing product, service or enterprise. Additionally, the solution could be an operational change or a change to an existing product or service.<br />
#Perform appropriate modeling, simulation, and analytical techniques to understand the feasibility and value of the alternative candidate solutions. Model or simulate operational scenarios from these services and use cases, and enrich them through reviews with stakeholders and subject matter experts.<br />
#Define basic operational concept or market strategy, and/or business models.<br />
##From previous modeled operational scenarios and operational modes, deduce and express the usage of operational concepts, or technical concepts.<br />
##Collect and enrich needs, expectations, scenarios, and constraints.<br />
##Validate the mission of any potential SoI in the context of any proposed market strategy or business model.<br />
#Evaluate the set of alternatives and select the best alternative.<br />
##Perform a trade study of the alternatives to discriminate between the alternatives.<br />
#Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.<br />
<br />
===Mission Analysis Artifacts===<br />
<br />
This process may create several artifacts, such as<br />
*recommendations for revisions to the enterprise ConOps;<br />
*preliminary operational concept document or inputs;<br />
*mission analysis and definition reports;<br />
*[[System Analysis|system analysis]] artifacts (e.g., use case diagrams, context diagrams, sequence/activity diagrams, functional flow block diagrams);<br />
*trade study results (alternatives analysis); and<br />
*market study/analysis reports.<br />
<br />
===Methods and Modeling Techniques===<br />
<br />
MA uses several techniques, such as<br />
<br />
*use case analysis;<br />
*operational analysis; <br />
*functional analysis;<br />
*technical documentation review;<br />
*trade studies;<br />
*modeling;<br />
*simulation;<br />
*prototyping;<br />
*workshops, interviews, and questionnaires;<br />
*market competitive assessments;<br />
*benchmarking; and<br />
*organizational analysis techniques (e.g., strengths, weaknesses, opportunities, threats (SWOT analysis), and product portfolios).<br />
<br />
==Practical Considerations==<br />
Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1. <br />
<br />
<center><br />
{|<br />
|+'''Table 1. Major Pitfalls for Mission Analysis.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|Wrong level of system addressed<br />
|When delineating the boundaries of the SoI and defining the mission and purpose of the system at the very beginning of systems engineering, a classic mistake is to place the system-of-interest at the wrong level of abstraction. The level of abstraction can be too high or too low (sitting respectively in the upper-system or in a sub-system). This is the consequence of the principle stating that a system is always included in a larger system and of confusing the purpose and the mission of the SoI.<br />
|-<br />
|Operational modes or scenarios missing<br />
|In commercial products or systems, the lack or insufficient description of operational modes and scenarios (how the SoI will be used, in which situations, etc.) is often encountered.<br />
|}<br />
</center><br />
<br />
<br />
Proven practices with mission analysis and marketing analysis are presented in Table 2.<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Mission Analysis Proven Practices.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|Models of operational scenarios<br />
|Using modeling techniques as indicated in sections above for operational scenarios in any kind of SoI (including commercial systems).<br />
|-<br />
|Models of the context<br />
|Consider the context of use as a system and force oneself to use modeling techniques for main aspects of the context (functional, behavioral, physical, etc.).<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
DoD. 2010. ''DoD Architecture Framework'', version 2.02. Arlington, VA: U.S. Department of Defense. Accessed August 29, 2012. Available at: http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_v2-02_web.pdf.<br />
<br />
ESA. 2008. ''Mission Analysis: Towards a European Harmonization.'' Paris, France: European Space Agency. Accessed August 29, 2012. Available at: http://www.esa.int/esapub/bulletin/bulletin134/bul134b_schoenmaekers.pdf.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering -- Life cycle processes -- Requirements engineering.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC/IEEE 29148:2011.<br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
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), ISO/IEC/IEEE 29148.<br />
<br />
Kaplan, R.S. and D.P. Norton. 2008. “Developing the Strategy: Vision, Value Gaps, and Analysis,” Balanced Scorecard Report. Cambridge, MA, USA: Harvard Business School Publishing, Jan-Feb 2008.<br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A simple method for phased mission analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309.<br />
<br />
NDIA. 2010. “Mission Analysis Committee Charter”. Website of the National Defense Industrial Association, Systems Engineering Division, Mission Analysis Committee. Accessed August 29, 2012. Available at: http://www.ndia.org/Divisions/Divisions/SystemsEngineering/Documents/Committees/Mission%20Analysis%20Committee/Mission%20Analysis%20Committee%20Charter.pdf.<br />
<br />
Shupp, J.K. 2003. “The Mission Analysis Discipline: Bringing focus to the fuzziness about Attaining Good Architectures.” Proceedings of INCOSE 13th International Symposium, July 2003.<br />
<br />
The Open Group. 2011. ''TOGAF'', version 9.1. Hogeweg, The Netherlands: Van Haren Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.<br />
<br />
Wikipedia contributors, "Market analysis," Wikipedia, The Free Encyclopedia, http://en.wikipedia.org/w/index.php?title=Market_analysis&oldid=508583878 (accessed August 29, 2012).<br />
<br />
Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™." Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.<br />
<br />
===Primary References===<br />
ISO/IEC/IEEE. 2008. ''[[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]]:2008 (E).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]: From System Goals to UML Models to Software Specifications''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
Center for Quality Management. 1993. "Special Issue on Kano's Methods for Understanding Customer Defined Quality." ''Center for Quality Management Journal.'' 2(4) (Fall 1993). <br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.<br />
<br />
Freeman, R. "Chapter 27: Achieving Strategic Aims: Moving Toward a Process Based Military Enterprise," in ''Handbook of Military Industrial Engineering.'' A.B. Badiru and M.U. Thomas (eds). Boca Raton, FL, USA: Taylor & Francis Group, CRC Press.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering.'' 3rd ed. London, UK: Springer.<br />
<br />
Kano, N. 1984. "Attractive Quality and Must-Be Quality." ''Quality JSQC.'' 14(2) (October 1984). <br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309. <br />
<br />
Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques." ''Software Engineering''. New York, NY: McGraw-Hill.<br />
<br />
MITRE. 2011. "Concept Development." ''Systems Engineering Guide.'' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/]].<br />
<br />
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/]].<br />
<br />
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]].<br />
----<br />
<center>[[Concept Definition|< Previous Article]] | [[Concept Definition|Parent Article]] | [[Stakeholder Needs and Requirements|Next Article >]]</center><br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Concept Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_and_Mission_Analysis&diff=48818Business and Mission Analysis2013-10-22T05:06:05Z<p>Groedler: </p>
<hr />
<div>[[Concept Definition (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 [[Stakeholder (glossary)|stakeholders]] are closely examined in the Mission Analysis activity and the Stakeholder Needs and Requirements activity, respectively. Concept Definition begins before any formal definition of the [[System-of-Interest (glossary)|system-of-interest]] (SoI) is developed. The activities are grouped and described as generic processes that are performed concurrently and/or iteratively depending on the selected [[Life Cycle Model (glossary) | life cycle model]].<br />
<br />
[[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), 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 Requirement (glossary)|Stakeholder Needs and Requirements]] activity 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. <br />
<br />
If a new or modified system is needed then [[System Definition (glossary) | System Definition]] activities are performed to assess the system. The specific activities and sequence of Concept Definition activities and their involvement in the life cycle activities of any system, will be dependent upon the type of life cycle model being utilized. <br />
<br />
==Topics==<br />
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: <br />
*[[Mission Analysis]]<br />
*[[Stakeholder Needs and Requirements]]<br />
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.<br />
<br />
==Concept Definition Activities==<br />
There are two primary activities discussed under concept definition: [[Mission Analysis (glossary)|Mission Analysis]] and the definition of [[Stakeholder Requirement (glossary)|Stakeholder Needs and Requirements]]:<br />
<br />
# [[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. <br />
#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. <br />
<br />
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|Mission Analysis]] topic depicts this interaction. The products and artifacts produced during Concept Definition are then used in [[System Definition (glossary)|System Definition]].<br />
<br />
The different aspects of how [[Systems Thinking (glossary) | systems thinking]] is applicable to concept definition are discussed in SEBoK Part 2. In particular, the use of a combination of [[Hard System (glossary) | hard system]] and [[Soft System (glossary) |soft system]] approaches depending on the type of problem or class of solution is discussed in the [[Identifying and Understanding Problems and Opportunities]] article.<br />
<br />
===Top-Down Approach: From Problem to Solution===<br />
In a top-down approach, concept definition activities are focused primarily on understanding the problem, the operational needs/requirements within the problem space, and the conditions that constrain the solution and bound the solution space. The concept definition activities determine the mission context, [[Mission Analysis (glossary)|Mission Analysis]], and the needs to be fulfilled in that context by a new or modified system (i.e., the SoI), and addresses [[Stakeholder Requirement (glossary)|stakeholder needs and requirements]]. <br />
<br />
The [[System Definition (glossary)|System Definition]] activities consider functional, behavioral, temporal, and physical aspects of one or more solutions based on the results of concept definition. [[System Analysis (glossary)|System Analysis]] considers the advantages and disadvantages of the proposed system solutions both in terms of how they satisfy the needs established in concept definition, as well as the relative cost, time scales and other development issues. This may require further refinement of the concept definition to ensure all legacy relationships and stakeholders relevant to a particular solution architecture have been considered in the stakeholder requirements.<br />
<br />
The outcomes of this iteration between Concept Definition and System Definition define a required system solution and its associated problem context, which are used for [[System Realization (glossary)|System Realization]], [[System Deployment and Use (glossary) | System Deployment and Use]], and [[Product and Service Life Management| Product and Service Life Management]] of one or more solution implementations. In this approach problem understanding and solution selection activities are completed in the front-end portion of system development and design and then maintained and refined as necessary throughout the life cycle of any resulting solution systems. Top-down activities can be sequential, iterative, recursive or evolutionary depending upon the life cycle model.<br />
<br />
For the Concept Definition, an appropriate architecture framework representation can be useful in the visualization and analysis of the mission and solution requirements. These includes the U.S. Department of Defense Architecture Framework (DoDAF) operations view (DoD 2010), the Zachman Framework (Rows1 and 2) (Zachman 2008), and The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM) (The Open Group 2010) Phases A and B within the concept definition when performing mission analysis and evaluating stakeholder needs and requirements.<br />
<br />
===Bottom-Up Approach: Evolution of the Solution===<br />
<br />
In some situations, the concept definition activities determine the need to evolve existing capabilities or add new capabilities to an existing system. During the concept definition, the alternatives to address the needs are evaluated. Engineers are then led to reconsider the system definition in order to modify or adapt some structural, functional, behavioral, or temporal properties during the [[Product (glossary)|product (glossary)]] or [[Service (glossary)|service (glossary)]] life cycle for a changing [[context (glossary)|context (glossary)]] of use or for the purpose of improving existing solutions. <br />
<br />
[[Reverse Engineering (glossary)|Reverse engineering]] is often necessary to enable system engineers to (re)characterize the properties of the system-of-interest (SoI) or its elements. This is an important step to ensure that system engineers understand the SoI before beginning modification. For more information on system definition, see the [[System Definition]] article.<br />
<br />
A bottom-up approach is necessary for analysis purposes, or for (re)using existing elements in the design [[Architecture (glossary)|architecture]]. Changes in the context of use or a need for improvement can prompt this. In contrast, a top-down approach is generally used to define an initial design solution corresponding to a problem or a set of needs.<br />
<br />
Bottom-up and top-down approaches can be, and often are, mixed (in what is oftern referred to as a “middle-out” approach).<br />
<br />
===Drivers of Solutions: Push Versus Pull===<br />
<br />
There are two paradigms that drive the concept definition: ''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 have an effect on other lifecycle processes, such as in verification and validation, as it is performed in defense industries versus alpha/beta testing done in some commercial domains.<br />
<br />
===Separation and Iteration between Problem and Solution===<br />
<br />
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 Analysis (glossary)|System Analysis]] activities are used to provide the link between problems and solutions. <br />
<br />
As systems generally integrate existing and new [[System Element (glossary)|system elements]], a bottom-up approach can be combined 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. As discussed in [[System Life Cycle Process Models: Iterative]], this is iterative for these evolutionary systems.<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
DoD. 2010. ''DoD Architecture Framework'', version 2.02. Arlington, VA: U.S. Department of Defense. Accessed August 29, 2012. Available at: http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_v2-02_web.pdf.<br />
<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley & Sons.<br />
<br />
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight'' (April 2010): 41-43.<br />
<br />
The Open Group. 2011. ''TOGAF'', version 9.1. Hogeweg, The Netherlands: Van Haren Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.<br />
<br />
Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™." Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.<br />
<br />
===Primary References===<br />
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.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ISO/IEC/IEEE. 2008. ''[[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]]:2008 (E).<br />
<br />
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]].<br />
<br />
===Additional References===<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley & Sons.<br />
<br />
Hitchins, D. 2008.''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.<br />
<br />
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. <br />
<br />
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight.'' (April 2010): 41-43.<br />
<br />
NASA. 2007. ''Systems Engineering Handbook''. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.<br />
<br />
----<br />
<center>[[Lean Engineering|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[Mission Analysis|Next Article >]]</center><br />
<br />
<br />
{{DISQUS}}<br />
<br />
<br />
[[Category:Part 3]][[Category:Knowledge Area]]</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Alignment_and_Comparison_of_Systems_Engineering_Standards&diff=38131Alignment and Comparison of Systems Engineering Standards2012-08-07T03:55:22Z<p>Groedler: /* Current Efforts */</p>
<hr />
<div>Over the past decade, a number of the standards development organizations (SDOs) and other industry associations have been working collaboratively to align the systems and software engineering standards. The objective is to have a set of standards that can easily be used concurrently within both engineering disciplines due to the disparity that often lies within their use of common terminology and concepts. <br />
==Problem==<br />
There has been a lack of integration both within and across SDOs. This has led to systems and software engineering standards that have different terminology, process sets, process structures, levels of prescription, and audiences. These differences have been both between systems and software, and to some extent, within each. The problem has been exacerbated, in whole or part, by competing standards (Roedler 2010).<br />
<br />
==Cause==<br />
The cause of this problem includes several factors, as follows (Roedler 2010):<br />
*Culture - “We’re different”; “Not invented here” <br />
*Organizational - Different teams, committees, etc.<br />
*Competition - Many Standards Development Organizations<br />
*Domains - Focused, narrow view often doesn’t look beyond the domain for commonality<br />
<br />
==Impact==<br />
The impact of this problem includes the following (Roedler 2010):<br />
*Less effective or efficient processes that are not focused on leveraging commonalities. This causes redundancy and has resulted in incompatibilities and inconsistencies between the standards making it difficult to concurrently use them together. <br />
*Less effective solutions that are not focused on a common approach to solve a problem or need.<br />
*Obstacle for communicating (at all levels), working in integrated teams, and leveraging resources.<br />
*Stove-piping due to the incompatibilities, inconsistencies, and lack of leveraging commonalities.<br />
<br />
==Objective==<br />
The objective is to make the standards more usable together by achieving (Roedler 2010):<br />
*Common vocabulary<br />
*Single, integrated process set<br />
*Single process structure<br />
*Jointly planned level of prescription <br />
*Suitable across the audiences <br />
*Accounts for considerations in a wide range of domains and applications<br />
<br />
==Alignment of Systems Engineering Standards==<br />
===Approach===<br />
A collaborative effort has been in place for the past decade that includes ISO/IEC JTC1/SC7 (Information Technology, Systems and Software Engineering), IEEE Computer Society, the International Council on Systems Engineering (INCOSE), and others. Figure 1 depicts the approach being used to align the standards through this collaboration. It is built around a foundational set of vocabulary, process definition conventions, and life cycle management concepts provided by ISO/IEC/IEEE 24765 (systems and software engineering vocabulary), ISO/IEC TR 24774 (guidelines for process description), and ISO/IEC/IEEE TR 24748-1 (guide to life cycle management), respectively. At the heart of the approach is the alignment of the ISO/IEC/IEEE 15288 (system life cycle processes) and ISO/IEC/IEEE 12207 (software life cycle processes), which provide the top level process framework for life cycle management of systems and software. This enables concurrent and consistent use of the standards to support both systems and software life cycle management on a single project. The approach includes the development or revision of a set of lower level supporting standards and technical reports for elaboration of specific processes, description of practices for specific purposes (e.g., systems/software assurance), description of artifacts, and guidance for the application of the standards.<br />
<br />
[[File:Approach_for_Systems_and_Software_Standards_Alignment.PNG|thumb|center|800px|Figure 1. Approach for Systems and Software Standards Alignment(Roedler 2011 -Adapted from Moore) Reprinted with permission of James Moore of MITRE and Garry Roedler.]]<br />
<br />
===Past Accomplishments===<br />
Significant progress has been made towards the alignment objectives for the groups discussed above. Figure 2 shows a May 2011 snapshot of the status of the standards that are being aligned. In addition, four of the standards shown as “In-process” are complete, but waiting for final publication. The set of standards span ISO/IEC, IEEE, INCOSE, and PMI. This figure depicts the standards in one of many possible taxonomies.<br />
<br />
[[File:Standards_Alignment_Results_as_of_May_2011.PNG|thumb|center|800px|Figure 2. Standards Alignment Results as of May 2011(Roedler 2011) Reprinted with permission of Garry Roedler.]]<br />
<br />
===Current Efforts===<br />
<br />
A Life Cycle Process Harmonization Advisory Group has been evaluating the current standards for systems and software engineering. The objective of the group is to provide a set of recommendations for further harmonization of the industry standards. Specifically, its charter includes:<br />
*Perform an architectural analysis and recommend a framework for an integrated set of process standards in software and IT systems domains<br />
*Make recommendations regarding the future content, structure, and relationships of ISO/IEC 12207, ISO/IEC 15288 and their guides, as well as other related SC 7 documents<br />
<br />
To support the development of the recommendations, process modeling of ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207 has been performed and analyzed for consistency, completeness/gaps, and opportunities. In addition, analysis from other working groups, technical liaisons, and users of the standards has been collected. The output of this effort will be a harmonization strategy, set of recommendations for specific standards, and timing/sequencing recommendations (Roedler 2011).<br />
<br />
Additionally, as the industry continues to consider harmonization needs of these standards, the collaboration has grown to include the work of the organizations and projects shown in Figure X. These organizations are working towards the goal of completing a complementary and supplemetary set of Systems Engineering resources that use the same terminology, principles, concepts, practices, and processes and can be used concurrently without issues.<br />
<br />
==Comparison of Systems Engineering Standards==<br />
<br />
See Figure 1 located in the [[Relevant Standards]] for Systems Engineering Article to see the breadth and level of detail for many of the SE related standards. Since EIA 632 (Engineering of a System) is currently in revision, a comparison of ISO/IEC/IEEE 15288 (System life cycle processes) and EIA 632 will be deferred until the revision is complete. <br />
<br />
Figure 3 shows a comparison of the 3-part technical reports that provide life cycle management guidance. Part 1 is focused on the provision of common terminology and concepts that apply to both systems and software. Part 2 provides guidance that directly supports ISO/IEC/IEEE 15288 that is specific to systems. And Part 3 provides guidance that directly supports ISO/IEC/IEEE 12207 that is specific to software (Roedler 2010). <br />
<br />
[[File:Standards_Alignment_Results_as_of_May_2011a.PNG|thumb|center|800px|Figure 3. Standards Alignment Results as of May 2011 (Roedler 2011)Reprinted with permission of Garry Roedler.]]<br />
<br />
==Practical Considerations==<br />
Key pitfalls and good practices related to systems engineering standards are described in the [[Relevant Standards]] article.<br />
<br />
There are also instances in which standards groups for program management, safety, or other disciplines create standards on topics addressed within systems engineering but use different terminology, culture, etc. One such example is risk management, which has been dealt with by many professional societies from different perspectives.<br />
<br />
Systems engineers must also be aware of the standards that govern the specialty disciplines that support systems engineering, as discussed in Part 6.<br />
<br />
==References== <br />
This article relies heavily on limited sources. Reviewers are requested to identify additional sources.<br />
<br />
===Works Cited===<br />
<br />
Roedler, Garry. 2010. ''[[An Overview of ISO/IEC/IEEE 15288, System Life Cycle Processes]].'' Asian Pacific Council on Systems Engineering (APCOSE) Conference.<br />
<br />
===Primary References===<br />
<br />
Roedler, Garry. 2010. An Overview of ISO/IEC/IEEE 15288, System Life Cycle Processes. Asian Pacific Council on Systems Engineering (APCOSE) Conference.<br />
<br />
===Additional References===<br />
<br />
See additional references in the [[Relevant Standards]] article.<br />
<br />
----<br />
<center>[[Relevant Standards|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Application of Systems Engineering Standards|Next Article >]]</center><br />
<br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Systems Engineering Standards]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Alignment_and_Comparison_of_Systems_Engineering_Standards&diff=38130Alignment and Comparison of Systems Engineering Standards2012-08-07T03:44:39Z<p>Groedler: /* Primary References */</p>
<hr />
<div>Over the past decade, a number of the standards development organizations (SDOs) and other industry associations have been working collaboratively to align the systems and software engineering standards. The objective is to have a set of standards that can easily be used concurrently within both engineering disciplines due to the disparity that often lies within their use of common terminology and concepts. <br />
==Problem==<br />
There has been a lack of integration both within and across SDOs. This has led to systems and software engineering standards that have different terminology, process sets, process structures, levels of prescription, and audiences. These differences have been both between systems and software, and to some extent, within each. The problem has been exacerbated, in whole or part, by competing standards (Roedler 2010).<br />
<br />
==Cause==<br />
The cause of this problem includes several factors, as follows (Roedler 2010):<br />
*Culture - “We’re different”; “Not invented here” <br />
*Organizational - Different teams, committees, etc.<br />
*Competition - Many Standards Development Organizations<br />
*Domains - Focused, narrow view often doesn’t look beyond the domain for commonality<br />
<br />
==Impact==<br />
The impact of this problem includes the following (Roedler 2010):<br />
*Less effective or efficient processes that are not focused on leveraging commonalities. This causes redundancy and has resulted in incompatibilities and inconsistencies between the standards making it difficult to concurrently use them together. <br />
*Less effective solutions that are not focused on a common approach to solve a problem or need.<br />
*Obstacle for communicating (at all levels), working in integrated teams, and leveraging resources.<br />
*Stove-piping due to the incompatibilities, inconsistencies, and lack of leveraging commonalities.<br />
<br />
==Objective==<br />
The objective is to make the standards more usable together by achieving (Roedler 2010):<br />
*Common vocabulary<br />
*Single, integrated process set<br />
*Single process structure<br />
*Jointly planned level of prescription <br />
*Suitable across the audiences <br />
*Accounts for considerations in a wide range of domains and applications<br />
<br />
==Alignment of Systems Engineering Standards==<br />
===Approach===<br />
A collaborative effort has been in place for the past decade that includes ISO/IEC JTC1/SC7 (Information Technology, Systems and Software Engineering), IEEE Computer Society, the International Council on Systems Engineering (INCOSE), and others. Figure 1 depicts the approach being used to align the standards through this collaboration. It is built around a foundational set of vocabulary, process definition conventions, and life cycle management concepts provided by ISO/IEC/IEEE 24765 (systems and software engineering vocabulary), ISO/IEC TR 24774 (guidelines for process description), and ISO/IEC/IEEE TR 24748-1 (guide to life cycle management), respectively. At the heart of the approach is the alignment of the ISO/IEC/IEEE 15288 (system life cycle processes) and ISO/IEC/IEEE 12207 (software life cycle processes), which provide the top level process framework for life cycle management of systems and software. This enables concurrent and consistent use of the standards to support both systems and software life cycle management on a single project. The approach includes the development or revision of a set of lower level supporting standards and technical reports for elaboration of specific processes, description of practices for specific purposes (e.g., systems/software assurance), description of artifacts, and guidance for the application of the standards.<br />
<br />
[[File:Approach_for_Systems_and_Software_Standards_Alignment.PNG|thumb|center|800px|Figure 1. Approach for Systems and Software Standards Alignment(Roedler 2011 -Adapted from Moore) Reprinted with permission of James Moore of MITRE and Garry Roedler.]]<br />
<br />
===Past Accomplishments===<br />
Significant progress has been made towards the alignment objectives for the groups discussed above. Figure 2 shows a May 2011 snapshot of the status of the standards that are being aligned. In addition, four of the standards shown as “In-process” are complete, but waiting for final publication. The set of standards span ISO/IEC, IEEE, INCOSE, and PMI. This figure depicts the standards in one of many possible taxonomies.<br />
<br />
[[File:Standards_Alignment_Results_as_of_May_2011.PNG|thumb|center|800px|Figure 2. Standards Alignment Results as of May 2011(Roedler 2011) Reprinted with permission of Garry Roedler.]]<br />
<br />
===Current Efforts===<br />
<br />
A Life Cycle Process Harmonization Advisory Group has been evaluating the current standards for systems and software engineering. The objective of the group is to provide a set of recommendations for further harmonization of the industry standards. Specifically, its charter includes:<br />
*Perform an architectural analysis and recommend a framework for an integrated set of process standards in software and IT systems domains<br />
*Make recommendations regarding the future content, structure, and relationships of ISO/IEC 12207, ISO/IEC 15288 and their guides, as well as other related SC 7 documents<br />
<br />
To support the development of the recommendations, process modeling of ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207 has been performed and analyzed for consistency, completeness/gaps, and opportunities. In addition, analysis from other working groups, technical liaisons, and users of the standards has been collected. The output of this effect will be a harmonization strategy, set of recommendations for specific standards, and timing/sequencing recommendations (Roedler 2011).<br />
<br />
==Comparison of Systems Engineering Standards==<br />
<br />
See Figure 1 located in the [[Relevant Standards]] for Systems Engineering Article to see the breadth and level of detail for many of the SE related standards. Since EIA 632 (Engineering of a System) is currently in revision, a comparison of ISO/IEC/IEEE 15288 (System life cycle processes) and EIA 632 will be deferred until the revision is complete. <br />
<br />
Figure 3 shows a comparison of the 3-part technical reports that provide life cycle management guidance. Part 1 is focused on the provision of common terminology and concepts that apply to both systems and software. Part 2 provides guidance that directly supports ISO/IEC/IEEE 15288 that is specific to systems. And Part 3 provides guidance that directly supports ISO/IEC/IEEE 12207 that is specific to software (Roedler 2010). <br />
<br />
[[File:Standards_Alignment_Results_as_of_May_2011a.PNG|thumb|center|800px|Figure 3. Standards Alignment Results as of May 2011 (Roedler 2011)Reprinted with permission of Garry Roedler.]]<br />
<br />
==Practical Considerations==<br />
Key pitfalls and good practices related to systems engineering standards are described in the [[Relevant Standards]] article.<br />
<br />
There are also instances in which standards groups for program management, safety, or other disciplines create standards on topics addressed within systems engineering but use different terminology, culture, etc. One such example is risk management, which has been dealt with by many professional societies from different perspectives.<br />
<br />
Systems engineers must also be aware of the standards that govern the specialty disciplines that support systems engineering, as discussed in Part 6.<br />
<br />
==References== <br />
This article relies heavily on limited sources. Reviewers are requested to identify additional sources.<br />
<br />
===Works Cited===<br />
<br />
Roedler, Garry. 2010. ''[[An Overview of ISO/IEC/IEEE 15288, System Life Cycle Processes]].'' Asian Pacific Council on Systems Engineering (APCOSE) Conference.<br />
<br />
===Primary References===<br />
<br />
Roedler, Garry. 2010. An Overview of ISO/IEC/IEEE 15288, System Life Cycle Processes. Asian Pacific Council on Systems Engineering (APCOSE) Conference.<br />
<br />
===Additional References===<br />
<br />
See additional references in the [[Relevant Standards]] article.<br />
<br />
----<br />
<center>[[Relevant Standards|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Application of Systems Engineering Standards|Next Article >]]</center><br />
<br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Systems Engineering Standards]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Application_of_Systems_Engineering_Standards&diff=38129Application of Systems Engineering Standards2012-08-07T03:43:49Z<p>Groedler: /* Primary References */</p>
<hr />
<div>There are many systems engineering standards that have evolved as indicated in [[Relevant Standards]]. In particular, there are standards that can have an influence on Organizations and their Projects as indicated in Figure 1. Some pitfalls and good practices in utilizing standards are also identified in the article on relevant standards. In this article, several additional factors related to the utilization of the standards are presented.<br />
==Standards and their Utilization==<br />
[[File:Potential_Standards_Influence_of_Organization_and_Project_Processes.PNG|thumb|center|800px|Figure 1. Potential Standards Influence of Organization and Project Processes (Roedler 2011) Reprinted with permission of Garry Roedler.]]<br />
<br />
A standard is an agreed, repeatable way of doing something. It is a published document that contains a technical specification or other precise criteria designed to be used consistently as a rule, guideline, or definition. Standards help to make life simpler and to increase the reliability and the effectiveness of many goods and services we use. Standards are created by bringing together the experience and expertise of all interested parties, such as the producers, sellers, buyers, users, and regulators of a particular material, product, process, or service.<br />
<br />
Standards are designed for voluntary use and do not impose any regulations. However, laws and regulations may refer to certain standards and make compliance with them compulsory.<br />
<br />
Further, organizations and their enterprises may choose to use standards as a means of providing uniformity in their operations and/or the products and services that they produce. The standard becomes a part of the corporate culture. In this regard, it is interesting to note that the ISO/IEC 15288 standard has provided such guidance and has provided a strong framework for systems engineers as well as systems engineering and business management, as forecast earlier by Arnold and Lawson (2004).<br />
<br />
[http://www.iso.org/directives ISO directives] state the following:<br />
<br />
<blockquote>''A standard does not in itself impose any obligation upon anyone to follow it. However, such an obligation may be imposed, for example, by legislation or by a contract. In order to be able to claim compliance with a standard, the user (of the standard) needs to be able to identify the requirements he is obliged to satisfy. The user needs also to be able to distinguish these requirements from other provisions where a certain freedom of choice is possible. Clear rules for the use of verbal forms (including modal auxiliaries) are therefore essential.''</blockquote><br />
<br />
==Requirements, Recommendations, and Permissions==<br />
<br />
In order to provide specificity, standards employ verb forms that convey requirements, recommendations, and permissions. For example, the ISO directives specify the following verb usages:<br />
<br />
*The word "shall" indicates requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted.<br />
<br />
*The word "should" indicates that among several possibilities, one is recommended as particularly suitable without mentioning or excluding others, or that a certain course of action is preferred, but not necessarily required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.<br />
<br />
*The word "may" indicates a course of action permissible within the limits of the standard.<br />
<br />
The directive also indicates that standards should avoid the use of "will," "must," etc.<br />
<br />
==Certification, Conformance and Compliance==<br />
<br />
In the context of the management system standards (ISO 9001:2000 and ISO 9001:2008 or ISO 14001:2004), “certification” refers to the issuing of written assurance (the certificate) by an independent external body that it has audited a management system and verified that it conforms to the requirements specified in the standard.<br />
<br />
Typically, other more specific systems engineering standards are not the subject of certification. They are self-imposed in order to improve uniformity of organization and enterprise operations or to improve the quality of products and services. Alternatively, they may be dictated by legislation, policy, or as part of a formal agreement between an [[Acquirer (glossary)|acquirer]] and a [[Supplier (glossary)|supplier]]. <br />
<br />
Conformance testing, or type testing, is testing to determine whether a product or system meets some specified standard that has been developed for efficiency or interoperability. To aid in this, many test procedures and test setups have been developed either by the standard's maintainers or external organizations, such as the Underwriters Laboratory (UL), specifically for testing conformance to standards.<br />
<br />
Conformance testing is often performed by external organizations, which is sometimes the standards body itself, to give greater guarantees of compliance. Products tested in such a manner are then advertised as being certified by that external organization as complying with the standard.<br />
<br />
Service providers, equipment manufacturers, and equipment suppliers rely on this data to ensure quality of service (QoS) through this conformance process.<br />
<br />
==Tailoring of Standards==<br />
<br />
Since the systems engineering standards provide guidelines, they are most often tailored to fit the needs of organizations and their enterprises in their operations and/or for the products and services that they provide, as well as to provide agreement in a contract. Tailoring is a process described in an annex to the ISO/IEC 15288 standard. <br />
<br />
The ISO/IEC 15288 addresses the issues of conformance, compliance, and tailoring as follows:<br />
<br />
*Full conformance - A claim of full conformance first declares the set of processes for which conformance is claimed. Full conformance is achieved by demonstrating that all of the requirements of the declared set of processes have been satisfied using the outcomes as evidence.<br />
<br />
*Tailored conformance - When this international standard is used as a basis for establishing a set of processes that do not qualify for full conformance, the clauses of this international standard are selected or modified in accordance with the tailoring process. <br />
<br />
*The tailored text, for which tailored conformance is claimed, is declared. Tailored conformance is achieved by demonstrating that requirements for the processes, as tailored, have been satisfied using the outcomes as evidence.<br />
<br />
*When the standard is used to help develop an agreement between an acquirer and a supplier, clauses of the standard can be selected for incorporation in the agreement with or without modification. In this case, it is more appropriate for the acquirer and supplier to claim compliance with the agreement than conformance with the standard.<br />
<br />
*Any organization (e.g., a national organization, industrial association, or company) imposing the standard as a condition of trade should specify and make public the minimum set of required processes, activities, and tasks, which constitute a supplier's conformance with the standard.<br />
<br />
==References== <br />
This article relies heavily on limited sources. Reviewers are requested to identify additional sources.<br />
<br />
===Works Cited===<br />
Arnold, S., and H. Lawson. 2004. "Viewing systems from a business management perspective." ''Systems Engineering'', 7 (3): 229.<br />
<br />
Roedler, Garry. 2010. An Overview of ISO/IEC/IEEE 15288, System Life Cycle Processes. Asian Pacific Council on Systems Engineering (APCOSE) Conference.<br />
<br />
===Primary References===<br />
Roedler, Garry. 2010. An Overview of ISO/IEC/IEEE 15288, System Life Cycle Processes. Asian Pacific Council on Systems Engineering (APCOSE) Conference.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
<br />
----<br />
<br />
<center>[[Alignment and Comparison of the Standards|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Applications of Systems Engineering|Next Article (Part 4) >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Systems Engineering Standards]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Application_of_Systems_Engineering_Standards&diff=38128Application of Systems Engineering Standards2012-08-07T03:42:36Z<p>Groedler: /* Works Cited */</p>
<hr />
<div>There are many systems engineering standards that have evolved as indicated in [[Relevant Standards]]. In particular, there are standards that can have an influence on Organizations and their Projects as indicated in Figure 1. Some pitfalls and good practices in utilizing standards are also identified in the article on relevant standards. In this article, several additional factors related to the utilization of the standards are presented.<br />
==Standards and their Utilization==<br />
[[File:Potential_Standards_Influence_of_Organization_and_Project_Processes.PNG|thumb|center|800px|Figure 1. Potential Standards Influence of Organization and Project Processes (Roedler 2011) Reprinted with permission of Garry Roedler.]]<br />
<br />
A standard is an agreed, repeatable way of doing something. It is a published document that contains a technical specification or other precise criteria designed to be used consistently as a rule, guideline, or definition. Standards help to make life simpler and to increase the reliability and the effectiveness of many goods and services we use. Standards are created by bringing together the experience and expertise of all interested parties, such as the producers, sellers, buyers, users, and regulators of a particular material, product, process, or service.<br />
<br />
Standards are designed for voluntary use and do not impose any regulations. However, laws and regulations may refer to certain standards and make compliance with them compulsory.<br />
<br />
Further, organizations and their enterprises may choose to use standards as a means of providing uniformity in their operations and/or the products and services that they produce. The standard becomes a part of the corporate culture. In this regard, it is interesting to note that the ISO/IEC 15288 standard has provided such guidance and has provided a strong framework for systems engineers as well as systems engineering and business management, as forecast earlier by Arnold and Lawson (2004).<br />
<br />
[http://www.iso.org/directives ISO directives] state the following:<br />
<br />
<blockquote>''A standard does not in itself impose any obligation upon anyone to follow it. However, such an obligation may be imposed, for example, by legislation or by a contract. In order to be able to claim compliance with a standard, the user (of the standard) needs to be able to identify the requirements he is obliged to satisfy. The user needs also to be able to distinguish these requirements from other provisions where a certain freedom of choice is possible. Clear rules for the use of verbal forms (including modal auxiliaries) are therefore essential.''</blockquote><br />
<br />
==Requirements, Recommendations, and Permissions==<br />
<br />
In order to provide specificity, standards employ verb forms that convey requirements, recommendations, and permissions. For example, the ISO directives specify the following verb usages:<br />
<br />
*The word "shall" indicates requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted.<br />
<br />
*The word "should" indicates that among several possibilities, one is recommended as particularly suitable without mentioning or excluding others, or that a certain course of action is preferred, but not necessarily required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.<br />
<br />
*The word "may" indicates a course of action permissible within the limits of the standard.<br />
<br />
The directive also indicates that standards should avoid the use of "will," "must," etc.<br />
<br />
==Certification, Conformance and Compliance==<br />
<br />
In the context of the management system standards (ISO 9001:2000 and ISO 9001:2008 or ISO 14001:2004), “certification” refers to the issuing of written assurance (the certificate) by an independent external body that it has audited a management system and verified that it conforms to the requirements specified in the standard.<br />
<br />
Typically, other more specific systems engineering standards are not the subject of certification. They are self-imposed in order to improve uniformity of organization and enterprise operations or to improve the quality of products and services. Alternatively, they may be dictated by legislation, policy, or as part of a formal agreement between an [[Acquirer (glossary)|acquirer]] and a [[Supplier (glossary)|supplier]]. <br />
<br />
Conformance testing, or type testing, is testing to determine whether a product or system meets some specified standard that has been developed for efficiency or interoperability. To aid in this, many test procedures and test setups have been developed either by the standard's maintainers or external organizations, such as the Underwriters Laboratory (UL), specifically for testing conformance to standards.<br />
<br />
Conformance testing is often performed by external organizations, which is sometimes the standards body itself, to give greater guarantees of compliance. Products tested in such a manner are then advertised as being certified by that external organization as complying with the standard.<br />
<br />
Service providers, equipment manufacturers, and equipment suppliers rely on this data to ensure quality of service (QoS) through this conformance process.<br />
<br />
==Tailoring of Standards==<br />
<br />
Since the systems engineering standards provide guidelines, they are most often tailored to fit the needs of organizations and their enterprises in their operations and/or for the products and services that they provide, as well as to provide agreement in a contract. Tailoring is a process described in an annex to the ISO/IEC 15288 standard. <br />
<br />
The ISO/IEC 15288 addresses the issues of conformance, compliance, and tailoring as follows:<br />
<br />
*Full conformance - A claim of full conformance first declares the set of processes for which conformance is claimed. Full conformance is achieved by demonstrating that all of the requirements of the declared set of processes have been satisfied using the outcomes as evidence.<br />
<br />
*Tailored conformance - When this international standard is used as a basis for establishing a set of processes that do not qualify for full conformance, the clauses of this international standard are selected or modified in accordance with the tailoring process. <br />
<br />
*The tailored text, for which tailored conformance is claimed, is declared. Tailored conformance is achieved by demonstrating that requirements for the processes, as tailored, have been satisfied using the outcomes as evidence.<br />
<br />
*When the standard is used to help develop an agreement between an acquirer and a supplier, clauses of the standard can be selected for incorporation in the agreement with or without modification. In this case, it is more appropriate for the acquirer and supplier to claim compliance with the agreement than conformance with the standard.<br />
<br />
*Any organization (e.g., a national organization, industrial association, or company) imposing the standard as a condition of trade should specify and make public the minimum set of required processes, activities, and tasks, which constitute a supplier's conformance with the standard.<br />
<br />
==References== <br />
This article relies heavily on limited sources. Reviewers are requested to identify additional sources.<br />
<br />
===Works Cited===<br />
Arnold, S., and H. Lawson. 2004. "Viewing systems from a business management perspective." ''Systems Engineering'', 7 (3): 229.<br />
<br />
Roedler, Garry. 2010. An Overview of ISO/IEC/IEEE 15288, System Life Cycle Processes. Asian Pacific Council on Systems Engineering (APCOSE) Conference.<br />
<br />
===Primary References===<br />
No primary references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
<br />
----<br />
<br />
<center>[[Alignment and Comparison of the Standards|< Previous Article]] | [[Service Life Extension|Parent Article]] | [[Applications of Systems Engineering|Next Article (Part 4) >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Systems Engineering Standards]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Stakeholder_Requirements_Definition&diff=38127Stakeholder Requirements Definition2012-08-07T02:48:40Z<p>Groedler: /* Additional References */</p>
<hr />
<div><br />
The System requirements are all of the [[Requirement (glossary)|requirements]] at the “system level” that have been properly translated from the list of stakeholders' requirements. The System Requirements form the basis of System [[Architecture (glossary)| Architecture]] and [[Design (glossary) |Design]], verification, validation, and stakeholder acceptance. <br />
<br />
System Requirements play major roles in the engineering activities. They serve:<br />
*as the essential inputs of the System Architecture and Design activities.<br />
*as reference for the System Validation activities.<br />
*as a communication means, between the various technical staff that interact within the project.<br />
<br />
==Principles Governing System Requirements==<br />
===Origin in Stakeholder Requirements===<br />
The set of Stakeholder Requirements may contain vague, ambiguous, and qualitative “user-oriented” need statements that are difficult to use for design or to verify. Each of these requirements may need to be further clarified and translated into “engineering-oriented” language to enable proper architecture definition, design and verification activities. The System Requirements resulting from this translation are expressed in technical language useful for architecture and design; unambiguous, consistent, coherent, exhaustive, and verifiable. Of course, close coordination with the stakeholders is necessary to ensure the translation is accurate.<br />
<br />
As an example, a need or an expectation such as "To easily maneuver a car to park it," will be transformed in a set of Stakeholder Requirements such as, "Increase the drivability of the car", "Decrease the effort for handling", "Assist the piloting", "Protect the coachwork against shocks or scratch", etc. Translating, for example, the Stakeholder Requirement "Increase the drivability of the car", results in a set of System Requirements specifying measurable characteristics such as the turning circle (steering lock), the wheelbase, etc.<br />
<br />
===Requirements Management===<br />
Requirements Management is performed to ensure alignment of the system and system element requirements with other representations, analysis and artifacts of the system. It includes ensuring an understanding of the requirements, obtaining commitment, managing changes, maintaining bi-directional traceability among the requirements and with the rest of the system definition, and alignment with project resources and schedule. There are many tools available to provide a supporting infrastructure for Requirements Management; the best choice is the one that best matches the processes of the project or enterprise. Requirements Management is also closely tied to Configuration Management for baseline management and control. When the requirements have been defined, documented, and approved, they need to be put under baseline management and control. The baseline allows the project to analyze and understand the impact (technical, cost, and schedule) of ongoing proposed changes.<br />
<br />
====Traceability and assignment of System Requirements during architecture and design====<br />
Requirements traceability provides the ability to trace information from the origin of the Stakeholder Requirements at the top level to requirements and other system definition elements at all levels of the system hierarchy - see section "Top-down and recursive approach to system decomposition" in the [[System Definition]] article. Traceability is also used to provide an understanding of the extent of a change as an input to impact analyses conducted with respect to proposed engineering improvements or requests for change.<br />
<br />
During [[Architecture (glossary) |architecture]] definition and [[Design (glossary) |design]], the assignment of requirements from one level to lower levels in the system hierarchy can be accomplished using several methods, as appropriate - see Table 1.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 1. Assessment Types for a System Requirement.''' (SEBoK Original)<br />
!Assignment Type for a System Requirement<br />
!Description<br />
|-<br />
|'''Direct Assignment'''<br />
|The system requirement from the higher level is directly assigned to a system or a system element for a lower level (for example, the color used to paint visible parts of the product).<br />
|-<br />
|'''Indirect Assignment (Simply Decomposed)'''<br />
|The system requirement is distributed across several systems or system elements and the sum or a more complex calculation for distribution is equal to the requirement of higher level (for example, a mass requirement, power distribution, reliability allocation, etc.) with sufficient margin or tolerance. A documented and configuration-managed "assignment budget" for each assignment must be maintained.<br />
|-<br />
|'''Indirect Assignment (Modeled and Decomposed)'''<br />
|The system requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique, and the resulting design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, a radar detection requirement may be analyzed; lower-level parameters for output power, beam size, frequencies, etc., will then be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.<br />
|-<br />
|'''Derived Requirement (from Design)'''<br />
|Such system requirements are developed during the design activities as a result of decision of the design team, not the stakeholder community. These requirements may include the use of commercial-off-the-shelf (COTS) items, existing systems or system elements in inventory, common components, and similar design decisions in order to produce a "best value" solution for the customer. As such these derived requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or a constraint.<br />
|}<br />
</center><br />
<br />
===Classification of System Requirements===<br />
Several classifications of System Requirements are possible, depending on the requirements definition methods and/or the architecture and design methods used. (ISO/IEC. 2011) provides a classification summarized below – see references for other interesting classifications. An example is given in Table 2.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Example of System Requirements Classification.''' (SEBoK Original)<br />
!Types of System Requirement<br />
!Description<br />
|-<br />
|'''Functional Requirements'''<br />
|Describe qualitatively the system functions or tasks to be performed in operation.<br />
|-<br />
|'''Performance Requirements'''<br />
|Define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task. <br />
|-<br />
|'''Usability Requirements'''<br />
|Define quality in use such as measurable effectiveness, efficiency, and satisfaction criteria.<br />
|-<br />
|'''Interface Requirements'''<br />
|Define how the system is required to interact or to exchange material, energy, or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface requirements include physical connections (physical interfaces) with external systems or internal system elements supporting interactions or exchanges.<br />
|-<br />
|'''Operational Requirements'''<br />
|Define operational conditions or properties under which the system is required to operate or exist. This type of requirement includes human factors and ergonomics, availability, maintainability, reliability, security.<br />
|-<br />
|'''Modes and/or States Requirements'''<br />
|Define the various operational modes of the system in use, and events conducting to transitions of modes.<br />
|-<br />
|'''Adaptability Requirements'''<br />
|Define potential extension, growth, or scalability during the lift of the system.<br />
|-<br />
|'''Physical Constraints'''<br />
|Define constraints on weight, volume, and dimension applicable on system elements that compose the system.<br />
|-<br />
|'''Design Constraints'''<br />
|Define the limits on the options open to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an online repository).<br />
|-<br />
|'''Environmental Conditions'''<br />
|Define the environmental conditions to be encountered by the system in its different operational modes. Should be addressed the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-induced environment (e.g. motion, shock, noise, electromagnetism, thermal, etc.), threats societal environment (e.g. legal, political, economic, social, business, etc.).<br />
|-<br />
|'''Logistical Requirements'''<br />
|Define the logistical conditions needed by the continuous utilization of the system. These requirements include sustainment (provision of facilities, level support, support personnel, spare parts, training, technical documentation, etc.), packaging, handling, shipping, transportation.<br />
|-<br />
|'''Policies and Regulations'''<br />
|Define relevant and applicable organizational policies or regulatory requirements that could affect the operation or performance of the system (e.g. labor policies, reports to regulatory agony, health or safety criteria, etc.).<br />
|-<br />
|'''Cost and Schedule Constraints'''<br />
|Define, for example, the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc.<br />
|}<br />
</center><br />
<br />
==Process Approach – System Requirements==<br />
===Purpose and Principle of the Approach===<br />
The purpose of the system requirements analysis process is to transform the stakeholder, user-oriented view of desired services and properties into a technical view of the product that meets the operational needs of the user. This process builds a representation of the system that will meet Stakeholder Requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable System Requirements that specify, from the supplier’s perspective, what performance and non-performance characteristics it must possess in order to satisfy stakeholders' requirements. (ISO/IEC. 2008)<br />
<br />
===Activities of the process===<br />
Major activities and tasks performed during this process include:<br />
#Analyze the Stakeholder Requirements to check completeness of expected services and [[Operational Scenario (glossary)|Operational Scenarios (glossary)]], conditions, Operational Modes, and constraints.<br />
#Define the System Requirements and its [[Rationale (glossary)]].<br />
#Classify the System Requirements using suggested classifications – see examples above.<br />
#Incorporate the derived requirements (coming from architecture and design) into the System Requirements baseline.<br />
#Establish the upward traceability with the Stakeholder Needs and Requirements. <br />
#Establish birectional traceability between requirements at adjacent levels of the system hierarchy. <br />
#Verify the quality and completeness of each System Requirement and the consistency of the set of System Requirements.<br />
#Validate the content and relevance of each System Requirement against the set of Stakeholder Requirements.<br />
#Identify potential [[Risk (glossary)|Risks (glossary)]] (or threats and hazards) that could be generated by the System Requirements.<br />
#Synthesize, record, and manage the System Requirements and potential associated Risks.<br />
#Upon aproval of the requirements, establish and control baselines along with the other system definition elements in conjunction with established Configuration Management practices.<br />
<br />
===Artifacts and Ontology Elements===<br />
This process may create several artifacts such as:<br />
#System Requirements Document<br />
#System Requirements Justification Document (for traceability purpose)<br />
#System Requirements Database, including traceability, analysis, rationale, decisions, and attributes, where appropriate.<br />
#System External Interface Requirements Document (this document describes the interfaces of the system with external elements of its context of use; the interface requirements can be integrated or not to the System Requirements Document above).<br />
<br />
This process handles the ontology elements of Table 3.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 3. Main Ontology Elements as Handled within System Requirements Definition.''' (SEBoK Original)<br />
!Element<br />
!Definition/Attributes (Examples)<br />
|-<br />
|'''System Requirement'''<br />
|Statement that expresses an expected characteristic or a constraint using a semantic code (such as natural language, mathematical, arithmetic, geometrical expression). A system requirement is feasible, objective, and verifiable.<br />
----<br />
Identifier; name; description; parent (result of a stakeholder requirement translation or of a design choice); type (classification); effectivity (immediately applicable, allocated to a later version, etc.); verification method (inspection, analysis, demonstration, test, etc.); decision (result of a trade-off study having led to choosing or rejecting the requirement); status (identified, analyzed, verified, allocated, satisfied). Criticality (importance related to the safety and the availability of the system); weighing/priority (relative importance compared to others); history records (date, author, identification, and contents of the modification, type of modification, reason for the modification); comments.<br />
|-<br />
|'''Rationale'''<br />
|Argument that provides the justification for the selection of an engineering element.<br />
----<br />
Identifier; name; description (rational, reasons for a requirement to be satisfied).<br />
|-<br />
|'''Scenario'''<br />
|A set of actions/functions representing the dynamic of exchanges between the functions allowing the system to achieve a mission or a service.<br />
----<br />
Identifier; name; description.<br />
|-<br />
|'''Risk'''<br />
|An event having a probability of occurrence and gravity degree on its consequence onto the system mission or on other characteristics (used for technical risk in engineering). A risk is the combination of vulnerability and of a danger or a threat.<br />
----<br />
Identifier; name; description; status.<br />
|}<br />
</center><br />
<br />
===Checking and Correctness of System Requirements===<br />
System Requirements should be checked to gauge whether they are well expressed and appropriate. There are number of characteristics which can be used to check System Requirements. The set of System Requirements can be verified using standard peer review techniques and by comparing each requirement against the set of requirements characteristics listed in Table 2 and Table 3 of section "Presentation and Quality of Requirements".<br />
<br />
The requirements can be further validated using the requirements elicitation and rationale capture described in section "Methods and Modeling Techniques."<br />
<br />
===Methods and Modeling Techniques===<br />
====Requirements Elicitation and Prototyping====<br />
Requirements Elicitation requires user involvement, and can be effective in gaining stakeholder involvement and buy-in. QFD (Quality Function Deployment) and prototyping are two common techniques that can be applied and are defined in this section. In addition, interviews, focus groups, and Delphi techniques are often applied to elicit requirements.<br />
<br />
QFD is a powerful technique to elicit requirements and compare design characteristics against user needs (Hauser and Clausing, 1988). The inputs to the QFD application are user needs and operational concepts, so it is essential that the users participate. Users from across the life cycle should be included so that all aspects of user needs are accounted for and prioritized.<br />
<br />
Early prototyping can help the users and developers interactively identify functional and operational requirements and user interface constraints. The prototyping allows for realistic user interaction, discovery, and feedback, as well as some sensitivity analysis. This improves the user's understanding of the requirements and increases the probability of satisfying their actual needs.<br />
<br />
====Capturing Requirements Rationale====<br />
One powerful and cost-effective technique to translate Stakeholder Requirements to System Requirements is to capture the rationale for each requirement. Requirements rationale is merely a statement as to why the requirement exists, any assumptions made, the results of related design studies, or any other related supporting information. This supports further requirements analysis and decomposition. The rationale can be captured directly in the requirements database. (Hull, M. E. C., Jackson, K., Dick, A. J. J. 2010).<br />
<br />
Some of the benefits include:<br />
*'''Reducing the total number of requirements'''. The process aids in identifying duplicates. Reducing requirements count will reduce project cost and risk.<br />
*'''Early exposure of bad assumptions'''. <br />
*'''Removes design implementation'''. Many poorly written stakeholder requirements are design requirements in disguise, in that the customer is intentionally or unintentionally specifying a candidate implementation. <br />
*'''Improves communication with the stakeholder community'''. By capturing the requirements rationale for all Stakeholders Requirements, the line of communication between the users and the designers is greatly improved. Adapted from (Hooks, I. F., and K. A. Farry. 2000) Chapter 8.<br />
<br />
====Modeling Techniques====<br />
Modeling techniques that can be used when requirements must be detailed or refined, or when they address topics not considered during the Stakeholder Requirements Definition and Mission Analysis include:<br />
*State-charts models (ISO/IEC. 2011) Section 8.4.2<br />
*Scenarios modeling (ISO/IEC. 2011) Section 6.2.3.1<br />
*Simulations, prototyping (ISO/IEC. 2011) Section 6.3.3.2<br />
*Quality Function Deployment (INCOSE. 2010) p. 83<br />
*Sequence diagram, Activity diagram, Use case, State machine diagram, Requirements diagram of [[Acronyms|SysML]]<br />
*Functional Flow Block Diagram for Operational Scenario<br />
<br />
====Presentation and Quality of Requirements====<br />
Generally, requirements are provided in a textual form. Guidelines exist for writing good requirements; they include recommendations about syntax of requirements statements, wording (exclusions, representation of concepts, etc.), characteristics(specific, measurable, achievable, feasible, testable, etc.). Refer to (INCOSE. 2010) section 4.2.2.2 and (ISO/IEC. 2011).<br />
<br />
There are several characteristics of requirements and sets of requirements that ensure the quality of requirements. These are used both to aid the development of the requirements and to verify the implementation of requirements into the solution. Table 4 provides a list and descriptions of the characteristics for individual requirements and Table 5 provides a list and descriptions of characteristics for a set of requirements, as adapted from (ISO/IEC. 2011) sections 5.2.5 and 5.2.6.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 4. Characteristics of Individual Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Necessary'''<br />
|The requirement defines an essential capability, characteristic, constant, and/or quality factor. If it is removed or deleted, a deficiency will exist, which cannot be fulfilled by other capabilities of the product or process.<br />
|-<br />
|'''Implementation Free'''<br />
|The requirement, while addressing what is necessary and sufficient in the system, avoids placing unnecessary constraints on the architectural design. The objective is to be implementation-independent. The requirement states what is required, not how the requirement should be met.<br />
|-<br />
|'''Unambiguous'''<br />
|The requirement is stated in such a way so that it can be interpreted in only one way. The requirement is stated simply and is easy to understand.<br />
|-<br />
|'''Consistent'''<br />
|The requirement is free of conflicts with other requirements.<br />
|-<br />
|'''Complete'''<br />
|The stated requirement needs no further amplification because it is measurable and sufficiently describes the capability and characteristics to meet the stakeholders' needs.<br />
|-<br />
|'''Singular'''<br />
|The requirement statement includes only one requirement with no use of conjunctions.<br />
|-<br />
|'''Feasible'''<br />
|The requirement is technically achievable and fits within system constraints (e.g., cost, schedule, technical, lethal, regulatory).<br />
|-<br />
|'''Traceable'''<br />
|The requirement is upwards traceable to specific documented stakeholder statement(s) of need, higher tier requirement, or other source (e.g., a trade or design study). The requirement is also downwards traceable to the specific requirements in the lower tier requirements specification or other system definition artifacts. That is, all parent-child relationships for the requirement are identified in tracing such that the requirement traces to its source and implementation.<br />
|-<br />
|'''Verifiable'''<br />
|The requirement has the means to prove that the system satisfies the specified requirement. Verifiability is enhanced when the requirement is measurable.<br />
|}<br />
</center><br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 5. Characteristics of a Set of Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Complete'''<br />
|The set of requirements needs no further amplification because it contains everything pertinent to the definition of the system or system element being specified. In addition, the set contains no to be defined (TBD), to be specified (TBS), or to be resolved (TBR) clauses. Resolution of the TBx designations may be iterative and there is an acceptable timeframe for TBx items, determined by risks and dependencies. Note: Some practices are recommended to improve completeness; include all requirement types; account for requirements in all stages of the life cycle; and involve all stakeholders in the requirements elicitation activity.<br />
|-<br />
|'''Consistent'''<br />
|The set of requirements does not have individual requirements which are contradictory. Requirements are not duplicate. The same term is used for the same item in all requirements.<br />
|-<br />
|'''Affordable'''<br />
|The complete set of requirements can be satisfied by a solution that is obtainable/feasible within life cycle constraints (e.g. cost, schedule, technical, legal, regulatory).<br />
|-<br />
|'''Bounded'''<br />
|The set of requirements maintains the identified scope for the intended solution without increasing beyond what is needed to satisfy user needs.<br />
|}<br />
</center><br />
<br />
====Requirements in Tables====<br />
Requirements may be provided in a table, especially when specifying a set of parameters for the system or a system element. It is good practice to make standard table templates available. For tables, the following conventions apply: <br />
*Invoke each requirements table in the requirements set that clearly points to the table.<br />
*Identify each table with a unique title and table number.<br />
*Include the word “requirements” in the table title.<br />
*Identify the purpose of the table in the text immediately preceding it and include an explanation of how to read and use the table, including context and units.<br />
*For independent-dependant variable situations, organize the table in a way that best accommodates the use of the information.<br />
*Each cell should contain, at most, a single requirement.<br />
<br />
====Requirements in Flow Charts====<br />
Flow charts often contain requirements in a graphical form. These requirements may include logic that must be incorporated into the system, operational requirements, process or procedural requirements, or other situations that are best defined graphically by a sequence of interrelated steps. For flow charts, the following conventions apply:<br />
*Invoke flow charts in the requirements set that clearly points to the flow chart.<br />
*Identify each flow chart with a unique title and figure number.<br />
*Include the word “requirements” in the title of the flow chart<br />
*Clearly indicate and explain unique symbols that represent requirements in the flow chart.<br />
<br />
====Requirements in Drawings====<br />
Drawings also provide a graphical means to define requirements. The type of requirement defined in a drawing depends on the type of drawing. Following conventions apply:<br />
*Drawings are used when they can aid in the description of the following:<br />
** Spatial requirements<br />
**Interface requirements<br />
**Layout requirements<br />
*Invoke drawings in the requirements set that clearly points to the drawing.<br />
<br />
<br />
<br />
==Practical Considerations about System Requirements==<br />
There are several '''pitfalls''' that will inhibit the generation and management of an optimal set of System Requirements. See Table 6.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 6. Major Pitfalls with Definition of System Requirements.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|'''Insufficient analysis of stakeholder requirements'''<br />
|The receivers of the stakeholder requirements do not perform a sufficient critical analysis of them; the consequence could be difficulties translating them into system requirements and the obligation to come back to the stakeholders, losing time.<br />
|-<br />
|'''Insufficient analysis of operational modes and scenarios'''<br />
|The operational modes and operational scenarios are not sufficiently analyzed or defined by the person in charge of writing the system requirements. Those elements allow the structuring of the system and its use early in the engineering and help the designer to remember functions and interfaces.<br />
|-<br />
|'''Uncompleted set of system requirements'''<br />
|If the system requirements are not sufficiently precise and complete, there is a great risk that the design will not have the expected level of quality and that the verification and validation of the system will be delayed.<br />
|-<br />
|'''Lack of verification method'''<br />
|Delaying the capture of verification methods and events for each system requirement; identification of the verification approach for each requirement often provides additional insight as to the correctness and necessity of the requirement itself.<br />
|-<br />
|'''Missing traceability'''<br />
|Incorrect or missing traceability of each requirement, both to an upper-level "parent" requirement and allocation to an appropriate system or system element.<br />
|}<br />
</center><br />
<br />
<br />
The following '''proven practices''' in system requirements engineering have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development. See Table 7.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 7. Proven Practices with Definition of System Requirements.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|+<br />
|'''Involve stakeholders'''<br />
|Involve the stakeholders early in the system requirements development process.<br />
|+<br />
|'''Presence of rationale'''<br />
|Capture the rationale for each system requirement.<br />
|+<br />
|'''Always before starting'''<br />
|Check that stakeholder requirements are complete as much as possible before starting the definition of the system requirements.<br />
|+<br />
|'''Peer reviews'''<br />
|Organize peer reviews of system requirements with applicable subject matter experts.<br />
|+<br />
|'''Modeling techniques'''<br />
|Use modeling techniques as indicated in sections above.<br />
|+<br />
|'''Requirements management tool'''<br />
|Consider using a requirements management tool, especially for more complex projects. This tool should have the capability to trace linkages between system requirements to show relationships. A requirements management tool is intended to facilitate and support the systematic managing of system requirements throughout the project life cycle.<br />
|+<br />
|'''Measures for requirement engineering'''<br />
|Use typical measures for requirement engineering - refer to the ''Systems Engineering Leading Indicators Guide'' (Roedler et al. 2010). Both process and product measures should be used for requirements engineering. To get the desired insight to facilitate risk-managed requirements engineering, it may be necessary to use more than one measure based on the information needs (risks, objectives, issues) for the requirements. Useful measures include:<br />
*Requirements volatility<br />
*Requirements trends<br />
*Requirements verification progress (plan vs. actual)<br />
*Requirements validation progress (plan vs. actual)<br />
*TBD and TBR closure per plan<br />
*Peer review defects<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Hauser, J. and D. Clausing. 1988. "The House of Quality." ''Harvard Business Review.'' (May - June 1988). <br />
<br />
Hooks, I. F., and K. A. Farry. 2000. ''Customer-centered products: Creating successful products through smart requirements management''. New York, NY, USA: American Management Association.<br />
<br />
Hull, M. E. C., Jackson, K., Dick, A. J. J. 2010. ''Systems Engineering''. 3rd ed. London, UK: Springer.<br />
<br />
INCOSE. 2011. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities'' Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
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. <br />
<br />
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).<br />
<br />
===Primary References===<br />
<br />
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]].<br />
<br />
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).<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com. <br />
<br />
Hooks, I.F., and K.A. Farry. 2000. ''Customer-Centered Products: Creating Successful Products through Smart Requirements Management.'' New York, NY, USA: American Management Association. <br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering''. 3rd ed. London, UK: Springer.<br />
<br />
Roedler, G., D. Rhodes, C. Jones, and H. Schimmoller. 2010. ''Systems Engineering Leading Indicators Guide''. Version 2.0. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2005-001-03.<br />
<br />
SEI. 2007. "Requirements Management Process Area" and "Requirements Development Process Area" in Capability Maturity Model Integrated (CMMI) for Development, version 1.2. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU). <br />
<br />
----<br />
<br />
<center>[[System Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Architectural Design: Logical|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Stakeholder_Requirements_Definition&diff=38126Stakeholder Requirements Definition2012-08-07T02:43:26Z<p>Groedler: </p>
<hr />
<div><br />
The System requirements are all of the [[Requirement (glossary)|requirements]] at the “system level” that have been properly translated from the list of stakeholders' requirements. The System Requirements form the basis of System [[Architecture (glossary)| Architecture]] and [[Design (glossary) |Design]], verification, validation, and stakeholder acceptance. <br />
<br />
System Requirements play major roles in the engineering activities. They serve:<br />
*as the essential inputs of the System Architecture and Design activities.<br />
*as reference for the System Validation activities.<br />
*as a communication means, between the various technical staff that interact within the project.<br />
<br />
==Principles Governing System Requirements==<br />
===Origin in Stakeholder Requirements===<br />
The set of Stakeholder Requirements may contain vague, ambiguous, and qualitative “user-oriented” need statements that are difficult to use for design or to verify. Each of these requirements may need to be further clarified and translated into “engineering-oriented” language to enable proper architecture definition, design and verification activities. The System Requirements resulting from this translation are expressed in technical language useful for architecture and design; unambiguous, consistent, coherent, exhaustive, and verifiable. Of course, close coordination with the stakeholders is necessary to ensure the translation is accurate.<br />
<br />
As an example, a need or an expectation such as "To easily maneuver a car to park it," will be transformed in a set of Stakeholder Requirements such as, "Increase the drivability of the car", "Decrease the effort for handling", "Assist the piloting", "Protect the coachwork against shocks or scratch", etc. Translating, for example, the Stakeholder Requirement "Increase the drivability of the car", results in a set of System Requirements specifying measurable characteristics such as the turning circle (steering lock), the wheelbase, etc.<br />
<br />
===Requirements Management===<br />
Requirements Management is performed to ensure alignment of the system and system element requirements with other representations, analysis and artifacts of the system. It includes ensuring an understanding of the requirements, obtaining commitment, managing changes, maintaining bi-directional traceability among the requirements and with the rest of the system definition, and alignment with project resources and schedule. There are many tools available to provide a supporting infrastructure for Requirements Management; the best choice is the one that best matches the processes of the project or enterprise. Requirements Management is also closely tied to Configuration Management for baseline management and control. When the requirements have been defined, documented, and approved, they need to be put under baseline management and control. The baseline allows the project to analyze and understand the impact (technical, cost, and schedule) of ongoing proposed changes.<br />
<br />
====Traceability and assignment of System Requirements during architecture and design====<br />
Requirements traceability provides the ability to trace information from the origin of the Stakeholder Requirements at the top level to requirements and other system definition elements at all levels of the system hierarchy - see section "Top-down and recursive approach to system decomposition" in the [[System Definition]] article. Traceability is also used to provide an understanding of the extent of a change as an input to impact analyses conducted with respect to proposed engineering improvements or requests for change.<br />
<br />
During [[Architecture (glossary) |architecture]] definition and [[Design (glossary) |design]], the assignment of requirements from one level to lower levels in the system hierarchy can be accomplished using several methods, as appropriate - see Table 1.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 1. Assessment Types for a System Requirement.''' (SEBoK Original)<br />
!Assignment Type for a System Requirement<br />
!Description<br />
|-<br />
|'''Direct Assignment'''<br />
|The system requirement from the higher level is directly assigned to a system or a system element for a lower level (for example, the color used to paint visible parts of the product).<br />
|-<br />
|'''Indirect Assignment (Simply Decomposed)'''<br />
|The system requirement is distributed across several systems or system elements and the sum or a more complex calculation for distribution is equal to the requirement of higher level (for example, a mass requirement, power distribution, reliability allocation, etc.) with sufficient margin or tolerance. A documented and configuration-managed "assignment budget" for each assignment must be maintained.<br />
|-<br />
|'''Indirect Assignment (Modeled and Decomposed)'''<br />
|The system requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique, and the resulting design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, a radar detection requirement may be analyzed; lower-level parameters for output power, beam size, frequencies, etc., will then be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.<br />
|-<br />
|'''Derived Requirement (from Design)'''<br />
|Such system requirements are developed during the design activities as a result of decision of the design team, not the stakeholder community. These requirements may include the use of commercial-off-the-shelf (COTS) items, existing systems or system elements in inventory, common components, and similar design decisions in order to produce a "best value" solution for the customer. As such these derived requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or a constraint.<br />
|}<br />
</center><br />
<br />
===Classification of System Requirements===<br />
Several classifications of System Requirements are possible, depending on the requirements definition methods and/or the architecture and design methods used. (ISO/IEC. 2011) provides a classification summarized below – see references for other interesting classifications. An example is given in Table 2.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Example of System Requirements Classification.''' (SEBoK Original)<br />
!Types of System Requirement<br />
!Description<br />
|-<br />
|'''Functional Requirements'''<br />
|Describe qualitatively the system functions or tasks to be performed in operation.<br />
|-<br />
|'''Performance Requirements'''<br />
|Define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task. <br />
|-<br />
|'''Usability Requirements'''<br />
|Define quality in use such as measurable effectiveness, efficiency, and satisfaction criteria.<br />
|-<br />
|'''Interface Requirements'''<br />
|Define how the system is required to interact or to exchange material, energy, or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface requirements include physical connections (physical interfaces) with external systems or internal system elements supporting interactions or exchanges.<br />
|-<br />
|'''Operational Requirements'''<br />
|Define operational conditions or properties under which the system is required to operate or exist. This type of requirement includes human factors and ergonomics, availability, maintainability, reliability, security.<br />
|-<br />
|'''Modes and/or States Requirements'''<br />
|Define the various operational modes of the system in use, and events conducting to transitions of modes.<br />
|-<br />
|'''Adaptability Requirements'''<br />
|Define potential extension, growth, or scalability during the lift of the system.<br />
|-<br />
|'''Physical Constraints'''<br />
|Define constraints on weight, volume, and dimension applicable on system elements that compose the system.<br />
|-<br />
|'''Design Constraints'''<br />
|Define the limits on the options open to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an online repository).<br />
|-<br />
|'''Environmental Conditions'''<br />
|Define the environmental conditions to be encountered by the system in its different operational modes. Should be addressed the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-induced environment (e.g. motion, shock, noise, electromagnetism, thermal, etc.), threats societal environment (e.g. legal, political, economic, social, business, etc.).<br />
|-<br />
|'''Logistical Requirements'''<br />
|Define the logistical conditions needed by the continuous utilization of the system. These requirements include sustainment (provision of facilities, level support, support personnel, spare parts, training, technical documentation, etc.), packaging, handling, shipping, transportation.<br />
|-<br />
|'''Policies and Regulations'''<br />
|Define relevant and applicable organizational policies or regulatory requirements that could affect the operation or performance of the system (e.g. labor policies, reports to regulatory agony, health or safety criteria, etc.).<br />
|-<br />
|'''Cost and Schedule Constraints'''<br />
|Define, for example, the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc.<br />
|}<br />
</center><br />
<br />
==Process Approach – System Requirements==<br />
===Purpose and Principle of the Approach===<br />
The purpose of the system requirements analysis process is to transform the stakeholder, user-oriented view of desired services and properties into a technical view of the product that meets the operational needs of the user. This process builds a representation of the system that will meet Stakeholder Requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable System Requirements that specify, from the supplier’s perspective, what performance and non-performance characteristics it must possess in order to satisfy stakeholders' requirements. (ISO/IEC. 2008)<br />
<br />
===Activities of the process===<br />
Major activities and tasks performed during this process include:<br />
#Analyze the Stakeholder Requirements to check completeness of expected services and [[Operational Scenario (glossary)|Operational Scenarios (glossary)]], conditions, Operational Modes, and constraints.<br />
#Define the System Requirements and its [[Rationale (glossary)]].<br />
#Classify the System Requirements using suggested classifications – see examples above.<br />
#Incorporate the derived requirements (coming from architecture and design) into the System Requirements baseline.<br />
#Establish the upward traceability with the Stakeholder Needs and Requirements. <br />
#Establish birectional traceability between requirements at adjacent levels of the system hierarchy. <br />
#Verify the quality and completeness of each System Requirement and the consistency of the set of System Requirements.<br />
#Validate the content and relevance of each System Requirement against the set of Stakeholder Requirements.<br />
#Identify potential [[Risk (glossary)|Risks (glossary)]] (or threats and hazards) that could be generated by the System Requirements.<br />
#Synthesize, record, and manage the System Requirements and potential associated Risks.<br />
#Upon aproval of the requirements, establish and control baselines along with the other system definition elements in conjunction with established Configuration Management practices.<br />
<br />
===Artifacts and Ontology Elements===<br />
This process may create several artifacts such as:<br />
#System Requirements Document<br />
#System Requirements Justification Document (for traceability purpose)<br />
#System Requirements Database, including traceability, analysis, rationale, decisions, and attributes, where appropriate.<br />
#System External Interface Requirements Document (this document describes the interfaces of the system with external elements of its context of use; the interface requirements can be integrated or not to the System Requirements Document above).<br />
<br />
This process handles the ontology elements of Table 3.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 3. Main Ontology Elements as Handled within System Requirements Definition.''' (SEBoK Original)<br />
!Element<br />
!Definition/Attributes (Examples)<br />
|-<br />
|'''System Requirement'''<br />
|Statement that expresses an expected characteristic or a constraint using a semantic code (such as natural language, mathematical, arithmetic, geometrical expression). A system requirement is feasible, objective, and verifiable.<br />
----<br />
Identifier; name; description; parent (result of a stakeholder requirement translation or of a design choice); type (classification); effectivity (immediately applicable, allocated to a later version, etc.); verification method (inspection, analysis, demonstration, test, etc.); decision (result of a trade-off study having led to choosing or rejecting the requirement); status (identified, analyzed, verified, allocated, satisfied). Criticality (importance related to the safety and the availability of the system); weighing/priority (relative importance compared to others); history records (date, author, identification, and contents of the modification, type of modification, reason for the modification); comments.<br />
|-<br />
|'''Rationale'''<br />
|Argument that provides the justification for the selection of an engineering element.<br />
----<br />
Identifier; name; description (rational, reasons for a requirement to be satisfied).<br />
|-<br />
|'''Scenario'''<br />
|A set of actions/functions representing the dynamic of exchanges between the functions allowing the system to achieve a mission or a service.<br />
----<br />
Identifier; name; description.<br />
|-<br />
|'''Risk'''<br />
|An event having a probability of occurrence and gravity degree on its consequence onto the system mission or on other characteristics (used for technical risk in engineering). A risk is the combination of vulnerability and of a danger or a threat.<br />
----<br />
Identifier; name; description; status.<br />
|}<br />
</center><br />
<br />
===Checking and Correctness of System Requirements===<br />
System Requirements should be checked to gauge whether they are well expressed and appropriate. There are number of characteristics which can be used to check System Requirements. The set of System Requirements can be verified using standard peer review techniques and by comparing each requirement against the set of requirements characteristics listed in Table 2 and Table 3 of section "Presentation and Quality of Requirements".<br />
<br />
The requirements can be further validated using the requirements elicitation and rationale capture described in section "Methods and Modeling Techniques."<br />
<br />
===Methods and Modeling Techniques===<br />
====Requirements Elicitation and Prototyping====<br />
Requirements Elicitation requires user involvement, and can be effective in gaining stakeholder involvement and buy-in. QFD (Quality Function Deployment) and prototyping are two common techniques that can be applied and are defined in this section. In addition, interviews, focus groups, and Delphi techniques are often applied to elicit requirements.<br />
<br />
QFD is a powerful technique to elicit requirements and compare design characteristics against user needs (Hauser and Clausing, 1988). The inputs to the QFD application are user needs and operational concepts, so it is essential that the users participate. Users from across the life cycle should be included so that all aspects of user needs are accounted for and prioritized.<br />
<br />
Early prototyping can help the users and developers interactively identify functional and operational requirements and user interface constraints. The prototyping allows for realistic user interaction, discovery, and feedback, as well as some sensitivity analysis. This improves the user's understanding of the requirements and increases the probability of satisfying their actual needs.<br />
<br />
====Capturing Requirements Rationale====<br />
One powerful and cost-effective technique to translate Stakeholder Requirements to System Requirements is to capture the rationale for each requirement. Requirements rationale is merely a statement as to why the requirement exists, any assumptions made, the results of related design studies, or any other related supporting information. This supports further requirements analysis and decomposition. The rationale can be captured directly in the requirements database. (Hull, M. E. C., Jackson, K., Dick, A. J. J. 2010).<br />
<br />
Some of the benefits include:<br />
*'''Reducing the total number of requirements'''. The process aids in identifying duplicates. Reducing requirements count will reduce project cost and risk.<br />
*'''Early exposure of bad assumptions'''. <br />
*'''Removes design implementation'''. Many poorly written stakeholder requirements are design requirements in disguise, in that the customer is intentionally or unintentionally specifying a candidate implementation. <br />
*'''Improves communication with the stakeholder community'''. By capturing the requirements rationale for all Stakeholders Requirements, the line of communication between the users and the designers is greatly improved. Adapted from (Hooks, I. F., and K. A. Farry. 2000) Chapter 8.<br />
<br />
====Modeling Techniques====<br />
Modeling techniques that can be used when requirements must be detailed or refined, or when they address topics not considered during the Stakeholder Requirements Definition and Mission Analysis include:<br />
*State-charts models (ISO/IEC. 2011) Section 8.4.2<br />
*Scenarios modeling (ISO/IEC. 2011) Section 6.2.3.1<br />
*Simulations, prototyping (ISO/IEC. 2011) Section 6.3.3.2<br />
*Quality Function Deployment (INCOSE. 2010) p. 83<br />
*Sequence diagram, Activity diagram, Use case, State machine diagram, Requirements diagram of [[Acronyms|SysML]]<br />
*Functional Flow Block Diagram for Operational Scenario<br />
<br />
====Presentation and Quality of Requirements====<br />
Generally, requirements are provided in a textual form. Guidelines exist for writing good requirements; they include recommendations about syntax of requirements statements, wording (exclusions, representation of concepts, etc.), characteristics(specific, measurable, achievable, feasible, testable, etc.). Refer to (INCOSE. 2010) section 4.2.2.2 and (ISO/IEC. 2011).<br />
<br />
There are several characteristics of requirements and sets of requirements that ensure the quality of requirements. These are used both to aid the development of the requirements and to verify the implementation of requirements into the solution. Table 4 provides a list and descriptions of the characteristics for individual requirements and Table 5 provides a list and descriptions of characteristics for a set of requirements, as adapted from (ISO/IEC. 2011) sections 5.2.5 and 5.2.6.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 4. Characteristics of Individual Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Necessary'''<br />
|The requirement defines an essential capability, characteristic, constant, and/or quality factor. If it is removed or deleted, a deficiency will exist, which cannot be fulfilled by other capabilities of the product or process.<br />
|-<br />
|'''Implementation Free'''<br />
|The requirement, while addressing what is necessary and sufficient in the system, avoids placing unnecessary constraints on the architectural design. The objective is to be implementation-independent. The requirement states what is required, not how the requirement should be met.<br />
|-<br />
|'''Unambiguous'''<br />
|The requirement is stated in such a way so that it can be interpreted in only one way. The requirement is stated simply and is easy to understand.<br />
|-<br />
|'''Consistent'''<br />
|The requirement is free of conflicts with other requirements.<br />
|-<br />
|'''Complete'''<br />
|The stated requirement needs no further amplification because it is measurable and sufficiently describes the capability and characteristics to meet the stakeholders' needs.<br />
|-<br />
|'''Singular'''<br />
|The requirement statement includes only one requirement with no use of conjunctions.<br />
|-<br />
|'''Feasible'''<br />
|The requirement is technically achievable and fits within system constraints (e.g., cost, schedule, technical, lethal, regulatory).<br />
|-<br />
|'''Traceable'''<br />
|The requirement is upwards traceable to specific documented stakeholder statement(s) of need, higher tier requirement, or other source (e.g., a trade or design study). The requirement is also downwards traceable to the specific requirements in the lower tier requirements specification or other system definition artifacts. That is, all parent-child relationships for the requirement are identified in tracing such that the requirement traces to its source and implementation.<br />
|-<br />
|'''Verifiable'''<br />
|The requirement has the means to prove that the system satisfies the specified requirement. Verifiability is enhanced when the requirement is measurable.<br />
|}<br />
</center><br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 5. Characteristics of a Set of Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Complete'''<br />
|The set of requirements needs no further amplification because it contains everything pertinent to the definition of the system or system element being specified. In addition, the set contains no to be defined (TBD), to be specified (TBS), or to be resolved (TBR) clauses. Resolution of the TBx designations may be iterative and there is an acceptable timeframe for TBx items, determined by risks and dependencies. Note: Some practices are recommended to improve completeness; include all requirement types; account for requirements in all stages of the life cycle; and involve all stakeholders in the requirements elicitation activity.<br />
|-<br />
|'''Consistent'''<br />
|The set of requirements does not have individual requirements which are contradictory. Requirements are not duplicate. The same term is used for the same item in all requirements.<br />
|-<br />
|'''Affordable'''<br />
|The complete set of requirements can be satisfied by a solution that is obtainable/feasible within life cycle constraints (e.g. cost, schedule, technical, legal, regulatory).<br />
|-<br />
|'''Bounded'''<br />
|The set of requirements maintains the identified scope for the intended solution without increasing beyond what is needed to satisfy user needs.<br />
|}<br />
</center><br />
<br />
====Requirements in Tables====<br />
Requirements may be provided in a table, especially when specifying a set of parameters for the system or a system element. It is good practice to make standard table templates available. For tables, the following conventions apply: <br />
*Invoke each requirements table in the requirements set that clearly points to the table.<br />
*Identify each table with a unique title and table number.<br />
*Include the word “requirements” in the table title.<br />
*Identify the purpose of the table in the text immediately preceding it and include an explanation of how to read and use the table, including context and units.<br />
*For independent-dependant variable situations, organize the table in a way that best accommodates the use of the information.<br />
*Each cell should contain, at most, a single requirement.<br />
<br />
====Requirements in Flow Charts====<br />
Flow charts often contain requirements in a graphical form. These requirements may include logic that must be incorporated into the system, operational requirements, process or procedural requirements, or other situations that are best defined graphically by a sequence of interrelated steps. For flow charts, the following conventions apply:<br />
*Invoke flow charts in the requirements set that clearly points to the flow chart.<br />
*Identify each flow chart with a unique title and figure number.<br />
*Include the word “requirements” in the title of the flow chart<br />
*Clearly indicate and explain unique symbols that represent requirements in the flow chart.<br />
<br />
====Requirements in Drawings====<br />
Drawings also provide a graphical means to define requirements. The type of requirement defined in a drawing depends on the type of drawing. Following conventions apply:<br />
*Drawings are used when they can aid in the description of the following:<br />
** Spatial requirements<br />
**Interface requirements<br />
**Layout requirements<br />
*Invoke drawings in the requirements set that clearly points to the drawing.<br />
<br />
<br />
<br />
==Practical Considerations about System Requirements==<br />
There are several '''pitfalls''' that will inhibit the generation and management of an optimal set of System Requirements. See Table 6.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 6. Major Pitfalls with Definition of System Requirements.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|'''Insufficient analysis of stakeholder requirements'''<br />
|The receivers of the stakeholder requirements do not perform a sufficient critical analysis of them; the consequence could be difficulties translating them into system requirements and the obligation to come back to the stakeholders, losing time.<br />
|-<br />
|'''Insufficient analysis of operational modes and scenarios'''<br />
|The operational modes and operational scenarios are not sufficiently analyzed or defined by the person in charge of writing the system requirements. Those elements allow the structuring of the system and its use early in the engineering and help the designer to remember functions and interfaces.<br />
|-<br />
|'''Uncompleted set of system requirements'''<br />
|If the system requirements are not sufficiently precise and complete, there is a great risk that the design will not have the expected level of quality and that the verification and validation of the system will be delayed.<br />
|-<br />
|'''Lack of verification method'''<br />
|Delaying the capture of verification methods and events for each system requirement; identification of the verification approach for each requirement often provides additional insight as to the correctness and necessity of the requirement itself.<br />
|-<br />
|'''Missing traceability'''<br />
|Incorrect or missing traceability of each requirement, both to an upper-level "parent" requirement and allocation to an appropriate system or system element.<br />
|}<br />
</center><br />
<br />
<br />
The following '''proven practices''' in system requirements engineering have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development. See Table 7.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 7. Proven Practices with Definition of System Requirements.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|+<br />
|'''Involve stakeholders'''<br />
|Involve the stakeholders early in the system requirements development process.<br />
|+<br />
|'''Presence of rationale'''<br />
|Capture the rationale for each system requirement.<br />
|+<br />
|'''Always before starting'''<br />
|Check that stakeholder requirements are complete as much as possible before starting the definition of the system requirements.<br />
|+<br />
|'''Peer reviews'''<br />
|Organize peer reviews of system requirements with applicable subject matter experts.<br />
|+<br />
|'''Modeling techniques'''<br />
|Use modeling techniques as indicated in sections above.<br />
|+<br />
|'''Requirements management tool'''<br />
|Consider using a requirements management tool, especially for more complex projects. This tool should have the capability to trace linkages between system requirements to show relationships. A requirements management tool is intended to facilitate and support the systematic managing of system requirements throughout the project life cycle.<br />
|+<br />
|'''Measures for requirement engineering'''<br />
|Use typical measures for requirement engineering - refer to the ''Systems Engineering Leading Indicators Guide'' (Roedler et al. 2010). Both process and product measures should be used for requirements engineering. To get the desired insight to facilitate risk-managed requirements engineering, it may be necessary to use more than one measure based on the information needs (risks, objectives, issues) for the requirements. Useful measures include:<br />
*Requirements volatility<br />
*Requirements trends<br />
*Requirements verification progress (plan vs. actual)<br />
*Requirements validation progress (plan vs. actual)<br />
*TBD and TBR closure per plan<br />
*Peer review defects<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Hauser, J. and D. Clausing. 1988. "The House of Quality." ''Harvard Business Review.'' (May - June 1988). <br />
<br />
Hooks, I. F., and K. A. Farry. 2000. ''Customer-centered products: Creating successful products through smart requirements management''. New York, NY, USA: American Management Association.<br />
<br />
Hull, M. E. C., Jackson, K., Dick, A. J. J. 2010. ''Systems Engineering''. 3rd ed. London, UK: Springer.<br />
<br />
INCOSE. 2011. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities'' Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
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. <br />
<br />
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).<br />
<br />
===Primary References===<br />
<br />
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]].<br />
<br />
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).<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com. <br />
<br />
Hooks, I.F., and K.A. Farry. 2000. ''Customer-Centered Products: Creating Successful Products through Smart Requirements Management.'' New York, NY, USA: American Management Association. <br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering''. 3rd ed. London, UK: Springer.<br />
<br />
Roedler, G., D. Rhodes, C. Jones, and H. Schimmoller. 2010. ''Systems Engineering Leading Indicators Guide''. Version 2.0. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2005-001-03.<br />
----<br />
<br />
<center>[[System Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Architectural Design: Logical|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Stakeholder_Requirements_Definition&diff=38125Stakeholder Requirements Definition2012-08-07T02:30:12Z<p>Groedler: /* Activities of the process */</p>
<hr />
<div><br />
The System requirements are all of the [[Requirement (glossary)|requirements]] at the “system level” that have been properly translated from the list of stakeholders' requirements. The System Requirements form the basis of System [[Architecture (glossary)| Architecture]] and [[Design (glossary) |Design]], verification, validation, and stakeholder acceptance. <br />
<br />
System Requirements play major roles in the engineering activities. They serve:<br />
*as the essential inputs of the System Architecture and Design activities.<br />
*as reference for the System Validation activities.<br />
*as a communication means, between the various technical staff that interact within the project.<br />
<br />
==Principles Governing System Requirements==<br />
===Origin in Stakeholder Requirements===<br />
The set of Stakeholder Requirements may contain vague, ambiguous, and qualitative “user-oriented” need statements that are difficult to use for design or to verify. Each of these requirements may need to be further clarified and translated into “engineering-oriented” language to enable proper architecture definition, design and verification activities. The System Requirements resulting from this translation are expressed in technical language useful for architecture and design; unambiguous, consistent, coherent, exhaustive, and verifiable. Of course, close coordination with the stakeholders is necessary to ensure the translation is accurate.<br />
<br />
As an example, a need or an expectation such as "To easily maneuver a car to park it," will be transformed in a set of Stakeholder Requirements such as, "Increase the drivability of the car", "Decrease the effort for handling", "Assist the piloting", "Protect the coachwork against shocks or scratch", etc. Translating, for example, the Stakeholder Requirement "Increase the drivability of the car", results in a set of System Requirements specifying measurable characteristics such as the turning circle (steering lock), the wheelbase, etc.<br />
<br />
===Traceability and assignment of System Requirements during architecture and design===<br />
Requirements traceability provides the ability to trace information from the origin of the Stakeholder Requirements at the top level to the lowest level of the system hierarchy - see section "Top-down and recursive approach to system decomposition" in the [[System Definition]] article. Traceability is also used to provide an understanding of the extent of a change as an input to impact analyses conducted with respect to proposed engineering improvements or requests for change.<br />
<br />
During [[Architecture (glossary) |architecture]] definition and [[Design (glossary) |design]], the assignment of requirements from one level to lower levels in the system hierarchy can be accomplished using several methods, as appropriate - see Table 1.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 1. Assessment Types for a System Requirement.''' (SEBoK Original)<br />
!Assignment Type for a System Requirement<br />
!Description<br />
|-<br />
|'''Direct Assignment'''<br />
|The system requirement from the higher level is directly assigned to a system or a system element for a lower level (for example, the color used to paint visible parts of the product).<br />
|-<br />
|'''Indirect Assignment (Simply Decomposed)'''<br />
|The system requirement is distributed across several systems or system elements and the sum or a more complex calculation for distribution is equal to the requirement of higher level (for example, a mass requirement, power distribution, reliability allocation, etc.) with sufficient margin or tolerance. A documented and configuration-managed "assignment budget" for each assignment must be maintained.<br />
|-<br />
|'''Indirect Assignment (Modeled and Decomposed)'''<br />
|The system requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique, and the resulting design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, a radar detection requirement may be analyzed; lower-level parameters for output power, beam size, frequencies, etc., will then be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.<br />
|-<br />
|'''Derived Requirement (from Design)'''<br />
|Such system requirements are developed during the design activities as a result of decision of the design team, not the stakeholder community. These requirements may include the use of commercial-off-the-shelf (COTS) items, existing systems or system elements in inventory, common components, and similar design decisions in order to produce a "best value" solution for the customer. As such these derived requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or a constraint.<br />
|}<br />
</center><br />
<br />
===Classification of System Requirements===<br />
Several classifications of System Requirements are possible, depending on the requirements definition methods and/or the architecture and design methods used. (ISO/IEC. 2011) provides a classification summarized below – see references for other interesting classifications. An example is given in Table 2.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Example of System Requirements Classification.''' (SEBoK Original)<br />
!Types of System Requirement<br />
!Description<br />
|-<br />
|'''Functional Requirements'''<br />
|Describe qualitatively the system functions or tasks to be performed in operation.<br />
|-<br />
|'''Performance Requirements'''<br />
|Define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task. <br />
|-<br />
|'''Usability Requirements'''<br />
|Define quality in use such as measurable effectiveness, efficiency, and satisfaction criteria.<br />
|-<br />
|'''Interface Requirements'''<br />
|Define how the system is required to interact or to exchange material, energy, or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface requirements include physical connections (physical interfaces) with external systems or internal system elements supporting interactions or exchanges.<br />
|-<br />
|'''Operational Requirements'''<br />
|Define operational conditions or properties under which the system is required to operate or exist. This type of requirement includes human factors and ergonomics, availability, maintainability, reliability, security.<br />
|-<br />
|'''Modes and/or States Requirements'''<br />
|Define the various operational modes of the system in use, and events conducting to transitions of modes.<br />
|-<br />
|'''Adaptability Requirements'''<br />
|Define potential extension, growth, or scalability during the lift of the system.<br />
|-<br />
|'''Physical Constraints'''<br />
|Define constraints on weight, volume, and dimension applicable on system elements that compose the system.<br />
|-<br />
|'''Design Constraints'''<br />
|Define the limits on the options open to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an online repository).<br />
|-<br />
|'''Environmental Conditions'''<br />
|Define the environmental conditions to be encountered by the system in its different operational modes. Should be addressed the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-induced environment (e.g. motion, shock, noise, electromagnetism, thermal, etc.), threats societal environment (e.g. legal, political, economic, social, business, etc.).<br />
|-<br />
|'''Logistical Requirements'''<br />
|Define the logistical conditions needed by the continuous utilization of the system. These requirements include sustainment (provision of facilities, level support, support personnel, spare parts, training, technical documentation, etc.), packaging, handling, shipping, transportation.<br />
|-<br />
|'''Policies and Regulations'''<br />
|Define relevant and applicable organizational policies or regulatory requirements that could affect the operation or performance of the system (e.g. labor policies, reports to regulatory agony, health or safety criteria, etc.).<br />
|-<br />
|'''Cost and Schedule Constraints'''<br />
|Define, for example, the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc.<br />
|}<br />
</center><br />
<br />
==Process Approach – System Requirements==<br />
===Purpose and Principle of the Approach===<br />
The purpose of the system requirements analysis process is to transform the stakeholder, user-oriented view of desired services and properties into a technical view of the product that meets the operational needs of the user. This process builds a representation of the system that will meet Stakeholder Requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable System Requirements that specify, from the supplier’s perspective, what performance and non-performance characteristics it must possess in order to satisfy stakeholders' requirements. (ISO/IEC. 2008)<br />
<br />
===Activities of the process===<br />
Major activities and tasks performed during this process include:<br />
#Analyze the Stakeholder Requirements to check completeness of expected services and [[Operational Scenario (glossary)|Operational Scenarios (glossary)]], conditions, Operational Modes, and constraints.<br />
#Define the System Requirements and its [[Rationale (glossary)]].<br />
#Classify the System Requirements using suggested classifications – see examples above.<br />
#Incorporate the derived requirements (coming from architecture and design) into the System Requirements baseline.<br />
#Establish the upward traceability with the Stakeholder Needs and Requirements. <br />
#Establish birectional traceability between requirements at adjacent levels of the system hierarchy. <br />
#Verify the quality and completeness of each System Requirement and the consistency of the set of System Requirements.<br />
#Validate the content and relevance of each System Requirement against the set of Stakeholder Requirements.<br />
#Identify potential [[Risk (glossary)|Risks (glossary)]] (or threats and hazards) that could be generated by the System Requirements.<br />
#Synthesize, record, and manage the System Requirements and potential associated Risks.<br />
#Upon aproval of the requirements, establish and control baselines along with the other system definition elements in conjunction with established Configuration Management practices.<br />
<br />
===Artifacts and Ontology Elements===<br />
This process may create several artifacts such as:<br />
#System Requirements Document<br />
#System Requirements Justification Document (for traceability purpose)<br />
#System Requirements Database, including traceability, analysis, rationale, decisions, and attributes, where appropriate.<br />
#System External Interface Requirements Document (this document describes the interfaces of the system with external elements of its context of use; the interface requirements can be integrated or not to the System Requirements Document above).<br />
<br />
This process handles the ontology elements of Table 3.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 3. Main Ontology Elements as Handled within System Requirements Definition.''' (SEBoK Original)<br />
!Element<br />
!Definition/Attributes (Examples)<br />
|-<br />
|'''System Requirement'''<br />
|Statement that expresses an expected characteristic or a constraint using a semantic code (such as natural language, mathematical, arithmetic, geometrical expression). A system requirement is feasible, objective, and verifiable.<br />
----<br />
Identifier; name; description; parent (result of a stakeholder requirement translation or of a design choice); type (classification); effectivity (immediately applicable, allocated to a later version, etc.); verification method (inspection, analysis, demonstration, test, etc.); decision (result of a trade-off study having led to choosing or rejecting the requirement); status (identified, analyzed, verified, allocated, satisfied). Criticality (importance related to the safety and the availability of the system); weighing/priority (relative importance compared to others); history records (date, author, identification, and contents of the modification, type of modification, reason for the modification); comments.<br />
|-<br />
|'''Rationale'''<br />
|Argument that provides the justification for the selection of an engineering element.<br />
----<br />
Identifier; name; description (rational, reasons for a requirement to be satisfied).<br />
|-<br />
|'''Scenario'''<br />
|A set of actions/functions representing the dynamic of exchanges between the functions allowing the system to achieve a mission or a service.<br />
----<br />
Identifier; name; description.<br />
|-<br />
|'''Risk'''<br />
|An event having a probability of occurrence and gravity degree on its consequence onto the system mission or on other characteristics (used for technical risk in engineering). A risk is the combination of vulnerability and of a danger or a threat.<br />
----<br />
Identifier; name; description; status.<br />
|}<br />
</center><br />
<br />
===Checking and Correctness of System Requirements===<br />
System Requirements should be checked to gauge whether they are well expressed and appropriate. There are number of characteristics which can be used to check System Requirements. The set of System Requirements can be verified using standard peer review techniques and by comparing each requirement against the set of requirements characteristics listed in Table 2 and Table 3 of section "Presentation and Quality of Requirements".<br />
<br />
The requirements can be further validated using the requirements elicitation and rationale capture described in section "Methods and Modeling Techniques."<br />
<br />
===Methods and Modeling Techniques===<br />
====Requirements Elicitation and Prototyping====<br />
Requirements Elicitation requires user involvement, and can be effective in gaining stakeholder involvement and buy-in. QFD (Quality Function Deployment) and prototyping are two common techniques that can be applied and are defined in this section. In addition, interviews, focus groups, and Delphi techniques are often applied to elicit requirements.<br />
<br />
QFD is a powerful technique to elicit requirements and compare design characteristics against user needs (Hauser and Clausing, 1988). The inputs to the QFD application are user needs and operational concepts, so it is essential that the users participate. Users from across the life cycle should be included so that all aspects of user needs are accounted for and prioritized.<br />
<br />
Early prototyping can help the users and developers interactively identify functional and operational requirements and user interface constraints. The prototyping allows for realistic user interaction, discovery, and feedback, as well as some sensitivity analysis. This improves the user's understanding of the requirements and increases the probability of satisfying their actual needs.<br />
<br />
====Capturing Requirements Rationale====<br />
One powerful and cost-effective technique to translate Stakeholder Requirements to System Requirements is to capture the rationale for each requirement. Requirements rationale is merely a statement as to why the requirement exists, any assumptions made, the results of related design studies, or any other related supporting information. This supports further requirements analysis and decomposition. The rationale can be captured directly in the requirements database. (Hull, M. E. C., Jackson, K., Dick, A. J. J. 2010).<br />
<br />
Some of the benefits include:<br />
*'''Reducing the total number of requirements'''. The process aids in identifying duplicates. Reducing requirements count will reduce project cost and risk.<br />
*'''Early exposure of bad assumptions'''. <br />
*'''Removes design implementation'''. Many poorly written stakeholder requirements are design requirements in disguise, in that the customer is intentionally or unintentionally specifying a candidate implementation. <br />
*'''Improves communication with the stakeholder community'''. By capturing the requirements rationale for all Stakeholders Requirements, the line of communication between the users and the designers is greatly improved. Adapted from (Hooks, I. F., and K. A. Farry. 2000) Chapter 8.<br />
<br />
====Modeling Techniques====<br />
Modeling techniques that can be used when requirements must be detailed or refined, or when they address topics not considered during the Stakeholder Requirements Definition and Mission Analysis include:<br />
*State-charts models (ISO/IEC. 2011) Section 8.4.2<br />
*Scenarios modeling (ISO/IEC. 2011) Section 6.2.3.1<br />
*Simulations, prototyping (ISO/IEC. 2011) Section 6.3.3.2<br />
*Quality Function Deployment (INCOSE. 2010) p. 83<br />
*Sequence diagram, Activity diagram, Use case, State machine diagram, Requirements diagram of [[Acronyms|SysML]]<br />
*Functional Flow Block Diagram for Operational Scenario<br />
<br />
====Presentation and Quality of Requirements====<br />
Generally, requirements are provided in a textual form. Guidelines exist for writing good requirements; they include recommendations about syntax of requirements statements, wording (exclusions, representation of concepts, etc.), characteristics(specific, measurable, achievable, feasible, testable, etc.). Refer to (INCOSE. 2010) section 4.2.2.2 and (ISO/IEC. 2011).<br />
<br />
There are several characteristics of requirements and sets of requirements that ensure the quality of requirements. These are used both to aid the development of the requirements and to verify the implementation of requirements into the solution. Table 4 provides a list and descriptions of the characteristics for individual requirements and Table 5 provides a list and descriptions of characteristics for a set of requirements, as adapted from (ISO/IEC. 2011) sections 5.2.5 and 5.2.6.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 4. Characteristics of Individual Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Necessary'''<br />
|The requirement defines an essential capability, characteristic, constant, and/or quality factor. If it is removed or deleted, a deficiency will exist, which cannot be fulfilled by other capabilities of the product or process.<br />
|-<br />
|'''Implementation Free'''<br />
|The requirement, while addressing what is necessary and sufficient in the system, avoids placing unnecessary constraints on the architectural design. The objective is to be implementation-independent. The requirement states what is required, not how the requirement should be met.<br />
|-<br />
|'''Unambiguous'''<br />
|The requirement is stated in such a way so that it can be interpreted in only one way. The requirement is stated simply and is easy to understand.<br />
|-<br />
|'''Consistent'''<br />
|The requirement is free of conflicts with other requirements.<br />
|-<br />
|'''Complete'''<br />
|The stated requirement needs no further amplification because it is measurable and sufficiently describes the capability and characteristics to meet the stakeholders' needs.<br />
|-<br />
|'''Singular'''<br />
|The requirement statement includes only one requirement with no use of conjunctions.<br />
|-<br />
|'''Feasible'''<br />
|The requirement is technically achievable and fits within system constraints (e.g., cost, schedule, technical, lethal, regulatory).<br />
|-<br />
|'''Traceable'''<br />
|The requirement is upwards traceable to specific documented stakeholder statement(s) of need, higher tier requirement, or other source (e.g., a trade or design study). The requirement is also downwards traceable to the specific requirements in the lower tier requirements specification or other system definition artifacts. That is, all parent-child relationships for the requirement are identified in tracing such that the requirement traces to its source and implementation.<br />
|-<br />
|'''Verifiable'''<br />
|The requirement has the means to prove that the system satisfies the specified requirement. Verifiability is enhanced when the requirement is measurable.<br />
|}<br />
</center><br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 5. Characteristics of a Set of Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Complete'''<br />
|The set of requirements needs no further amplification because it contains everything pertinent to the definition of the system or system element being specified. In addition, the set contains no to be defined (TBD), to be specified (TBS), or to be resolved (TBR) clauses. Resolution of the TBx designations may be iterative and there is an acceptable timeframe for TBx items, determined by risks and dependencies. Note: Some practices are recommended to improve completeness; include all requirement types; account for requirements in all stages of the life cycle; and involve all stakeholders in the requirements elicitation activity.<br />
|-<br />
|'''Consistent'''<br />
|The set of requirements does not have individual requirements which are contradictory. Requirements are not duplicate. The same term is used for the same item in all requirements.<br />
|-<br />
|'''Affordable'''<br />
|The complete set of requirements can be satisfied by a solution that is obtainable/feasible within life cycle constraints (e.g. cost, schedule, technical, legal, regulatory).<br />
|-<br />
|'''Bounded'''<br />
|The set of requirements maintains the identified scope for the intended solution without increasing beyond what is needed to satisfy user needs.<br />
|}<br />
</center><br />
<br />
====Requirements in Tables====<br />
Requirements may be provided in a table, especially when specifying a set of parameters for the system or a system element. It is good practice to make standard table templates available. For tables, the following conventions apply: <br />
*Invoke each requirements table in the requirements set that clearly points to the table.<br />
*Identify each table with a unique title and table number.<br />
*Include the word “requirements” in the table title.<br />
*Identify the purpose of the table in the text immediately preceding it and include an explanation of how to read and use the table, including context and units.<br />
*For independent-dependant variable situations, organize the table in a way that best accommodates the use of the information.<br />
*Each cell should contain, at most, a single requirement.<br />
<br />
====Requirements in Flow Charts====<br />
Flow charts often contain requirements in a graphical form. These requirements may include logic that must be incorporated into the system, operational requirements, process or procedural requirements, or other situations that are best defined graphically by a sequence of interrelated steps. For flow charts, the following conventions apply:<br />
*Invoke flow charts in the requirements set that clearly points to the flow chart.<br />
*Identify each flow chart with a unique title and figure number.<br />
*Include the word “requirements” in the title of the flow chart<br />
*Clearly indicate and explain unique symbols that represent requirements in the flow chart.<br />
<br />
====Requirements in Drawings====<br />
Drawings also provide a graphical means to define requirements. The type of requirement defined in a drawing depends on the type of drawing. Following conventions apply:<br />
*Drawings are used when they can aid in the description of the following:<br />
** Spatial requirements<br />
**Interface requirements<br />
**Layout requirements<br />
*Invoke drawings in the requirements set that clearly points to the drawing.<br />
<br />
<br />
<br />
==Practical Considerations about System Requirements==<br />
There are several '''pitfalls''' that will inhibit the generation and management of an optimal set of System Requirements. See Table 6.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 6. Major Pitfalls with Definition of System Requirements.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|'''Insufficient analysis of stakeholder requirements'''<br />
|The receivers of the stakeholder requirements do not perform a sufficient critical analysis of them; the consequence could be difficulties translating them into system requirements and the obligation to come back to the stakeholders, losing time.<br />
|-<br />
|'''Insufficient analysis of operational modes and scenarios'''<br />
|The operational modes and operational scenarios are not sufficiently analyzed or defined by the person in charge of writing the system requirements. Those elements allow the structuring of the system and its use early in the engineering and help the designer to remember functions and interfaces.<br />
|-<br />
|'''Uncompleted set of system requirements'''<br />
|If the system requirements are not sufficiently precise and complete, there is a great risk that the design will not have the expected level of quality and that the verification and validation of the system will be delayed.<br />
|-<br />
|'''Lack of verification method'''<br />
|Delaying the capture of verification methods and events for each system requirement; identification of the verification approach for each requirement often provides additional insight as to the correctness and necessity of the requirement itself.<br />
|-<br />
|'''Missing traceability'''<br />
|Incorrect or missing traceability of each requirement, both to an upper-level "parent" requirement and allocation to an appropriate system or system element.<br />
|}<br />
</center><br />
<br />
<br />
The following '''proven practices''' in system requirements engineering have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development. See Table 7.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 7. Proven Practices with Definition of System Requirements.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|+<br />
|'''Involve stakeholders'''<br />
|Involve the stakeholders early in the system requirements development process.<br />
|+<br />
|'''Presence of rationale'''<br />
|Capture the rationale for each system requirement.<br />
|+<br />
|'''Always before starting'''<br />
|Check that stakeholder requirements are complete as much as possible before starting the definition of the system requirements.<br />
|+<br />
|'''Peer reviews'''<br />
|Organize peer reviews of system requirements with applicable subject matter experts.<br />
|+<br />
|'''Modeling techniques'''<br />
|Use modeling techniques as indicated in sections above.<br />
|+<br />
|'''Requirements management tool'''<br />
|Consider using a requirements management tool, especially for more complex projects. This tool should have the capability to trace linkages between system requirements to show relationships. A requirements management tool is intended to facilitate and support the systematic managing of system requirements throughout the project life cycle.<br />
|+<br />
|'''Measures for requirement engineering'''<br />
|Use typical measures for requirement engineering - refer to the ''Systems Engineering Leading Indicators Guide'' (Roedler et al. 2010). Both process and product measures should be used for requirements engineering. To get the desired insight to facilitate risk-managed requirements engineering, it may be necessary to use more than one measure based on the information needs (risks, objectives, issues) for the requirements. Useful measures include:<br />
*Requirements volatility<br />
*Requirements trends<br />
*Requirements verification progress (plan vs. actual)<br />
*Requirements validation progress (plan vs. actual)<br />
*TBD and TBR closure per plan<br />
*Peer review defects<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Hauser, J. and D. Clausing. 1988. "The House of Quality." ''Harvard Business Review.'' (May - June 1988). <br />
<br />
Hooks, I. F., and K. A. Farry. 2000. ''Customer-centered products: Creating successful products through smart requirements management''. New York, NY, USA: American Management Association.<br />
<br />
Hull, M. E. C., Jackson, K., Dick, A. J. J. 2010. ''Systems Engineering''. 3rd ed. London, UK: Springer.<br />
<br />
INCOSE. 2011. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities'' Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
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. <br />
<br />
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).<br />
<br />
===Primary References===<br />
<br />
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]].<br />
<br />
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).<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com. <br />
<br />
Hooks, I.F., and K.A. Farry. 2000. ''Customer-Centered Products: Creating Successful Products through Smart Requirements Management.'' New York, NY, USA: American Management Association. <br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering''. 3rd ed. London, UK: Springer.<br />
<br />
Roedler, G., D. Rhodes, C. Jones, and H. Schimmoller. 2010. ''Systems Engineering Leading Indicators Guide''. Version 2.0. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2005-001-03.<br />
----<br />
<br />
<center>[[System Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Architectural Design: Logical|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_and_Mission_Analysis&diff=38124Business and Mission Analysis2012-08-07T02:11:15Z<p>Groedler: /* Drivers of Solutions: Push versus Pull */</p>
<hr />
<div>Concept definition is the set of systems engineering activities in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the [[System of Interest (SoI) (glossary)]] is developed. [[Mission Analysis]] focuses on defining the problem or opportunity that exists (often called the problem space), as well as understanding the constraints on and boundaries of the solution space. [[Stakeholder Needs and Requirements]] explores and defines the operational aspects of a potential solution for the stakeholders from their pointof view, independent of any specific solution.<br />
<br />
Mission analysis examines ''why'' a solution is desired; what problem or opportunity it will address. Stakeholder needs and requirements describe ''what'' a solution should accomplish. Both ''why'' and ''what'' need to be answered before any consideration of ''how'' the problem will be addressed (i.e., what type of solution) and ''how'' the solution will be defined and developed. If the chosen solution is a new or modified system, then [[System Definition]] activities are performed to define the system. <br />
<br />
Various authors use different terms to describe these phases. For example, Kossiakoff and Sweet (2005) call them ''needs analysis'' and ''concept exploration.''<br />
<br />
To download a PDF of all of Part 3 (including this knowledge area), please [http://www.sebokwiki.org/075/images/0/07/SEBoK075_Part3.pdf click here].<br />
<br />
==Topics==<br />
The topics contained within this knowledge area include:<br />
*[[Mission Analysis]]<br />
*[[Stakeholder Needs and Requirements]]<br />
<br />
==Concept Definition Activities==<br />
There are two primary activities discussed under concept definition: [[Mission Analysis|mission analysis]] and the definition of [[Stakeholder Needs and Requirements|stakeholder needs and requirements]]:<br />
<br />
*[[Mission Analysis]] initiates the life cycle of a potential [[System of Interest (SoI) (glossary)|system of interest (SoI)]] that could solve a problem or realize an opportunity for developing a new product, service or enterprise. These activities define the problem space, identify the stakeholders, develop preliminary operational concepts, and identify environmental conditions and constraints that bound the solution space.<br />
*[[Stakeholder Needs and Requirements]] works with the stakeholders across the life cycle to elicit and capture a set of needs, expectations, goals, or objectives of a desired solution to the problem or opportunity, called Stakeholder Needs. The stakeholder needs are used to produce a clear, concise, and verifiable set of stakeholder requirements.<br />
<br />
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. Stakeholder Needs and Requirements identifies and defines the needs and requirements of the stakeholders in a manner that enables characterizing the solution alternatives. MA then takes the set of needs and requirements and carries the analysis down to the point that the needs and requirements have been transitioned from problem space to solution space including concept, requirement (stakeholder/mission) and boundary or context so that a solution concept (black box level) can be selected from the alternatives. Figure 1 in the [[Mission Analysis|mission analysis]] topic depicts this interaction. The products and artifacts produced during concept definition are then used in [[System Definition]].<br />
<br />
===Top-Down Approach: from Problem to Solution===<br />
<br />
In a top-down approach, [[Concept Definition|concept definition]] activities are focused primarily on understanding the problem, the operational needs/requirements within the problem space, and the conditions that constrain the solution and bound the solution space. The concept definition activities determine whether a new or modified system (i.e., the System-Of-Interest) is needed to fulfill the need. The [[System Definition|system definition]] activities use the outcomes of concept defintion and are focused on defining the system through a set of system requirements, logical and physical architectures, and the design of solutions. Outcomes of system definition are used for [[System Realization|system realization]], [[System Deployment and Use|system deployment and use]], and [[Product and Service Life Management|product and service life management]]. In this approach, system definition includes activities that are completed primarily in the front-end portion of system development and the design itself. Top-down activities can be sequential, iterative, recursive or evolutionary. These activities are based on the results of [[Mission Analysis]] and the definition of [[Stakeholder Needs and Requirements]] and generally consist of the development of [[System Requirement (glossary)|system requirements (glossary)]] that consist of the refinement and translation of the [[Stakeholder Requirement (glossary)|stakeholder requirements (glossary)]] into [[System Requirement (glossary)|system (technical) requirements]]. These system requirements are then used as inputs for the [[Architectural Design: Logical|logical architecture design]], which includes functional, behavioral, temporal, and physical architectural aspects. [[System Analysis]] studies are performed to evaluate and select the potential system elements that compose the system and are the most suitable. System analysis is intended to provide a best value, balanced solution involving all relevant engineering elements (stakeholder requirements, system requirements, and design properties). For the concept definition, an appropriate architecture framework representation can be useful in the visualization and analysis of the mission and solution requirements. These include DoDAF Operations View, Zachman Framework (Rows1 and 2), and TOGAF ADM Phase A and B within the Concept Definition when performing Mission Analysis and Stakeholders Needs and Requirements.<br />
<br />
===Bottom-Up Approach: Evolution of the Solution===<br />
<br />
In some situations, the concept definition activities determine the need to evolve existing capabilities or add new capabilities to an existing system. During the concept definition, the alternatives to address the need are evaaluated and engineers are then led to reconsider the system definition in order to modify or adapt some structural, functional, behavioral, or temporal properties during the [[Product (glossary)|product (glossary)]] or [[Service (glossary)|service (glossary)]] life cycle to adapt to a changing [[context (glossary)|context (glossary)]] of use or for the purpose of improving existing solutions. [[Reverse Engineering (glossary)|Reverse engineering (glossary)]] is often necessary to enable system engineers to (re)characterize the properties of the system of interest (SoI) or its elements; this is an important step to ensure that system engineers understand the SoI before beginning modification. (For more information on system definition, please see [[System Definition]].)<br />
<br />
A bottom-up approach is necessary for analysis purposes, or for (re)using existing elements in the design [[architecture (glossary)|architecture (glossary)]]. Changes in the context of use or a need for improvement can prompt this. In contrast, a top-down approach is generally used to define an initial design solution corresponding to a problem or a set of needs.<br />
<br />
Bottom-up and top-down approaches can be, and often are, mixed.<br />
<br />
===Drivers of Solutions: Push versus Pull===<br />
<br />
There are two paradigms that drive the concept definition - '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' paradign is based on creating a solution to address a perceived opportunity, such as a product or service anticipated to be wanted by or attractive to some portion of the population (whether a current market exists or not). This can have an effect on other lifecylcle processes, for example in verification and validation, as it is performed in defense industries versus alpha/beta test done in some commercial domains.<br />
<br />
===Separation and Iteration between Problem and Solution===<br />
<br />
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 Analysis|System analysis]] activities are used to perform the link between problems and solutions. <br />
<br />
As systems generally integrate existing and new [[System Element (glossary)|system elements (glossary)]], a bottom-up approach can be combined with a top-down approach to take into account legacy elements, as well as to identify the services and capabilities they provide in order to define applicable interface requirements and constraints. As discussed in [[System Life Cycle Process Models: Iterative]], this is iterative for these evolutionary systems. <br />
<br />
For more details about systems approaches, please see the [[Systems Approach Applied to Engineered Systems | Systems Approach Applied to Engineered Systems]] Knowledge Area. In addition, the references “What Is the Systems Approach?” (Jackson, Hitchins, Eisner 2010, 41-43) and ''A 21st Century Systems Methodology'' (Hitchins 2007) are recommended.<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
Kossiakoff, A, and W. Sweet. 2009. ''Systems Engineering: Principles and Practice.'' Hoboken, NJ, USA: John Wiley and Sons. <br />
<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley & Sons.<br />
<br />
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight'' (April 2010): 41-43.<br />
<br />
===Primary References===<br />
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).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ANSI/EIA. 1998. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA 632-1998. <br />
<br />
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 Electronical Commission (IEC), ISO/IEC 19760:2003 (E). <br />
<br />
ISO/IEC. 2007. Systems Engineering – Application and Management of The Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007. <br />
<br />
NASA. 2007. Systems Engineering Handbook. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.<br />
<br />
===Additional References===<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley & Sons.<br />
<br />
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight'' (April 2010): 41-43.<br />
<br />
----<br />
<center>[[Lean Engineering|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[Mission Analysis|Next Article >]]</center><br />
<br />
==Comments from SEBoK 0.5==<br />
This article is new to the SEBoK for version 0.75. As such, there are no associated 0.5 comments. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
{{DISQUS}}<br />
<br />
<br />
[[Category:Part 3]][[Category:Knowledge Area]]</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_and_Mission_Analysis&diff=38123Business and Mission Analysis2012-08-07T02:06:25Z<p>Groedler: </p>
<hr />
<div>Concept definition is the set of systems engineering activities in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the [[System of Interest (SoI) (glossary)]] is developed. [[Mission Analysis]] focuses on defining the problem or opportunity that exists (often called the problem space), as well as understanding the constraints on and boundaries of the solution space. [[Stakeholder Needs and Requirements]] explores and defines the operational aspects of a potential solution for the stakeholders from their pointof view, independent of any specific solution.<br />
<br />
Mission analysis examines ''why'' a solution is desired; what problem or opportunity it will address. Stakeholder needs and requirements describe ''what'' a solution should accomplish. Both ''why'' and ''what'' need to be answered before any consideration of ''how'' the problem will be addressed (i.e., what type of solution) and ''how'' the solution will be defined and developed. If the chosen solution is a new or modified system, then [[System Definition]] activities are performed to define the system. <br />
<br />
Various authors use different terms to describe these phases. For example, Kossiakoff and Sweet (2005) call them ''needs analysis'' and ''concept exploration.''<br />
<br />
To download a PDF of all of Part 3 (including this knowledge area), please [http://www.sebokwiki.org/075/images/0/07/SEBoK075_Part3.pdf click here].<br />
<br />
==Topics==<br />
The topics contained within this knowledge area include:<br />
*[[Mission Analysis]]<br />
*[[Stakeholder Needs and Requirements]]<br />
<br />
==Concept Definition Activities==<br />
There are two primary activities discussed under concept definition: [[Mission Analysis|mission analysis]] and the definition of [[Stakeholder Needs and Requirements|stakeholder needs and requirements]]:<br />
<br />
*[[Mission Analysis]] initiates the life cycle of a potential [[System of Interest (SoI) (glossary)|system of interest (SoI)]] that could solve a problem or realize an opportunity for developing a new product, service or enterprise. These activities define the problem space, identify the stakeholders, develop preliminary operational concepts, and identify environmental conditions and constraints that bound the solution space.<br />
*[[Stakeholder Needs and Requirements]] works with the stakeholders across the life cycle to elicit and capture a set of needs, expectations, goals, or objectives of a desired solution to the problem or opportunity, called Stakeholder Needs. The stakeholder needs are used to produce a clear, concise, and verifiable set of stakeholder requirements.<br />
<br />
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. Stakeholder Needs and Requirements identifies and defines the needs and requirements of the stakeholders in a manner that enables characterizing the solution alternatives. MA then takes the set of needs and requirements and carries the analysis down to the point that the needs and requirements have been transitioned from problem space to solution space including concept, requirement (stakeholder/mission) and boundary or context so that a solution concept (black box level) can be selected from the alternatives. Figure 1 in the [[Mission Analysis|mission analysis]] topic depicts this interaction. The products and artifacts produced during concept definition are then used in [[System Definition]].<br />
<br />
===Top-Down Approach: from Problem to Solution===<br />
<br />
In a top-down approach, [[Concept Definition|concept definition]] activities are focused primarily on understanding the problem, the operational needs/requirements within the problem space, and the conditions that constrain the solution and bound the solution space. The concept definition activities determine whether a new or modified system (i.e., the System-Of-Interest) is needed to fulfill the need. The [[System Definition|system definition]] activities use the outcomes of concept defintion and are focused on defining the system through a set of system requirements, logical and physical architectures, and the design of solutions. Outcomes of system definition are used for [[System Realization|system realization]], [[System Deployment and Use|system deployment and use]], and [[Product and Service Life Management|product and service life management]]. In this approach, system definition includes activities that are completed primarily in the front-end portion of system development and the design itself. Top-down activities can be sequential, iterative, recursive or evolutionary. These activities are based on the results of [[Mission Analysis]] and the definition of [[Stakeholder Needs and Requirements]] and generally consist of the development of [[System Requirement (glossary)|system requirements (glossary)]] that consist of the refinement and translation of the [[Stakeholder Requirement (glossary)|stakeholder requirements (glossary)]] into [[System Requirement (glossary)|system (technical) requirements]]. These system requirements are then used as inputs for the [[Architectural Design: Logical|logical architecture design]], which includes functional, behavioral, temporal, and physical architectural aspects. [[System Analysis]] studies are performed to evaluate and select the potential system elements that compose the system and are the most suitable. System analysis is intended to provide a best value, balanced solution involving all relevant engineering elements (stakeholder requirements, system requirements, and design properties). For the concept definition, an appropriate architecture framework representation can be useful in the visualization and analysis of the mission and solution requirements. These include DoDAF Operations View, Zachman Framework (Rows1 and 2), and TOGAF ADM Phase A and B within the Concept Definition when performing Mission Analysis and Stakeholders Needs and Requirements.<br />
<br />
===Bottom-Up Approach: Evolution of the Solution===<br />
<br />
In some situations, the concept definition activities determine the need to evolve existing capabilities or add new capabilities to an existing system. During the concept definition, the alternatives to address the need are evaaluated and engineers are then led to reconsider the system definition in order to modify or adapt some structural, functional, behavioral, or temporal properties during the [[Product (glossary)|product (glossary)]] or [[Service (glossary)|service (glossary)]] life cycle to adapt to a changing [[context (glossary)|context (glossary)]] of use or for the purpose of improving existing solutions. [[Reverse Engineering (glossary)|Reverse engineering (glossary)]] is often necessary to enable system engineers to (re)characterize the properties of the system of interest (SoI) or its elements; this is an important step to ensure that system engineers understand the SoI before beginning modification. (For more information on system definition, please see [[System Definition]].)<br />
<br />
A bottom-up approach is necessary for analysis purposes, or for (re)using existing elements in the design [[architecture (glossary)|architecture (glossary)]]. Changes in the context of use or a need for improvement can prompt this. In contrast, a top-down approach is generally used to define an initial design solution corresponding to a problem or a set of needs.<br />
<br />
Bottom-up and top-down approaches can be, and often are, mixed.<br />
<br />
===Drivers of Solutions: Push versus Pull===<br />
<br />
There are two paradigms that drive the concept definition - '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' paradign is based on creating a solution to address a perceived opportunity, such as a product or service anticipated to be wanted by or attractive to some portion of the population (whether a current market exists or not). <br />
<br />
===Separation and Iteration between Problem and Solution===<br />
<br />
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 Analysis|System analysis]] activities are used to perform the link between problems and solutions. <br />
<br />
As systems generally integrate existing and new [[System Element (glossary)|system elements (glossary)]], a bottom-up approach can be combined with a top-down approach to take into account legacy elements, as well as to identify the services and capabilities they provide in order to define applicable interface requirements and constraints. As discussed in [[System Life Cycle Process Models: Iterative]], this is iterative for these evolutionary systems. <br />
<br />
For more details about systems approaches, please see the [[Systems Approach Applied to Engineered Systems | Systems Approach Applied to Engineered Systems]] Knowledge Area. In addition, the references “What Is the Systems Approach?” (Jackson, Hitchins, Eisner 2010, 41-43) and ''A 21st Century Systems Methodology'' (Hitchins 2007) are recommended.<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
Kossiakoff, A, and W. Sweet. 2009. ''Systems Engineering: Principles and Practice.'' Hoboken, NJ, USA: John Wiley and Sons. <br />
<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley & Sons.<br />
<br />
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight'' (April 2010): 41-43.<br />
<br />
===Primary References===<br />
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).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ANSI/EIA. 1998. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA 632-1998. <br />
<br />
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 Electronical Commission (IEC), ISO/IEC 19760:2003 (E). <br />
<br />
ISO/IEC. 2007. Systems Engineering – Application and Management of The Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007. <br />
<br />
NASA. 2007. Systems Engineering Handbook. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.<br />
<br />
===Additional References===<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley & Sons.<br />
<br />
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight'' (April 2010): 41-43.<br />
<br />
----<br />
<center>[[Lean Engineering|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[Mission Analysis|Next Article >]]</center><br />
<br />
==Comments from SEBoK 0.5==<br />
This article is new to the SEBoK for version 0.75. As such, there are no associated 0.5 comments. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
{{DISQUS}}<br />
<br />
<br />
[[Category:Part 3]][[Category:Knowledge Area]]</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_or_Mission_Analysis&diff=38122Business or Mission Analysis2012-08-07T01:41:32Z<p>Groedler: /* Activities of the Process */</p>
<hr />
<div>The starting point of engineering any [[System of Interest (SoI) (glossary)|system of interest (SoI)]] is understanding the socio-economic and technological context wherein potential problems or opportunities reside. The enterprise strategic goals and [[Stakeholder (glossary)| stakeholders’]] needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], and [[Customer (glossary)|customers]]. An important set of activities, called [[Mission Analysis (glossary)|mission analysis]] ([[Acronyms|MA]]) (also called [[Market Analysis (glossary)|market analysis]] or business anlaysis in certain domains or sectors), is often performed iteratively with [[Stakeholder Needs and Requirements]] generation to better understand the problem (or opportunity) space, as well as the solution space. The execution of this process enables a systems engineer to then establish a set of [[Stakeholder Requirement (glossary)| stakeholder requirements]] for a potential SoI, or other solution, that could provide a capability or service needed by the acquirer, the users, and the other stakeholders in a defined environment. <br />
<br />
MA is part of the larger set of [[Concept Definition|concept definition]] activities. [[Concept Definition|Concept definition]] is the phase of systems engineering in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the [[System of Interest (SoI) (glossary)|system of interest]] is developed. In fact, the activities of concept definition determine whether the enterprise strategic goals and stakeholder needs will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution. Mission analysis focuses on the identification of the primary purpose(s) of the solution, while [[Stakeholder Needs and Requirements]] definition explores what capabilities stakeholders desire and may include some detail on the performance of certain aspects of the solution.<br />
<br />
== Purpose and Definition ==<br />
The purpose of MA is to understand a mission/market problem or opportunity, analyze the solution space, and initiate the life cycle of a potential solution that could answer the problem or take advantage of an opportunity.<br />
<br />
MA, known in some domains as [[Market Analysis (glossary)|market analysis (glossary)]] or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise. The definition of a mission need in a problem space frames the solution, both in terms of the direct application to the mission or business function, and in terms of the context for the resulting solution. MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. It characterizes the operational need in terms of mission description/provisions and the environment/context the need exists within, together with the proposed enterprise concept of operations and operational scenarios. The primary products of MA are the revised Concept of Operations ([[Concept of Operations (ConOps) (glossary)|ConOps]]) of the enterprise, the [[Operational Concept (glossary)|Operational Concept]], the [[Operational Scenario (glossary)|Operational Scenarios]] for the mission, and the context in which the solution will exist. <br />
<br />
MA may include mathematical analysis, modeling, simulation, visualization, and other analytical tools to characterize the intended mission and determine how to best achieve the needs/objectives. MA evaluates alternative approaches to determine which alternative approach best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions). Thus, MA defines the problem space and analyzes the solution space alternatives using quality attribute constraints driven by the enterprise objectives.<br />
<br />
==Principles and Concepts==<br />
===Mission Analysis and Concept of Operations===<br />
MA and the [[Concept of Operations (ConOps) (glossary)|ConOps]] are broadly used in defense and aerospace organizations to analyze and define how the system is intended to operate, as well as how the major operations or operational scenarios are intended to be performed, taking into account the strategic, operational, and tactical aspects of the identified scenarios. MA is a type of strategic or operations analysis related to needs, capability gaps, or opportnities and solutions that can be applied to any organization that evolves its strategy for its business objectives.<br />
<br />
In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering ([[Acronyms|SE]]) leaders interact with enterprise leaders and operations analysts to understand: <br />
*the enterprise ConOps and future mission, business, and operational (MBO) objectives; <br />
*the characterization of the Operational Concept and objectives (i.e., constraints, mission or operational scenarios, tasks, resources, risks, assumptions, and related missions or operations); and<br />
*how specific missions or operations are currently conducted and what gaps exist in those areas.<br />
<br />
They then conceptually explore and select from alternative candidate solutions. This interaction ensures a full understanding of both the problem space and the solution space. The alternative candidate solutions can include a wide range of approaches to address the need, as well as variants for an approach to optimize specific characteristics (e.g., using a different distribution of satellite orbit parameters to maximize coverage or events while minimizing the number of satellites). Analysis, modeling and simulation, and trade studies are employed to select alternative approaches (Charter of the Mission Analysis Committee, National Defense Industrial Association, Systems Engineering Division).<br />
<br />
"The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems (as black boxes) to forward the organization's goals and objectives. The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations within the business in regards to the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of future business and systems” (ISO/IEC 2011). <br />
<br />
These notions are also used in industrial sectors, such as aviation administrations and aeronautic transportation, health care systems, space, etc., with adapted definitions and/or terms, such as operational concepts, usage concepts and/or technological concepts. For example, “mission analysis” is the term used to describe the mathematical analysis of satellite orbits performed to determine how best to achieve the objectives of a space mission (European Space Agency).<br />
<br />
In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:<br />
<br />
<blockquote>''. . . studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and this in turn of the global environmental analysis. Through all these analyses, the chances, strengths, weaknesses, and risks of a company can be identified. Finally, with the help of a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm's planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company.'' (Wikipedia, 02/12/12)</blockquote><br />
<br />
Anywhere these notions are used, it is evident that they are based on fundamental concepts, such as the [[Operational Mode (glossary)|operational mode]] (or state of the system), [[Scenario (glossary)|scenario]] (of actions), the enterprise level concept of operations and the system level operational concepts, [[Function (glossary) |functions]] (providing services), etc. For more explanations about the concept of operations and operational concept, refer to ''Systems and Software Engineering - Requirements Engineering'' (ISO/IEC 2011); useful information can be found in Annex A, "System Operational Concept", and Annex B, "Concept of Operations" (ISO/IEC 2011).<br />
<br />
===Mission Analysis as Part of Enterprise Strategy Development===<br />
Periodically, most enterprises re-evaluate their strategy with respect to their mission, vision, and positioning to accomplish their goals. Figure 1 shows the interactions of the enterprise strategy development and the concept definition, including MA and stakeholder needs and requirements that are involved in an iterative manner to fully develop the strategy and define future capabilities and solutions. As the enterprise evolves the strategy, it is essential to conduct the supporting MA or strategic analysis for each element of the enterprise to determine their readiness to achieve their future objectives. This analysis examines the current state to identify any problems or opportunities related to the objective achievement and aids the enterprise in fully understanding and defining the problem space. The analysis examines the external environment and interfaces in search of impacts and trends, as well as the internal enterprise to gauge its capabilities and value stream gaps. Additionally, a SWOT analysis may be performed to weigh the strengths, weaknesses, opportunities, and threats. As the problem space is defined, stakeholder needs and requirements activities are performed to define the stakeholder needs and transform them into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, the future state of core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities (see [[Stakeholder Needs and Requirements]] for more information). Finally, MA is engaged again to examine the solution space. Candidate solutions that span the potential solution space are identified, from simple operational changes, to various system developments or modifications. Various techniques are applied to analyze the candidates, understand their feasibility and value, and select the best alternative.<br />
<br />
[[File:Enterprise_Strategy_and_Concept_Development.PNG|thumb|700px|center|Figure 1. Enterprise Strategy and Concept Development (Roedler 2012) Reprinted with permission of Garry Roedler]]<br />
<br />
==Process Approach==<br />
===Activities of the Process===<br />
It is necessary to perform the following major activities and tasks during this process: <br />
#Review and understand the enterprise mission, vision, and ConOps.<br />
#Identify and define any gaps and opportunities related to future evolution of the strategy:<br />
##Examine the current state to identify any problems or opportunities related to the objective achievement, including any deficiencies of the existing system.<br />
##Analyze the context of the actual PESTAL factors (Political, Economic, Social, Technological, Environmental, and Legal), while studying sensitive factors such as cost and effectiveness, security and safety improvement, performance improvement or lack of existing systems, market opportunities, regulation changes, users' dissatisfaction, etc. External, internal, and SWOT analysis should be included as well. For the technological considerations, an appropriate architectural framework representation, such as DoDAF Operations View, Zachman Framework (Rows1 and 2), and TOGAF ADM Phase A and B within the Concept Definition when performing Mission Analysis and Stakeholders Needs and Requirements.<br />
##Define any mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without thinking to solution. <br />
#Examine and evaluate the solution space.<br />
##Identify the main stakeholders (customers, users, administrations, regulations, etc.).<br />
##Identify high level operational modes or states, or potential use cases.<br />
##Identify candidate solutions that span the potential solution space, from simple operational changes, to various system developments or modifications. Identify existing systems, products, and services that may address the need for operational or functional modifications. Deduce what potential expected services may be needed. A potential and not yet existing product, service or enterprise is called the "system-of-interest" (SoI). Additionally, the solution could be an operational change or a change to an existing product or service.<br />
#Perform appropriate modeling, simulation, and analytical techniques to understand the feasibility and value of the alternative candidate solutions. Model or simulate operational scenarios from these services and use cases, and enrich them through reviews with stakeholders and subject matter experts.<br />
#Define basic operational concept or market strategy, and/or business models.<br />
##From previous modeled operational scenarios and operational modes, deduce and express the usage of operational concepts, or technical concepts.<br />
##Collect and enrich needs, expectations, scenarios, and constraints.<br />
##Validate the mission of any potential SoI in the context of any proposed market strategy or business model.<br />
#Evaluate the set of alternatives and select the best alternative.<br />
##Perform a trade study of the alternatives to discriminate between the alternatives.<br />
#Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.<br />
<br />
===Mission Analysis Artifacts===<br />
<br />
This process may create several artifacts, such as:<br />
*recommendations for revisions to the enterprise ConOps;<br />
*preliminary operational concept document or inputs;<br />
*mission analysis and definition reports;<br />
*system analysis artifacts (e.g., use case diagrams, context diagrams, sequence/activity diagrams, functional flow block diagrams);<br />
*trade study results (alternatives analysis); and<br />
*market study/analysis reports.<br />
<br />
===Methods and Modeling Techniques===<br />
<br />
MA uses techniques, such as:<br />
<br />
*use case analysis;<br />
*operational analysis; <br />
*functional analysis;<br />
*technical documentation review;<br />
*trade studies;<br />
*modeling;<br />
*simulation;<br />
*prototyping;<br />
*workshops, interviews, and questionnaires;<br />
*market competitive assessments;<br />
*benchmarking; and<br />
*organizational analysis techniques (e.g., strengths, weaknesses, opportunities, threats (SWOT analysis), and product portfolios).<br />
<br />
==Practical Considerations==<br />
Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1. <br />
<br />
<center><br />
{|<br />
|+'''Table 1. Major Pitfalls with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|Wrong level of system addressed<br />
|When delineating the boundaries of the system-of-interest and defining the mission and purpose of the system at the very beginning of systems engineering, a classic mistake is to place the system-of-interest at the wrong level of abstraction. The level of abstraction can be too high or too low (sitting respectively in the upper-system or in a sub-system). This is the consequence of the principle stating that a system is always included in a larger system and of confusing the purpose and the mission of the system-of-interest.<br />
|-<br />
|Operational modes or scenarios missing<br />
|In commercial products or systems, the lack or insufficient description of operational modes and scenarios (how the system-of-interest will be used, in which situations, etc.) is often encountered.<br />
|}<br />
</center><br />
<br />
<br />
Proven practices with mission analysis and marketing analysis are presented in Table 2.<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Proven Practices with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|Models of operational scenarios<br />
|Using modeling techniques as indicated in sections above for operational scenarios in any kind of system-of-interest (including commercial systems).<br />
|-<br />
|Models of the context<br />
|Consider the context of use as a system and force oneself to use modeling techniques for main aspects of the context (functional, behavioral, physical, etc.).<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Freeman, Richard, “Achieving Strategic Aims: Moving Toward a Process Based Military Enterprise”<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering -- Life cycle processes -- Requirements engineering'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC/IEEE 29148:2011<br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
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.<br />
<br />
Kaplan, Robert S. and Norton, David P., “Developing the Strategy: Vision, Value Gaps, and Analysis”, Balanced Scorecard Report, Harvard Business School Publishing, Jan-Feb 2008<br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A simple method for phased mission analysis." ''Reliability Engineering & System Safety'' 45(3): 299-309.<br />
<br />
National Defense Industrial Association, Systems Engineering Division, Mission Analysis Committee, “Mission Analysis Committee Charter”<br />
<br />
Shupp, Jeffrey K., “The Mission Analysis Discipline: Bringing focus to the fuzziness about Attaining Good Architectures”, Proceedings of INCOSE 13th International Symposium, July 2003.<br />
<br />
Wikipedia, “Market Analysis”, 12 February 2012.<br />
<br />
===Primary References===<br />
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).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
Center for Quality Management. 1993. "Special Issue on Kano's Methods for Understanding Customer Defined Quality." ''Center for Quality Management Journal'' 2(4) (Fall 1993). <br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering.'' 3rd ed. London, UK: Springer.<br />
<br />
Kano, N. 1984. "Attractive Quality and Must-Be Quality." ''Quality JSQC'' 14(2) (October 1984). <br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309. <br />
<br />
Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques," in ''Software Engineering''. New York, NY: McGraw-Hill.<br />
<br />
MITRE. 2011. "Concept Development." ''Systems Engineering Guide. '' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/]].<br />
<br />
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/]].<br />
<br />
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]].<br />
----<br />
<center>[[Concept Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Stakeholder Needs and Requirements|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Concept Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_and_Mission_Analysis&diff=38121Business and Mission Analysis2012-08-07T01:38:48Z<p>Groedler: /* Concept Definition Activities */</p>
<hr />
<div>Concept definition is the set of systems engineering activities in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the [[System of Interest (SoI) (glossary)]] is developed. [[Mission Analysis]] focuses on defining the problem or opportunity that exists (often called the problem space), as well as understanding the constraints on and boundaries of the solution space. [[Stakeholder Needs and Requirements]] explores and defines the operational aspects of a potential solution for the stakeholders from their pointof view, independent of any specific solution.<br />
<br />
Mission analysis examines ''why'' a solution is desired; what problem or opportunity it will address. Stakeholder needs and requirements describe ''what'' a solution should accomplish. Both ''why'' and ''what'' need to be answered before any consideration of ''how'' the problem will be addressed (i.e., what type of solution) and ''how'' the solution will be defined and developed. If the chosen solution is a new or modified system, then [[System Definition]] activities are performed to define the system. <br />
<br />
Various authors use different terms to describe these phases. For example, Kossiakoff and Sweet (2005) call them ''needs analysis'' and ''concept exploration.''<br />
<br />
To download a PDF of all of Part 3 (including this knowledge area), please [http://www.sebokwiki.org/075/images/0/07/SEBoK075_Part3.pdf click here].<br />
<br />
==Topics==<br />
The topics contained within this knowledge area include:<br />
*[[Mission Analysis]]<br />
*[[Stakeholder Needs and Requirements]]<br />
<br />
==Concept Definition Activities==<br />
There are two primary activities discussed under concept definition: [[Mission Analysis|mission analysis]] and the definition of [[Stakeholder Needs and Requirements|stakeholder needs and requirements]]:<br />
<br />
*[[Mission Analysis]] initiates the life cycle of a potential [[System of Interest (SoI) (glossary)|system of interest (SoI)]] that could solve a problem or realize an opportunity for developing a new product, service or enterprise. These activities define the problem space, identify the stakeholders, develop preliminary operational concepts, and identify environmental conditions and constraints that bound the solution space.<br />
*[[Stakeholder Needs and Requirements]] works with the stakeholders across the life cycle to elicit and capture a set of needs, expectations, goals, or objectives of a desired solution to the problem or opportunity, called Stakeholder Needs. The stakeholder needs are used to produce a clear, concise, and verifiable set of stakeholder requirements.<br />
<br />
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. Stakeholder Needs and Requirements identifies and defines the needs and requirements of the stakeholders in a manner that enables characterizing the solution alternatives. MA then takes the set of needs and requirements and carries the analysis down to the point that the needs and requirements have been transitioned from problem space to solution space including concept, requirement (stakeholder/mission) and boundary or context so that a solution concept (black box level) can be selected from the alternatives. Figure 1 in the [[Mission Analysis|mission analysis]] topic depicts this interaction. The products and artifacts produced during concept definition are then used in [[System Definition]].<br />
<br />
===Top-Down Approach: from Problem to Solution===<br />
<br />
In a top-down approach, [[Concept Definition|concept definition]] activities are focused primarily on understanding the problem, the operational needs/requirements within the problem space, and the conditions that constrain the solution and bound the solution space. The concept definition activities determine whether a new or modified system (i.e., the System-Of-Interest) is needed to fulfill the need. The [[System Definition|system definition]] activities use the outcomes of concept defintion and are focused on defining the system through a set of system requirements, logical and physical architectures, and the design of solutions. Outcomes of system definition are used for [[System Realization|system realization]], [[System Deployment and Use|system deployment and use]], and [[Product and Service Life Management|product and service life management]]. In this approach, system definition includes activities that are completed primarily in the front-end portion of system development and the design itself. Top-down activities can be sequential, iterative, recursive or evolutionary. These activities are based on the results of [[Mission Analysis]] and the definition of [[Stakeholder Needs and Requirements]] and generally consist of the development of [[System Requirement (glossary)|system requirements (glossary)]] that consist of the refinement and translation of the [[Stakeholder Requirement (glossary)|stakeholder requirements (glossary)]] into [[System Requirement (glossary)|system (technical) requirements]]. These system requirements are then used as inputs for the [[Architectural Design: Logical|logical architecture design]], which includes functional, behavioral, temporal, and physical architectural aspects. [[System Analysis]] studies are performed to evaluate and select the potential system elements that compose the system and are the most suitable. System analysis is intended to provide a best value, balanced solution involving all relevant engineering elements (stakeholder requirements, system requirements, and design properties). For the concept definition, an appropriate architecture framework representation can be useful in the visualization and analysis of the mission and solution requirements. These include DoDAF Operations View, Zachman Framework (Rows1 and 2), and TOGAF ADM Phase A and B within the Concept Definition when performing Mission Analysis and Stakeholders Needs and Requirements.<br />
<br />
===Bottom-Up Approach: Evolution of the Solution===<br />
<br />
In some situations, the concept definition activities determine the need to evolve existing capabilities or add new capabilities to an existing system. During the concept definition, the alternatives to address the need are evaaluated and engineers are then led to reconsider the system definition in order to modify or adapt some structural, functional, behavioral, or temporal properties during the [[Product (glossary)|product (glossary)]] or [[Service (glossary)|service (glossary)]] life cycle to adapt to a changing [[context (glossary)|context (glossary)]] of use or for the purpose of improving existing solutions. [[Reverse Engineering (glossary)|Reverse engineering (glossary)]] is often necessary to enable system engineers to (re)characterize the properties of the system of interest (SoI) or its elements; this is an important step to ensure that system engineers understand the SoI before beginning modification. (For more information on system definition, please see [[System Definition]].)<br />
<br />
A bottom-up approach is necessary for analysis purposes, or for (re)using existing elements in the design [[architecture (glossary)|architecture (glossary)]]. Changes in the context of use or a need for improvement can prompt this. In contrast, a top-down approach is generally used to define an initial design solution corresponding to a problem or a set of needs.<br />
<br />
Bottom-up and top-down approaches can be, and often are, mixed.<br />
<br />
===Separation and Iteration between Problem and Solution===<br />
<br />
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 Analysis|System analysis]] activities are used to perform the link between problems and solutions. <br />
<br />
As systems generally integrate existing and new [[System Element (glossary)|system elements (glossary)]], a bottom-up approach can be combined with a top-down approach to take into account legacy elements, as well as to identify the services and capabilities they provide in order to define applicable interface requirements and constraints. As discussed in [[System Life Cycle Process Models: Iterative]], this is iterative for these evolutionary systems. <br />
<br />
For more details about systems approaches, please see the [[Systems Approach Applied to Engineered Systems | Systems Approach Applied to Engineered Systems]] Knowledge Area. In addition, the references “What Is the Systems Approach?” (Jackson, Hitchins, Eisner 2010, 41-43) and ''A 21st Century Systems Methodology'' (Hitchins 2007) are recommended.<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
Kossiakoff, A, and W. Sweet. 2009. ''Systems Engineering: Principles and Practice.'' Hoboken, NJ, USA: John Wiley and Sons. <br />
<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley & Sons.<br />
<br />
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight'' (April 2010): 41-43.<br />
<br />
===Primary References===<br />
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).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ANSI/EIA. 1998. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA 632-1998. <br />
<br />
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 Electronical Commission (IEC), ISO/IEC 19760:2003 (E). <br />
<br />
ISO/IEC. 2007. Systems Engineering – Application and Management of The Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007. <br />
<br />
NASA. 2007. Systems Engineering Handbook. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.<br />
<br />
===Additional References===<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley & Sons.<br />
<br />
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight'' (April 2010): 41-43.<br />
<br />
----<br />
<center>[[Lean Engineering|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[Mission Analysis|Next Article >]]</center><br />
<br />
==Comments from SEBoK 0.5==<br />
This article is new to the SEBoK for version 0.75. As such, there are no associated 0.5 comments. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
{{DISQUS}}<br />
<br />
<br />
[[Category:Part 3]][[Category:Knowledge Area]]</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_and_Mission_Analysis&diff=38120Business and Mission Analysis2012-08-07T01:08:35Z<p>Groedler: /* Top-Down Approach: from Problem to Solution */</p>
<hr />
<div>Concept definition is the set of systems engineering activities in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the [[System of Interest (SoI) (glossary)]] is developed. [[Mission Analysis]] focuses on defining the problem or opportunity that exists (often called the problem space), as well as understanding the constraints on and boundaries of the solution space. [[Stakeholder Needs and Requirements]] explores and defines the operational aspects of a potential solution for the stakeholders from their pointof view, independent of any specific solution.<br />
<br />
Mission analysis examines ''why'' a solution is desired; what problem or opportunity it will address. Stakeholder needs and requirements describe ''what'' a solution should accomplish. Both ''why'' and ''what'' need to be answered before any consideration of ''how'' the problem will be addressed (i.e., what type of solution) and ''how'' the solution will be defined and developed. If the chosen solution is a new or modified system, then [[System Definition]] activities are performed to define the system. <br />
<br />
Various authors use different terms to describe these phases. For example, Kossiakoff and Sweet (2005) call them ''needs analysis'' and ''concept exploration.''<br />
<br />
To download a PDF of all of Part 3 (including this knowledge area), please [http://www.sebokwiki.org/075/images/0/07/SEBoK075_Part3.pdf click here].<br />
<br />
==Topics==<br />
The topics contained within this knowledge area include:<br />
*[[Mission Analysis]]<br />
*[[Stakeholder Needs and Requirements]]<br />
<br />
==Concept Definition Activities==<br />
There are two primary activities discussed under concept definition: [[Mission Analysis|mission analysis]] and the definition of [[Stakeholder Needs and Requirements|stakeholder needs and requirements]]:<br />
<br />
*[[Mission Analysis]] initiates the life cycle of a potential [[System of Interest (SoI) (glossary)|system of interest (SoI)]] that could solve a problem or realize an opportunity for developing a new product, service or enterprise. These activities define the problem space, identify the stakeholders, develop preliminary operational concepts, and identify environmental conditions and constraints that bound the solution space.<br />
*[[Stakeholder Needs and Requirements]] works with the stakeholders across the life cycle to elicit and capture a set of needs, expectations, goals, or objectives of a desired solution to the problem or opportunity, called Stakeholder Needs. The stakeholder needs are used to produce a clear, concise, and verifiable set of stakeholder requirements.<br />
<br />
The products and artifacts produced during concept definition are then used in [[System Definition]].<br />
<br />
===Top-Down Approach: from Problem to Solution===<br />
<br />
In a top-down approach, [[Concept Definition|concept definition]] activities are focused primarily on understanding the problem, the operational needs/requirements within the problem space, and the conditions that constrain the solution and bound the solution space. The concept definition activities determine whether a new or modified system (i.e., the System-Of-Interest) is needed to fulfill the need. The [[System Definition|system definition]] activities use the outcomes of concept defintion and are focused on defining the system through a set of system requirements, logical and physical architectures, and the design of solutions. Outcomes of system definition are used for [[System Realization|system realization]], [[System Deployment and Use|system deployment and use]], and [[Product and Service Life Management|product and service life management]]. In this approach, system definition includes activities that are completed primarily in the front-end portion of system development and the design itself. Top-down activities can be sequential, iterative, recursive or evolutionary. These activities are based on the results of [[Mission Analysis]] and the definition of [[Stakeholder Needs and Requirements]] and generally consist of the development of [[System Requirement (glossary)|system requirements (glossary)]] that consist of the refinement and translation of the [[Stakeholder Requirement (glossary)|stakeholder requirements (glossary)]] into [[System Requirement (glossary)|system (technical) requirements]]. These system requirements are then used as inputs for the [[Architectural Design: Logical|logical architecture design]], which includes functional, behavioral, temporal, and physical architectural aspects. [[System Analysis]] studies are performed to evaluate and select the potential system elements that compose the system and are the most suitable. System analysis is intended to provide a best value, balanced solution involving all relevant engineering elements (stakeholder requirements, system requirements, and design properties). For the concept definition, an appropriate architecture framework representation can be useful in the visualization and analysis of the mission and solution requirements. These include DoDAF Operations View, Zachman Framework (Rows1 and 2), and TOGAF ADM Phase A and B within the Concept Definition when performing Mission Analysis and Stakeholders Needs and Requirements.<br />
<br />
===Bottom-Up Approach: Evolution of the Solution===<br />
<br />
In some situations, the concept definition activities determine the need to evolve existing capabilities or add new capabilities to an existing system. During the concept definition, the alternatives to address the need are evaaluated and engineers are then led to reconsider the system definition in order to modify or adapt some structural, functional, behavioral, or temporal properties during the [[Product (glossary)|product (glossary)]] or [[Service (glossary)|service (glossary)]] life cycle to adapt to a changing [[context (glossary)|context (glossary)]] of use or for the purpose of improving existing solutions. [[Reverse Engineering (glossary)|Reverse engineering (glossary)]] is often necessary to enable system engineers to (re)characterize the properties of the system of interest (SoI) or its elements; this is an important step to ensure that system engineers understand the SoI before beginning modification. (For more information on system definition, please see [[System Definition]].)<br />
<br />
A bottom-up approach is necessary for analysis purposes, or for (re)using existing elements in the design [[architecture (glossary)|architecture (glossary)]]. Changes in the context of use or a need for improvement can prompt this. In contrast, a top-down approach is generally used to define an initial design solution corresponding to a problem or a set of needs.<br />
<br />
Bottom-up and top-down approaches can be, and often are, mixed.<br />
<br />
===Separation and Iteration between Problem and Solution===<br />
<br />
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 Analysis|System analysis]] activities are used to perform the link between problems and solutions. <br />
<br />
As systems generally integrate existing and new [[System Element (glossary)|system elements (glossary)]], a bottom-up approach can be combined with a top-down approach to take into account legacy elements, as well as to identify the services and capabilities they provide in order to define applicable interface requirements and constraints. As discussed in [[System Life Cycle Process Models: Iterative]], this is iterative for these evolutionary systems. <br />
<br />
For more details about systems approaches, please see the [[Systems Approach Applied to Engineered Systems | Systems Approach Applied to Engineered Systems]] Knowledge Area. In addition, the references “What Is the Systems Approach?” (Jackson, Hitchins, Eisner 2010, 41-43) and ''A 21st Century Systems Methodology'' (Hitchins 2007) are recommended.<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
Kossiakoff, A, and W. Sweet. 2009. ''Systems Engineering: Principles and Practice.'' Hoboken, NJ, USA: John Wiley and Sons. <br />
<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley & Sons.<br />
<br />
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight'' (April 2010): 41-43.<br />
<br />
===Primary References===<br />
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).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ANSI/EIA. 1998. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA 632-1998. <br />
<br />
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 Electronical Commission (IEC), ISO/IEC 19760:2003 (E). <br />
<br />
ISO/IEC. 2007. Systems Engineering – Application and Management of The Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007. <br />
<br />
NASA. 2007. Systems Engineering Handbook. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.<br />
<br />
===Additional References===<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley & Sons.<br />
<br />
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight'' (April 2010): 41-43.<br />
<br />
----<br />
<center>[[Lean Engineering|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[Mission Analysis|Next Article >]]</center><br />
<br />
==Comments from SEBoK 0.5==<br />
This article is new to the SEBoK for version 0.75. As such, there are no associated 0.5 comments. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
{{DISQUS}}<br />
<br />
<br />
[[Category:Part 3]][[Category:Knowledge Area]]</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_and_Mission_Analysis&diff=38119Business and Mission Analysis2012-08-07T01:05:24Z<p>Groedler: /* Top-Down Approach: from Problem to Solution */</p>
<hr />
<div>Concept definition is the set of systems engineering activities in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the [[System of Interest (SoI) (glossary)]] is developed. [[Mission Analysis]] focuses on defining the problem or opportunity that exists (often called the problem space), as well as understanding the constraints on and boundaries of the solution space. [[Stakeholder Needs and Requirements]] explores and defines the operational aspects of a potential solution for the stakeholders from their pointof view, independent of any specific solution.<br />
<br />
Mission analysis examines ''why'' a solution is desired; what problem or opportunity it will address. Stakeholder needs and requirements describe ''what'' a solution should accomplish. Both ''why'' and ''what'' need to be answered before any consideration of ''how'' the problem will be addressed (i.e., what type of solution) and ''how'' the solution will be defined and developed. If the chosen solution is a new or modified system, then [[System Definition]] activities are performed to define the system. <br />
<br />
Various authors use different terms to describe these phases. For example, Kossiakoff and Sweet (2005) call them ''needs analysis'' and ''concept exploration.''<br />
<br />
To download a PDF of all of Part 3 (including this knowledge area), please [http://www.sebokwiki.org/075/images/0/07/SEBoK075_Part3.pdf click here].<br />
<br />
==Topics==<br />
The topics contained within this knowledge area include:<br />
*[[Mission Analysis]]<br />
*[[Stakeholder Needs and Requirements]]<br />
<br />
==Concept Definition Activities==<br />
There are two primary activities discussed under concept definition: [[Mission Analysis|mission analysis]] and the definition of [[Stakeholder Needs and Requirements|stakeholder needs and requirements]]:<br />
<br />
*[[Mission Analysis]] initiates the life cycle of a potential [[System of Interest (SoI) (glossary)|system of interest (SoI)]] that could solve a problem or realize an opportunity for developing a new product, service or enterprise. These activities define the problem space, identify the stakeholders, develop preliminary operational concepts, and identify environmental conditions and constraints that bound the solution space.<br />
*[[Stakeholder Needs and Requirements]] works with the stakeholders across the life cycle to elicit and capture a set of needs, expectations, goals, or objectives of a desired solution to the problem or opportunity, called Stakeholder Needs. The stakeholder needs are used to produce a clear, concise, and verifiable set of stakeholder requirements.<br />
<br />
The products and artifacts produced during concept definition are then used in [[System Definition]].<br />
<br />
===Top-Down Approach: from Problem to Solution===<br />
<br />
In a top-down approach, [[Concept Definition|concept definition]] activities are focused primarily on understanding the problem, the operational needs/requirements within the problem space, and the conditions that constrain the solution and bound the solution space. The concept definition activities determine whether a new or modified system (i.e., the System-Of-Interest) is needed to fulfill the need. The [[System Definition|system definition]] activities use the outcomes of concept defintion and are focused on defining the system through a set of system requirements, logical and physical architectures, and the design of solutions. Outcomes of system definition are used for [[System Realization|system realization]], [[System Deployment and Use|system deployment and use]], and [[Product and Service Life Management|product and service life management]]. In this approach, system definition includes activities that are completed primarily in the front-end portion of system development and the design itself. Top-down activities can be sequential, iterative, recursive or evolutionary. These activities are based on the results of [[Mission Analysis]] and the definition of [[Stakeholder Needs and Requirements]] and generally consist of the development of [[System Requirement (glossary)|system requirements (glossary)]] that consist of the refinement and translation of the [[Stakeholder Requirement (glossary)|stakeholder requirements (glossary)]] into [[System Requirement (glossary)|system (technical) requirements]]. These system requirements are then used as inputs for the [[Architectural Design: Logical|logical architecture design]], which includes functional, behavioral, temporal, and physical architectural aspects. [[System Analysis]] studies are performed to evaluate and select the potential system elements that compose the system and are the most suitable. System analysis is intended to provide a best value, balanced solution involving all relevant engineering elements (stakeholder requirements, system requirements, and design properties). For the concept definition, an appropriate architecture framework representation can be useful, such as DoDAF Operations View, Zachman Framework (Rows1 and 2), and TOGAF ADM Phase A and B within the Concept Definition when performing Mission Analysis and Stakeholders Needs and Requirements.<br />
<br />
===Bottom-Up Approach: Evolution of the Solution===<br />
<br />
In some situations, the concept definition activities determine the need to evolve existing capabilities or add new capabilities to an existing system. During the concept definition, the alternatives to address the need are evaaluated and engineers are then led to reconsider the system definition in order to modify or adapt some structural, functional, behavioral, or temporal properties during the [[Product (glossary)|product (glossary)]] or [[Service (glossary)|service (glossary)]] life cycle to adapt to a changing [[context (glossary)|context (glossary)]] of use or for the purpose of improving existing solutions. [[Reverse Engineering (glossary)|Reverse engineering (glossary)]] is often necessary to enable system engineers to (re)characterize the properties of the system of interest (SoI) or its elements; this is an important step to ensure that system engineers understand the SoI before beginning modification. (For more information on system definition, please see [[System Definition]].)<br />
<br />
A bottom-up approach is necessary for analysis purposes, or for (re)using existing elements in the design [[architecture (glossary)|architecture (glossary)]]. Changes in the context of use or a need for improvement can prompt this. In contrast, a top-down approach is generally used to define an initial design solution corresponding to a problem or a set of needs.<br />
<br />
Bottom-up and top-down approaches can be, and often are, mixed.<br />
<br />
===Separation and Iteration between Problem and Solution===<br />
<br />
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 Analysis|System analysis]] activities are used to perform the link between problems and solutions. <br />
<br />
As systems generally integrate existing and new [[System Element (glossary)|system elements (glossary)]], a bottom-up approach can be combined with a top-down approach to take into account legacy elements, as well as to identify the services and capabilities they provide in order to define applicable interface requirements and constraints. As discussed in [[System Life Cycle Process Models: Iterative]], this is iterative for these evolutionary systems. <br />
<br />
For more details about systems approaches, please see the [[Systems Approach Applied to Engineered Systems | Systems Approach Applied to Engineered Systems]] Knowledge Area. In addition, the references “What Is the Systems Approach?” (Jackson, Hitchins, Eisner 2010, 41-43) and ''A 21st Century Systems Methodology'' (Hitchins 2007) are recommended.<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
Kossiakoff, A, and W. Sweet. 2009. ''Systems Engineering: Principles and Practice.'' Hoboken, NJ, USA: John Wiley and Sons. <br />
<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley & Sons.<br />
<br />
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight'' (April 2010): 41-43.<br />
<br />
===Primary References===<br />
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).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ANSI/EIA. 1998. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA 632-1998. <br />
<br />
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 Electronical Commission (IEC), ISO/IEC 19760:2003 (E). <br />
<br />
ISO/IEC. 2007. Systems Engineering – Application and Management of The Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007. <br />
<br />
NASA. 2007. Systems Engineering Handbook. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.<br />
<br />
===Additional References===<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley & Sons.<br />
<br />
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight'' (April 2010): 41-43.<br />
<br />
----<br />
<center>[[Lean Engineering|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[Mission Analysis|Next Article >]]</center><br />
<br />
==Comments from SEBoK 0.5==<br />
This article is new to the SEBoK for version 0.75. As such, there are no associated 0.5 comments. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
{{DISQUS}}<br />
<br />
<br />
[[Category:Part 3]][[Category:Knowledge Area]]</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_or_Mission_Analysis&diff=38113Business or Mission Analysis2012-08-06T22:34:01Z<p>Groedler: /* Mission Analysis and Concept of Operations */</p>
<hr />
<div>The starting point of engineering any [[System of Interest (SoI) (glossary)|system of interest (SoI)]] is understanding the socio-economic and technological context wherein potential problems or opportunities reside. The enterprise strategic goals and [[Stakeholder (glossary)| stakeholders’]] needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], and [[Customer (glossary)|customers]]. An important set of activities, called [[Mission Analysis (glossary)|mission analysis]] ([[Acronyms|MA]]) (also called [[Market Analysis (glossary)|market analysis]] or business anlaysis in certain domains or sectors), is often performed iteratively with [[Stakeholder Needs and Requirements]] generation to better understand the problem (or opportunity) space, as well as the solution space. The execution of this process enables a systems engineer to then establish a set of [[Stakeholder Requirement (glossary)| stakeholder requirements]] for a potential SoI, or other solution, that could provide a capability or service needed by the acquirer, the users, and the other stakeholders in a defined environment. <br />
<br />
MA is part of the larger set of [[Concept Definition|concept definition]] activities. [[Concept Definition|Concept definition]] is the phase of systems engineering in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the [[System of Interest (SoI) (glossary)|system of interest]] is developed. In fact, the activities of concept definition determine whether the enterprise strategic goals and stakeholder needs will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution. Mission analysis focuses on the identification of the primary purpose(s) of the solution, while [[Stakeholder Needs and Requirements]] definition explores what capabilities stakeholders desire and may include some detail on the performance of certain aspects of the solution.<br />
<br />
== Purpose and Definition ==<br />
The purpose of MA is to understand a mission/market problem or opportunity, analyze the solution space, and initiate the life cycle of a potential solution that could answer the problem or take advantage of an opportunity.<br />
<br />
MA, known in some domains as [[Market Analysis (glossary)|market analysis (glossary)]] or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise. The definition of a mission need in a problem space frames the solution, both in terms of the direct application to the mission or business function, and in terms of the context for the resulting solution. MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. It characterizes the operational need in terms of mission description/provisions and the environment/context the need exists within, together with the proposed enterprise concept of operations and operational scenarios. The primary products of MA are the revised Concept of Operations ([[Concept of Operations (ConOps) (glossary)|ConOps]]) of the enterprise, the [[Operational Concept (glossary)|Operational Concept]], the [[Operational Scenario (glossary)|Operational Scenarios]] for the mission, and the context in which the solution will exist. <br />
<br />
MA may include mathematical analysis, modeling, simulation, visualization, and other analytical tools to characterize the intended mission and determine how to best achieve the needs/objectives. MA evaluates alternative approaches to determine which alternative approach best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions). Thus, MA defines the problem space and analyzes the solution space alternatives using quality attribute constraints driven by the enterprise objectives.<br />
<br />
==Principles and Concepts==<br />
===Mission Analysis and Concept of Operations===<br />
MA and the [[Concept of Operations (ConOps) (glossary)|ConOps]] are broadly used in defense and aerospace organizations to analyze and define how the system is intended to operate, as well as how the major operations or operational scenarios are intended to be performed, taking into account the strategic, operational, and tactical aspects of the identified scenarios. MA is a type of strategic or operations analysis related to needs, capability gaps, or opportnities and solutions that can be applied to any organization that evolves its strategy for its business objectives.<br />
<br />
In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering ([[Acronyms|SE]]) leaders interact with enterprise leaders and operations analysts to understand: <br />
*the enterprise ConOps and future mission, business, and operational (MBO) objectives; <br />
*the characterization of the Operational Concept and objectives (i.e., constraints, mission or operational scenarios, tasks, resources, risks, assumptions, and related missions or operations); and<br />
*how specific missions or operations are currently conducted and what gaps exist in those areas.<br />
<br />
They then conceptually explore and select from alternative candidate solutions. This interaction ensures a full understanding of both the problem space and the solution space. The alternative candidate solutions can include a wide range of approaches to address the need, as well as variants for an approach to optimize specific characteristics (e.g., using a different distribution of satellite orbit parameters to maximize coverage or events while minimizing the number of satellites). Analysis, modeling and simulation, and trade studies are employed to select alternative approaches (Charter of the Mission Analysis Committee, National Defense Industrial Association, Systems Engineering Division).<br />
<br />
"The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems (as black boxes) to forward the organization's goals and objectives. The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations within the business in regards to the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of future business and systems” (ISO/IEC 2011). <br />
<br />
These notions are also used in industrial sectors, such as aviation administrations and aeronautic transportation, health care systems, space, etc., with adapted definitions and/or terms, such as operational concepts, usage concepts and/or technological concepts. For example, “mission analysis” is the term used to describe the mathematical analysis of satellite orbits performed to determine how best to achieve the objectives of a space mission (European Space Agency).<br />
<br />
In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:<br />
<br />
<blockquote>''. . . studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and this in turn of the global environmental analysis. Through all these analyses, the chances, strengths, weaknesses, and risks of a company can be identified. Finally, with the help of a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm's planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company.'' (Wikipedia, 02/12/12)</blockquote><br />
<br />
Anywhere these notions are used, it is evident that they are based on fundamental concepts, such as the [[Operational Mode (glossary)|operational mode]] (or state of the system), [[Scenario (glossary)|scenario]] (of actions), the enterprise level concept of operations and the system level operational concepts, [[Function (glossary) |functions]] (providing services), etc. For more explanations about the concept of operations and operational concept, refer to ''Systems and Software Engineering - Requirements Engineering'' (ISO/IEC 2011); useful information can be found in Annex A, "System Operational Concept", and Annex B, "Concept of Operations" (ISO/IEC 2011).<br />
<br />
===Mission Analysis as Part of Enterprise Strategy Development===<br />
Periodically, most enterprises re-evaluate their strategy with respect to their mission, vision, and positioning to accomplish their goals. Figure 1 shows the interactions of the enterprise strategy development and the concept definition, including MA and stakeholder needs and requirements that are involved in an iterative manner to fully develop the strategy and define future capabilities and solutions. As the enterprise evolves the strategy, it is essential to conduct the supporting MA or strategic analysis for each element of the enterprise to determine their readiness to achieve their future objectives. This analysis examines the current state to identify any problems or opportunities related to the objective achievement and aids the enterprise in fully understanding and defining the problem space. The analysis examines the external environment and interfaces in search of impacts and trends, as well as the internal enterprise to gauge its capabilities and value stream gaps. Additionally, a SWOT analysis may be performed to weigh the strengths, weaknesses, opportunities, and threats. As the problem space is defined, stakeholder needs and requirements activities are performed to define the stakeholder needs and transform them into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, the future state of core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities (see [[Stakeholder Needs and Requirements]] for more information). Finally, MA is engaged again to examine the solution space. Candidate solutions that span the potential solution space are identified, from simple operational changes, to various system developments or modifications. Various techniques are applied to analyze the candidates, understand their feasibility and value, and select the best alternative.<br />
<br />
[[File:Enterprise_Strategy_and_Concept_Development.PNG|thumb|700px|center|Figure 1. Enterprise Strategy and Concept Development (Roedler 2012) Reprinted with permission of Garry Roedler]]<br />
<br />
==Process Approach==<br />
===Activities of the Process===<br />
It is necessary to perform the following major activities and tasks during this process: <br />
#Review and understand the enterprise mission, vision, and ConOps.<br />
#Identify and define any gaps and opportunities related to future evolution of the strategy:<br />
##Examine the current state to identify any problems or opportunities related to the objective achievement, including any deficiencies of the existing system.<br />
##Analyze the context of the actual PESTAL factors (Political, Economic, Social, Technological, Environmental, and Legal), while studying sensitive factors such as cost and effectiveness, security and safety improvement, performance improvement or lack of existing systems, market opportunities, regulation changes, users' dissatisfaction, etc. External, internal, and SWOT analysis should be included as well.<br />
##Define any mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without thinking to solution. <br />
#Examine and evaluate the solution space.<br />
##Identify the main stakeholders (customers, users, administrations, regulations, etc.).<br />
##Identify high level operational modes or states, or potential use cases.<br />
##Identify candidate solutions that span the potential solution space, from simple operational changes, to various system developments or modifications. Identify existing systems, products, and services that may address the need for operational or functional modifications. Deduce what potential expected services may be needed. A potential and not yet existing product, service or enterprise is called the "system-of-interest" (SoI). Additionally, the solution could be an operational change or a change to an existing product or service.<br />
#Perform appropriate modeling, simulation, and analytical techniques to understand the feasibility and value of the alternative candidate solutions. Model or simulate operational scenarios from these services and use cases, and enrich them through reviews with stakeholders and subject matter experts.<br />
#Define basic operational concept or market strategy, and/or business models.<br />
##From previous modeled operational scenarios and operational modes, deduce and express the usage of operational concepts, or technical concepts.<br />
##Collect and enrich needs, expectations, scenarios, and constraints.<br />
##Validate the mission of any potential SoI in the context of any proposed market strategy or business model.<br />
#Evaluate the set of alternatives and select the best alternative.<br />
##Perform a trade study of the alternatives to discriminate between the alternatives.<br />
#Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.<br />
<br />
===Mission Analysis Artifacts===<br />
<br />
This process may create several artifacts, such as:<br />
*recommendations for revisions to the enterprise ConOps;<br />
*preliminary operational concept document or inputs;<br />
*mission analysis and definition reports;<br />
*system analysis artifacts (e.g., use case diagrams, context diagrams, sequence/activity diagrams, functional flow block diagrams);<br />
*trade study results (alternatives analysis); and<br />
*market study/analysis reports.<br />
<br />
===Methods and Modeling Techniques===<br />
<br />
MA uses techniques, such as:<br />
<br />
*use case analysis;<br />
*operational analysis; <br />
*functional analysis;<br />
*technical documentation review;<br />
*trade studies;<br />
*modeling;<br />
*simulation;<br />
*prototyping;<br />
*workshops, interviews, and questionnaires;<br />
*market competitive assessments;<br />
*benchmarking; and<br />
*organizational analysis techniques (e.g., strengths, weaknesses, opportunities, threats (SWOT analysis), and product portfolios).<br />
<br />
==Practical Considerations==<br />
Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1. <br />
<br />
<center><br />
{|<br />
|+'''Table 1. Major Pitfalls with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|Wrong level of system addressed<br />
|When delineating the boundaries of the system-of-interest and defining the mission and purpose of the system at the very beginning of systems engineering, a classic mistake is to place the system-of-interest at the wrong level of abstraction. The level of abstraction can be too high or too low (sitting respectively in the upper-system or in a sub-system). This is the consequence of the principle stating that a system is always included in a larger system and of confusing the purpose and the mission of the system-of-interest.<br />
|-<br />
|Operational modes or scenarios missing<br />
|In commercial products or systems, the lack or insufficient description of operational modes and scenarios (how the system-of-interest will be used, in which situations, etc.) is often encountered.<br />
|}<br />
</center><br />
<br />
<br />
Proven practices with mission analysis and marketing analysis are presented in Table 2.<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Proven Practices with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|Models of operational scenarios<br />
|Using modeling techniques as indicated in sections above for operational scenarios in any kind of system-of-interest (including commercial systems).<br />
|-<br />
|Models of the context<br />
|Consider the context of use as a system and force oneself to use modeling techniques for main aspects of the context (functional, behavioral, physical, etc.).<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Freeman, Richard, “Achieving Strategic Aims: Moving Toward a Process Based Military Enterprise”<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering -- Life cycle processes -- Requirements engineering'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC/IEEE 29148:2011<br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
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.<br />
<br />
Kaplan, Robert S. and Norton, David P., “Developing the Strategy: Vision, Value Gaps, and Analysis”, Balanced Scorecard Report, Harvard Business School Publishing, Jan-Feb 2008<br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A simple method for phased mission analysis." ''Reliability Engineering & System Safety'' 45(3): 299-309.<br />
<br />
National Defense Industrial Association, Systems Engineering Division, Mission Analysis Committee, “Mission Analysis Committee Charter”<br />
<br />
Shupp, Jeffrey K., “The Mission Analysis Discipline: Bringing focus to the fuzziness about Attaining Good Architectures”, Proceedings of INCOSE 13th International Symposium, July 2003.<br />
<br />
Wikipedia, “Market Analysis”, 12 February 2012.<br />
<br />
===Primary References===<br />
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).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
Center for Quality Management. 1993. "Special Issue on Kano's Methods for Understanding Customer Defined Quality." ''Center for Quality Management Journal'' 2(4) (Fall 1993). <br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering.'' 3rd ed. London, UK: Springer.<br />
<br />
Kano, N. 1984. "Attractive Quality and Must-Be Quality." ''Quality JSQC'' 14(2) (October 1984). <br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309. <br />
<br />
Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques," in ''Software Engineering''. New York, NY: McGraw-Hill.<br />
<br />
MITRE. 2011. "Concept Development." ''Systems Engineering Guide. '' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/]].<br />
<br />
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/]].<br />
<br />
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]].<br />
----<br />
<center>[[Concept Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Stakeholder Needs and Requirements|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Concept Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_or_Mission_Analysis&diff=38104Business or Mission Analysis2012-08-06T22:21:12Z<p>Groedler: /* Purpose and Definition */</p>
<hr />
<div>The starting point of engineering any [[System of Interest (SoI) (glossary)|system of interest (SoI)]] is understanding the socio-economic and technological context wherein potential problems or opportunities reside. The enterprise strategic goals and [[Stakeholder (glossary)| stakeholders’]] needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], and [[Customer (glossary)|customers]]. An important set of activities, called [[Mission Analysis (glossary)|mission analysis]] ([[Acronyms|MA]]) (also called [[Market Analysis (glossary)|market analysis]] or business anlaysis in certain domains or sectors), is often performed iteratively with [[Stakeholder Needs and Requirements]] generation to better understand the problem (or opportunity) space, as well as the solution space. The execution of this process enables a systems engineer to then establish a set of [[Stakeholder Requirement (glossary)| stakeholder requirements]] for a potential SoI, or other solution, that could provide a capability or service needed by the acquirer, the users, and the other stakeholders in a defined environment. <br />
<br />
MA is part of the larger set of [[Concept Definition|concept definition]] activities. [[Concept Definition|Concept definition]] is the phase of systems engineering in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the [[System of Interest (SoI) (glossary)|system of interest]] is developed. In fact, the activities of concept definition determine whether the enterprise strategic goals and stakeholder needs will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution. Mission analysis focuses on the identification of the primary purpose(s) of the solution, while [[Stakeholder Needs and Requirements]] definition explores what capabilities stakeholders desire and may include some detail on the performance of certain aspects of the solution.<br />
<br />
== Purpose and Definition ==<br />
The purpose of MA is to understand a mission/market problem or opportunity, analyze the solution space, and initiate the life cycle of a potential solution that could answer the problem or take advantage of an opportunity.<br />
<br />
MA, known in some domains as [[Market Analysis (glossary)|market analysis (glossary)]] or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise. The definition of a mission need in a problem space frames the solution, both in terms of the direct application to the mission or business function, and in terms of the context for the resulting solution. MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. It characterizes the operational need in terms of mission description/provisions and the environment/context the need exists within, together with the proposed enterprise concept of operations and operational scenarios. The primary products of MA are the revised Concept of Operations ([[Concept of Operations (ConOps) (glossary)|ConOps]]) of the enterprise, the [[Operational Concept (glossary)|Operational Concept]], the [[Operational Scenario (glossary)|Operational Scenarios]] for the mission, and the context in which the solution will exist. <br />
<br />
MA may include mathematical analysis, modeling, simulation, visualization, and other analytical tools to characterize the intended mission and determine how to best achieve the needs/objectives. MA evaluates alternative approaches to determine which alternative approach best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions). Thus, MA defines the problem space and analyzes the solution space alternatives using quality attribute constraints driven by the enterprise objectives.<br />
<br />
==Principles and Concepts==<br />
===Mission Analysis and Concept of Operations===<br />
MA and the [[Concept of Operations (ConOps) (glossary)|ConOps]] are broadly used in defense and aerospace organizations to analyze and define how the system is intended to operate, as well as how the major operations or operational scenarios are intended to be performed, taking into account the strategic, operational, and tactical aspects of the identified scenarios. MA is a type of strategic or operations analysis related to needs or capability gaps and solutions that can be applied to any organization that evolves its strategy for its business objectives.<br />
<br />
In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering ([[Acronyms|SE]]) leaders interact with enterprise leaders and operations analysts to understand: <br />
*the enterprise ConOps and future mission, business, and operational (MBO) objectives; <br />
*the characterization of the Operational Concept and objectives (i.e., constraints, mission or operational scenarios, tasks, resources, risks, assumptions, and related missions or operations); and<br />
*how specific missions or operations are currently conducted and what gaps exist in those areas.<br />
<br />
They then conceptually explore and select from alternative candidate solutions. This interaction ensures a full understanding of both the problem space and the solution space. The alternative candidate solutions can include a wide range of approaches to address the need, as well as variants for an approach to optimize specific characteristics (e.g., using a different distribution of satellite orbit parameters to maximize coverage or events while minimizing the number of satellites). Analysis, modeling and simulation, and trade studies are employed to select alternative approaches (Charter of the Mission Analysis Committee, National Defense Industrial Association, Systems Engineering Division).<br />
<br />
"The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems (as black boxes) to forward the organization's goals and objectives. The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations within the business in regards to the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of future business and systems” (ISO/IEC 2011). <br />
<br />
These notions are also used in industrial sectors, such as aviation administrations and aeronautic transportation, health care systems, space, etc., with adapted definitions and/or terms, such as operational concepts, usage concepts and/or technological concepts. For example, “mission analysis” is the term used to describe the mathematical analysis of satellite orbits performed to determine how best to achieve the objectives of a space mission (European Space Agency).<br />
<br />
In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:<br />
<br />
<blockquote>''. . . studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and this in turn of the global environmental analysis. Through all these analyses, the chances, strengths, weaknesses, and risks of a company can be identified. Finally, with the help of a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm's planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company.'' (Wikipedia, 02/12/12)</blockquote><br />
<br />
Anywhere these notions are used, it is evident that they are based on fundamental concepts, such as the [[Operational Mode (glossary)|operational mode]] (or state of the system), [[Scenario (glossary)|scenario]] (of actions), the enterprise level concept of operations and the system level operational concepts, [[Function (glossary) |functions]] (providing services), etc. For more explanations about the concept of operations and operational concept, refer to ''Systems and Software Engineering - Requirements Engineering'' (ISO/IEC 2011); useful information can be found in Annex A, "System Operational Concept", and Annex B, "Concept of Operations" (ISO/IEC 2011).<br />
<br />
===Mission Analysis as Part of Enterprise Strategy Development===<br />
Periodically, most enterprises re-evaluate their strategy with respect to their mission, vision, and positioning to accomplish their goals. Figure 1 shows the interactions of the enterprise strategy development and the concept definition, including MA and stakeholder needs and requirements that are involved in an iterative manner to fully develop the strategy and define future capabilities and solutions. As the enterprise evolves the strategy, it is essential to conduct the supporting MA or strategic analysis for each element of the enterprise to determine their readiness to achieve their future objectives. This analysis examines the current state to identify any problems or opportunities related to the objective achievement and aids the enterprise in fully understanding and defining the problem space. The analysis examines the external environment and interfaces in search of impacts and trends, as well as the internal enterprise to gauge its capabilities and value stream gaps. Additionally, a SWOT analysis may be performed to weigh the strengths, weaknesses, opportunities, and threats. As the problem space is defined, stakeholder needs and requirements activities are performed to define the stakeholder needs and transform them into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, the future state of core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities (see [[Stakeholder Needs and Requirements]] for more information). Finally, MA is engaged again to examine the solution space. Candidate solutions that span the potential solution space are identified, from simple operational changes, to various system developments or modifications. Various techniques are applied to analyze the candidates, understand their feasibility and value, and select the best alternative.<br />
<br />
[[File:Enterprise_Strategy_and_Concept_Development.PNG|thumb|700px|center|Figure 1. Enterprise Strategy and Concept Development (Roedler 2012) Reprinted with permission of Garry Roedler]]<br />
<br />
==Process Approach==<br />
===Activities of the Process===<br />
It is necessary to perform the following major activities and tasks during this process: <br />
#Review and understand the enterprise mission, vision, and ConOps.<br />
#Identify and define any gaps and opportunities related to future evolution of the strategy:<br />
##Examine the current state to identify any problems or opportunities related to the objective achievement, including any deficiencies of the existing system.<br />
##Analyze the context of the actual PESTAL factors (Political, Economic, Social, Technological, Environmental, and Legal), while studying sensitive factors such as cost and effectiveness, security and safety improvement, performance improvement or lack of existing systems, market opportunities, regulation changes, users' dissatisfaction, etc. External, internal, and SWOT analysis should be included as well.<br />
##Define any mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without thinking to solution. <br />
#Examine and evaluate the solution space.<br />
##Identify the main stakeholders (customers, users, administrations, regulations, etc.).<br />
##Identify high level operational modes or states, or potential use cases.<br />
##Identify candidate solutions that span the potential solution space, from simple operational changes, to various system developments or modifications. Identify existing systems, products, and services that may address the need for operational or functional modifications. Deduce what potential expected services may be needed. A potential and not yet existing product, service or enterprise is called the "system-of-interest" (SoI). Additionally, the solution could be an operational change or a change to an existing product or service.<br />
#Perform appropriate modeling, simulation, and analytical techniques to understand the feasibility and value of the alternative candidate solutions. Model or simulate operational scenarios from these services and use cases, and enrich them through reviews with stakeholders and subject matter experts.<br />
#Define basic operational concept or market strategy, and/or business models.<br />
##From previous modeled operational scenarios and operational modes, deduce and express the usage of operational concepts, or technical concepts.<br />
##Collect and enrich needs, expectations, scenarios, and constraints.<br />
##Validate the mission of any potential SoI in the context of any proposed market strategy or business model.<br />
#Evaluate the set of alternatives and select the best alternative.<br />
##Perform a trade study of the alternatives to discriminate between the alternatives.<br />
#Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.<br />
<br />
===Mission Analysis Artifacts===<br />
<br />
This process may create several artifacts, such as:<br />
*recommendations for revisions to the enterprise ConOps;<br />
*preliminary operational concept document or inputs;<br />
*mission analysis and definition reports;<br />
*system analysis artifacts (e.g., use case diagrams, context diagrams, sequence/activity diagrams, functional flow block diagrams);<br />
*trade study results (alternatives analysis); and<br />
*market study/analysis reports.<br />
<br />
===Methods and Modeling Techniques===<br />
<br />
MA uses techniques, such as:<br />
<br />
*use case analysis;<br />
*operational analysis; <br />
*functional analysis;<br />
*technical documentation review;<br />
*trade studies;<br />
*modeling;<br />
*simulation;<br />
*prototyping;<br />
*workshops, interviews, and questionnaires;<br />
*market competitive assessments;<br />
*benchmarking; and<br />
*organizational analysis techniques (e.g., strengths, weaknesses, opportunities, threats (SWOT analysis), and product portfolios).<br />
<br />
==Practical Considerations==<br />
Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1. <br />
<br />
<center><br />
{|<br />
|+'''Table 1. Major Pitfalls with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|Wrong level of system addressed<br />
|When delineating the boundaries of the system-of-interest and defining the mission and purpose of the system at the very beginning of systems engineering, a classic mistake is to place the system-of-interest at the wrong level of abstraction. The level of abstraction can be too high or too low (sitting respectively in the upper-system or in a sub-system). This is the consequence of the principle stating that a system is always included in a larger system and of confusing the purpose and the mission of the system-of-interest.<br />
|-<br />
|Operational modes or scenarios missing<br />
|In commercial products or systems, the lack or insufficient description of operational modes and scenarios (how the system-of-interest will be used, in which situations, etc.) is often encountered.<br />
|}<br />
</center><br />
<br />
<br />
Proven practices with mission analysis and marketing analysis are presented in Table 2.<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Proven Practices with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|Models of operational scenarios<br />
|Using modeling techniques as indicated in sections above for operational scenarios in any kind of system-of-interest (including commercial systems).<br />
|-<br />
|Models of the context<br />
|Consider the context of use as a system and force oneself to use modeling techniques for main aspects of the context (functional, behavioral, physical, etc.).<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Freeman, Richard, “Achieving Strategic Aims: Moving Toward a Process Based Military Enterprise”<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering -- Life cycle processes -- Requirements engineering'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC/IEEE 29148:2011<br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
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.<br />
<br />
Kaplan, Robert S. and Norton, David P., “Developing the Strategy: Vision, Value Gaps, and Analysis”, Balanced Scorecard Report, Harvard Business School Publishing, Jan-Feb 2008<br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A simple method for phased mission analysis." ''Reliability Engineering & System Safety'' 45(3): 299-309.<br />
<br />
National Defense Industrial Association, Systems Engineering Division, Mission Analysis Committee, “Mission Analysis Committee Charter”<br />
<br />
Shupp, Jeffrey K., “The Mission Analysis Discipline: Bringing focus to the fuzziness about Attaining Good Architectures”, Proceedings of INCOSE 13th International Symposium, July 2003.<br />
<br />
Wikipedia, “Market Analysis”, 12 February 2012.<br />
<br />
===Primary References===<br />
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).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
Center for Quality Management. 1993. "Special Issue on Kano's Methods for Understanding Customer Defined Quality." ''Center for Quality Management Journal'' 2(4) (Fall 1993). <br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering.'' 3rd ed. London, UK: Springer.<br />
<br />
Kano, N. 1984. "Attractive Quality and Must-Be Quality." ''Quality JSQC'' 14(2) (October 1984). <br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309. <br />
<br />
Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques," in ''Software Engineering''. New York, NY: McGraw-Hill.<br />
<br />
MITRE. 2011. "Concept Development." ''Systems Engineering Guide. '' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/]].<br />
<br />
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/]].<br />
<br />
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]].<br />
----<br />
<center>[[Concept Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Stakeholder Needs and Requirements|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Concept Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_or_Mission_Analysis&diff=38103Business or Mission Analysis2012-08-06T22:17:06Z<p>Groedler: /* Purpose and Definition */</p>
<hr />
<div>The starting point of engineering any [[System of Interest (SoI) (glossary)|system of interest (SoI)]] is understanding the socio-economic and technological context wherein potential problems or opportunities reside. The enterprise strategic goals and [[Stakeholder (glossary)| stakeholders’]] needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], and [[Customer (glossary)|customers]]. An important set of activities, called [[Mission Analysis (glossary)|mission analysis]] ([[Acronyms|MA]]) (also called [[Market Analysis (glossary)|market analysis]] or business anlaysis in certain domains or sectors), is often performed iteratively with [[Stakeholder Needs and Requirements]] generation to better understand the problem (or opportunity) space, as well as the solution space. The execution of this process enables a systems engineer to then establish a set of [[Stakeholder Requirement (glossary)| stakeholder requirements]] for a potential SoI, or other solution, that could provide a capability or service needed by the acquirer, the users, and the other stakeholders in a defined environment. <br />
<br />
MA is part of the larger set of [[Concept Definition|concept definition]] activities. [[Concept Definition|Concept definition]] is the phase of systems engineering in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the [[System of Interest (SoI) (glossary)|system of interest]] is developed. In fact, the activities of concept definition determine whether the enterprise strategic goals and stakeholder needs will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution. Mission analysis focuses on the identification of the primary purpose(s) of the solution, while [[Stakeholder Needs and Requirements]] definition explores what capabilities stakeholders desire and may include some detail on the performance of certain aspects of the solution.<br />
<br />
== Purpose and Definition ==<br />
The purpose of MA is to understand a problem or opportunity, analyze the solution space, and initiate the life cycle of a potential solution that could answer the problem or take advantage of an opportunity.<br />
<br />
MA, known in some domains as [[Market Analysis (glossary)|market analysis (glossary)]] or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise. The definition of a mission need in a problem space frames the solution, both in terms of the direct application to the mission or business function, and in terms of the context for the resulting solution. MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. It characterizes the operational need in terms of mission description/provisions and the environment/context the need exists within, together with the proposed enterprise concept of operations and operational scenarios. The primary products of MA are the revised Concept of Operations ([[Concept of Operations (ConOps) (glossary)|ConOps]]) of the enterprise, the [[Operational Concept (glossary)|Operational Concept]], the [[Operational Scenario (glossary)|Operational Scenarios]] for the mission, and the context in which the solution will exist. <br />
<br />
MA may include mathematical analysis, modeling, simulation, visualization, and other analytical tools to characterize the intended mission and determine how to best achieve the needs/objectives. MA evaluates alternative approaches to determine which alternative approach best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions). Thus, MA defines the problem space and analyzes the solution space alternatives using quality attribute constraints driven by the enterprise objectives.<br />
<br />
==Principles and Concepts==<br />
===Mission Analysis and Concept of Operations===<br />
MA and the [[Concept of Operations (ConOps) (glossary)|ConOps]] are broadly used in defense and aerospace organizations to analyze and define how the system is intended to operate, as well as how the major operations or operational scenarios are intended to be performed, taking into account the strategic, operational, and tactical aspects of the identified scenarios. MA is a type of strategic or operations analysis related to needs or capability gaps and solutions that can be applied to any organization that evolves its strategy for its business objectives.<br />
<br />
In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering ([[Acronyms|SE]]) leaders interact with enterprise leaders and operations analysts to understand: <br />
*the enterprise ConOps and future mission, business, and operational (MBO) objectives; <br />
*the characterization of the Operational Concept and objectives (i.e., constraints, mission or operational scenarios, tasks, resources, risks, assumptions, and related missions or operations); and<br />
*how specific missions or operations are currently conducted and what gaps exist in those areas.<br />
<br />
They then conceptually explore and select from alternative candidate solutions. This interaction ensures a full understanding of both the problem space and the solution space. The alternative candidate solutions can include a wide range of approaches to address the need, as well as variants for an approach to optimize specific characteristics (e.g., using a different distribution of satellite orbit parameters to maximize coverage or events while minimizing the number of satellites). Analysis, modeling and simulation, and trade studies are employed to select alternative approaches (Charter of the Mission Analysis Committee, National Defense Industrial Association, Systems Engineering Division).<br />
<br />
"The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems (as black boxes) to forward the organization's goals and objectives. The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations within the business in regards to the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of future business and systems” (ISO/IEC 2011). <br />
<br />
These notions are also used in industrial sectors, such as aviation administrations and aeronautic transportation, health care systems, space, etc., with adapted definitions and/or terms, such as operational concepts, usage concepts and/or technological concepts. For example, “mission analysis” is the term used to describe the mathematical analysis of satellite orbits performed to determine how best to achieve the objectives of a space mission (European Space Agency).<br />
<br />
In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:<br />
<br />
<blockquote>''. . . studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and this in turn of the global environmental analysis. Through all these analyses, the chances, strengths, weaknesses, and risks of a company can be identified. Finally, with the help of a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm's planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company.'' (Wikipedia, 02/12/12)</blockquote><br />
<br />
Anywhere these notions are used, it is evident that they are based on fundamental concepts, such as the [[Operational Mode (glossary)|operational mode]] (or state of the system), [[Scenario (glossary)|scenario]] (of actions), the enterprise level concept of operations and the system level operational concepts, [[Function (glossary) |functions]] (providing services), etc. For more explanations about the concept of operations and operational concept, refer to ''Systems and Software Engineering - Requirements Engineering'' (ISO/IEC 2011); useful information can be found in Annex A, "System Operational Concept", and Annex B, "Concept of Operations" (ISO/IEC 2011).<br />
<br />
===Mission Analysis as Part of Enterprise Strategy Development===<br />
Periodically, most enterprises re-evaluate their strategy with respect to their mission, vision, and positioning to accomplish their goals. Figure 1 shows the interactions of the enterprise strategy development and the concept definition, including MA and stakeholder needs and requirements that are involved in an iterative manner to fully develop the strategy and define future capabilities and solutions. As the enterprise evolves the strategy, it is essential to conduct the supporting MA or strategic analysis for each element of the enterprise to determine their readiness to achieve their future objectives. This analysis examines the current state to identify any problems or opportunities related to the objective achievement and aids the enterprise in fully understanding and defining the problem space. The analysis examines the external environment and interfaces in search of impacts and trends, as well as the internal enterprise to gauge its capabilities and value stream gaps. Additionally, a SWOT analysis may be performed to weigh the strengths, weaknesses, opportunities, and threats. As the problem space is defined, stakeholder needs and requirements activities are performed to define the stakeholder needs and transform them into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, the future state of core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities (see [[Stakeholder Needs and Requirements]] for more information). Finally, MA is engaged again to examine the solution space. Candidate solutions that span the potential solution space are identified, from simple operational changes, to various system developments or modifications. Various techniques are applied to analyze the candidates, understand their feasibility and value, and select the best alternative.<br />
<br />
[[File:Enterprise_Strategy_and_Concept_Development.PNG|thumb|700px|center|Figure 1. Enterprise Strategy and Concept Development (Roedler 2012) Reprinted with permission of Garry Roedler]]<br />
<br />
==Process Approach==<br />
===Activities of the Process===<br />
It is necessary to perform the following major activities and tasks during this process: <br />
#Review and understand the enterprise mission, vision, and ConOps.<br />
#Identify and define any gaps and opportunities related to future evolution of the strategy:<br />
##Examine the current state to identify any problems or opportunities related to the objective achievement, including any deficiencies of the existing system.<br />
##Analyze the context of the actual PESTAL factors (Political, Economic, Social, Technological, Environmental, and Legal), while studying sensitive factors such as cost and effectiveness, security and safety improvement, performance improvement or lack of existing systems, market opportunities, regulation changes, users' dissatisfaction, etc. External, internal, and SWOT analysis should be included as well.<br />
##Define any mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without thinking to solution. <br />
#Examine and evaluate the solution space.<br />
##Identify the main stakeholders (customers, users, administrations, regulations, etc.).<br />
##Identify high level operational modes or states, or potential use cases.<br />
##Identify candidate solutions that span the potential solution space, from simple operational changes, to various system developments or modifications. Identify existing systems, products, and services that may address the need for operational or functional modifications. Deduce what potential expected services may be needed. A potential and not yet existing product, service or enterprise is called the "system-of-interest" (SoI). Additionally, the solution could be an operational change or a change to an existing product or service.<br />
#Perform appropriate modeling, simulation, and analytical techniques to understand the feasibility and value of the alternative candidate solutions. Model or simulate operational scenarios from these services and use cases, and enrich them through reviews with stakeholders and subject matter experts.<br />
#Define basic operational concept or market strategy, and/or business models.<br />
##From previous modeled operational scenarios and operational modes, deduce and express the usage of operational concepts, or technical concepts.<br />
##Collect and enrich needs, expectations, scenarios, and constraints.<br />
##Validate the mission of any potential SoI in the context of any proposed market strategy or business model.<br />
#Evaluate the set of alternatives and select the best alternative.<br />
##Perform a trade study of the alternatives to discriminate between the alternatives.<br />
#Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.<br />
<br />
===Mission Analysis Artifacts===<br />
<br />
This process may create several artifacts, such as:<br />
*recommendations for revisions to the enterprise ConOps;<br />
*preliminary operational concept document or inputs;<br />
*mission analysis and definition reports;<br />
*system analysis artifacts (e.g., use case diagrams, context diagrams, sequence/activity diagrams, functional flow block diagrams);<br />
*trade study results (alternatives analysis); and<br />
*market study/analysis reports.<br />
<br />
===Methods and Modeling Techniques===<br />
<br />
MA uses techniques, such as:<br />
<br />
*use case analysis;<br />
*operational analysis; <br />
*functional analysis;<br />
*technical documentation review;<br />
*trade studies;<br />
*modeling;<br />
*simulation;<br />
*prototyping;<br />
*workshops, interviews, and questionnaires;<br />
*market competitive assessments;<br />
*benchmarking; and<br />
*organizational analysis techniques (e.g., strengths, weaknesses, opportunities, threats (SWOT analysis), and product portfolios).<br />
<br />
==Practical Considerations==<br />
Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1. <br />
<br />
<center><br />
{|<br />
|+'''Table 1. Major Pitfalls with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|Wrong level of system addressed<br />
|When delineating the boundaries of the system-of-interest and defining the mission and purpose of the system at the very beginning of systems engineering, a classic mistake is to place the system-of-interest at the wrong level of abstraction. The level of abstraction can be too high or too low (sitting respectively in the upper-system or in a sub-system). This is the consequence of the principle stating that a system is always included in a larger system and of confusing the purpose and the mission of the system-of-interest.<br />
|-<br />
|Operational modes or scenarios missing<br />
|In commercial products or systems, the lack or insufficient description of operational modes and scenarios (how the system-of-interest will be used, in which situations, etc.) is often encountered.<br />
|}<br />
</center><br />
<br />
<br />
Proven practices with mission analysis and marketing analysis are presented in Table 2.<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Proven Practices with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|Models of operational scenarios<br />
|Using modeling techniques as indicated in sections above for operational scenarios in any kind of system-of-interest (including commercial systems).<br />
|-<br />
|Models of the context<br />
|Consider the context of use as a system and force oneself to use modeling techniques for main aspects of the context (functional, behavioral, physical, etc.).<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Freeman, Richard, “Achieving Strategic Aims: Moving Toward a Process Based Military Enterprise”<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering -- Life cycle processes -- Requirements engineering'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC/IEEE 29148:2011<br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
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.<br />
<br />
Kaplan, Robert S. and Norton, David P., “Developing the Strategy: Vision, Value Gaps, and Analysis”, Balanced Scorecard Report, Harvard Business School Publishing, Jan-Feb 2008<br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A simple method for phased mission analysis." ''Reliability Engineering & System Safety'' 45(3): 299-309.<br />
<br />
National Defense Industrial Association, Systems Engineering Division, Mission Analysis Committee, “Mission Analysis Committee Charter”<br />
<br />
Shupp, Jeffrey K., “The Mission Analysis Discipline: Bringing focus to the fuzziness about Attaining Good Architectures”, Proceedings of INCOSE 13th International Symposium, July 2003.<br />
<br />
Wikipedia, “Market Analysis”, 12 February 2012.<br />
<br />
===Primary References===<br />
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).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
Center for Quality Management. 1993. "Special Issue on Kano's Methods for Understanding Customer Defined Quality." ''Center for Quality Management Journal'' 2(4) (Fall 1993). <br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering.'' 3rd ed. London, UK: Springer.<br />
<br />
Kano, N. 1984. "Attractive Quality and Must-Be Quality." ''Quality JSQC'' 14(2) (October 1984). <br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309. <br />
<br />
Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques," in ''Software Engineering''. New York, NY: McGraw-Hill.<br />
<br />
MITRE. 2011. "Concept Development." ''Systems Engineering Guide. '' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/]].<br />
<br />
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/]].<br />
<br />
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]].<br />
----<br />
<center>[[Concept Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Stakeholder Needs and Requirements|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Concept Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_or_Mission_Analysis&diff=38101Business or Mission Analysis2012-08-06T22:06:06Z<p>Groedler: /* Methods and Modeling Techniques */</p>
<hr />
<div>The starting point of engineering any [[System of Interest (SoI) (glossary)|system of interest (SoI)]] is understanding the socio-economic and technological context wherein potential problems or opportunities reside. The enterprise strategic goals and [[Stakeholder (glossary)| stakeholders’]] needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], and [[Customer (glossary)|customers]]. An important set of activities, called [[Mission Analysis (glossary)|mission analysis]] ([[Acronyms|MA]]) (also called [[Market Analysis (glossary)|market analysis]] or business anlaysis in certain domains or sectors), is often performed iteratively with [[Stakeholder Needs and Requirements]] generation to better understand the problem (or opportunity) space, as well as the solution space. The execution of this process enables a systems engineer to then establish a set of [[Stakeholder Requirement (glossary)| stakeholder requirements]] for a potential SoI, or other solution, that could provide a capability or service needed by the acquirer, the users, and the other stakeholders in a defined environment. <br />
<br />
MA is part of the larger set of [[Concept Definition|concept definition]] activities. [[Concept Definition|Concept definition]] is the phase of systems engineering in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the [[System of Interest (SoI) (glossary)|system of interest]] is developed. In fact, the activities of concept definition determine whether the enterprise strategic goals and stakeholder needs will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution. Mission analysis focuses on the identification of the primary purpose(s) of the solution, while [[Stakeholder Needs and Requirements]] definition explores what capabilities stakeholders desire and may include some detail on the performance of certain aspects of the solution.<br />
<br />
== Purpose and Definition ==<br />
The purpose of MA is to understand a problem or opportunity, analyze the solution space, and initiate the life cycle of a potential solution that could answer the problem or take advantage of an opportunity.<br />
<br />
MA, known in some domains as [[Market Analysis (glossary)|market analysis (glossary)]] or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise. The definition of a need in a problem space frames the solution, both in terms of the direct application to the mission or business function, and in terms of the context for the resulting solution. MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. It characterizes the operational need in terms of mission description/provisions and the environment/context the need exists within, together with the proposed enterprise concept of operations and operational scenarios. The primary products of MA are the revised Concept of Operations ([[Concept of Operations (ConOps) (glossary)|ConOps]]) of the enterprise, the [[Operational Concept (glossary)|Operational Concept]], the [[Operational Scenario (glossary)|Operational Scenarios]] for the mission, and the context in which the solution will exist. <br />
<br />
MA may include mathematical analysis, modeling, simulation, visualization, and other analytical tools to characterize the intended mission and determine how to best achieve the needs/objectives. MA evaluates alternative approaches to determine which alternative approach best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions). Thus, MA defines the problem space and analyzes the solution space alternatives using quality attribute constraints driven by the enterprise objectives.<br />
<br />
==Principles and Concepts==<br />
===Mission Analysis and Concept of Operations===<br />
MA and the [[Concept of Operations (ConOps) (glossary)|ConOps]] are broadly used in defense and aerospace organizations to analyze and define how the system is intended to operate, as well as how the major operations or operational scenarios are intended to be performed, taking into account the strategic, operational, and tactical aspects of the identified scenarios. MA is a type of strategic or operations analysis related to needs or capability gaps and solutions that can be applied to any organization that evolves its strategy for its business objectives.<br />
<br />
In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering ([[Acronyms|SE]]) leaders interact with enterprise leaders and operations analysts to understand: <br />
*the enterprise ConOps and future mission, business, and operational (MBO) objectives; <br />
*the characterization of the Operational Concept and objectives (i.e., constraints, mission or operational scenarios, tasks, resources, risks, assumptions, and related missions or operations); and<br />
*how specific missions or operations are currently conducted and what gaps exist in those areas.<br />
<br />
They then conceptually explore and select from alternative candidate solutions. This interaction ensures a full understanding of both the problem space and the solution space. The alternative candidate solutions can include a wide range of approaches to address the need, as well as variants for an approach to optimize specific characteristics (e.g., using a different distribution of satellite orbit parameters to maximize coverage or events while minimizing the number of satellites). Analysis, modeling and simulation, and trade studies are employed to select alternative approaches (Charter of the Mission Analysis Committee, National Defense Industrial Association, Systems Engineering Division).<br />
<br />
"The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems (as black boxes) to forward the organization's goals and objectives. The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations within the business in regards to the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of future business and systems” (ISO/IEC 2011). <br />
<br />
These notions are also used in industrial sectors, such as aviation administrations and aeronautic transportation, health care systems, space, etc., with adapted definitions and/or terms, such as operational concepts, usage concepts and/or technological concepts. For example, “mission analysis” is the term used to describe the mathematical analysis of satellite orbits performed to determine how best to achieve the objectives of a space mission (European Space Agency).<br />
<br />
In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:<br />
<br />
<blockquote>''. . . studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and this in turn of the global environmental analysis. Through all these analyses, the chances, strengths, weaknesses, and risks of a company can be identified. Finally, with the help of a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm's planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company.'' (Wikipedia, 02/12/12)</blockquote><br />
<br />
Anywhere these notions are used, it is evident that they are based on fundamental concepts, such as the [[Operational Mode (glossary)|operational mode]] (or state of the system), [[Scenario (glossary)|scenario]] (of actions), the enterprise level concept of operations and the system level operational concepts, [[Function (glossary) |functions]] (providing services), etc. For more explanations about the concept of operations and operational concept, refer to ''Systems and Software Engineering - Requirements Engineering'' (ISO/IEC 2011); useful information can be found in Annex A, "System Operational Concept", and Annex B, "Concept of Operations" (ISO/IEC 2011).<br />
<br />
===Mission Analysis as Part of Enterprise Strategy Development===<br />
Periodically, most enterprises re-evaluate their strategy with respect to their mission, vision, and positioning to accomplish their goals. Figure 1 shows the interactions of the enterprise strategy development and the concept definition, including MA and stakeholder needs and requirements that are involved in an iterative manner to fully develop the strategy and define future capabilities and solutions. As the enterprise evolves the strategy, it is essential to conduct the supporting MA or strategic analysis for each element of the enterprise to determine their readiness to achieve their future objectives. This analysis examines the current state to identify any problems or opportunities related to the objective achievement and aids the enterprise in fully understanding and defining the problem space. The analysis examines the external environment and interfaces in search of impacts and trends, as well as the internal enterprise to gauge its capabilities and value stream gaps. Additionally, a SWOT analysis may be performed to weigh the strengths, weaknesses, opportunities, and threats. As the problem space is defined, stakeholder needs and requirements activities are performed to define the stakeholder needs and transform them into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, the future state of core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities (see [[Stakeholder Needs and Requirements]] for more information). Finally, MA is engaged again to examine the solution space. Candidate solutions that span the potential solution space are identified, from simple operational changes, to various system developments or modifications. Various techniques are applied to analyze the candidates, understand their feasibility and value, and select the best alternative.<br />
<br />
[[File:Enterprise_Strategy_and_Concept_Development.PNG|thumb|700px|center|Figure 1. Enterprise Strategy and Concept Development (Roedler 2012) Reprinted with permission of Garry Roedler]]<br />
<br />
==Process Approach==<br />
===Activities of the Process===<br />
It is necessary to perform the following major activities and tasks during this process: <br />
#Review and understand the enterprise mission, vision, and ConOps.<br />
#Identify and define any gaps and opportunities related to future evolution of the strategy:<br />
##Examine the current state to identify any problems or opportunities related to the objective achievement, including any deficiencies of the existing system.<br />
##Analyze the context of the actual PESTAL factors (Political, Economic, Social, Technological, Environmental, and Legal), while studying sensitive factors such as cost and effectiveness, security and safety improvement, performance improvement or lack of existing systems, market opportunities, regulation changes, users' dissatisfaction, etc. External, internal, and SWOT analysis should be included as well.<br />
##Define any mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without thinking to solution. <br />
#Examine and evaluate the solution space.<br />
##Identify the main stakeholders (customers, users, administrations, regulations, etc.).<br />
##Identify high level operational modes or states, or potential use cases.<br />
##Identify candidate solutions that span the potential solution space, from simple operational changes, to various system developments or modifications. Identify existing systems, products, and services that may address the need for operational or functional modifications. Deduce what potential expected services may be needed. A potential and not yet existing product, service or enterprise is called the "system-of-interest" (SoI). Additionally, the solution could be an operational change or a change to an existing product or service.<br />
#Perform appropriate modeling, simulation, and analytical techniques to understand the feasibility and value of the alternative candidate solutions. Model or simulate operational scenarios from these services and use cases, and enrich them through reviews with stakeholders and subject matter experts.<br />
#Define basic operational concept or market strategy, and/or business models.<br />
##From previous modeled operational scenarios and operational modes, deduce and express the usage of operational concepts, or technical concepts.<br />
##Collect and enrich needs, expectations, scenarios, and constraints.<br />
##Validate the mission of any potential SoI in the context of any proposed market strategy or business model.<br />
#Evaluate the set of alternatives and select the best alternative.<br />
##Perform a trade study of the alternatives to discriminate between the alternatives.<br />
#Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.<br />
<br />
===Mission Analysis Artifacts===<br />
<br />
This process may create several artifacts, such as:<br />
*recommendations for revisions to the enterprise ConOps;<br />
*preliminary operational concept document or inputs;<br />
*mission analysis and definition reports;<br />
*system analysis artifacts (e.g., use case diagrams, context diagrams, sequence/activity diagrams, functional flow block diagrams);<br />
*trade study results (alternatives analysis); and<br />
*market study/analysis reports.<br />
<br />
===Methods and Modeling Techniques===<br />
<br />
MA uses techniques, such as:<br />
<br />
*use case analysis;<br />
*operational analysis; <br />
*functional analysis;<br />
*technical documentation review;<br />
*trade studies;<br />
*modeling;<br />
*simulation;<br />
*prototyping;<br />
*workshops, interviews, and questionnaires;<br />
*market competitive assessments;<br />
*benchmarking; and<br />
*organizational analysis techniques (e.g., strengths, weaknesses, opportunities, threats (SWOT analysis), and product portfolios).<br />
<br />
==Practical Considerations==<br />
Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1. <br />
<br />
<center><br />
{|<br />
|+'''Table 1. Major Pitfalls with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|Wrong level of system addressed<br />
|When delineating the boundaries of the system-of-interest and defining the mission and purpose of the system at the very beginning of systems engineering, a classic mistake is to place the system-of-interest at the wrong level of abstraction. The level of abstraction can be too high or too low (sitting respectively in the upper-system or in a sub-system). This is the consequence of the principle stating that a system is always included in a larger system and of confusing the purpose and the mission of the system-of-interest.<br />
|-<br />
|Operational modes or scenarios missing<br />
|In commercial products or systems, the lack or insufficient description of operational modes and scenarios (how the system-of-interest will be used, in which situations, etc.) is often encountered.<br />
|}<br />
</center><br />
<br />
<br />
Proven practices with mission analysis and marketing analysis are presented in Table 2.<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Proven Practices with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|Models of operational scenarios<br />
|Using modeling techniques as indicated in sections above for operational scenarios in any kind of system-of-interest (including commercial systems).<br />
|-<br />
|Models of the context<br />
|Consider the context of use as a system and force oneself to use modeling techniques for main aspects of the context (functional, behavioral, physical, etc.).<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Freeman, Richard, “Achieving Strategic Aims: Moving Toward a Process Based Military Enterprise”<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering -- Life cycle processes -- Requirements engineering'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC/IEEE 29148:2011<br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
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.<br />
<br />
Kaplan, Robert S. and Norton, David P., “Developing the Strategy: Vision, Value Gaps, and Analysis”, Balanced Scorecard Report, Harvard Business School Publishing, Jan-Feb 2008<br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A simple method for phased mission analysis." ''Reliability Engineering & System Safety'' 45(3): 299-309.<br />
<br />
National Defense Industrial Association, Systems Engineering Division, Mission Analysis Committee, “Mission Analysis Committee Charter”<br />
<br />
Shupp, Jeffrey K., “The Mission Analysis Discipline: Bringing focus to the fuzziness about Attaining Good Architectures”, Proceedings of INCOSE 13th International Symposium, July 2003.<br />
<br />
Wikipedia, “Market Analysis”, 12 February 2012.<br />
<br />
===Primary References===<br />
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).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
Center for Quality Management. 1993. "Special Issue on Kano's Methods for Understanding Customer Defined Quality." ''Center for Quality Management Journal'' 2(4) (Fall 1993). <br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering.'' 3rd ed. London, UK: Springer.<br />
<br />
Kano, N. 1984. "Attractive Quality and Must-Be Quality." ''Quality JSQC'' 14(2) (October 1984). <br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309. <br />
<br />
Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques," in ''Software Engineering''. New York, NY: McGraw-Hill.<br />
<br />
MITRE. 2011. "Concept Development." ''Systems Engineering Guide. '' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/]].<br />
<br />
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/]].<br />
<br />
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]].<br />
----<br />
<center>[[Concept Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Stakeholder Needs and Requirements|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Concept Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_or_Mission_Analysis&diff=38099Business or Mission Analysis2012-08-06T22:04:07Z<p>Groedler: /* Mission Analysis Artifacts */</p>
<hr />
<div>The starting point of engineering any [[System of Interest (SoI) (glossary)|system of interest (SoI)]] is understanding the socio-economic and technological context wherein potential problems or opportunities reside. The enterprise strategic goals and [[Stakeholder (glossary)| stakeholders’]] needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], and [[Customer (glossary)|customers]]. An important set of activities, called [[Mission Analysis (glossary)|mission analysis]] ([[Acronyms|MA]]) (also called [[Market Analysis (glossary)|market analysis]] or business anlaysis in certain domains or sectors), is often performed iteratively with [[Stakeholder Needs and Requirements]] generation to better understand the problem (or opportunity) space, as well as the solution space. The execution of this process enables a systems engineer to then establish a set of [[Stakeholder Requirement (glossary)| stakeholder requirements]] for a potential SoI, or other solution, that could provide a capability or service needed by the acquirer, the users, and the other stakeholders in a defined environment. <br />
<br />
MA is part of the larger set of [[Concept Definition|concept definition]] activities. [[Concept Definition|Concept definition]] is the phase of systems engineering in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the [[System of Interest (SoI) (glossary)|system of interest]] is developed. In fact, the activities of concept definition determine whether the enterprise strategic goals and stakeholder needs will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution. Mission analysis focuses on the identification of the primary purpose(s) of the solution, while [[Stakeholder Needs and Requirements]] definition explores what capabilities stakeholders desire and may include some detail on the performance of certain aspects of the solution.<br />
<br />
== Purpose and Definition ==<br />
The purpose of MA is to understand a problem or opportunity, analyze the solution space, and initiate the life cycle of a potential solution that could answer the problem or take advantage of an opportunity.<br />
<br />
MA, known in some domains as [[Market Analysis (glossary)|market analysis (glossary)]] or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise. The definition of a need in a problem space frames the solution, both in terms of the direct application to the mission or business function, and in terms of the context for the resulting solution. MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. It characterizes the operational need in terms of mission description/provisions and the environment/context the need exists within, together with the proposed enterprise concept of operations and operational scenarios. The primary products of MA are the revised Concept of Operations ([[Concept of Operations (ConOps) (glossary)|ConOps]]) of the enterprise, the [[Operational Concept (glossary)|Operational Concept]], the [[Operational Scenario (glossary)|Operational Scenarios]] for the mission, and the context in which the solution will exist. <br />
<br />
MA may include mathematical analysis, modeling, simulation, visualization, and other analytical tools to characterize the intended mission and determine how to best achieve the needs/objectives. MA evaluates alternative approaches to determine which alternative approach best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions). Thus, MA defines the problem space and analyzes the solution space alternatives using quality attribute constraints driven by the enterprise objectives.<br />
<br />
==Principles and Concepts==<br />
===Mission Analysis and Concept of Operations===<br />
MA and the [[Concept of Operations (ConOps) (glossary)|ConOps]] are broadly used in defense and aerospace organizations to analyze and define how the system is intended to operate, as well as how the major operations or operational scenarios are intended to be performed, taking into account the strategic, operational, and tactical aspects of the identified scenarios. MA is a type of strategic or operations analysis related to needs or capability gaps and solutions that can be applied to any organization that evolves its strategy for its business objectives.<br />
<br />
In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering ([[Acronyms|SE]]) leaders interact with enterprise leaders and operations analysts to understand: <br />
*the enterprise ConOps and future mission, business, and operational (MBO) objectives; <br />
*the characterization of the Operational Concept and objectives (i.e., constraints, mission or operational scenarios, tasks, resources, risks, assumptions, and related missions or operations); and<br />
*how specific missions or operations are currently conducted and what gaps exist in those areas.<br />
<br />
They then conceptually explore and select from alternative candidate solutions. This interaction ensures a full understanding of both the problem space and the solution space. The alternative candidate solutions can include a wide range of approaches to address the need, as well as variants for an approach to optimize specific characteristics (e.g., using a different distribution of satellite orbit parameters to maximize coverage or events while minimizing the number of satellites). Analysis, modeling and simulation, and trade studies are employed to select alternative approaches (Charter of the Mission Analysis Committee, National Defense Industrial Association, Systems Engineering Division).<br />
<br />
"The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems (as black boxes) to forward the organization's goals and objectives. The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations within the business in regards to the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of future business and systems” (ISO/IEC 2011). <br />
<br />
These notions are also used in industrial sectors, such as aviation administrations and aeronautic transportation, health care systems, space, etc., with adapted definitions and/or terms, such as operational concepts, usage concepts and/or technological concepts. For example, “mission analysis” is the term used to describe the mathematical analysis of satellite orbits performed to determine how best to achieve the objectives of a space mission (European Space Agency).<br />
<br />
In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:<br />
<br />
<blockquote>''. . . studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and this in turn of the global environmental analysis. Through all these analyses, the chances, strengths, weaknesses, and risks of a company can be identified. Finally, with the help of a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm's planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company.'' (Wikipedia, 02/12/12)</blockquote><br />
<br />
Anywhere these notions are used, it is evident that they are based on fundamental concepts, such as the [[Operational Mode (glossary)|operational mode]] (or state of the system), [[Scenario (glossary)|scenario]] (of actions), the enterprise level concept of operations and the system level operational concepts, [[Function (glossary) |functions]] (providing services), etc. For more explanations about the concept of operations and operational concept, refer to ''Systems and Software Engineering - Requirements Engineering'' (ISO/IEC 2011); useful information can be found in Annex A, "System Operational Concept", and Annex B, "Concept of Operations" (ISO/IEC 2011).<br />
<br />
===Mission Analysis as Part of Enterprise Strategy Development===<br />
Periodically, most enterprises re-evaluate their strategy with respect to their mission, vision, and positioning to accomplish their goals. Figure 1 shows the interactions of the enterprise strategy development and the concept definition, including MA and stakeholder needs and requirements that are involved in an iterative manner to fully develop the strategy and define future capabilities and solutions. As the enterprise evolves the strategy, it is essential to conduct the supporting MA or strategic analysis for each element of the enterprise to determine their readiness to achieve their future objectives. This analysis examines the current state to identify any problems or opportunities related to the objective achievement and aids the enterprise in fully understanding and defining the problem space. The analysis examines the external environment and interfaces in search of impacts and trends, as well as the internal enterprise to gauge its capabilities and value stream gaps. Additionally, a SWOT analysis may be performed to weigh the strengths, weaknesses, opportunities, and threats. As the problem space is defined, stakeholder needs and requirements activities are performed to define the stakeholder needs and transform them into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, the future state of core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities (see [[Stakeholder Needs and Requirements]] for more information). Finally, MA is engaged again to examine the solution space. Candidate solutions that span the potential solution space are identified, from simple operational changes, to various system developments or modifications. Various techniques are applied to analyze the candidates, understand their feasibility and value, and select the best alternative.<br />
<br />
[[File:Enterprise_Strategy_and_Concept_Development.PNG|thumb|700px|center|Figure 1. Enterprise Strategy and Concept Development (Roedler 2012) Reprinted with permission of Garry Roedler]]<br />
<br />
==Process Approach==<br />
===Activities of the Process===<br />
It is necessary to perform the following major activities and tasks during this process: <br />
#Review and understand the enterprise mission, vision, and ConOps.<br />
#Identify and define any gaps and opportunities related to future evolution of the strategy:<br />
##Examine the current state to identify any problems or opportunities related to the objective achievement, including any deficiencies of the existing system.<br />
##Analyze the context of the actual PESTAL factors (Political, Economic, Social, Technological, Environmental, and Legal), while studying sensitive factors such as cost and effectiveness, security and safety improvement, performance improvement or lack of existing systems, market opportunities, regulation changes, users' dissatisfaction, etc. External, internal, and SWOT analysis should be included as well.<br />
##Define any mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without thinking to solution. <br />
#Examine and evaluate the solution space.<br />
##Identify the main stakeholders (customers, users, administrations, regulations, etc.).<br />
##Identify high level operational modes or states, or potential use cases.<br />
##Identify candidate solutions that span the potential solution space, from simple operational changes, to various system developments or modifications. Identify existing systems, products, and services that may address the need for operational or functional modifications. Deduce what potential expected services may be needed. A potential and not yet existing product, service or enterprise is called the "system-of-interest" (SoI). Additionally, the solution could be an operational change or a change to an existing product or service.<br />
#Perform appropriate modeling, simulation, and analytical techniques to understand the feasibility and value of the alternative candidate solutions. Model or simulate operational scenarios from these services and use cases, and enrich them through reviews with stakeholders and subject matter experts.<br />
#Define basic operational concept or market strategy, and/or business models.<br />
##From previous modeled operational scenarios and operational modes, deduce and express the usage of operational concepts, or technical concepts.<br />
##Collect and enrich needs, expectations, scenarios, and constraints.<br />
##Validate the mission of any potential SoI in the context of any proposed market strategy or business model.<br />
#Evaluate the set of alternatives and select the best alternative.<br />
##Perform a trade study of the alternatives to discriminate between the alternatives.<br />
#Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.<br />
<br />
===Mission Analysis Artifacts===<br />
<br />
This process may create several artifacts, such as:<br />
*recommendations for revisions to the enterprise ConOps;<br />
*preliminary operational concept document or inputs;<br />
*mission analysis and definition reports;<br />
*system analysis artifacts (e.g., use case diagrams, context diagrams, sequence/activity diagrams, functional flow block diagrams);<br />
*trade study results (alternatives analysis); and<br />
*market study/analysis reports.<br />
<br />
===Methods and Modeling Techniques===<br />
<br />
MA uses techniques, such as:<br />
<br />
*use case diagrams;<br />
*context relationships diagrams; <br />
*sequence and/or activity diagrams;<br />
*functional flow block diagrams;<br />
*technical documentation review;<br />
*trade studies;<br />
*modeling;<br />
*simulation;<br />
*prototyping;<br />
*workshops, interviews, and questionnaires;<br />
*market competitive assessments;<br />
*benchmarking; and<br />
*organizational analysis techniques (e.g., strengths, weaknesses, opportunities, threats (SWOT analysis), and product portfolios).<br />
<br />
==Practical Considerations==<br />
Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1. <br />
<br />
<center><br />
{|<br />
|+'''Table 1. Major Pitfalls with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|Wrong level of system addressed<br />
|When delineating the boundaries of the system-of-interest and defining the mission and purpose of the system at the very beginning of systems engineering, a classic mistake is to place the system-of-interest at the wrong level of abstraction. The level of abstraction can be too high or too low (sitting respectively in the upper-system or in a sub-system). This is the consequence of the principle stating that a system is always included in a larger system and of confusing the purpose and the mission of the system-of-interest.<br />
|-<br />
|Operational modes or scenarios missing<br />
|In commercial products or systems, the lack or insufficient description of operational modes and scenarios (how the system-of-interest will be used, in which situations, etc.) is often encountered.<br />
|}<br />
</center><br />
<br />
<br />
Proven practices with mission analysis and marketing analysis are presented in Table 2.<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Proven Practices with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|Models of operational scenarios<br />
|Using modeling techniques as indicated in sections above for operational scenarios in any kind of system-of-interest (including commercial systems).<br />
|-<br />
|Models of the context<br />
|Consider the context of use as a system and force oneself to use modeling techniques for main aspects of the context (functional, behavioral, physical, etc.).<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Freeman, Richard, “Achieving Strategic Aims: Moving Toward a Process Based Military Enterprise”<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering -- Life cycle processes -- Requirements engineering'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC/IEEE 29148:2011<br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
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.<br />
<br />
Kaplan, Robert S. and Norton, David P., “Developing the Strategy: Vision, Value Gaps, and Analysis”, Balanced Scorecard Report, Harvard Business School Publishing, Jan-Feb 2008<br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A simple method for phased mission analysis." ''Reliability Engineering & System Safety'' 45(3): 299-309.<br />
<br />
National Defense Industrial Association, Systems Engineering Division, Mission Analysis Committee, “Mission Analysis Committee Charter”<br />
<br />
Shupp, Jeffrey K., “The Mission Analysis Discipline: Bringing focus to the fuzziness about Attaining Good Architectures”, Proceedings of INCOSE 13th International Symposium, July 2003.<br />
<br />
Wikipedia, “Market Analysis”, 12 February 2012.<br />
<br />
===Primary References===<br />
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).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
Center for Quality Management. 1993. "Special Issue on Kano's Methods for Understanding Customer Defined Quality." ''Center for Quality Management Journal'' 2(4) (Fall 1993). <br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering.'' 3rd ed. London, UK: Springer.<br />
<br />
Kano, N. 1984. "Attractive Quality and Must-Be Quality." ''Quality JSQC'' 14(2) (October 1984). <br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309. <br />
<br />
Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques," in ''Software Engineering''. New York, NY: McGraw-Hill.<br />
<br />
MITRE. 2011. "Concept Development." ''Systems Engineering Guide. '' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/]].<br />
<br />
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/]].<br />
<br />
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]].<br />
----<br />
<center>[[Concept Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Stakeholder Needs and Requirements|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Concept Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_or_Mission_Analysis&diff=38096Business or Mission Analysis2012-08-06T21:52:12Z<p>Groedler: </p>
<hr />
<div>The starting point of engineering any [[System of Interest (SoI) (glossary)|system of interest (SoI)]] is understanding the socio-economic and technological context wherein potential problems or opportunities reside. The enterprise strategic goals and [[Stakeholder (glossary)| stakeholders’]] needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], and [[Customer (glossary)|customers]]. An important set of activities, called [[Mission Analysis (glossary)|mission analysis]] ([[Acronyms|MA]]) (also called [[Market Analysis (glossary)|market analysis]] or business anlaysis in certain domains or sectors), is often performed iteratively with [[Stakeholder Needs and Requirements]] generation to better understand the problem (or opportunity) space, as well as the solution space. The execution of this process enables a systems engineer to then establish a set of [[Stakeholder Requirement (glossary)| stakeholder requirements]] for a potential SoI, or other solution, that could provide a capability or service needed by the acquirer, the users, and the other stakeholders in a defined environment. <br />
<br />
MA is part of the larger set of [[Concept Definition|concept definition]] activities. [[Concept Definition|Concept definition]] is the phase of systems engineering in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the [[System of Interest (SoI) (glossary)|system of interest]] is developed. In fact, the activities of concept definition determine whether the enterprise strategic goals and stakeholder needs will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution. Mission analysis focuses on the identification of the primary purpose(s) of the solution, while [[Stakeholder Needs and Requirements]] definition explores what capabilities stakeholders desire and may include some detail on the performance of certain aspects of the solution.<br />
<br />
== Purpose and Definition ==<br />
The purpose of MA is to understand a problem or opportunity, analyze the solution space, and initiate the life cycle of a potential solution that could answer the problem or take advantage of an opportunity.<br />
<br />
MA, known in some domains as [[Market Analysis (glossary)|market analysis (glossary)]] or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise. The definition of a need in a problem space frames the solution, both in terms of the direct application to the mission or business function, and in terms of the context for the resulting solution. MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. It characterizes the operational need in terms of mission description/provisions and the environment/context the need exists within, together with the proposed enterprise concept of operations and operational scenarios. The primary products of MA are the revised Concept of Operations ([[Concept of Operations (ConOps) (glossary)|ConOps]]) of the enterprise, the [[Operational Concept (glossary)|Operational Concept]], the [[Operational Scenario (glossary)|Operational Scenarios]] for the mission, and the context in which the solution will exist. <br />
<br />
MA may include mathematical analysis, modeling, simulation, visualization, and other analytical tools to characterize the intended mission and determine how to best achieve the needs/objectives. MA evaluates alternative approaches to determine which alternative approach best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions). Thus, MA defines the problem space and analyzes the solution space alternatives using quality attribute constraints driven by the enterprise objectives.<br />
<br />
==Principles and Concepts==<br />
===Mission Analysis and Concept of Operations===<br />
MA and the [[Concept of Operations (ConOps) (glossary)|ConOps]] are broadly used in defense and aerospace organizations to analyze and define how the system is intended to operate, as well as how the major operations or operational scenarios are intended to be performed, taking into account the strategic, operational, and tactical aspects of the identified scenarios. MA is a type of strategic or operations analysis related to needs or capability gaps and solutions that can be applied to any organization that evolves its strategy for its business objectives.<br />
<br />
In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering ([[Acronyms|SE]]) leaders interact with enterprise leaders and operations analysts to understand: <br />
*the enterprise ConOps and future mission, business, and operational (MBO) objectives; <br />
*the characterization of the Operational Concept and objectives (i.e., constraints, mission or operational scenarios, tasks, resources, risks, assumptions, and related missions or operations); and<br />
*how specific missions or operations are currently conducted and what gaps exist in those areas.<br />
<br />
They then conceptually explore and select from alternative candidate solutions. This interaction ensures a full understanding of both the problem space and the solution space. The alternative candidate solutions can include a wide range of approaches to address the need, as well as variants for an approach to optimize specific characteristics (e.g., using a different distribution of satellite orbit parameters to maximize coverage or events while minimizing the number of satellites). Analysis, modeling and simulation, and trade studies are employed to select alternative approaches (Charter of the Mission Analysis Committee, National Defense Industrial Association, Systems Engineering Division).<br />
<br />
"The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems (as black boxes) to forward the organization's goals and objectives. The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations within the business in regards to the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of future business and systems” (ISO/IEC 2011). <br />
<br />
These notions are also used in industrial sectors, such as aviation administrations and aeronautic transportation, health care systems, space, etc., with adapted definitions and/or terms, such as operational concepts, usage concepts and/or technological concepts. For example, “mission analysis” is the term used to describe the mathematical analysis of satellite orbits performed to determine how best to achieve the objectives of a space mission (European Space Agency).<br />
<br />
In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:<br />
<br />
<blockquote>''. . . studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and this in turn of the global environmental analysis. Through all these analyses, the chances, strengths, weaknesses, and risks of a company can be identified. Finally, with the help of a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm's planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company.'' (Wikipedia, 02/12/12)</blockquote><br />
<br />
Anywhere these notions are used, it is evident that they are based on fundamental concepts, such as the [[Operational Mode (glossary)|operational mode]] (or state of the system), [[Scenario (glossary)|scenario]] (of actions), the enterprise level concept of operations and the system level operational concepts, [[Function (glossary) |functions]] (providing services), etc. For more explanations about the concept of operations and operational concept, refer to ''Systems and Software Engineering - Requirements Engineering'' (ISO/IEC 2011); useful information can be found in Annex A, "System Operational Concept", and Annex B, "Concept of Operations" (ISO/IEC 2011).<br />
<br />
===Mission Analysis as Part of Enterprise Strategy Development===<br />
Periodically, most enterprises re-evaluate their strategy with respect to their mission, vision, and positioning to accomplish their goals. Figure 1 shows the interactions of the enterprise strategy development and the concept definition, including MA and stakeholder needs and requirements that are involved in an iterative manner to fully develop the strategy and define future capabilities and solutions. As the enterprise evolves the strategy, it is essential to conduct the supporting MA or strategic analysis for each element of the enterprise to determine their readiness to achieve their future objectives. This analysis examines the current state to identify any problems or opportunities related to the objective achievement and aids the enterprise in fully understanding and defining the problem space. The analysis examines the external environment and interfaces in search of impacts and trends, as well as the internal enterprise to gauge its capabilities and value stream gaps. Additionally, a SWOT analysis may be performed to weigh the strengths, weaknesses, opportunities, and threats. As the problem space is defined, stakeholder needs and requirements activities are performed to define the stakeholder needs and transform them into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, the future state of core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities (see [[Stakeholder Needs and Requirements]] for more information). Finally, MA is engaged again to examine the solution space. Candidate solutions that span the potential solution space are identified, from simple operational changes, to various system developments or modifications. Various techniques are applied to analyze the candidates, understand their feasibility and value, and select the best alternative.<br />
<br />
[[File:Enterprise_Strategy_and_Concept_Development.PNG|thumb|700px|center|Figure 1. Enterprise Strategy and Concept Development (Roedler 2012) Reprinted with permission of Garry Roedler]]<br />
<br />
==Process Approach==<br />
===Activities of the Process===<br />
It is necessary to perform the following major activities and tasks during this process: <br />
#Review and understand the enterprise mission, vision, and ConOps.<br />
#Identify and define any gaps and opportunities related to future evolution of the strategy:<br />
##Examine the current state to identify any problems or opportunities related to the objective achievement, including any deficiencies of the existing system.<br />
##Analyze the context of the actual PESTAL factors (Political, Economic, Social, Technological, Environmental, and Legal), while studying sensitive factors such as cost and effectiveness, security and safety improvement, performance improvement or lack of existing systems, market opportunities, regulation changes, users' dissatisfaction, etc. External, internal, and SWOT analysis should be included as well.<br />
##Define any mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without thinking to solution. <br />
#Examine and evaluate the solution space.<br />
##Identify the main stakeholders (customers, users, administrations, regulations, etc.).<br />
##Identify high level operational modes or states, or potential use cases.<br />
##Identify candidate solutions that span the potential solution space, from simple operational changes, to various system developments or modifications. Identify existing systems, products, and services that may address the need for operational or functional modifications. Deduce what potential expected services may be needed. A potential and not yet existing product, service or enterprise is called the "system-of-interest" (SoI). Additionally, the solution could be an operational change or a change to an existing product or service.<br />
#Perform appropriate modeling, simulation, and analytical techniques to understand the feasibility and value of the alternative candidate solutions. Model or simulate operational scenarios from these services and use cases, and enrich them through reviews with stakeholders and subject matter experts.<br />
#Define basic operational concept or market strategy, and/or business models.<br />
##From previous modeled operational scenarios and operational modes, deduce and express the usage of operational concepts, or technical concepts.<br />
##Collect and enrich needs, expectations, scenarios, and constraints.<br />
##Validate the mission of any potential SoI in the context of any proposed market strategy or business model.<br />
#Evaluate the set of alternatives and select the best alternative.<br />
##Perform a trade study of the alternatives to discriminate between the alternatives.<br />
#Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.<br />
<br />
===Mission Analysis Artifacts===<br />
<br />
This process may create several artifacts, such as:<br />
*recommendations for revisions to the enterprise ConOps;<br />
*preliminary operational concept document or inputs;<br />
*mission analysis and definition reports;<br />
*trade study results (alternatives analysis); and<br />
*market study/analysis reports.<br />
<br />
===Methods and Modeling Techniques===<br />
<br />
MA uses techniques, such as:<br />
<br />
*use case diagrams;<br />
*context relationships diagrams; <br />
*sequence and/or activity diagrams;<br />
*functional flow block diagrams;<br />
*technical documentation review;<br />
*trade studies;<br />
*modeling;<br />
*simulation;<br />
*prototyping;<br />
*workshops, interviews, and questionnaires;<br />
*market competitive assessments;<br />
*benchmarking; and<br />
*organizational analysis techniques (e.g., strengths, weaknesses, opportunities, threats (SWOT analysis), and product portfolios).<br />
<br />
==Practical Considerations==<br />
Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1. <br />
<br />
<center><br />
{|<br />
|+'''Table 1. Major Pitfalls with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|Wrong level of system addressed<br />
|When delineating the boundaries of the system-of-interest and defining the mission and purpose of the system at the very beginning of systems engineering, a classic mistake is to place the system-of-interest at the wrong level of abstraction. The level of abstraction can be too high or too low (sitting respectively in the upper-system or in a sub-system). This is the consequence of the principle stating that a system is always included in a larger system and of confusing the purpose and the mission of the system-of-interest.<br />
|-<br />
|Operational modes or scenarios missing<br />
|In commercial products or systems, the lack or insufficient description of operational modes and scenarios (how the system-of-interest will be used, in which situations, etc.) is often encountered.<br />
|}<br />
</center><br />
<br />
<br />
Proven practices with mission analysis and marketing analysis are presented in Table 2.<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Proven Practices with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|Models of operational scenarios<br />
|Using modeling techniques as indicated in sections above for operational scenarios in any kind of system-of-interest (including commercial systems).<br />
|-<br />
|Models of the context<br />
|Consider the context of use as a system and force oneself to use modeling techniques for main aspects of the context (functional, behavioral, physical, etc.).<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Freeman, Richard, “Achieving Strategic Aims: Moving Toward a Process Based Military Enterprise”<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering -- Life cycle processes -- Requirements engineering'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC/IEEE 29148:2011<br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
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.<br />
<br />
Kaplan, Robert S. and Norton, David P., “Developing the Strategy: Vision, Value Gaps, and Analysis”, Balanced Scorecard Report, Harvard Business School Publishing, Jan-Feb 2008<br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A simple method for phased mission analysis." ''Reliability Engineering & System Safety'' 45(3): 299-309.<br />
<br />
National Defense Industrial Association, Systems Engineering Division, Mission Analysis Committee, “Mission Analysis Committee Charter”<br />
<br />
Shupp, Jeffrey K., “The Mission Analysis Discipline: Bringing focus to the fuzziness about Attaining Good Architectures”, Proceedings of INCOSE 13th International Symposium, July 2003.<br />
<br />
Wikipedia, “Market Analysis”, 12 February 2012.<br />
<br />
===Primary References===<br />
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).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
Center for Quality Management. 1993. "Special Issue on Kano's Methods for Understanding Customer Defined Quality." ''Center for Quality Management Journal'' 2(4) (Fall 1993). <br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering.'' 3rd ed. London, UK: Springer.<br />
<br />
Kano, N. 1984. "Attractive Quality and Must-Be Quality." ''Quality JSQC'' 14(2) (October 1984). <br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309. <br />
<br />
Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques," in ''Software Engineering''. New York, NY: McGraw-Hill.<br />
<br />
MITRE. 2011. "Concept Development." ''Systems Engineering Guide. '' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/]].<br />
<br />
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/]].<br />
<br />
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]].<br />
----<br />
<center>[[Concept Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Stakeholder Needs and Requirements|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Concept Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_or_Mission_Analysis&diff=38094Business or Mission Analysis2012-08-06T21:43:52Z<p>Groedler: </p>
<hr />
<div>The starting point of engineering any [[System of Interest (SoI) (glossary)|system of interest (SoI)]] is understanding the socio-economic and technological context wherein potential problems or opportunities reside. The enterprise strategic goals and [[Stakeholder (glossary)| stakeholders’]] needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], and [[Customer (glossary)|customers]]. An important set of activities, called [[Mission Analysis (glossary)|mission analysis]] ([[Acronyms|MA]]) (also called [[Market Analysis (glossary)|market analysis]] or business anlaysis in certain domains or sectors), is often performed iteratively with [[Stakeholder Needs and Requirements]] generation to better understand the problem space, as well as the solution space. The execution of this process enables a systems engineer to then establish a set of [[Stakeholder Requirement (glossary)| stakeholder requirements]] for a potential SoI, or other solution, that could provide a capability or service needed by the acquirer, the users, and the other stakeholders in a defined environment. <br />
<br />
MA is part of the larger set of [[Concept Definition|concept definition]] activities. [[Concept Definition|Concept definition]] is the phase of systems engineering in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the [[System of Interest (SoI) (glossary)|system of interest]] is developed. In fact, the activities of concept definition determine whether the enterprise strategic goals and stakeholder needs will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution. Mission analysis focuses on the identification of the primary purpose(s) of the solution, while [[Stakeholder Needs and Requirements]] definition explores what capabilities stakeholders desire and may include some detail on the performance of certain aspects of the solution.<br />
<br />
== Purpose and Definition ==<br />
The purpose of MA is to understand a problem or opportunity, analyze the solution space, and initiate the life cycle of a potential solution that could answer the problem or take advantage of an opportunity.<br />
<br />
MA, known in some domains as [[Market Analysis (glossary)|market analysis (glossary)]] or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise. The definition of a need in a problem space frames the solution, both in terms of the direct application to the mission or business function, and in terms of the context for the resulting solution. MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. It characterizes the operational need in terms of mission description/provisions and the environment/context the need exists within, together with the proposed enterprise concept of operations and operational scenarios. The primary products of MA are the revised Concept of Operations ([[Concept of Operations (ConOps) (glossary)|ConOps]]) of the enterprise, the [[Operational Concept (glossary)|Operational Concept]], the [[Operational Scenario (glossary)|Operational Scenarios]] for the mission, and the context in which the solution will exist. <br />
<br />
MA may include mathematical analysis, modeling, simulation, visualization, and other analytical tools to characterize the intended mission and determine how to best achieve the needs/objectives. MA evaluates alternative approaches to determine which alternative approach best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions). Thus, MA defines the problem space and analyzes the solution space alternatives using quality attribute constraints driven by the enterprise objectives.<br />
<br />
==Principles and Concepts==<br />
===Mission Analysis and Concept of Operations===<br />
MA and the [[Concept of Operations (ConOps) (glossary)|ConOps]] are broadly used in defense and aerospace organizations to analyze and define how the system is intended to operate, as well as how the major operations or operational scenarios are intended to be performed, taking into account the strategic, operational, and tactical aspects of the identified scenarios. MA is a type of strategic or operations analysis related to needs or capability gaps and solutions that can be applied to any organization that evolves its strategy for its business objectives.<br />
<br />
In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering ([[Acronyms|SE]]) leaders interact with enterprise leaders and operations analysts to understand: <br />
*the enterprise ConOps and future mission, business, and operational (MBO) objectives; <br />
*the characterization of the Operational Concept and objectives (i.e., constraints, mission or operational scenarios, tasks, resources, risks, assumptions, and related missions or operations); and<br />
*how specific missions or operations are currently conducted and what gaps exist in those areas.<br />
<br />
They then conceptually explore and select from alternative candidate solutions. This interaction ensures a full understanding of both the problem space and the solution space. The alternative candidate solutions can include a wide range of approaches to address the need, as well as variants for an approach to optimize specific characteristics (e.g., using a different distribution of satellite orbit parameters to maximize coverage or events while minimizing the number of satellites). Analysis, modeling and simulation, and trade studies are employed to select alternative approaches (Charter of the Mission Analysis Committee, National Defense Industrial Association, Systems Engineering Division).<br />
<br />
"The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems (as black boxes) to forward the organization's goals and objectives. The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations within the business in regards to the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of future business and systems” (ISO/IEC 2011). <br />
<br />
These notions are also used in industrial sectors, such as aviation administrations and aeronautic transportation, health care systems, space, etc., with adapted definitions and/or terms, such as operational concepts, usage concepts and/or technological concepts. For example, “mission analysis” is the term used to describe the mathematical analysis of satellite orbits performed to determine how best to achieve the objectives of a space mission (European Space Agency).<br />
<br />
In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:<br />
<br />
<blockquote>''. . . studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and this in turn of the global environmental analysis. Through all these analyses, the chances, strengths, weaknesses, and risks of a company can be identified. Finally, with the help of a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm's planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company.'' (Wikipedia, 02/12/12)</blockquote><br />
<br />
Anywhere these notions are used, it is evident that they are based on fundamental concepts, such as the [[Operational Mode (glossary)|operational mode]] (or state of the system), [[Scenario (glossary)|scenario]] (of actions), the enterprise level concept of operations and the system level operational concepts, [[Function (glossary) |functions]] (providing services), etc. For more explanations about the concept of operations and operational concept, refer to ''Systems and Software Engineering - Requirements Engineering'' (ISO/IEC 2011); useful information can be found in Annex A, "System Operational Concept", and Annex B, "Concept of Operations" (ISO/IEC 2011).<br />
<br />
===Mission Analysis as Part of Enterprise Strategy Development===<br />
Periodically, most enterprises re-evaluate their strategy with respect to their mission, vision, and positioning to accomplish their goals. Figure 1 shows the interactions of the enterprise strategy development and the concept definition, including MA and stakeholder needs and requirements that are involved in an iterative manner to fully develop the strategy and define future capabilities and solutions. As the enterprise evolves the strategy, it is essential to conduct the supporting MA or strategic analysis for each element of the enterprise to determine their readiness to achieve their future objectives. This analysis examines the current state to identify any problems or opportunities related to the objective achievement and aids the enterprise in fully understanding and defining the problem space. The analysis examines the external environment and interfaces in search of impacts and trends, as well as the internal enterprise to gauge its capabilities and value stream gaps. Additionally, a SWOT analysis may be performed to weigh the strengths, weaknesses, opportunities, and threats. As the problem space is defined, stakeholder needs and requirements activities are performed to define the stakeholder needs and transform them into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, the future state of core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities (see [[Stakeholder Needs and Requirements]] for more information). Finally, MA is engaged again to examine the solution space. Candidate solutions that span the potential solution space are identified, from simple operational changes, to various system developments or modifications. Various techniques are applied to analyze the candidates, understand their feasibility and value, and select the best alternative.<br />
<br />
[[File:Enterprise_Strategy_and_Concept_Development.PNG|thumb|700px|center|Figure 1. Enterprise Strategy and Concept Development (Roedler 2012) Reprinted with permission of Garry Roedler]]<br />
<br />
==Process Approach==<br />
===Activities of the Process===<br />
It is necessary to perform the following major activities and tasks during this process: <br />
#Review and understand the enterprise mission, vision, and ConOps.<br />
#Identify and define any gaps and opportunities related to future evolution of the strategy:<br />
##Examine the current state to identify any problems or opportunities related to the objective achievement, including any deficiencies of the existing system.<br />
##Analyze the context of the actual PESTAL factors (Political, Economic, Social, Technological, Environmental, and Legal), while studying sensitive factors such as cost and effectiveness, security and safety improvement, performance improvement or lack of existing systems, market opportunities, regulation changes, users' dissatisfaction, etc. External, internal, and SWOT analysis should be included as well.<br />
##Define any mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without thinking to solution. <br />
#Examine and evaluate the solution space.<br />
##Identify the main stakeholders (customers, users, administrations, regulations, etc.).<br />
##Identify high level operational modes or states, or potential use cases.<br />
##Identify candidate solutions that span the potential solution space, from simple operational changes, to various system developments or modifications. Identify existing systems, products, and services that may address the need for operational or functional modifications. Deduce what potential expected services may be needed. A potential and not yet existing product, service or enterprise is called the "system-of-interest" (SoI). Additionally, the solution could be an operational change or a change to an existing product or service.<br />
#Perform appropriate modeling, simulation, and analytical techniques to understand the feasibility and value of the alternative candidate solutions. Model or simulate operational scenarios from these services and use cases, and enrich them through reviews with stakeholders and subject matter experts.<br />
#Define basic operational concept or market strategy, and/or business models.<br />
##From previous modeled operational scenarios and operational modes, deduce and express the usage of operational concepts, or technical concepts.<br />
##Collect and enrich needs, expectations, scenarios, and constraints.<br />
##Validate the mission of any potential SoI in the context of any proposed market strategy or business model.<br />
#Evaluate the set of alternatives and select the best alternative.<br />
##Perform a trade study of the alternatives to discriminate between the alternatives.<br />
#Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.<br />
<br />
===Mission Analysis Artifacts===<br />
<br />
This process may create several artifacts, such as:<br />
*recommendations for revisions to the enterprise ConOps;<br />
*preliminary operational concept document or inputs;<br />
*mission analysis and definition reports;<br />
*trade study results (alternatives analysis); and<br />
*market study/analysis reports.<br />
<br />
===Methods and Modeling Techniques===<br />
<br />
MA uses techniques, such as:<br />
<br />
*use case diagrams;<br />
*context relationships diagrams; <br />
*sequence and/or activity diagrams;<br />
*functional flow block diagrams;<br />
*technical documentation review;<br />
*trade studies;<br />
*modeling;<br />
*simulation;<br />
*prototyping;<br />
*workshops, interviews, and questionnaires;<br />
*market competitive assessments;<br />
*benchmarking; and<br />
*organizational analysis techniques (e.g., strengths, weaknesses, opportunities, threats (SWOT analysis), and product portfolios).<br />
<br />
==Practical Considerations==<br />
Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1. <br />
<br />
<center><br />
{|<br />
|+'''Table 1. Major Pitfalls with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|Wrong level of system addressed<br />
|When delineating the boundaries of the system-of-interest and defining the mission and purpose of the system at the very beginning of systems engineering, a classic mistake is to place the system-of-interest at the wrong level of abstraction. The level of abstraction can be too high or too low (sitting respectively in the upper-system or in a sub-system). This is the consequence of the principle stating that a system is always included in a larger system and of confusing the purpose and the mission of the system-of-interest.<br />
|-<br />
|Operational modes or scenarios missing<br />
|In commercial products or systems, the lack or insufficient description of operational modes and scenarios (how the system-of-interest will be used, in which situations, etc.) is often encountered.<br />
|}<br />
</center><br />
<br />
<br />
Proven practices with mission analysis and marketing analysis are presented in Table 2.<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Proven Practices with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|Models of operational scenarios<br />
|Using modeling techniques as indicated in sections above for operational scenarios in any kind of system-of-interest (including commercial systems).<br />
|-<br />
|Models of the context<br />
|Consider the context of use as a system and force oneself to use modeling techniques for main aspects of the context (functional, behavioral, physical, etc.).<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Freeman, Richard, “Achieving Strategic Aims: Moving Toward a Process Based Military Enterprise”<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering -- Life cycle processes -- Requirements engineering'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC/IEEE 29148:2011<br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
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.<br />
<br />
Kaplan, Robert S. and Norton, David P., “Developing the Strategy: Vision, Value Gaps, and Analysis”, Balanced Scorecard Report, Harvard Business School Publishing, Jan-Feb 2008<br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A simple method for phased mission analysis." ''Reliability Engineering & System Safety'' 45(3): 299-309.<br />
<br />
National Defense Industrial Association, Systems Engineering Division, Mission Analysis Committee, “Mission Analysis Committee Charter”<br />
<br />
Shupp, Jeffrey K., “The Mission Analysis Discipline: Bringing focus to the fuzziness about Attaining Good Architectures”, Proceedings of INCOSE 13th International Symposium, July 2003.<br />
<br />
Wikipedia, “Market Analysis”, 12 February 2012.<br />
<br />
===Primary References===<br />
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).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
Center for Quality Management. 1993. "Special Issue on Kano's Methods for Understanding Customer Defined Quality." ''Center for Quality Management Journal'' 2(4) (Fall 1993). <br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering.'' 3rd ed. London, UK: Springer.<br />
<br />
Kano, N. 1984. "Attractive Quality and Must-Be Quality." ''Quality JSQC'' 14(2) (October 1984). <br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309. <br />
<br />
Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques," in ''Software Engineering''. New York, NY: McGraw-Hill.<br />
<br />
MITRE. 2011. "Concept Development." ''Systems Engineering Guide. '' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/]].<br />
<br />
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/]].<br />
<br />
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]].<br />
----<br />
<center>[[Concept Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Stakeholder Needs and Requirements|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Concept Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_or_Mission_Analysis&diff=38093Business or Mission Analysis2012-08-06T21:35:45Z<p>Groedler: </p>
<hr />
<div>The starting point of engineering any [[System of Interest (SoI) (glossary)|system of interest (SoI)]] is understanding the socio-economic and technological context wherein potential problems or opportunities reside. The enterprise strategic goals and [[Stakeholder (glossary)| stakeholders’]] needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], and [[Customer (glossary)|customers]]. An important set of activities, called [[Mission Analysis (glossary)|mission analysis]] ([[Acronyms|MA]]) (also called [[Market Analysis (glossary)|market analysis]] or business anlaysis in certain domains or sectors), is often performed iteratively with [[Stakeholder Needs and Requirements]] generation to better understand the problem space, as well as the solution space. The execution of this process enables a systems engineer to then establish a set of [[Stakeholder Requirement (glossary)| stakeholder requirements]] for a potential SoI, or other solution, that could provide a capability or service needed by the acquirer, the users, and the other stakeholders in a defined environment. <br />
<br />
MA is part of the larger set of [[Concept Definition|concept definition]] activities. [[Concept Definition|Concept definition]] is the phase of systems engineering in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the [[System of Interest (SoI) (glossary)|system of interest]] is developed. In fact, the activities of concept definition determine whether the enterprise strategic goals and stakeholder needs will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution. Mission analysis focuses on the identification of the primary purpose(s) of the solution, while [[Stakeholder Needs and Requirements]] definition explores what capabilities stakeholders desire and may include some detail on the performance of certain aspects of the solution.<br />
<br />
== Purpose and Definition ==<br />
The purpose of MA is to understand a problem or opportunity, analyze the solution space, and initiate the life cycle of a potential solution that could answer the problem or take advantage of an opportunity.<br />
<br />
MA, known in some domains as [[Market Analysis (glossary)|market analysis (glossary)]] or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise. The definition of a need in a problem space frames the solution, both in terms of the direct application to the mission or business function, and in terms of the context for the resulting solution. MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. It characterizes the operational need in terms of mission description/provisions and the environment/context the need exists within, together with the proposed enterprise concept of operations and operational scenarios. The primary products of MA are the revised Concept of Operations ([[Concept of Operations (ConOps) (glossary)|ConOps]]) of the enterprise, the [[Operational Concept (glossary)|Operational Concept]], the [[Operational Scenario (glossary)|Operational Scenarios]] for the mission, and the context in which the solution will exist. <br />
<br />
MA may include mathematical analysis, modeling, simulation, visualization, and other analytical tools to characterize the intended mission and determine how to best achieve the needs/objectives. MA evaluates alternative approaches to determine which alternative approach best supports the stakeholder needs (among both materiel and non-materiel solution alternatives). Thus, MA defines the problem space and analyzes the solution space alternatives using quality attribute constraints driven by the enterprise objectives.<br />
<br />
==Principles and Concepts==<br />
===Mission Analysis and Concept of Operations===<br />
MA and the [[Concept of Operations (ConOps) (glossary)|ConOps]] are broadly used in defense and aerospace organizations to analyze and define how the system is intended to operate, as well as how the major operations or operational scenarios are intended to be performed, taking into account the strategic, operational, and tactical aspects of the identified scenarios. MA is a type of strategic or operations analysis related to needs or capability gaps and solutions that can be applied to any organization that evolves its strategy for its business objectives.<br />
<br />
In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering ([[Acronyms|SE]]) leaders interact with enterprise leaders and operations analysts to understand: <br />
*the enterprise ConOps and future mission, business, and operational (MBO) objectives; <br />
*the characterization of the Operational Concept and objectives (i.e., constraints, mission or operational scenarios, tasks, resources, risks, assumptions, and related missions or operations); and<br />
*how specific missions or operations are currently conducted and what gaps exist in those areas.<br />
<br />
They then conceptually explore and select from alternative candidate solutions. This interaction ensures a full understanding of both the problem space and the solution space. The alternative candidate solutions can include a wide range of approaches to address the need, as well as variants for an approach to optimize specific characteristics (e.g., using a different distribution of satellite orbit parameters to maximize coverage or events while minimizing the number of satellites). Analysis, modeling and simulation, and trade studies are employed to select alternative approaches (Charter of the Mission Analysis Committee, National Defense Industrial Association, Systems Engineering Division).<br />
<br />
"The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems (as black boxes) to forward the organization's goals and objectives. The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations within the business in regards to the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of future business and systems” (ISO/IEC 2011). <br />
<br />
These notions are also used in industrial sectors, such as aviation administrations and aeronautic transportation, health care systems, space, etc., with adapted definitions and/or terms, such as operational concepts, usage concepts and/or technological concepts. For example, “mission analysis” is the term used to describe the mathematical analysis of satellite orbits performed to determine how best to achieve the objectives of a space mission (European Space Agency).<br />
<br />
In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:<br />
<br />
<blockquote>''. . . studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and this in turn of the global environmental analysis. Through all these analyses, the chances, strengths, weaknesses, and risks of a company can be identified. Finally, with the help of a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm's planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company.'' (Wikipedia, 02/12/12)</blockquote><br />
<br />
Anywhere these notions are used, it is evident that they are based on fundamental concepts, such as the [[Operational Mode (glossary)|operational mode]] (or state of the system), [[Scenario (glossary)|scenario]] (of actions), the enterprise level concept of operations and the system level operational concepts, [[Function (glossary) |functions]] (providing services), etc. For more explanations about the concept of operations and operational concept, refer to ''Systems and Software Engineering - Requirements Engineering'' (ISO/IEC 2011); useful information can be found in Annex A, "System Operational Concept", and Annex B, "Concept of Operations" (ISO/IEC 2011).<br />
<br />
===Mission Analysis as Part of Enterprise Strategy Development===<br />
Periodically, most enterprises re-evaluate their strategy with respect to their mission, vision, and positioning to accomplish their goals. Figure 1 shows the interactions of the enterprise strategy development and the concept definition, including MA and stakeholder needs and requirements that are involved in an iterative manner to fully develop the strategy and define future capabilities and solutions. As the enterprise evolves the strategy, it is essential to conduct the supporting MA or strategic analysis for each element of the enterprise to determine their readiness to achieve their future objectives. This analysis examines the current state to identify any problems or opportunities related to the objective achievement and aids the enterprise in fully understanding and defining the problem space. The analysis examines the external environment and interfaces in search of impacts and trends, as well as the internal enterprise to gauge its capabilities and value stream gaps. Additionally, a SWOT analysis may be performed to weigh the strengths, weaknesses, opportunities, and threats. As the problem space is defined, stakeholder needs and requirements activities are performed to define the stakeholder needs and transform them into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, the future state of core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities (see [[Stakeholder Needs and Requirements]] for more information). Finally, MA is engaged again to examine the solution space. Candidate solutions that span the potential solution space are identified, from simple operational changes, to various system developments or modifications. Various techniques are applied to analyze the candidates, understand their feasibility and value, and select the best alternative.<br />
<br />
[[File:Enterprise_Strategy_and_Concept_Development.PNG|thumb|700px|center|Figure 1. Enterprise Strategy and Concept Development (Roedler 2012) Reprinted with permission of Garry Roedler]]<br />
<br />
==Process Approach==<br />
===Activities of the Process===<br />
It is necessary to perform the following major activities and tasks during this process: <br />
#Review and understand the enterprise mission, vision, and ConOps.<br />
#Identify and define any gaps and opportunities related to future evolution of the strategy:<br />
##Examine the current state to identify any problems or opportunities related to the objective achievement, including any deficiencies of the existing system.<br />
##Analyze the context of the actual PESTAL factors (Political, Economic, Social, Technological, Environmental, and Legal), while studying sensitive factors such as cost and effectiveness, security and safety improvement, performance improvement or lack of existing systems, market opportunities, regulation changes, users' dissatisfaction, etc. External, internal, and SWOT analysis should be included as well.<br />
##Define any mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without thinking to solution. <br />
#Examine and evaluate the solution space.<br />
##Identify the main stakeholders (customers, users, administrations, regulations, etc.).<br />
##Identify high level operational modes or states, or potential use cases.<br />
##Identify candidate solutions that span the potential solution space, from simple operational changes, to various system developments or modifications. Identify existing systems, products, and services that may address the need for operational or functional modifications. Deduce what potential expected services may be needed. A potential and not yet existing product, service or enterprise is called the "system-of-interest" (SoI). Additionally, the solution could be an operational change or a change to an existing product or service.<br />
#Perform appropriate modeling, simulation, and analytical techniques to understand the feasibility and value of the alternative candidate solutions. Model or simulate operational scenarios from these services and use cases, and enrich them through reviews with stakeholders and subject matter experts.<br />
#Define basic operational concept or market strategy, and/or business models.<br />
##From previous modeled operational scenarios and operational modes, deduce and express the usage of operational concepts, or technical concepts.<br />
##Collect and enrich needs, expectations, scenarios, and constraints.<br />
##Validate the mission of any potential SoI in the context of any proposed market strategy or business model.<br />
#Evaluate the set of alternatives and select the best alternative.<br />
##Perform a trade study of the alternatives to discriminate between the alternatives.<br />
#Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.<br />
<br />
===Mission Analysis Artifacts===<br />
<br />
This process may create several artifacts, such as:<br />
*recommendations for revisions to the enterprise ConOps;<br />
*preliminary operational concept document or inputs;<br />
*mission analysis and definition reports;<br />
*trade study results (alternatives analysis); and<br />
*market study/analysis reports.<br />
<br />
===Methods and Modeling Techniques===<br />
<br />
MA uses techniques, such as:<br />
<br />
*use case diagrams;<br />
*context relationships diagrams; <br />
*sequence and/or activity diagrams;<br />
*functional flow block diagrams;<br />
*technical documentation review;<br />
*trade studies;<br />
*modeling;<br />
*simulation;<br />
*prototyping;<br />
*workshops, interviews, and questionnaires;<br />
*market competitive assessments;<br />
*benchmarking; and<br />
*organizational analysis techniques (e.g., strengths, weaknesses, opportunities, threats (SWOT analysis), and product portfolios).<br />
<br />
==Practical Considerations==<br />
Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1. <br />
<br />
<center><br />
{|<br />
|+'''Table 1. Major Pitfalls with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|Wrong level of system addressed<br />
|When delineating the boundaries of the system-of-interest and defining the mission and purpose of the system at the very beginning of systems engineering, a classic mistake is to place the system-of-interest at the wrong level of abstraction. The level of abstraction can be too high or too low (sitting respectively in the upper-system or in a sub-system). This is the consequence of the principle stating that a system is always included in a larger system and of confusing the purpose and the mission of the system-of-interest.<br />
|-<br />
|Operational modes or scenarios missing<br />
|In commercial products or systems, the lack or insufficient description of operational modes and scenarios (how the system-of-interest will be used, in which situations, etc.) is often encountered.<br />
|}<br />
</center><br />
<br />
<br />
Proven practices with mission analysis and marketing analysis are presented in Table 2.<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Proven Practices with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|Models of operational scenarios<br />
|Using modeling techniques as indicated in sections above for operational scenarios in any kind of system-of-interest (including commercial systems).<br />
|-<br />
|Models of the context<br />
|Consider the context of use as a system and force oneself to use modeling techniques for main aspects of the context (functional, behavioral, physical, etc.).<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Freeman, Richard, “Achieving Strategic Aims: Moving Toward a Process Based Military Enterprise”<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering -- Life cycle processes -- Requirements engineering'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC/IEEE 29148:2011<br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
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.<br />
<br />
Kaplan, Robert S. and Norton, David P., “Developing the Strategy: Vision, Value Gaps, and Analysis”, Balanced Scorecard Report, Harvard Business School Publishing, Jan-Feb 2008<br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A simple method for phased mission analysis." ''Reliability Engineering & System Safety'' 45(3): 299-309.<br />
<br />
National Defense Industrial Association, Systems Engineering Division, Mission Analysis Committee, “Mission Analysis Committee Charter”<br />
<br />
Shupp, Jeffrey K., “The Mission Analysis Discipline: Bringing focus to the fuzziness about Attaining Good Architectures”, Proceedings of INCOSE 13th International Symposium, July 2003.<br />
<br />
Wikipedia, “Market Analysis”, 12 February 2012.<br />
<br />
===Primary References===<br />
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).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
Center for Quality Management. 1993. "Special Issue on Kano's Methods for Understanding Customer Defined Quality." ''Center for Quality Management Journal'' 2(4) (Fall 1993). <br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering.'' 3rd ed. London, UK: Springer.<br />
<br />
Kano, N. 1984. "Attractive Quality and Must-Be Quality." ''Quality JSQC'' 14(2) (October 1984). <br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309. <br />
<br />
Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques," in ''Software Engineering''. New York, NY: McGraw-Hill.<br />
<br />
MITRE. 2011. "Concept Development." ''Systems Engineering Guide. '' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/]].<br />
<br />
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/]].<br />
<br />
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]].<br />
----<br />
<center>[[Concept Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Stakeholder Needs and Requirements|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Concept Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Business_or_Mission_Analysis&diff=38089Business or Mission Analysis2012-08-06T21:26:37Z<p>Groedler: </p>
<hr />
<div>The starting point of engineering any [[System of Interest (SoI) (glossary)|system of interest (SoI)]] is understanding the socio-economic and technological context wherein potential problems or opportunities reside. The enterprise strategic goals and [[Stakeholder (glossary)| stakeholders’]] needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], and [[Customer (glossary)|customers]]. An important set of activities, called [[Mission Analysis (glossary)|mission analysis]] ([[Acronyms|MA]]) (also called [[Market Analysis (glossary)|market analysis]] or business anlaysis in certain domains or sectors), is often performed iteratively with [[Stakeholder Needs and Requirements]] generation to better understand the problem space, as well as the solution space. The execution of this process enables a systems engineer to then establish a set of [[Stakeholder Requirement (glossary)| stakeholder requirements]] for a potential SoI, or other solution, that could provide a capability or service needed by the acquirer, the users, and the other stakeholders in a defined environment. <br />
<br />
MA is part of the larger set of [[Concept Definition|concept definition]] activities. [[Concept Definition|Concept definition]] is the phase of systems engineering in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the [[System of Interest (SoI) (glossary)|system of interest]] is developed. Mission analysis focuses on the identification of the primary purpose(s) of the system, while [[Stakeholder Needs and Requirements]] definition explores what capabilities stakeholders desire and may include some detail on how certain aspects of the system must perform.<br />
<br />
== Purpose and Definition ==<br />
The purpose of MA is to understand a problem or opportunity, analyze the solution space, and initiate the life cycle of a potential solution that could answer the problem or take advantage of an opportunity.<br />
<br />
MA, known in some domains as [[Strategic Analysis (glossary)|strategic analysis (glossary)]] or [[Market Analysis (glossary)|market analysis (glossary)]], is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise. The definition of a need in a problem space frames the solution, both in terms of the direct application to the mission or business function, and in terms of the context for the resulting solution. MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. It characterizes the operational need in terms of mission requirements and the environment/context the need exists within, together with the enterprise concept of operations and operational scenarios. The primary products of MA are the Concept of Operations ([[Concept of Operations (ConOps) (glossary)|ConOps]]) of the enterprise, the [[Operational Concept (glossary)|Operational Concept]], the [[Operational Scenario (glossary)|Operational Scenarios]] for the mission, and the context in which the solution will exist. <br />
<br />
MA may include mathematical analysis, modeling, simulation, visualization, and other analytical tools to characterize the intended mission and determine how to best achieve the needs/objectives. MA evaluates alternative approaches to determine which alternative approach best supports the stakeholder needs (among both materiel and non-materiel solution alternatives). Thus, MA defines the problem space and analyzes the solution space alternatives using quality attribute constraints driven by the enterprise objectives.<br />
<br />
==Principles and Concepts==<br />
===Mission Analysis and Concept of Operations===<br />
MA and the [[Concept of Operations (ConOps) (glossary)|ConOps]] are broadly used in defense and aerospace organizations to analyze and define how the system is intended to operate, as well as how the major operations or operational scenarios are intended to be performed, taking into account the strategic, operational, and tactical aspects of the identified scenarios. MA is a type of strategic or operations analysis related to needs or capability gaps and solutions that can be applied to any organization that evolves its strategy for its business objectives.<br />
<br />
In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering ([[Acronyms|SE]]) leaders interact with enterprise leaders and operations analysts to understand: <br />
*the enterprise ConOps and future mission, business, and operational (MBO) objectives; <br />
*the characterization of the Operational Concept and objectives (i.e., constraints, mission or operational scenarios, tasks, resources, risks, assumptions, and related missions or operations); and<br />
*how specific missions or operations are currently conducted and what gaps exist in those areas.<br />
<br />
They then conceptually explore and select from alternative candidate solutions. This interaction ensures a full understanding of both the problem space and the solution space. The alternative candidate solutions can include a wide range of approaches to address the need, as well as variants for an approach to optimize specific characteristics (e.g., using a different distribution of satellite orbit parameters to maximize coverage or events while minimizing the number of satellites). Analysis, modeling and simulation, and trade studies are employed to select alternative approaches (Charter of the Mission Analysis Committee, National Defense Industrial Association, Systems Engineering Division).<br />
<br />
"The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems (as black boxes) to forward the organization's goals and objectives. The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations within the business in regards to the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of future business and systems” (ISO/IEC 2011). <br />
<br />
These notions are also used in industrial sectors, such as aviation administrations and aeronautic transportation, health care systems, space, etc., with adapted definitions and/or terms, such as operational concepts, usage concepts and/or technological concepts. For example, “mission analysis” is the term used to describe the mathematical analysis of satellite orbits performed to determine how best to achieve the objectives of a space mission (European Space Agency).<br />
<br />
In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that:<br />
<br />
<blockquote>''. . . studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and this in turn of the global environmental analysis. Through all these analyses, the chances, strengths, weaknesses, and risks of a company can be identified. Finally, with the help of a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm's planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company.'' (Wikipedia, 02/12/12)</blockquote><br />
<br />
Anywhere these notions are used, it is evident that they are based on fundamental concepts, such as the [[Operational Mode (glossary)|operational mode]] (or state of the system), [[Scenario (glossary)|scenario]] (of actions), the enterprise level concept of operations and the system level operational concepts, [[Function (glossary) |functions]] (providing services), etc. For more explanations about the concept of operations and operational concept, refer to ''Systems and Software Engineering - Requirements Engineering'' (ISO/IEC 2011); useful information can be found in Annex A, "System Operational Concept", and Annex B, "Concept of Operations" (ISO/IEC 2011).<br />
<br />
===Mission Analysis as Part of Enterprise Strategy Development===<br />
Periodically, most enterprises re-evaluate their strategy with respect to their mission, vision, and positioning to accomplish their goals. Figure 1 shows the interactions of the enterprise strategy development and the concept definition, including MA and stakeholder needs and requirements that are involved in an iterative manner to fully develop the strategy and define future capabilities and solutions. As the enterprise evolves the strategy, it is essential to conduct the supporting MA or strategic analysis for each element of the enterprise to determine their readiness to achieve their future objectives. This analysis examines the current state to identify any problems or opportunities related to the objective achievement and aids the enterprise in fully understanding and defining the problem space. The analysis examines the external environment and interfaces in search of impacts and trends, as well as the internal enterprise to gauge its capabilities and value stream gaps. Additionally, a SWOT analysis may be performed to weigh the strengths, weaknesses, opportunities, and threats. As the problem space is defined, stakeholder needs and requirements activities are performed to define the stakeholder needs and transform them into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, the future state of core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities (see [[Stakeholder Needs and Requirements]] for more information). Finally, MA is engaged again to examine the solution space. Candidate solutions that span the potential solution space are identified, from simple operational changes, to various system developments or modifications. Various techniques are applied to analyze the candidates, understand their feasibility and value, and select the best alternative.<br />
<br />
[[File:Enterprise_Strategy_and_Concept_Development.PNG|thumb|700px|center|Figure 1. Enterprise Strategy and Concept Development (Roedler 2012) Reprinted with permission of Garry Roedler]]<br />
<br />
==Process Approach==<br />
===Activities of the Process===<br />
It is necessary to perform the following major activities and tasks during this process: <br />
#Review and understand the enterprise mission, vision, and ConOps.<br />
#Identify and define any gaps and opportunities related to future evolution of the strategy:<br />
##Examine the current state to identify any problems or opportunities related to the objective achievement, including any deficiencies of the existing system.<br />
##Analyze the context of the actual PESTAL factors (Political, Economic, Social, Technological, Environmental, and Legal), while studying sensitive factors such as cost and effectiveness, security and safety improvement, performance improvement or lack of existing systems, market opportunities, regulation changes, users' dissatisfaction, etc. External, internal, and SWOT analysis should be included as well.<br />
##Define any mission, business, and/or operational problem or opportunity, as well as its context, and any key parameters, without thinking to solution. <br />
#Examine and evaluate the solution space.<br />
##Identify the main stakeholders (customers, users, administrations, regulations, etc.).<br />
##Identify high level operational modes or states, or potential use cases.<br />
##Identify candidate solutions that span the potential solution space, from simple operational changes, to various system developments or modifications. Identify existing systems, products, and services that may address the need for operational or functional modifications. Deduce what potential expected services may be needed. A potential and not yet existing product, service or enterprise is called the "system-of-interest" (SoI). Additionally, the solution could be an operational change or a change to an existing product or service.<br />
#Perform appropriate modeling, simulation, and analytical techniques to understand the feasibility and value of the alternative candidate solutions. Model or simulate operational scenarios from these services and use cases, and enrich them through reviews with stakeholders and subject matter experts.<br />
#Define basic operational concept or market strategy, and/or business models.<br />
##From previous modeled operational scenarios and operational modes, deduce and express the usage of operational concepts, or technical concepts.<br />
##Collect and enrich needs, expectations, scenarios, and constraints.<br />
##Validate the mission of any potential SoI in the context of any proposed market strategy or business model.<br />
#Evaluate the set of alternatives and select the best alternative.<br />
##Perform a trade study of the alternatives to discriminate between the alternatives.<br />
#Provide feedback on feasibility, market factors, and alternatives for use in completion of the enterprise strategy and further actions.<br />
<br />
===Mission Analysis Artifacts===<br />
<br />
This process may create several artifacts, such as:<br />
*recommendations for revisions to the enterprise ConOps;<br />
*preliminary operational concept document or inputs;<br />
*mission analysis and definition reports;<br />
*trade study results (alternatives analysis); and<br />
*market study/analysis reports.<br />
<br />
===Methods and Modeling Techniques===<br />
<br />
MA uses techniques, such as:<br />
<br />
*use case diagrams;<br />
*context relationships diagrams; <br />
*sequence and/or activity diagrams;<br />
*functional flow block diagrams;<br />
*technical documentation review;<br />
*trade studies;<br />
*modeling;<br />
*simulation;<br />
*prototyping;<br />
*workshops, interviews, and questionnaires;<br />
*market competitive assessments;<br />
*benchmarking; and<br />
*organizational analysis techniques (e.g., strengths, weaknesses, opportunities, threats (SWOT analysis), and product portfolios).<br />
<br />
==Practical Considerations==<br />
Major pitfalls encountered with mission analysis and marketing analysis are presented in Table 1. <br />
<br />
<center><br />
{|<br />
|+'''Table 1. Major Pitfalls with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|Wrong level of system addressed<br />
|When delineating the boundaries of the system-of-interest and defining the mission and purpose of the system at the very beginning of systems engineering, a classic mistake is to place the system-of-interest at the wrong level of abstraction. The level of abstraction can be too high or too low (sitting respectively in the upper-system or in a sub-system). This is the consequence of the principle stating that a system is always included in a larger system and of confusing the purpose and the mission of the system-of-interest.<br />
|-<br />
|Operational modes or scenarios missing<br />
|In commercial products or systems, the lack or insufficient description of operational modes and scenarios (how the system-of-interest will be used, in which situations, etc.) is often encountered.<br />
|}<br />
</center><br />
<br />
<br />
Proven practices with mission analysis and marketing analysis are presented in Table 2.<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Proven Practices with Definition of Mission Analysis.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|Models of operational scenarios<br />
|Using modeling techniques as indicated in sections above for operational scenarios in any kind of system-of-interest (including commercial systems).<br />
|-<br />
|Models of the context<br />
|Consider the context of use as a system and force oneself to use modeling techniques for main aspects of the context (functional, behavioral, physical, etc.).<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Freeman, Richard, “Achieving Strategic Aims: Moving Toward a Process Based Military Enterprise”<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering -- Life cycle processes -- Requirements engineering'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC/IEEE 29148:2011<br />
<br />
ISO/IEC/IEEE. 2008. ''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:2008 (E).<br />
<br />
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.<br />
<br />
Kaplan, Robert S. and Norton, David P., “Developing the Strategy: Vision, Value Gaps, and Analysis”, Balanced Scorecard Report, Harvard Business School Publishing, Jan-Feb 2008<br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A simple method for phased mission analysis." ''Reliability Engineering & System Safety'' 45(3): 299-309.<br />
<br />
National Defense Industrial Association, Systems Engineering Division, Mission Analysis Committee, “Mission Analysis Committee Charter”<br />
<br />
Shupp, Jeffrey K., “The Mission Analysis Discipline: Bringing focus to the fuzziness about Attaining Good Architectures”, Proceedings of INCOSE 13th International Symposium, July 2003.<br />
<br />
Wikipedia, “Market Analysis”, 12 February 2012.<br />
<br />
===Primary References===<br />
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).<br />
<br />
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]].<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
Center for Quality Management. 1993. "Special Issue on Kano's Methods for Understanding Customer Defined Quality." ''Center for Quality Management Journal'' 2(4) (Fall 1993). <br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com.<br />
<br />
IEEE. 1998. ''Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document''. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers, IEEE 1362:1998.<br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering.'' 3rd ed. London, UK: Springer.<br />
<br />
Kano, N. 1984. "Attractive Quality and Must-Be Quality." ''Quality JSQC'' 14(2) (October 1984). <br />
<br />
Kohda, T., M. Wada, and K. Inoue. 1994. "A Simple Method for Phased Mission Analysis." ''Reliability Engineering & System Safety.'' 45(3): 299-309. <br />
<br />
Marca, D. A. and C. L. McGowan. 1987. "SADT: Structured analysis and design techniques," in ''Software Engineering''. New York, NY: McGraw-Hill.<br />
<br />
MITRE. 2011. "Concept Development." ''Systems Engineering Guide. '' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/concept_development/]].<br />
<br />
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/]].<br />
<br />
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]].<br />
----<br />
<center>[[Concept Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Stakeholder Needs and Requirements|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Concept Definition]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Logistics&diff=38025Logistics2012-08-06T18:17:44Z<p>Groedler: /* Sustainment Planning */</p>
<hr />
<div>There are several definitions for logistics within systems engineering and the definition used will determine what activities are considered part of logistics. The SEBoK defines [[logistics (glossary)]] as “the science of planning and implementing the acquisition and use of the resources necessary to sustain the operation of a system.”<br />
<br />
==Overview==<br />
The ability to “sustain the operation of a system” is determined by the inherent supportability of the system (a function of design) and the processes used to sustain the functions and capabilities of the system in the context of the end user. <br />
<br />
[[File:Affordable_Sys_Ops_Effect_DAU_GB_Roedler.jpg|thumb|600px|center|Figure 1. Affordable System Operational Effectiveness (DAU Guidebook 2012, pg. 385 ) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
==Sustainment Planning==<br />
The focus of [[sustainment (glossary)|sustainment]] planning is to influence the inherent supportability of the system and to plan the sustainment capabilities and processes that will be used to sustain system operations.<br />
Influence Inherent Supportability (Operational Suitability)<br />
<br />
Sustainment influence requires an understanding of the [[concept of operations (ConOps) (glossary)|concept of operations (ConOps), system missions, [[mission (glossary)|mission]] profiles, and [[System Capability (glossary)|system capabilities]] to understand the [[rationale (glossary)|rationale]] behind functional and performance priorities. Understanding the rationale paves the way for decisions about necessary tradeoffs between system performance, availability, and [[Life Cycle Cost (LCC) (glossary)|Life Cycle Cost (LCC)]], with impact on the cost effectiveness of system operation, maintenance, and logistics support. There is no single list of sustainment considerations or specific way of grouping them as they are highly inter-related. They range from: compatibility, [[interoperability (glossary)|interoperability]]; transportability; [[reliability (glossary)|reliability]]; [[maintainability (glossary)|maintainability]]; [[manpower (glossary)|manpower]]; [[Human Factors (glossary)|human factors]]; [[safety (glossary)|safety]]; natural environment effects (including occupational health; habitability); diagnostics & prognostics (including real-time maintenance data collection); and corrosion protection & mitigation. The following are key design considerations:<br />
<br />
'''[[Architecture (glossary)|Architecture]] Considerations''': The focus on openness, modularity, scalability, and upgradeability is critical to implementing an incremental acquisition strategy. In addition, the architecture attributes that expand system [[flexibility (glossary)|flexibility]] and affordability can pay dividends later when obsolescence and end-of-life issues are resolved through a concerted technology refreshment strategy. However trade-offs are required relative to the extent each attribute is used.<br />
<br />
'''[[Reliability (glossary)|Reliability]] Considerations''': Reliability is critical because it contributes to a system's effectiveness as well as its suitability in terms of logistics burden and the cost to fix [[Failure (glossary)|failures]]. For each system, there is a level of basic reliability that must be achieved for the system to be considered useful. Reliability is also one of the most critical elements in determining the logistics infrastructure and footprint. Consequently, system reliability should be a primary focus during design (along with system technical performance, functions, and capabilities). The primary objective is to achieve the necessary probability of operational success and minimize the risk of failure within defined availability, cost, schedule, weight, power, and volume constraints. While performing such analyses, trade-offs should be conducted and dependencies should be explored with system maintainability and integrated with the supportability analysis that addresses support event frequency (i.e. Reliability), event duration and event cost. Such a focus will play a significant role in minimizing the necessary logistics footprint, while maximizing system availability.<br />
<br />
'''[[Maintainability (glossary)|Maintainability]] Considerations''': The design emphasis on maintainability is to reduce the maintenance burden and supply chain by reducing the time, personnel, tools, test equipment, training, facilities and cost to maintain the system. Maintainability engineering includes the activities, methods, and practices used to design minimal system maintenance requirements (designing out unnecessary and inefficient processes) and associated costs for preventive and corrective maintenance as well as servicing or calibration activities. Maintainability should be a designed-in capability and not an add-on option because good maintenance procedures cannot overcome poor system and equipment maintainability design. The primary objective is to reduce the time it takes for a properly trained maintainer to detect and isolate the failure (coverage and efficiency) and affect repair. Intrinsic factors contributing to maintainability are:<br />
<br />
*''[[Modularity (glossary)|Modularity]]'': Packaging of components such that they can be repaired via remove and replace action vs. on-board repair. Care should be taken not to "over modularize" and trade-offs to evaluate replacement, transportation, and repair costs should be accomplished to determine the most cost effective approach.<br />
*''Interoperability'': The compatibility of components with standard interface protocols to facilitate rapid repair and enhancement/upgrade through black box technology using common interfaces. Physical interfaces should be designed so that mating between components can only happen correctly.<br />
*''Physical accessibility'': The designed-in structural assurance that components requiring more frequent monitoring, checkout, and maintenance can be easily accessed. This is especially important in Low Observable platforms. Maintenance points should be directly visible and accessible to maintainers, including access for corrosion inspection and mitigation.<br />
*Designs that require ''minimum preventative maintenance'' including corrosion prevention and mitigation. Emphasis should be on balancing the maintenance requirement over the life cycle with minimal user workload.<br />
*''Embedded training and testing'' when it is determined to be the optimal solution from a [[Total Ownership Cost (glossary)|Total Ownership Cost (TOC)]] and Materiel Availability perspective.<br />
*''[[Human Systems Integration (HSI) (glossary)|Human Systems Integration (HSI)]]'' to optimize total system performance and minimize life-cycle costs by designing systems and incorporating technologies that require minimal manpower, provide effective training, can be operated and maintained by users, are suitable (habitable and safe with minimal environmental and occupational health hazards), and survivable (for both the user and the equipment).<br />
<br />
'''Support Considerations''': Support features cannot be easily "added-on" after the design is established. Consequently supportability should be a high priority early in the program's planning and integral to the system design and development process. Support features cut across reliability, maintainability, and the supply chain to facilitate detection, isolation, and timely repair/replacement of system anomalies. These include features for servicing and other activities necessary for operation and support including resources that contribute to the overall support of the system. Typical supportability features include diagnostics, prognostics (see CBM+ Guidebook), calibration requirements, many HSI issues (e.g. training, safety, HFE, occupational health, etc.), skill levels, documentation, maintenance data collection, compatibility, interoperability, transportability, handling (e.g., lift/hard/tie down points, etc.), packing requirements, facility requirements, accessibility, and other factors that contribute to an optimum environment for sustaining an operational system.<br />
<br />
==Plan Sustainment Processes==<br />
Process efficiency reflects how well the system can be produced, operated, serviced (including fueling) and maintained. It reflects the degree to which the logistics processes (including the supply chain), infrastructure, and footprint have been balanced to provide an agile, deployable, and operationally effective system. <br />
<br />
Achieving process efficiency requires early and continuing emphasis on the various logistics support processes along with the design considerations. The continued emphasis is important because processes present opportunities for improving operational effectiveness even after the "design-in" window has passed via lean-six sigma, supply chain optimization and other continuous process improvement (CPI) techniques. <br />
<br />
==Sustainment Analysis (Product Support Package)==<br />
<br />
The product support package documents the output of supportability analysis and includes details related to the following topics (links below are to excerpts from (NATO RTO 2001):<br />
<br />
*Product/IT System/Medical System Support Management (integrated life cycle sustainment planning)<br />
**Product/IT System/Medical System Support Strategies<br />
**Lifecycle sustainment planning<br />
**Requirements Management<br />
**[[Total Ownership Cost (glossary)|Total Ownership Costs (TOC)]] / [[Life Cycle Cost (LCC) (glossary)|Life Cycle Costs (LCC)]] planning & management<br />
**[[Integration (glossary)|Integration]] and management of product support activities<br />
**[[Configuration Management (glossary)|Configuration Management]]<br />
**Production & Distribution<br />
**Energy, Environmental, Safety and Health (EESH) management<br />
**Policies & Guidance<br />
**[[Risk Management (glossary)|Risk Management]]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-12.pdf Design Interface]<br />
**[[Reliability (glossary)|Reliability]]<br />
**[[Maintainability (glossary)|Maintainability]]<br />
**Supportability<br />
**Affordability<br />
**[[Configuration Management (glossary)|Configuration Management]]<br />
**Safety requirements<br />
**Environmental and HAZMAT requirements<br />
**[[Human Systems Integration (HSI) (glossary)|Human Systems Integration]]<br />
**Calibration<br />
**Anti-Tamper<br />
**Habitability<br />
**Disposal<br />
**Legal requirements<br />
*Sustaining Engineering<br />
**Failure Reporting, Analysis, and Corrective Action System (FRACAS)<br />
**Value Engineering<br />
**Diminishing Manufacturing Sources and Material Shortages<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-06.pdf Supply Support (materiel planning)]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-03.pdf Maintenance Planning]<br />
**Reliability Centered Maintenance (RCM)<br />
**Maintenance Concepts<br />
**Levels of Maintenance (Level of Repair Analysis)<br />
**Conditioned Based Maintenance<br />
**Prognostics & Health Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-05.pdf Support Equipment]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-07.pdf Technical Data]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-04.pdf Manpower & Personnel]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-08.pdf Training & Training Support]<br />
*[http://www.decisionlens.com/docs/WP_Strategic_Facilities_and_Infrastructure_Planning.pdf Facilities & Infrastructure]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-11.pdf Packaging, Handling, Storage, & Transportation]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-09.pdf Computer Resources]<br />
<br />
==Sustainment Implementation==<br />
Once the system becomes operational, the results of sustainment planning effort needs to implemented. Systems engineering supports the execution of the twelve integrated product support elements of a sustainment program that strives to ensure the system meets operational performance requirements in the most cost-effective manner over its total remaining life cycle.<br />
<br />
[[File:Sustainment_Implementation_Illustration_Logistics_Roedler.jpg|thumb|center|600px|Figure 2. Sustainment Implementation Illustration (DAU Guidebook 2012) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
Once a system is put into use, systems engineering is often required to correct problems that degrade continued use, and/or to add new capabilities to improve product performance in the current or a new environment. In the context of integrated product support, these systems engineering activities correspond to the IPS element “Sustaining Engineering.” Changes made to fielded systems to correct problems or increase performance should include any necessary adjustments to the IPS elements, and should consider the interrelationships and integration of the elements to maintain the effectiveness of system’s support strategy.<br />
<br />
The degree of change required to the product support elements varies with the severity of the problem. Minor problems may require a simple adjustment to a maintenance procedure, a change of supplier, a training course modification or a change to a technical manual. In contrast, problems that require system or component redesign may require engineering change proposals and approvals, IPS element trade studies, Business Case Analysis, and updates to the product support strategy. The focus is to correct problems that degrade continued use, regardless of the degree of severity.<br />
<br />
Evolutionary systems provide a strategy for acquisition of mature technology; the system delivers capabilities incrementally, planning for future capability enhancements. For these systems a System of Systems perspective is required to synchronize the Primary and Sustainment Systems.<br />
<br />
For more information refer to: An Enterprise Framework for Operationally Effective System of Systems Design.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
NATO RTO. 2001. ''Logistics Test and Evaluation in Flight Test''. Flight Test Techniques Series – Volume 20. Quebec, Canada: North Atlantic Treaty Organization (NATO) Research and Technology Organization (RTO). RTO-AG-300 Vol. 20, AC/323(SCI-010)TP/38. Table of contents available at: http://ftp.rta.nato.int/public//PubFullText/RTO/AG/RTO-AG-300-V20///AG-300-V20-$$TOC.pdf<br />
<br />
===Primary References===<br />
Blanchard, B.S. 1998. ''[[Logistics Engineering and Management]].'' Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
Blanchard, B. and Fabrycky, W. 2011. ''[[Systems Engineering and Analysis]],'' 5th Ed. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Bobinis, J. and Herald, T. 2012. “An Enterprise Framework for Operationally Effective System of Systems Design.” Journal of Enterprise Architecture May 2012, Volume 8, Number 2. Available at: https:// www.mendling.com/publications/JEA12-2.pdf.<br />
<br />
Daganzo, C. 2005. ''[[Logistics Systems Analysis]].'' 4th Edition. New York, NY, USA: Springer.<br />
<br />
Fabrycky, W.J. and B.S. Blanchard. 1991. ''[[Life-Cycle Cost and Economic Analysis]]''. Upper Saddle River, NJ, USA: Prentice-Hall.<br />
<br />
Ghiani, G., Laporte, G., and Musmanno, R. 2004. ''[[Introduction to Logistics Systems Planning and Control]].'' Hoboken, NJ, USA: Wiley-Interscience.<br />
<br />
Jones, J.V. 1995. ''[[Integrated Logistics Support Handbook]].'' New York, NY, USA: McGraw Hill.<br />
<br />
===Additional References===<br />
Barros, L.L. 1998. "The Optimization of Repair Decision Using Life-Cycle Cost Parameters." ''IMA Journal of Management Mathematics.'' 9(4): 403.<br />
<br />
Berkowitz, D., et al. 2005. ''Defining and Implementing Performance-Based Logistics in Government''. Washington, DC, USA: Defense Technical Information Center. Accessed 6 Sept 2011. Available at: http://handle.dtic.mil/100.2/ADP018510.<br />
<br />
Gajpal, P.P., L.S. Ganesh, and C. Rajendran. 1994. "Criticality Analysis of Spare Parts Using the Analytic Hierarchy Process." ''International Journal of Production Economics'' 35(1-3): 293-297. <br />
<br />
MITRE. 2011. "Integrated Logistics Support." ''Systems Engineering Guide.'' Accessed 11 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/acquisition_systems_engineering/integrated_logistics_support/]].<br />
<br />
Murthy, D.N.P. and W.R. Blischke. 2000. "Strategic Warranty Management: A Life-Cycle Approach." ''Engineering Management'' 47(1): 40-54.<br />
<br />
Northrop Grumman Corporation. 2000. ''Logistics Systems Engineering''. Accessed 6 Sept 2011. Available at: www.es.northropgrumman.com/solutions/navlogistics/.../nsd_logistics.pdf.<br />
<br />
Solomon, R., P.A. Sandborn, and M.G. Pecht. 2000. "Electronic Part Life Cycle Concepts and Obsolescence Forecasting." ''IEEE Transactions on Components and Packaging Technologies'' 23(4): 707-717. <br />
<br />
Spengler, T. and M. Schroter. 2003. "Strategic Management of Spare Parts in Closed-Loop Supply Chains: A System Dynamics Approach." ''Interfaces'' p. 7-17.<br />
<br />
----<br />
<center>[[System Maintenance|< Previous Article]] | [[System Deployment and Use|Parent Article]] | [[Systems Engineering Management|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Deployment and Use]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Logistics&diff=38022Logistics2012-08-06T18:16:31Z<p>Groedler: /* Sustainment Planning */</p>
<hr />
<div>There are several definitions for logistics within systems engineering and the definition used will determine what activities are considered part of logistics. The SEBoK defines [[logistics (glossary)]] as “the science of planning and implementing the acquisition and use of the resources necessary to sustain the operation of a system.”<br />
<br />
==Overview==<br />
The ability to “sustain the operation of a system” is determined by the inherent supportability of the system (a function of design) and the processes used to sustain the functions and capabilities of the system in the context of the end user. <br />
<br />
[[File:Affordable_Sys_Ops_Effect_DAU_GB_Roedler.jpg|thumb|600px|center|Figure 1. Affordable System Operational Effectiveness (DAU Guidebook 2012, pg. 385 ) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
==Sustainment Planning==<br />
The focus of [[sustainment (glossary)|sustainment]] planning is to influence the inherent supportability of the system and to plan the sustainment capabilities and processes that will be used to sustain system operations.<br />
Influence Inherent Supportability (Operational Suitability)<br />
<br />
Sustainment influence requires an understanding of the [[concept of operations (ConOps) (glossary)|concept of operations (ConOps), system missions, [[mission (glossary)|mission]] profiles, and [[System Capability (glossary)|system capabilities]] to understand the [[rationale (glossary)|rationale]] behind functional and performance priorities. Understanding the rationale paves the way for decisions about necessary tradeoffs between system performance, availability, and [[Life Cycle Cost (LCC) (glossary)|Life Cycle Cost (LCC)]], with impact on the cost effectiveness of system operation, maintenance, and logistics support. There is no single list of sustainment considerations or specific way of grouping them as they are highly inter-related. They range from: compatibility, [[interoperability (glossary)|interoperability]]; transportability; [[reliability (glossary)|reliability]]; [[maintainability (glossary)|maintainability]]; [[manpower (glossary)|manpower]]; [[human factors (glossary)|human factors]]; [[safety (glossary)|safety]]; natural environment effects (including occupational health; habitability); diagnostics & prognostics (including real-time maintenance data collection); and corrosion protection & mitigation. The following are key design considerations:<br />
<br />
'''[[Architecture (glossary)|Architecture]] Considerations''': The focus on openness, modularity, scalability, and upgradeability is critical to implementing an incremental acquisition strategy. In addition, the architecture attributes that expand system [[flexibility (glossary)|flexibility]] and affordability can pay dividends later when obsolescence and end-of-life issues are resolved through a concerted technology refreshment strategy. However trade-offs are required relative to the extent each attribute is used.<br />
<br />
'''[[Reliability (glossary)|Reliability]] Considerations''': Reliability is critical because it contributes to a system's effectiveness as well as its suitability in terms of logistics burden and the cost to fix [[Failure (glossary)|failures]]. For each system, there is a level of basic reliability that must be achieved for the system to be considered useful. Reliability is also one of the most critical elements in determining the logistics infrastructure and footprint. Consequently, system reliability should be a primary focus during design (along with system technical performance, functions, and capabilities). The primary objective is to achieve the necessary probability of operational success and minimize the risk of failure within defined availability, cost, schedule, weight, power, and volume constraints. While performing such analyses, trade-offs should be conducted and dependencies should be explored with system maintainability and integrated with the supportability analysis that addresses support event frequency (i.e. Reliability), event duration and event cost. Such a focus will play a significant role in minimizing the necessary logistics footprint, while maximizing system availability.<br />
<br />
'''[[Maintainability (glossary)|Maintainability]] Considerations''': The design emphasis on maintainability is to reduce the maintenance burden and supply chain by reducing the time, personnel, tools, test equipment, training, facilities and cost to maintain the system. Maintainability engineering includes the activities, methods, and practices used to design minimal system maintenance requirements (designing out unnecessary and inefficient processes) and associated costs for preventive and corrective maintenance as well as servicing or calibration activities. Maintainability should be a designed-in capability and not an add-on option because good maintenance procedures cannot overcome poor system and equipment maintainability design. The primary objective is to reduce the time it takes for a properly trained maintainer to detect and isolate the failure (coverage and efficiency) and affect repair. Intrinsic factors contributing to maintainability are:<br />
<br />
*''[[Modularity (glossary)|Modularity]]'': Packaging of components such that they can be repaired via remove and replace action vs. on-board repair. Care should be taken not to "over modularize" and trade-offs to evaluate replacement, transportation, and repair costs should be accomplished to determine the most cost effective approach.<br />
*''Interoperability'': The compatibility of components with standard interface protocols to facilitate rapid repair and enhancement/upgrade through black box technology using common interfaces. Physical interfaces should be designed so that mating between components can only happen correctly.<br />
*''Physical accessibility'': The designed-in structural assurance that components requiring more frequent monitoring, checkout, and maintenance can be easily accessed. This is especially important in Low Observable platforms. Maintenance points should be directly visible and accessible to maintainers, including access for corrosion inspection and mitigation.<br />
*Designs that require ''minimum preventative maintenance'' including corrosion prevention and mitigation. Emphasis should be on balancing the maintenance requirement over the life cycle with minimal user workload.<br />
*''Embedded training and testing'' when it is determined to be the optimal solution from a [[Total Ownership Cost (glossary)|Total Ownership Cost (TOC)]] and Materiel Availability perspective.<br />
*''[[Human Systems Integration (HSI) (glossary)|Human Systems Integration (HSI)]]'' to optimize total system performance and minimize life-cycle costs by designing systems and incorporating technologies that require minimal manpower, provide effective training, can be operated and maintained by users, are suitable (habitable and safe with minimal environmental and occupational health hazards), and survivable (for both the user and the equipment).<br />
<br />
'''Support Considerations''': Support features cannot be easily "added-on" after the design is established. Consequently supportability should be a high priority early in the program's planning and integral to the system design and development process. Support features cut across reliability, maintainability, and the supply chain to facilitate detection, isolation, and timely repair/replacement of system anomalies. These include features for servicing and other activities necessary for operation and support including resources that contribute to the overall support of the system. Typical supportability features include diagnostics, prognostics (see CBM+ Guidebook), calibration requirements, many HSI issues (e.g. training, safety, HFE, occupational health, etc.), skill levels, documentation, maintenance data collection, compatibility, interoperability, transportability, handling (e.g., lift/hard/tie down points, etc.), packing requirements, facility requirements, accessibility, and other factors that contribute to an optimum environment for sustaining an operational system.<br />
<br />
==Plan Sustainment Processes==<br />
Process efficiency reflects how well the system can be produced, operated, serviced (including fueling) and maintained. It reflects the degree to which the logistics processes (including the supply chain), infrastructure, and footprint have been balanced to provide an agile, deployable, and operationally effective system. <br />
<br />
Achieving process efficiency requires early and continuing emphasis on the various logistics support processes along with the design considerations. The continued emphasis is important because processes present opportunities for improving operational effectiveness even after the "design-in" window has passed via lean-six sigma, supply chain optimization and other continuous process improvement (CPI) techniques. <br />
<br />
==Sustainment Analysis (Product Support Package)==<br />
<br />
The product support package documents the output of supportability analysis and includes details related to the following topics (links below are to excerpts from (NATO RTO 2001):<br />
<br />
*Product/IT System/Medical System Support Management (integrated life cycle sustainment planning)<br />
**Product/IT System/Medical System Support Strategies<br />
**Lifecycle sustainment planning<br />
**Requirements Management<br />
**[[Total Ownership Cost (glossary)|Total Ownership Costs (TOC)]] / [[Life Cycle Cost (LCC) (glossary)|Life Cycle Costs (LCC)]] planning & management<br />
**[[Integration (glossary)|Integration]] and management of product support activities<br />
**[[Configuration Management (glossary)|Configuration Management]]<br />
**Production & Distribution<br />
**Energy, Environmental, Safety and Health (EESH) management<br />
**Policies & Guidance<br />
**[[Risk Management (glossary)|Risk Management]]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-12.pdf Design Interface]<br />
**[[Reliability (glossary)|Reliability]]<br />
**[[Maintainability (glossary)|Maintainability]]<br />
**Supportability<br />
**Affordability<br />
**[[Configuration Management (glossary)|Configuration Management]]<br />
**Safety requirements<br />
**Environmental and HAZMAT requirements<br />
**[[Human Systems Integration (HSI) (glossary)|Human Systems Integration]]<br />
**Calibration<br />
**Anti-Tamper<br />
**Habitability<br />
**Disposal<br />
**Legal requirements<br />
*Sustaining Engineering<br />
**Failure Reporting, Analysis, and Corrective Action System (FRACAS)<br />
**Value Engineering<br />
**Diminishing Manufacturing Sources and Material Shortages<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-06.pdf Supply Support (materiel planning)]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-03.pdf Maintenance Planning]<br />
**Reliability Centered Maintenance (RCM)<br />
**Maintenance Concepts<br />
**Levels of Maintenance (Level of Repair Analysis)<br />
**Conditioned Based Maintenance<br />
**Prognostics & Health Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-05.pdf Support Equipment]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-07.pdf Technical Data]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-04.pdf Manpower & Personnel]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-08.pdf Training & Training Support]<br />
*[http://www.decisionlens.com/docs/WP_Strategic_Facilities_and_Infrastructure_Planning.pdf Facilities & Infrastructure]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-11.pdf Packaging, Handling, Storage, & Transportation]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-09.pdf Computer Resources]<br />
<br />
==Sustainment Implementation==<br />
Once the system becomes operational, the results of sustainment planning effort needs to implemented. Systems engineering supports the execution of the twelve integrated product support elements of a sustainment program that strives to ensure the system meets operational performance requirements in the most cost-effective manner over its total remaining life cycle.<br />
<br />
[[File:Sustainment_Implementation_Illustration_Logistics_Roedler.jpg|thumb|center|600px|Figure 2. Sustainment Implementation Illustration (DAU Guidebook 2012) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
Once a system is put into use, systems engineering is often required to correct problems that degrade continued use, and/or to add new capabilities to improve product performance in the current or a new environment. In the context of integrated product support, these systems engineering activities correspond to the IPS element “Sustaining Engineering.” Changes made to fielded systems to correct problems or increase performance should include any necessary adjustments to the IPS elements, and should consider the interrelationships and integration of the elements to maintain the effectiveness of system’s support strategy.<br />
<br />
The degree of change required to the product support elements varies with the severity of the problem. Minor problems may require a simple adjustment to a maintenance procedure, a change of supplier, a training course modification or a change to a technical manual. In contrast, problems that require system or component redesign may require engineering change proposals and approvals, IPS element trade studies, Business Case Analysis, and updates to the product support strategy. The focus is to correct problems that degrade continued use, regardless of the degree of severity.<br />
<br />
Evolutionary systems provide a strategy for acquisition of mature technology; the system delivers capabilities incrementally, planning for future capability enhancements. For these systems a System of Systems perspective is required to synchronize the Primary and Sustainment Systems.<br />
<br />
For more information refer to: An Enterprise Framework for Operationally Effective System of Systems Design.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
NATO RTO. 2001. ''Logistics Test and Evaluation in Flight Test''. Flight Test Techniques Series – Volume 20. Quebec, Canada: North Atlantic Treaty Organization (NATO) Research and Technology Organization (RTO). RTO-AG-300 Vol. 20, AC/323(SCI-010)TP/38. Table of contents available at: http://ftp.rta.nato.int/public//PubFullText/RTO/AG/RTO-AG-300-V20///AG-300-V20-$$TOC.pdf<br />
<br />
===Primary References===<br />
Blanchard, B.S. 1998. ''[[Logistics Engineering and Management]].'' Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
Blanchard, B. and Fabrycky, W. 2011. ''[[Systems Engineering and Analysis]],'' 5th Ed. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Bobinis, J. and Herald, T. 2012. “An Enterprise Framework for Operationally Effective System of Systems Design.” Journal of Enterprise Architecture May 2012, Volume 8, Number 2. Available at: https:// www.mendling.com/publications/JEA12-2.pdf.<br />
<br />
Daganzo, C. 2005. ''[[Logistics Systems Analysis]].'' 4th Edition. New York, NY, USA: Springer.<br />
<br />
Fabrycky, W.J. and B.S. Blanchard. 1991. ''[[Life-Cycle Cost and Economic Analysis]]''. Upper Saddle River, NJ, USA: Prentice-Hall.<br />
<br />
Ghiani, G., Laporte, G., and Musmanno, R. 2004. ''[[Introduction to Logistics Systems Planning and Control]].'' Hoboken, NJ, USA: Wiley-Interscience.<br />
<br />
Jones, J.V. 1995. ''[[Integrated Logistics Support Handbook]].'' New York, NY, USA: McGraw Hill.<br />
<br />
===Additional References===<br />
Barros, L.L. 1998. "The Optimization of Repair Decision Using Life-Cycle Cost Parameters." ''IMA Journal of Management Mathematics.'' 9(4): 403.<br />
<br />
Berkowitz, D., et al. 2005. ''Defining and Implementing Performance-Based Logistics in Government''. Washington, DC, USA: Defense Technical Information Center. Accessed 6 Sept 2011. Available at: http://handle.dtic.mil/100.2/ADP018510.<br />
<br />
Gajpal, P.P., L.S. Ganesh, and C. Rajendran. 1994. "Criticality Analysis of Spare Parts Using the Analytic Hierarchy Process." ''International Journal of Production Economics'' 35(1-3): 293-297. <br />
<br />
MITRE. 2011. "Integrated Logistics Support." ''Systems Engineering Guide.'' Accessed 11 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/acquisition_systems_engineering/integrated_logistics_support/]].<br />
<br />
Murthy, D.N.P. and W.R. Blischke. 2000. "Strategic Warranty Management: A Life-Cycle Approach." ''Engineering Management'' 47(1): 40-54.<br />
<br />
Northrop Grumman Corporation. 2000. ''Logistics Systems Engineering''. Accessed 6 Sept 2011. Available at: www.es.northropgrumman.com/solutions/navlogistics/.../nsd_logistics.pdf.<br />
<br />
Solomon, R., P.A. Sandborn, and M.G. Pecht. 2000. "Electronic Part Life Cycle Concepts and Obsolescence Forecasting." ''IEEE Transactions on Components and Packaging Technologies'' 23(4): 707-717. <br />
<br />
Spengler, T. and M. Schroter. 2003. "Strategic Management of Spare Parts in Closed-Loop Supply Chains: A System Dynamics Approach." ''Interfaces'' p. 7-17.<br />
<br />
----<br />
<center>[[System Maintenance|< Previous Article]] | [[System Deployment and Use|Parent Article]] | [[Systems Engineering Management|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Deployment and Use]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Logistics&diff=38018Logistics2012-08-06T18:08:58Z<p>Groedler: /* Sustainment Planning */</p>
<hr />
<div>There are several definitions for logistics within systems engineering and the definition used will determine what activities are considered part of logistics. The SEBoK defines [[logistics (glossary)]] as “the science of planning and implementing the acquisition and use of the resources necessary to sustain the operation of a system.”<br />
<br />
==Overview==<br />
The ability to “sustain the operation of a system” is determined by the inherent supportability of the system (a function of design) and the processes used to sustain the functions and capabilities of the system in the context of the end user. <br />
<br />
[[File:Affordable_Sys_Ops_Effect_DAU_GB_Roedler.jpg|thumb|600px|center|Figure 1. Affordable System Operational Effectiveness (DAU Guidebook 2012, pg. 385 ) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
==Sustainment Planning==<br />
The focus of [[sustainment (glossary)|sustainment]] planning is to influence the inherent supportability of the system and to plan the sustainment capabilities and processes that will be used to sustain system operations.<br />
Influence Inherent Supportability (Operational Suitability)<br />
<br />
Sustainment influence requires an understanding of the [[concept of operations (ConOps) (glossary)|concept of operations (ConOps), system missions, [[mission (glossary)|mission]] profiles, and [[system capability (glossary)|system capabilities]] to understand the [[rationale (glossary)|rationale]] behind functional and performance priorities. Understanding the rationale paves the way for decisions about necessary tradeoffs between system performance, availability, and [[Life Cycle Cost (LCC) (glossary)|Life Cycle Cost (LCC)]], with impact on the cost effectiveness of system operation, maintenance, and logistics support. There is no single list of sustainment considerations or specific way of grouping them as they are highly inter-related. They range from: compatibility, [[interoperability (glossary)|interoperability]]; transportability; [[reliability (glossary)|reliability]]; [[maintainability (glossary)|maintainability]]; [[manpower (glossary)|manpower]]; [[human factors (glossary)|human factors]]; [[safety (glossary)|safety]]; natural environment effects (including occupational health; habitability); diagnostics & prognostics (including real-time maintenance data collection); and corrosion protection & mitigation. The following are key design considerations:<br />
<br />
'''[[Architecture (glossary)|Architecture]] Considerations''': The focus on openness, modularity, scalability, and upgradeability is critical to implementing an incremental acquisition strategy. In addition, the architecture attributes that expand system [[flexibility (glossary)|flexibility]] and affordability can pay dividends later when obsolescence and end-of-life issues are resolved through a concerted technology refreshment strategy. However trade-offs are required relative to the extent each attribute is used.<br />
<br />
'''[[Reliability (glossary)|Reliability]] Considerations''': Reliability is critical because it contributes to a system's effectiveness as well as its suitability in terms of logistics burden and the cost to fix [[Failure (glossary)|failures]]. For each system, there is a level of basic reliability that must be achieved for the system to be considered useful. Reliability is also one of the most critical elements in determining the logistics infrastructure and footprint. Consequently, system reliability should be a primary focus during design (along with system technical performance, functions, and capabilities). The primary objective is to achieve the necessary probability of operational success and minimize the risk of failure within defined availability, cost, schedule, weight, power, and volume constraints. While performing such analyses, trade-offs should be conducted and dependencies should be explored with system maintainability and integrated with the supportability analysis that addresses support event frequency (i.e. Reliability), event duration and event cost. Such a focus will play a significant role in minimizing the necessary logistics footprint, while maximizing system availability.<br />
<br />
'''[[Maintainability (glossary)|Maintainability]] Considerations''': The design emphasis on maintainability is to reduce the maintenance burden and supply chain by reducing the time, personnel, tools, test equipment, training, facilities and cost to maintain the system. Maintainability engineering includes the activities, methods, and practices used to design minimal system maintenance requirements (designing out unnecessary and inefficient processes) and associated costs for preventive and corrective maintenance as well as servicing or calibration activities. Maintainability should be a designed-in capability and not an add-on option because good maintenance procedures cannot overcome poor system and equipment maintainability design. The primary objective is to reduce the time it takes for a properly trained maintainer to detect and isolate the failure (coverage and efficiency) and affect repair. Intrinsic factors contributing to maintainability are:<br />
<br />
*''[[Modularity (glossary)|Modularity]]'': Packaging of components such that they can be repaired via remove and replace action vs. on-board repair. Care should be taken not to "over modularize" and trade-offs to evaluate replacement, transportation, and repair costs should be accomplished to determine the most cost effective approach.<br />
*''Interoperability'': The compatibility of components with standard interface protocols to facilitate rapid repair and enhancement/upgrade through black box technology using common interfaces. Physical interfaces should be designed so that mating between components can only happen correctly.<br />
*''Physical accessibility'': The designed-in structural assurance that components requiring more frequent monitoring, checkout, and maintenance can be easily accessed. This is especially important in Low Observable platforms. Maintenance points should be directly visible and accessible to maintainers, including access for corrosion inspection and mitigation.<br />
*Designs that require ''minimum preventative maintenance'' including corrosion prevention and mitigation. Emphasis should be on balancing the maintenance requirement over the life cycle with minimal user workload.<br />
*''Embedded training and testing'' when it is determined to be the optimal solution from a [[Total Ownership Cost (glossary)|Total Ownership Cost (TOC)]] and Materiel Availability perspective.<br />
*''[[Human Systems Integration (HSI) (glossary)|Human Systems Integration (HSI)]]'' to optimize total system performance and minimize life-cycle costs by designing systems and incorporating technologies that require minimal manpower, provide effective training, can be operated and maintained by users, are suitable (habitable and safe with minimal environmental and occupational health hazards), and survivable (for both the user and the equipment).<br />
<br />
'''Support Considerations''': Support features cannot be easily "added-on" after the design is established. Consequently supportability should be a high priority early in the program's planning and integral to the system design and development process. Support features cut across reliability, maintainability, and the supply chain to facilitate detection, isolation, and timely repair/replacement of system anomalies. These include features for servicing and other activities necessary for operation and support including resources that contribute to the overall support of the system. Typical supportability features include diagnostics, prognostics (see CBM+ Guidebook), calibration requirements, many HSI issues (e.g. training, safety, HFE, occupational health, etc.), skill levels, documentation, maintenance data collection, compatibility, interoperability, transportability, handling (e.g., lift/hard/tie down points, etc.), packing requirements, facility requirements, accessibility, and other factors that contribute to an optimum environment for sustaining an operational system.<br />
<br />
==Plan Sustainment Processes==<br />
Process efficiency reflects how well the system can be produced, operated, serviced (including fueling) and maintained. It reflects the degree to which the logistics processes (including the supply chain), infrastructure, and footprint have been balanced to provide an agile, deployable, and operationally effective system. <br />
<br />
Achieving process efficiency requires early and continuing emphasis on the various logistics support processes along with the design considerations. The continued emphasis is important because processes present opportunities for improving operational effectiveness even after the "design-in" window has passed via lean-six sigma, supply chain optimization and other continuous process improvement (CPI) techniques. <br />
<br />
==Sustainment Analysis (Product Support Package)==<br />
<br />
The product support package documents the output of supportability analysis and includes details related to the following topics (links below are to excerpts from (NATO RTO 2001):<br />
<br />
*Product/IT System/Medical System Support Management (integrated life cycle sustainment planning)<br />
**Product/IT System/Medical System Support Strategies<br />
**Lifecycle sustainment planning<br />
**Requirements Management<br />
**[[Total Ownership Cost (glossary)|Total Ownership Costs (TOC)]] / [[Life Cycle Cost (LCC) (glossary)|Life Cycle Costs (LCC)]] planning & management<br />
**[[Integration (glossary)|Integration]] and management of product support activities<br />
**[[Configuration Management (glossary)|Configuration Management]]<br />
**Production & Distribution<br />
**Energy, Environmental, Safety and Health (EESH) management<br />
**Policies & Guidance<br />
**[[Risk Management (glossary)|Risk Management]]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-12.pdf Design Interface]<br />
**[[Reliability (glossary)|Reliability]]<br />
**[[Maintainability (glossary)|Maintainability]]<br />
**Supportability<br />
**Affordability<br />
**[[Configuration Management (glossary)|Configuration Management]]<br />
**Safety requirements<br />
**Environmental and HAZMAT requirements<br />
**[[Human Systems Integration (HSI) (glossary)|Human Systems Integration]]<br />
**Calibration<br />
**Anti-Tamper<br />
**Habitability<br />
**Disposal<br />
**Legal requirements<br />
*Sustaining Engineering<br />
**Failure Reporting, Analysis, and Corrective Action System (FRACAS)<br />
**Value Engineering<br />
**Diminishing Manufacturing Sources and Material Shortages<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-06.pdf Supply Support (materiel planning)]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-03.pdf Maintenance Planning]<br />
**Reliability Centered Maintenance (RCM)<br />
**Maintenance Concepts<br />
**Levels of Maintenance (Level of Repair Analysis)<br />
**Conditioned Based Maintenance<br />
**Prognostics & Health Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-05.pdf Support Equipment]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-07.pdf Technical Data]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-04.pdf Manpower & Personnel]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-08.pdf Training & Training Support]<br />
*[http://www.decisionlens.com/docs/WP_Strategic_Facilities_and_Infrastructure_Planning.pdf Facilities & Infrastructure]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-11.pdf Packaging, Handling, Storage, & Transportation]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-09.pdf Computer Resources]<br />
<br />
==Sustainment Implementation==<br />
Once the system becomes operational, the results of sustainment planning effort needs to implemented. Systems engineering supports the execution of the twelve integrated product support elements of a sustainment program that strives to ensure the system meets operational performance requirements in the most cost-effective manner over its total remaining life cycle.<br />
<br />
[[File:Sustainment_Implementation_Illustration_Logistics_Roedler.jpg|thumb|center|600px|Figure 2. Sustainment Implementation Illustration (DAU Guidebook 2012) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
Once a system is put into use, systems engineering is often required to correct problems that degrade continued use, and/or to add new capabilities to improve product performance in the current or a new environment. In the context of integrated product support, these systems engineering activities correspond to the IPS element “Sustaining Engineering.” Changes made to fielded systems to correct problems or increase performance should include any necessary adjustments to the IPS elements, and should consider the interrelationships and integration of the elements to maintain the effectiveness of system’s support strategy.<br />
<br />
The degree of change required to the product support elements varies with the severity of the problem. Minor problems may require a simple adjustment to a maintenance procedure, a change of supplier, a training course modification or a change to a technical manual. In contrast, problems that require system or component redesign may require engineering change proposals and approvals, IPS element trade studies, Business Case Analysis, and updates to the product support strategy. The focus is to correct problems that degrade continued use, regardless of the degree of severity.<br />
<br />
Evolutionary systems provide a strategy for acquisition of mature technology; the system delivers capabilities incrementally, planning for future capability enhancements. For these systems a System of Systems perspective is required to synchronize the Primary and Sustainment Systems.<br />
<br />
For more information refer to: An Enterprise Framework for Operationally Effective System of Systems Design.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
NATO RTO. 2001. ''Logistics Test and Evaluation in Flight Test''. Flight Test Techniques Series – Volume 20. Quebec, Canada: North Atlantic Treaty Organization (NATO) Research and Technology Organization (RTO). RTO-AG-300 Vol. 20, AC/323(SCI-010)TP/38. Table of contents available at: http://ftp.rta.nato.int/public//PubFullText/RTO/AG/RTO-AG-300-V20///AG-300-V20-$$TOC.pdf<br />
<br />
===Primary References===<br />
Blanchard, B.S. 1998. ''[[Logistics Engineering and Management]].'' Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
Blanchard, B. and Fabrycky, W. 2011. ''[[Systems Engineering and Analysis]],'' 5th Ed. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Bobinis, J. and Herald, T. 2012. “An Enterprise Framework for Operationally Effective System of Systems Design.” Journal of Enterprise Architecture May 2012, Volume 8, Number 2. Available at: https:// www.mendling.com/publications/JEA12-2.pdf.<br />
<br />
Daganzo, C. 2005. ''[[Logistics Systems Analysis]].'' 4th Edition. New York, NY, USA: Springer.<br />
<br />
Fabrycky, W.J. and B.S. Blanchard. 1991. ''[[Life-Cycle Cost and Economic Analysis]]''. Upper Saddle River, NJ, USA: Prentice-Hall.<br />
<br />
Ghiani, G., Laporte, G., and Musmanno, R. 2004. ''[[Introduction to Logistics Systems Planning and Control]].'' Hoboken, NJ, USA: Wiley-Interscience.<br />
<br />
Jones, J.V. 1995. ''[[Integrated Logistics Support Handbook]].'' New York, NY, USA: McGraw Hill.<br />
<br />
===Additional References===<br />
Barros, L.L. 1998. "The Optimization of Repair Decision Using Life-Cycle Cost Parameters." ''IMA Journal of Management Mathematics.'' 9(4): 403.<br />
<br />
Berkowitz, D., et al. 2005. ''Defining and Implementing Performance-Based Logistics in Government''. Washington, DC, USA: Defense Technical Information Center. Accessed 6 Sept 2011. Available at: http://handle.dtic.mil/100.2/ADP018510.<br />
<br />
Gajpal, P.P., L.S. Ganesh, and C. Rajendran. 1994. "Criticality Analysis of Spare Parts Using the Analytic Hierarchy Process." ''International Journal of Production Economics'' 35(1-3): 293-297. <br />
<br />
MITRE. 2011. "Integrated Logistics Support." ''Systems Engineering Guide.'' Accessed 11 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/acquisition_systems_engineering/integrated_logistics_support/]].<br />
<br />
Murthy, D.N.P. and W.R. Blischke. 2000. "Strategic Warranty Management: A Life-Cycle Approach." ''Engineering Management'' 47(1): 40-54.<br />
<br />
Northrop Grumman Corporation. 2000. ''Logistics Systems Engineering''. Accessed 6 Sept 2011. Available at: www.es.northropgrumman.com/solutions/navlogistics/.../nsd_logistics.pdf.<br />
<br />
Solomon, R., P.A. Sandborn, and M.G. Pecht. 2000. "Electronic Part Life Cycle Concepts and Obsolescence Forecasting." ''IEEE Transactions on Components and Packaging Technologies'' 23(4): 707-717. <br />
<br />
Spengler, T. and M. Schroter. 2003. "Strategic Management of Spare Parts in Closed-Loop Supply Chains: A System Dynamics Approach." ''Interfaces'' p. 7-17.<br />
<br />
----<br />
<center>[[System Maintenance|< Previous Article]] | [[System Deployment and Use|Parent Article]] | [[Systems Engineering Management|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Deployment and Use]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Logistics&diff=38017Logistics2012-08-06T17:58:38Z<p>Groedler: /* Sustainment Planning */</p>
<hr />
<div>There are several definitions for logistics within systems engineering and the definition used will determine what activities are considered part of logistics. The SEBoK defines [[logistics (glossary)]] as “the science of planning and implementing the acquisition and use of the resources necessary to sustain the operation of a system.”<br />
<br />
==Overview==<br />
The ability to “sustain the operation of a system” is determined by the inherent supportability of the system (a function of design) and the processes used to sustain the functions and capabilities of the system in the context of the end user. <br />
<br />
[[File:Affordable_Sys_Ops_Effect_DAU_GB_Roedler.jpg|thumb|600px|center|Figure 1. Affordable System Operational Effectiveness (DAU Guidebook 2012, pg. 385 ) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
==Sustainment Planning==<br />
The focus of [[sustainment (glossary)|sustainment]] planning is to influence the inherent supportability of the system and to plan the sustainment capabilities and processes that will be used to sustain system operations.<br />
Influence Inherent Supportability (Operational Suitability)<br />
<br />
Sustainment influence requires an understanding of the concept of operations, system missions, mission profiles, and system capabilities to understand the rationale behind functional and performance priorities. Understanding the rationale paves the way for decisions about necessary tradeoffs between system performance, availability, and [[Life Cycle Cost (LCC) (glossary)|Life Cycle Cost (LCC)]], with impact on the cost effectiveness of system operation, maintenance, and logistics support. There is no single list of sustainment considerations or specific way of grouping them as they are highly inter-related. They range from: compatibility, interoperability; transportability; reliability; maintainability; manpower; human factors; safety; natural environment effects (including occupational health; habitability); diagnostics & prognostics (including real-time maintenance data collection); and corrosion protection & mitigation. The following are key design considerations:<br />
<br />
'''[[Architecture (glossary)|Architecture]] Considerations''': The focus on openness, modularity, scalability, and upgradeability is critical to implementing an incremental acquisition strategy. In addition, the architecture attributes that expand system flexibility and affordability can pay dividends later when obsolescence and end-of-life issues are resolved through a concerted technology refreshment strategy. However trade-offs are required relative to the extent each attribute is used.<br />
<br />
'''[[Reliability (glossary)|Reliability]] Considerations''': Reliability is critical because it contributes to a system's effectiveness as well as its suitability in terms of logistics burden and the cost to fix [[Failure (glossary)|failures]]. For each system, there is a level of basic reliability that must be achieved for the system to be considered useful. Reliability is also one of the most critical elements in determining the logistics infrastructure and footprint. Consequently, system reliability should be a primary focus during design (along with system technical performance, functions, and capabilities). The primary objective is to achieve the necessary probability of operational success and minimize the risk of failure within defined availability, cost, schedule, weight, power, and volume constraints. While performing such analyses, trade-offs should be conducted and dependencies should be explored with system maintainability and integrated with the supportability analysis that addresses support event frequency (i.e. Reliability), event duration and event cost. Such a focus will play a significant role in minimizing the necessary logistics footprint, while maximizing system availability.<br />
<br />
'''[[Maintainability (glossary)|Maintainability]] Considerations''': The design emphasis on maintainability is to reduce the maintenance burden and supply chain by reducing the time, personnel, tools, test equipment, training, facilities and cost to maintain the system. Maintainability engineering includes the activities, methods, and practices used to design minimal system maintenance requirements (designing out unnecessary and inefficient processes) and associated costs for preventive and corrective maintenance as well as servicing or calibration activities. Maintainability should be a designed-in capability and not an add-on option because good maintenance procedures cannot overcome poor system and equipment maintainability design. The primary objective is to reduce the time it takes for a properly trained maintainer to detect and isolate the failure (coverage and efficiency) and affect repair. Intrinsic factors contributing to maintainability are:<br />
<br />
*''[[Modularity (glossary)|Modularity]]'': Packaging of components such that they can be repaired via remove and replace action vs. on-board repair. Care should be taken not to "over modularize" and trade-offs to evaluate replacement, transportation, and repair costs should be accomplished to determine the most cost effective approach.<br />
*''Interoperability'': The compatibility of components with standard interface protocols to facilitate rapid repair and enhancement/upgrade through black box technology using common interfaces. Physical interfaces should be designed so that mating between components can only happen correctly.<br />
*''Physical accessibility'': The designed-in structural assurance that components requiring more frequent monitoring, checkout, and maintenance can be easily accessed. This is especially important in Low Observable platforms. Maintenance points should be directly visible and accessible to maintainers, including access for corrosion inspection and mitigation.<br />
*Designs that require ''minimum preventative maintenance'' including corrosion prevention and mitigation. Emphasis should be on balancing the maintenance requirement over the life cycle with minimal user workload.<br />
*''Embedded training and testing'' when it is determined to be the optimal solution from a [[Total Ownership Cost (glossary)|Total Ownership Cost (TOC)]] and Materiel Availability perspective.<br />
*''[[Human Systems Integration (HSI) (glossary)|Human Systems Integration (HSI)]]'' to optimize total system performance and minimize life-cycle costs by designing systems and incorporating technologies that require minimal manpower, provide effective training, can be operated and maintained by users, are suitable (habitable and safe with minimal environmental and occupational health hazards), and survivable (for both the user and the equipment).<br />
<br />
'''Support Considerations''': Support features cannot be easily "added-on" after the design is established. Consequently supportability should be a high priority early in the program's planning and integral to the system design and development process. Support features cut across reliability, maintainability, and the supply chain to facilitate detection, isolation, and timely repair/replacement of system anomalies. These include features for servicing and other activities necessary for operation and support including resources that contribute to the overall support of the system. Typical supportability features include diagnostics, prognostics (see CBM+ Guidebook), calibration requirements, many HSI issues (e.g. training, safety, HFE, occupational health, etc.), skill levels, documentation, maintenance data collection, compatibility, interoperability, transportability, handling (e.g., lift/hard/tie down points, etc.), packing requirements, facility requirements, accessibility, and other factors that contribute to an optimum environment for sustaining an operational system.<br />
<br />
==Plan Sustainment Processes==<br />
Process efficiency reflects how well the system can be produced, operated, serviced (including fueling) and maintained. It reflects the degree to which the logistics processes (including the supply chain), infrastructure, and footprint have been balanced to provide an agile, deployable, and operationally effective system. <br />
<br />
Achieving process efficiency requires early and continuing emphasis on the various logistics support processes along with the design considerations. The continued emphasis is important because processes present opportunities for improving operational effectiveness even after the "design-in" window has passed via lean-six sigma, supply chain optimization and other continuous process improvement (CPI) techniques. <br />
<br />
==Sustainment Analysis (Product Support Package)==<br />
<br />
The product support package documents the output of supportability analysis and includes details related to the following topics (links below are to excerpts from (NATO RTO 2001):<br />
<br />
*Product/IT System/Medical System Support Management (integrated life cycle sustainment planning)<br />
**Product/IT System/Medical System Support Strategies<br />
**Lifecycle sustainment planning<br />
**Requirements Management<br />
**[[Total Ownership Cost (glossary)|Total Ownership Costs (TOC)]] / [[Life Cycle Cost (LCC) (glossary)|Life Cycle Costs (LCC)]] planning & management<br />
**[[Integration (glossary)|Integration]] and management of product support activities<br />
**[[Configuration Management (glossary)|Configuration Management]]<br />
**Production & Distribution<br />
**Energy, Environmental, Safety and Health (EESH) management<br />
**Policies & Guidance<br />
**[[Risk Management (glossary)|Risk Management]]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-12.pdf Design Interface]<br />
**[[Reliability (glossary)|Reliability]]<br />
**[[Maintainability (glossary)|Maintainability]]<br />
**Supportability<br />
**Affordability<br />
**[[Configuration Management (glossary)|Configuration Management]]<br />
**Safety requirements<br />
**Environmental and HAZMAT requirements<br />
**[[Human Systems Integration (HSI) (glossary)|Human Systems Integration]]<br />
**Calibration<br />
**Anti-Tamper<br />
**Habitability<br />
**Disposal<br />
**Legal requirements<br />
*Sustaining Engineering<br />
**Failure Reporting, Analysis, and Corrective Action System (FRACAS)<br />
**Value Engineering<br />
**Diminishing Manufacturing Sources and Material Shortages<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-06.pdf Supply Support (materiel planning)]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-03.pdf Maintenance Planning]<br />
**Reliability Centered Maintenance (RCM)<br />
**Maintenance Concepts<br />
**Levels of Maintenance (Level of Repair Analysis)<br />
**Conditioned Based Maintenance<br />
**Prognostics & Health Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-05.pdf Support Equipment]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-07.pdf Technical Data]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-04.pdf Manpower & Personnel]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-08.pdf Training & Training Support]<br />
*[http://www.decisionlens.com/docs/WP_Strategic_Facilities_and_Infrastructure_Planning.pdf Facilities & Infrastructure]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-11.pdf Packaging, Handling, Storage, & Transportation]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-09.pdf Computer Resources]<br />
<br />
==Sustainment Implementation==<br />
Once the system becomes operational, the results of sustainment planning effort needs to implemented. Systems engineering supports the execution of the twelve integrated product support elements of a sustainment program that strives to ensure the system meets operational performance requirements in the most cost-effective manner over its total remaining life cycle.<br />
<br />
[[File:Sustainment_Implementation_Illustration_Logistics_Roedler.jpg|thumb|center|600px|Figure 2. Sustainment Implementation Illustration (DAU Guidebook 2012) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
Once a system is put into use, systems engineering is often required to correct problems that degrade continued use, and/or to add new capabilities to improve product performance in the current or a new environment. In the context of integrated product support, these systems engineering activities correspond to the IPS element “Sustaining Engineering.” Changes made to fielded systems to correct problems or increase performance should include any necessary adjustments to the IPS elements, and should consider the interrelationships and integration of the elements to maintain the effectiveness of system’s support strategy.<br />
<br />
The degree of change required to the product support elements varies with the severity of the problem. Minor problems may require a simple adjustment to a maintenance procedure, a change of supplier, a training course modification or a change to a technical manual. In contrast, problems that require system or component redesign may require engineering change proposals and approvals, IPS element trade studies, Business Case Analysis, and updates to the product support strategy. The focus is to correct problems that degrade continued use, regardless of the degree of severity.<br />
<br />
Evolutionary systems provide a strategy for acquisition of mature technology; the system delivers capabilities incrementally, planning for future capability enhancements. For these systems a System of Systems perspective is required to synchronize the Primary and Sustainment Systems.<br />
<br />
For more information refer to: An Enterprise Framework for Operationally Effective System of Systems Design.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
NATO RTO. 2001. ''Logistics Test and Evaluation in Flight Test''. Flight Test Techniques Series – Volume 20. Quebec, Canada: North Atlantic Treaty Organization (NATO) Research and Technology Organization (RTO). RTO-AG-300 Vol. 20, AC/323(SCI-010)TP/38. Table of contents available at: http://ftp.rta.nato.int/public//PubFullText/RTO/AG/RTO-AG-300-V20///AG-300-V20-$$TOC.pdf<br />
<br />
===Primary References===<br />
Blanchard, B.S. 1998. ''[[Logistics Engineering and Management]].'' Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
Blanchard, B. and Fabrycky, W. 2011. ''[[Systems Engineering and Analysis]],'' 5th Ed. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Bobinis, J. and Herald, T. 2012. “An Enterprise Framework for Operationally Effective System of Systems Design.” Journal of Enterprise Architecture May 2012, Volume 8, Number 2. Available at: https:// www.mendling.com/publications/JEA12-2.pdf.<br />
<br />
Daganzo, C. 2005. ''[[Logistics Systems Analysis]].'' 4th Edition. New York, NY, USA: Springer.<br />
<br />
Fabrycky, W.J. and B.S. Blanchard. 1991. ''[[Life-Cycle Cost and Economic Analysis]]''. Upper Saddle River, NJ, USA: Prentice-Hall.<br />
<br />
Ghiani, G., Laporte, G., and Musmanno, R. 2004. ''[[Introduction to Logistics Systems Planning and Control]].'' Hoboken, NJ, USA: Wiley-Interscience.<br />
<br />
Jones, J.V. 1995. ''[[Integrated Logistics Support Handbook]].'' New York, NY, USA: McGraw Hill.<br />
<br />
===Additional References===<br />
Barros, L.L. 1998. "The Optimization of Repair Decision Using Life-Cycle Cost Parameters." ''IMA Journal of Management Mathematics.'' 9(4): 403.<br />
<br />
Berkowitz, D., et al. 2005. ''Defining and Implementing Performance-Based Logistics in Government''. Washington, DC, USA: Defense Technical Information Center. Accessed 6 Sept 2011. Available at: http://handle.dtic.mil/100.2/ADP018510.<br />
<br />
Gajpal, P.P., L.S. Ganesh, and C. Rajendran. 1994. "Criticality Analysis of Spare Parts Using the Analytic Hierarchy Process." ''International Journal of Production Economics'' 35(1-3): 293-297. <br />
<br />
MITRE. 2011. "Integrated Logistics Support." ''Systems Engineering Guide.'' Accessed 11 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/acquisition_systems_engineering/integrated_logistics_support/]].<br />
<br />
Murthy, D.N.P. and W.R. Blischke. 2000. "Strategic Warranty Management: A Life-Cycle Approach." ''Engineering Management'' 47(1): 40-54.<br />
<br />
Northrop Grumman Corporation. 2000. ''Logistics Systems Engineering''. Accessed 6 Sept 2011. Available at: www.es.northropgrumman.com/solutions/navlogistics/.../nsd_logistics.pdf.<br />
<br />
Solomon, R., P.A. Sandborn, and M.G. Pecht. 2000. "Electronic Part Life Cycle Concepts and Obsolescence Forecasting." ''IEEE Transactions on Components and Packaging Technologies'' 23(4): 707-717. <br />
<br />
Spengler, T. and M. Schroter. 2003. "Strategic Management of Spare Parts in Closed-Loop Supply Chains: A System Dynamics Approach." ''Interfaces'' p. 7-17.<br />
<br />
----<br />
<center>[[System Maintenance|< Previous Article]] | [[System Deployment and Use|Parent Article]] | [[Systems Engineering Management|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Deployment and Use]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Logistics&diff=38015Logistics2012-08-06T17:57:21Z<p>Groedler: /* Sustainment Planning */</p>
<hr />
<div>There are several definitions for logistics within systems engineering and the definition used will determine what activities are considered part of logistics. The SEBoK defines [[logistics (glossary)]] as “the science of planning and implementing the acquisition and use of the resources necessary to sustain the operation of a system.”<br />
<br />
==Overview==<br />
The ability to “sustain the operation of a system” is determined by the inherent supportability of the system (a function of design) and the processes used to sustain the functions and capabilities of the system in the context of the end user. <br />
<br />
[[File:Affordable_Sys_Ops_Effect_DAU_GB_Roedler.jpg|thumb|600px|center|Figure 1. Affordable System Operational Effectiveness (DAU Guidebook 2012, pg. 385 ) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
==Sustainment Planning==<br />
The focus of sustainment planning is to influence the inherent supportability of the system and to plan the sustainment capabilities and processes that will be used to sustain system operations.<br />
Influence Inherent Supportability (Operational Suitability)<br />
<br />
Sustainment influence requires an understanding of the concept of operations, system missions, mission profiles, and system capabilities to understand the rationale behind functional and performance priorities. Understanding the rationale paves the way for decisions about necessary tradeoffs between system performance, availability, and [[Life Cycle Cost (LCC) (glossary)|Life Cycle Cost (LCC)]], with impact on the cost effectiveness of system operation, maintenance, and logistics support. There is no single list of sustainment considerations or specific way of grouping them as they are highly inter-related. They range from: compatibility, interoperability; transportability; reliability; maintainability; manpower; human factors; safety; natural environment effects (including occupational health; habitability); diagnostics & prognostics (including real-time maintenance data collection); and corrosion protection & mitigation. The following are key design considerations:<br />
<br />
'''[[Architecture (glossary)|Architecture]] Considerations''': The focus on openness, modularity, scalability, and upgradeability is critical to implementing an incremental acquisition strategy. In addition, the architecture attributes that expand system flexibility and affordability can pay dividends later when obsolescence and end-of-life issues are resolved through a concerted technology refreshment strategy. However trade-offs are required relative to the extent each attribute is used.<br />
<br />
'''[[Reliability (glossary)|Reliability]] Considerations''': Reliability is critical because it contributes to a system's effectiveness as well as its suitability in terms of logistics burden and the cost to fix [[Failure (glossary)|failures]]. For each system, there is a level of basic reliability that must be achieved for the system to be considered useful. Reliability is also one of the most critical elements in determining the logistics infrastructure and footprint. Consequently, system reliability should be a primary focus during design (along with system technical performance, functions, and capabilities). The primary objective is to achieve the necessary probability of operational success and minimize the risk of failure within defined availability, cost, schedule, weight, power, and volume constraints. While performing such analyses, trade-offs should be conducted and dependencies should be explored with system maintainability and integrated with the supportability analysis that addresses support event frequency (i.e. Reliability), event duration and event cost. Such a focus will play a significant role in minimizing the necessary logistics footprint, while maximizing system availability.<br />
<br />
'''[[Maintainability (glossary)|Maintainability]] Considerations''': The design emphasis on maintainability is to reduce the maintenance burden and supply chain by reducing the time, personnel, tools, test equipment, training, facilities and cost to maintain the system. Maintainability engineering includes the activities, methods, and practices used to design minimal system maintenance requirements (designing out unnecessary and inefficient processes) and associated costs for preventive and corrective maintenance as well as servicing or calibration activities. Maintainability should be a designed-in capability and not an add-on option because good maintenance procedures cannot overcome poor system and equipment maintainability design. The primary objective is to reduce the time it takes for a properly trained maintainer to detect and isolate the failure (coverage and efficiency) and affect repair. Intrinsic factors contributing to maintainability are:<br />
<br />
*''[[Modularity (glossary)|Modularity]]'': Packaging of components such that they can be repaired via remove and replace action vs. on-board repair. Care should be taken not to "over modularize" and trade-offs to evaluate replacement, transportation, and repair costs should be accomplished to determine the most cost effective approach.<br />
*''Interoperability'': The compatibility of components with standard interface protocols to facilitate rapid repair and enhancement/upgrade through black box technology using common interfaces. Physical interfaces should be designed so that mating between components can only happen correctly.<br />
*''Physical accessibility'': The designed-in structural assurance that components requiring more frequent monitoring, checkout, and maintenance can be easily accessed. This is especially important in Low Observable platforms. Maintenance points should be directly visible and accessible to maintainers, including access for corrosion inspection and mitigation.<br />
*Designs that require ''minimum preventative maintenance'' including corrosion prevention and mitigation. Emphasis should be on balancing the maintenance requirement over the life cycle with minimal user workload.<br />
*''Embedded training and testing'' when it is determined to be the optimal solution from a [[Total Ownership Cost (glossary)|Total Ownership Cost (TOC)]] and Materiel Availability perspective.<br />
*''[[Human Systems Integration (HSI) (glossary)|Human Systems Integration (HSI)]]'' to optimize total system performance and minimize life-cycle costs by designing systems and incorporating technologies that require minimal manpower, provide effective training, can be operated and maintained by users, are suitable (habitable and safe with minimal environmental and occupational health hazards), and survivable (for both the user and the equipment).<br />
<br />
'''Support Considerations''': Support features cannot be easily "added-on" after the design is established. Consequently supportability should be a high priority early in the program's planning and integral to the system design and development process. Support features cut across reliability, maintainability, and the supply chain to facilitate detection, isolation, and timely repair/replacement of system anomalies. These include features for servicing and other activities necessary for operation and support including resources that contribute to the overall support of the system. Typical supportability features include diagnostics, prognostics (see CBM+ Guidebook), calibration requirements, many HSI issues (e.g. training, safety, HFE, occupational health, etc.), skill levels, documentation, maintenance data collection, compatibility, interoperability, transportability, handling (e.g., lift/hard/tie down points, etc.), packing requirements, facility requirements, accessibility, and other factors that contribute to an optimum environment for sustaining an operational system.<br />
<br />
==Plan Sustainment Processes==<br />
Process efficiency reflects how well the system can be produced, operated, serviced (including fueling) and maintained. It reflects the degree to which the logistics processes (including the supply chain), infrastructure, and footprint have been balanced to provide an agile, deployable, and operationally effective system. <br />
<br />
Achieving process efficiency requires early and continuing emphasis on the various logistics support processes along with the design considerations. The continued emphasis is important because processes present opportunities for improving operational effectiveness even after the "design-in" window has passed via lean-six sigma, supply chain optimization and other continuous process improvement (CPI) techniques. <br />
<br />
==Sustainment Analysis (Product Support Package)==<br />
<br />
The product support package documents the output of supportability analysis and includes details related to the following topics (links below are to excerpts from (NATO RTO 2001):<br />
<br />
*Product/IT System/Medical System Support Management (integrated life cycle sustainment planning)<br />
**Product/IT System/Medical System Support Strategies<br />
**Lifecycle sustainment planning<br />
**Requirements Management<br />
**[[Total Ownership Cost (glossary)|Total Ownership Costs (TOC)]] / [[Life Cycle Cost (LCC) (glossary)|Life Cycle Costs (LCC)]] planning & management<br />
**[[Integration (glossary)|Integration]] and management of product support activities<br />
**[[Configuration Management (glossary)|Configuration Management]]<br />
**Production & Distribution<br />
**Energy, Environmental, Safety and Health (EESH) management<br />
**Policies & Guidance<br />
**[[Risk Management (glossary)|Risk Management]]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-12.pdf Design Interface]<br />
**[[Reliability (glossary)|Reliability]]<br />
**[[Maintainability (glossary)|Maintainability]]<br />
**Supportability<br />
**Affordability<br />
**[[Configuration Management (glossary)|Configuration Management]]<br />
**Safety requirements<br />
**Environmental and HAZMAT requirements<br />
**[[Human Systems Integration (HSI) (glossary)|Human Systems Integration]]<br />
**Calibration<br />
**Anti-Tamper<br />
**Habitability<br />
**Disposal<br />
**Legal requirements<br />
*Sustaining Engineering<br />
**Failure Reporting, Analysis, and Corrective Action System (FRACAS)<br />
**Value Engineering<br />
**Diminishing Manufacturing Sources and Material Shortages<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-06.pdf Supply Support (materiel planning)]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-03.pdf Maintenance Planning]<br />
**Reliability Centered Maintenance (RCM)<br />
**Maintenance Concepts<br />
**Levels of Maintenance (Level of Repair Analysis)<br />
**Conditioned Based Maintenance<br />
**Prognostics & Health Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-05.pdf Support Equipment]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-07.pdf Technical Data]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-04.pdf Manpower & Personnel]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-08.pdf Training & Training Support]<br />
*[http://www.decisionlens.com/docs/WP_Strategic_Facilities_and_Infrastructure_Planning.pdf Facilities & Infrastructure]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-11.pdf Packaging, Handling, Storage, & Transportation]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-09.pdf Computer Resources]<br />
<br />
==Sustainment Implementation==<br />
Once the system becomes operational, the results of sustainment planning effort needs to implemented. Systems engineering supports the execution of the twelve integrated product support elements of a sustainment program that strives to ensure the system meets operational performance requirements in the most cost-effective manner over its total remaining life cycle.<br />
<br />
[[File:Sustainment_Implementation_Illustration_Logistics_Roedler.jpg|thumb|center|600px|Figure 2. Sustainment Implementation Illustration (DAU Guidebook 2012) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
Once a system is put into use, systems engineering is often required to correct problems that degrade continued use, and/or to add new capabilities to improve product performance in the current or a new environment. In the context of integrated product support, these systems engineering activities correspond to the IPS element “Sustaining Engineering.” Changes made to fielded systems to correct problems or increase performance should include any necessary adjustments to the IPS elements, and should consider the interrelationships and integration of the elements to maintain the effectiveness of system’s support strategy.<br />
<br />
The degree of change required to the product support elements varies with the severity of the problem. Minor problems may require a simple adjustment to a maintenance procedure, a change of supplier, a training course modification or a change to a technical manual. In contrast, problems that require system or component redesign may require engineering change proposals and approvals, IPS element trade studies, Business Case Analysis, and updates to the product support strategy. The focus is to correct problems that degrade continued use, regardless of the degree of severity.<br />
<br />
Evolutionary systems provide a strategy for acquisition of mature technology; the system delivers capabilities incrementally, planning for future capability enhancements. For these systems a System of Systems perspective is required to synchronize the Primary and Sustainment Systems.<br />
<br />
For more information refer to: An Enterprise Framework for Operationally Effective System of Systems Design.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
NATO RTO. 2001. ''Logistics Test and Evaluation in Flight Test''. Flight Test Techniques Series – Volume 20. Quebec, Canada: North Atlantic Treaty Organization (NATO) Research and Technology Organization (RTO). RTO-AG-300 Vol. 20, AC/323(SCI-010)TP/38. Table of contents available at: http://ftp.rta.nato.int/public//PubFullText/RTO/AG/RTO-AG-300-V20///AG-300-V20-$$TOC.pdf<br />
<br />
===Primary References===<br />
Blanchard, B.S. 1998. ''[[Logistics Engineering and Management]].'' Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
Blanchard, B. and Fabrycky, W. 2011. ''[[Systems Engineering and Analysis]],'' 5th Ed. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Bobinis, J. and Herald, T. 2012. “An Enterprise Framework for Operationally Effective System of Systems Design.” Journal of Enterprise Architecture May 2012, Volume 8, Number 2. Available at: https:// www.mendling.com/publications/JEA12-2.pdf.<br />
<br />
Daganzo, C. 2005. ''[[Logistics Systems Analysis]].'' 4th Edition. New York, NY, USA: Springer.<br />
<br />
Fabrycky, W.J. and B.S. Blanchard. 1991. ''[[Life-Cycle Cost and Economic Analysis]]''. Upper Saddle River, NJ, USA: Prentice-Hall.<br />
<br />
Ghiani, G., Laporte, G., and Musmanno, R. 2004. ''[[Introduction to Logistics Systems Planning and Control]].'' Hoboken, NJ, USA: Wiley-Interscience.<br />
<br />
Jones, J.V. 1995. ''[[Integrated Logistics Support Handbook]].'' New York, NY, USA: McGraw Hill.<br />
<br />
===Additional References===<br />
Barros, L.L. 1998. "The Optimization of Repair Decision Using Life-Cycle Cost Parameters." ''IMA Journal of Management Mathematics.'' 9(4): 403.<br />
<br />
Berkowitz, D., et al. 2005. ''Defining and Implementing Performance-Based Logistics in Government''. Washington, DC, USA: Defense Technical Information Center. Accessed 6 Sept 2011. Available at: http://handle.dtic.mil/100.2/ADP018510.<br />
<br />
Gajpal, P.P., L.S. Ganesh, and C. Rajendran. 1994. "Criticality Analysis of Spare Parts Using the Analytic Hierarchy Process." ''International Journal of Production Economics'' 35(1-3): 293-297. <br />
<br />
MITRE. 2011. "Integrated Logistics Support." ''Systems Engineering Guide.'' Accessed 11 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/acquisition_systems_engineering/integrated_logistics_support/]].<br />
<br />
Murthy, D.N.P. and W.R. Blischke. 2000. "Strategic Warranty Management: A Life-Cycle Approach." ''Engineering Management'' 47(1): 40-54.<br />
<br />
Northrop Grumman Corporation. 2000. ''Logistics Systems Engineering''. Accessed 6 Sept 2011. Available at: www.es.northropgrumman.com/solutions/navlogistics/.../nsd_logistics.pdf.<br />
<br />
Solomon, R., P.A. Sandborn, and M.G. Pecht. 2000. "Electronic Part Life Cycle Concepts and Obsolescence Forecasting." ''IEEE Transactions on Components and Packaging Technologies'' 23(4): 707-717. <br />
<br />
Spengler, T. and M. Schroter. 2003. "Strategic Management of Spare Parts in Closed-Loop Supply Chains: A System Dynamics Approach." ''Interfaces'' p. 7-17.<br />
<br />
----<br />
<center>[[System Maintenance|< Previous Article]] | [[System Deployment and Use|Parent Article]] | [[Systems Engineering Management|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Deployment and Use]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Logistics&diff=38011Logistics2012-08-06T17:51:32Z<p>Groedler: /* Sustainment Analysis (Product Support Package) */</p>
<hr />
<div>There are several definitions for logistics within systems engineering and the definition used will determine what activities are considered part of logistics. The SEBoK defines [[logistics (glossary)]] as “the science of planning and implementing the acquisition and use of the resources necessary to sustain the operation of a system.”<br />
<br />
==Overview==<br />
The ability to “sustain the operation of a system” is determined by the inherent supportability of the system (a function of design) and the processes used to sustain the functions and capabilities of the system in the context of the end user. <br />
<br />
[[File:Affordable_Sys_Ops_Effect_DAU_GB_Roedler.jpg|thumb|600px|center|Figure 1. Affordable System Operational Effectiveness (DAU Guidebook 2012, pg. 385 ) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
==Sustainment Planning==<br />
The focus of sustainment planning is to influence the inherent supportability of the system and to plan the sustainment capabilities and processes that will be used to sustain system operations.<br />
Influence Inherent Supportability (Operational Suitability)<br />
<br />
Sustainment influence requires an understanding of the concept of operations, system missions, mission profiles, and system capabilities to understand the rationale behind functional and performance priorities. Understanding the rationale paves the way for decisions about necessary tradeoffs between system performance, availability, and [[Life Cycle Cost (LCC) (glossary)|Life Cycle Cost (LCC)]], with impact on the cost effectiveness of system operation, maintenance, and logistics support. There is no single list of sustainment considerations or specific way of grouping them as they are highly inter-related. They range from: compatibility, interoperability; transportability; reliability; maintainability; manpower; human factors; safety; natural environment effects (including occupational health; habitability); diagnostics & prognostics (including real-time maintenance data collection); and corrosion protection & mitigation. The following are key design considerations:<br />
<br />
'''Architecture Considerations''': The focus on openness, modularity, scalability, and upgradeability is critical to implementing an incremental acquisition strategy. In addition, the architecture attributes that expand system flexibility and affordability can pay dividends later when obsolescence and end-of-life issues are resolved through a concerted technology refreshment strategy. However trade-offs are required relative to the extent each attribute is used.<br />
<br />
'''Reliability Considerations''': Reliability is critical because it contributes to a system's effectiveness as well as its suitability in terms of logistics burden and the cost to fix [[Failure (glossary)|failures]]. For each system, there is a level of basic reliability that must be achieved for the system to be considered useful. Reliability is also one of the most critical elements in determining the logistics infrastructure and footprint. Consequently, system reliability should be a primary focus during design (along with system technical performance, functions, and capabilities). The primary objective is to achieve the necessary probability of operational success and minimize the risk of failure within defined availability, cost, schedule, weight, power, and volume constraints. While performing such analyses, trade-offs should be conducted and dependencies should be explored with system maintainability and integrated with the supportability analysis that addresses support event frequency (i.e. Reliability), event duration and event cost. Such a focus will play a significant role in minimizing the necessary logistics footprint, while maximizing system availability.<br />
<br />
'''Maintainability Considerations''': The design emphasis on maintainability is to reduce the maintenance burden and supply chain by reducing the time, personnel, tools, test equipment, training, facilities and cost to maintain the system. Maintainability engineering includes the activities, methods, and practices used to design minimal system maintenance requirements (designing out unnecessary and inefficient processes) and associated costs for preventive and corrective maintenance as well as servicing or calibration activities. Maintainability should be a designed-in capability and not an add-on option because good maintenance procedures cannot overcome poor system and equipment maintainability design. The primary objective is to reduce the time it takes for a properly trained maintainer to detect and isolate the failure (coverage and efficiency) and affect repair. Intrinsic factors contributing to maintainability are:<br />
<br />
*''Modularity'': Packaging of components such that they can be repaired via remove and replace action vs. on-board repair. Care should be taken not to "over modularize" and trade-offs to evaluate replacement, transportation, and repair costs should be accomplished to determine the most cost effective approach.<br />
*''Interoperability'': The compatibility of components with standard interface protocols to facilitate rapid repair and enhancement/upgrade through black box technology using common interfaces. Physical interfaces should be designed so that mating between components can only happen correctly.<br />
*''Physical accessibility'': The designed-in structural assurance that components requiring more frequent monitoring, checkout, and maintenance can be easily accessed. This is especially important in Low Observable platforms. Maintenance points should be directly visible and accessible to maintainers, including access for corrosion inspection and mitigation.<br />
*Designs that require ''minimum preventative maintenance'' including corrosion prevention and mitigation. Emphasis should be on balancing the maintenance requirement over the life cycle with minimal user workload.<br />
*''Embedded training and testing'' when it is determined to be the optimal solution from a [[Total Ownership Cost (glossary)|Total Ownership Cost (TOC)]] and Materiel Availability perspective.<br />
*''[[Human Systems Integration (HSI) (glossary)|Human Systems Integration (HSI)]]'' to optimize total system performance and minimize life-cycle costs by designing systems and incorporating technologies that require minimal manpower, provide effective training, can be operated and maintained by users, are suitable (habitable and safe with minimal environmental and occupational health hazards), and survivable (for both the user and the equipment).<br />
<br />
'''Support Considerations''': Support features cannot be easily "added-on" after the design is established. Consequently supportability should be a high priority early in the program's planning and integral to the system design and development process. Support features cut across reliability, maintainability, and the supply chain to facilitate detection, isolation, and timely repair/replacement of system anomalies. These include features for servicing and other activities necessary for operation and support including resources that contribute to the overall support of the system. Typical supportability features include diagnostics, prognostics (see CBM+ Guidebook), calibration requirements, many HSI issues (e.g. training, safety, HFE, occupational health, etc.), skill levels, documentation, maintenance data collection, compatibility, interoperability, transportability, handling (e.g., lift/hard/tie down points, etc.), packing requirements, facility requirements, accessibility, and other factors that contribute to an optimum environment for sustaining an operational system.<br />
<br />
==Plan Sustainment Processes==<br />
Process efficiency reflects how well the system can be produced, operated, serviced (including fueling) and maintained. It reflects the degree to which the logistics processes (including the supply chain), infrastructure, and footprint have been balanced to provide an agile, deployable, and operationally effective system. <br />
<br />
Achieving process efficiency requires early and continuing emphasis on the various logistics support processes along with the design considerations. The continued emphasis is important because processes present opportunities for improving operational effectiveness even after the "design-in" window has passed via lean-six sigma, supply chain optimization and other continuous process improvement (CPI) techniques. <br />
<br />
==Sustainment Analysis (Product Support Package)==<br />
<br />
The product support package documents the output of supportability analysis and includes details related to the following topics (links below are to excerpts from (NATO RTO 2001):<br />
<br />
*Product/IT System/Medical System Support Management (integrated life cycle sustainment planning)<br />
**Product/IT System/Medical System Support Strategies<br />
**Lifecycle sustainment planning<br />
**Requirements Management<br />
**[[Total Ownership Cost (glossary)|Total Ownership Costs (TOC)]] / [[Life Cycle Cost (LCC) (glossary)|Life Cycle Costs (LCC)]] planning & management<br />
**[[Integration (glossary)|Integration]] and management of product support activities<br />
**[[Configuration Management (glossary)|Configuration Management]]<br />
**Production & Distribution<br />
**Energy, Environmental, Safety and Health (EESH) management<br />
**Policies & Guidance<br />
**[[Risk Management (glossary)|Risk Management]]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-12.pdf Design Interface]<br />
**[[Reliability (glossary)|Reliability]]<br />
**[[Maintainability (glossary)|Maintainability]]<br />
**Supportability<br />
**Affordability<br />
**[[Configuration Management (glossary)|Configuration Management]]<br />
**Safety requirements<br />
**Environmental and HAZMAT requirements<br />
**[[Human Systems Integration (HSI) (glossary)|Human Systems Integration]]<br />
**Calibration<br />
**Anti-Tamper<br />
**Habitability<br />
**Disposal<br />
**Legal requirements<br />
*Sustaining Engineering<br />
**Failure Reporting, Analysis, and Corrective Action System (FRACAS)<br />
**Value Engineering<br />
**Diminishing Manufacturing Sources and Material Shortages<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-06.pdf Supply Support (materiel planning)]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-03.pdf Maintenance Planning]<br />
**Reliability Centered Maintenance (RCM)<br />
**Maintenance Concepts<br />
**Levels of Maintenance (Level of Repair Analysis)<br />
**Conditioned Based Maintenance<br />
**Prognostics & Health Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-05.pdf Support Equipment]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-07.pdf Technical Data]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-04.pdf Manpower & Personnel]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-08.pdf Training & Training Support]<br />
*[http://www.decisionlens.com/docs/WP_Strategic_Facilities_and_Infrastructure_Planning.pdf Facilities & Infrastructure]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-11.pdf Packaging, Handling, Storage, & Transportation]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-09.pdf Computer Resources]<br />
<br />
==Sustainment Implementation==<br />
Once the system becomes operational, the results of sustainment planning effort needs to implemented. Systems engineering supports the execution of the twelve integrated product support elements of a sustainment program that strives to ensure the system meets operational performance requirements in the most cost-effective manner over its total remaining life cycle.<br />
<br />
[[File:Sustainment_Implementation_Illustration_Logistics_Roedler.jpg|thumb|center|600px|Figure 2. Sustainment Implementation Illustration (DAU Guidebook 2012) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
Once a system is put into use, systems engineering is often required to correct problems that degrade continued use, and/or to add new capabilities to improve product performance in the current or a new environment. In the context of integrated product support, these systems engineering activities correspond to the IPS element “Sustaining Engineering.” Changes made to fielded systems to correct problems or increase performance should include any necessary adjustments to the IPS elements, and should consider the interrelationships and integration of the elements to maintain the effectiveness of system’s support strategy.<br />
<br />
The degree of change required to the product support elements varies with the severity of the problem. Minor problems may require a simple adjustment to a maintenance procedure, a change of supplier, a training course modification or a change to a technical manual. In contrast, problems that require system or component redesign may require engineering change proposals and approvals, IPS element trade studies, Business Case Analysis, and updates to the product support strategy. The focus is to correct problems that degrade continued use, regardless of the degree of severity.<br />
<br />
Evolutionary systems provide a strategy for acquisition of mature technology; the system delivers capabilities incrementally, planning for future capability enhancements. For these systems a System of Systems perspective is required to synchronize the Primary and Sustainment Systems.<br />
<br />
For more information refer to: An Enterprise Framework for Operationally Effective System of Systems Design.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
NATO RTO. 2001. ''Logistics Test and Evaluation in Flight Test''. Flight Test Techniques Series – Volume 20. Quebec, Canada: North Atlantic Treaty Organization (NATO) Research and Technology Organization (RTO). RTO-AG-300 Vol. 20, AC/323(SCI-010)TP/38. Table of contents available at: http://ftp.rta.nato.int/public//PubFullText/RTO/AG/RTO-AG-300-V20///AG-300-V20-$$TOC.pdf<br />
<br />
===Primary References===<br />
Blanchard, B.S. 1998. ''[[Logistics Engineering and Management]].'' Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
Blanchard, B. and Fabrycky, W. 2011. ''[[Systems Engineering and Analysis]],'' 5th Ed. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Bobinis, J. and Herald, T. 2012. “An Enterprise Framework for Operationally Effective System of Systems Design.” Journal of Enterprise Architecture May 2012, Volume 8, Number 2. Available at: https:// www.mendling.com/publications/JEA12-2.pdf.<br />
<br />
Daganzo, C. 2005. ''[[Logistics Systems Analysis]].'' 4th Edition. New York, NY, USA: Springer.<br />
<br />
Fabrycky, W.J. and B.S. Blanchard. 1991. ''[[Life-Cycle Cost and Economic Analysis]]''. Upper Saddle River, NJ, USA: Prentice-Hall.<br />
<br />
Ghiani, G., Laporte, G., and Musmanno, R. 2004. ''[[Introduction to Logistics Systems Planning and Control]].'' Hoboken, NJ, USA: Wiley-Interscience.<br />
<br />
Jones, J.V. 1995. ''[[Integrated Logistics Support Handbook]].'' New York, NY, USA: McGraw Hill.<br />
<br />
===Additional References===<br />
Barros, L.L. 1998. "The Optimization of Repair Decision Using Life-Cycle Cost Parameters." ''IMA Journal of Management Mathematics.'' 9(4): 403.<br />
<br />
Berkowitz, D., et al. 2005. ''Defining and Implementing Performance-Based Logistics in Government''. Washington, DC, USA: Defense Technical Information Center. Accessed 6 Sept 2011. Available at: http://handle.dtic.mil/100.2/ADP018510.<br />
<br />
Gajpal, P.P., L.S. Ganesh, and C. Rajendran. 1994. "Criticality Analysis of Spare Parts Using the Analytic Hierarchy Process." ''International Journal of Production Economics'' 35(1-3): 293-297. <br />
<br />
MITRE. 2011. "Integrated Logistics Support." ''Systems Engineering Guide.'' Accessed 11 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/acquisition_systems_engineering/integrated_logistics_support/]].<br />
<br />
Murthy, D.N.P. and W.R. Blischke. 2000. "Strategic Warranty Management: A Life-Cycle Approach." ''Engineering Management'' 47(1): 40-54.<br />
<br />
Northrop Grumman Corporation. 2000. ''Logistics Systems Engineering''. Accessed 6 Sept 2011. Available at: www.es.northropgrumman.com/solutions/navlogistics/.../nsd_logistics.pdf.<br />
<br />
Solomon, R., P.A. Sandborn, and M.G. Pecht. 2000. "Electronic Part Life Cycle Concepts and Obsolescence Forecasting." ''IEEE Transactions on Components and Packaging Technologies'' 23(4): 707-717. <br />
<br />
Spengler, T. and M. Schroter. 2003. "Strategic Management of Spare Parts in Closed-Loop Supply Chains: A System Dynamics Approach." ''Interfaces'' p. 7-17.<br />
<br />
----<br />
<center>[[System Maintenance|< Previous Article]] | [[System Deployment and Use|Parent Article]] | [[Systems Engineering Management|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Deployment and Use]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Logistics&diff=37995Logistics2012-08-06T17:36:40Z<p>Groedler: /* Sustainment Planning */</p>
<hr />
<div>There are several definitions for logistics within systems engineering and the definition used will determine what activities are considered part of logistics. The SEBoK defines [[logistics (glossary)]] as “the science of planning and implementing the acquisition and use of the resources necessary to sustain the operation of a system.”<br />
<br />
==Overview==<br />
The ability to “sustain the operation of a system” is determined by the inherent supportability of the system (a function of design) and the processes used to sustain the functions and capabilities of the system in the context of the end user. <br />
<br />
[[File:Affordable_Sys_Ops_Effect_DAU_GB_Roedler.jpg|thumb|600px|center|Figure 1. Affordable System Operational Effectiveness (DAU Guidebook 2012, pg. 385 ) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
==Sustainment Planning==<br />
The focus of sustainment planning is to influence the inherent supportability of the system and to plan the sustainment capabilities and processes that will be used to sustain system operations.<br />
Influence Inherent Supportability (Operational Suitability)<br />
<br />
Sustainment influence requires an understanding of the concept of operations, system missions, mission profiles, and system capabilities to understand the rationale behind functional and performance priorities. Understanding the rationale paves the way for decisions about necessary tradeoffs between system performance, availability, and [[Life Cycle Cost (LCC) (glossary)|Life Cycle Cost (LCC)]], with impact on the cost effectiveness of system operation, maintenance, and logistics support. There is no single list of sustainment considerations or specific way of grouping them as they are highly inter-related. They range from: compatibility, interoperability; transportability; reliability; maintainability; manpower; human factors; safety; natural environment effects (including occupational health; habitability); diagnostics & prognostics (including real-time maintenance data collection); and corrosion protection & mitigation. The following are key design considerations:<br />
<br />
'''Architecture Considerations''': The focus on openness, modularity, scalability, and upgradeability is critical to implementing an incremental acquisition strategy. In addition, the architecture attributes that expand system flexibility and affordability can pay dividends later when obsolescence and end-of-life issues are resolved through a concerted technology refreshment strategy. However trade-offs are required relative to the extent each attribute is used.<br />
<br />
'''Reliability Considerations''': Reliability is critical because it contributes to a system's effectiveness as well as its suitability in terms of logistics burden and the cost to fix [[Failure (glossary)|failures]]. For each system, there is a level of basic reliability that must be achieved for the system to be considered useful. Reliability is also one of the most critical elements in determining the logistics infrastructure and footprint. Consequently, system reliability should be a primary focus during design (along with system technical performance, functions, and capabilities). The primary objective is to achieve the necessary probability of operational success and minimize the risk of failure within defined availability, cost, schedule, weight, power, and volume constraints. While performing such analyses, trade-offs should be conducted and dependencies should be explored with system maintainability and integrated with the supportability analysis that addresses support event frequency (i.e. Reliability), event duration and event cost. Such a focus will play a significant role in minimizing the necessary logistics footprint, while maximizing system availability.<br />
<br />
'''Maintainability Considerations''': The design emphasis on maintainability is to reduce the maintenance burden and supply chain by reducing the time, personnel, tools, test equipment, training, facilities and cost to maintain the system. Maintainability engineering includes the activities, methods, and practices used to design minimal system maintenance requirements (designing out unnecessary and inefficient processes) and associated costs for preventive and corrective maintenance as well as servicing or calibration activities. Maintainability should be a designed-in capability and not an add-on option because good maintenance procedures cannot overcome poor system and equipment maintainability design. The primary objective is to reduce the time it takes for a properly trained maintainer to detect and isolate the failure (coverage and efficiency) and affect repair. Intrinsic factors contributing to maintainability are:<br />
<br />
*''Modularity'': Packaging of components such that they can be repaired via remove and replace action vs. on-board repair. Care should be taken not to "over modularize" and trade-offs to evaluate replacement, transportation, and repair costs should be accomplished to determine the most cost effective approach.<br />
*''Interoperability'': The compatibility of components with standard interface protocols to facilitate rapid repair and enhancement/upgrade through black box technology using common interfaces. Physical interfaces should be designed so that mating between components can only happen correctly.<br />
*''Physical accessibility'': The designed-in structural assurance that components requiring more frequent monitoring, checkout, and maintenance can be easily accessed. This is especially important in Low Observable platforms. Maintenance points should be directly visible and accessible to maintainers, including access for corrosion inspection and mitigation.<br />
*Designs that require ''minimum preventative maintenance'' including corrosion prevention and mitigation. Emphasis should be on balancing the maintenance requirement over the life cycle with minimal user workload.<br />
*''Embedded training and testing'' when it is determined to be the optimal solution from a [[Total Ownership Cost (glossary)|Total Ownership Cost (TOC)]] and Materiel Availability perspective.<br />
*''[[Human Systems Integration (HSI) (glossary)|Human Systems Integration (HSI)]]'' to optimize total system performance and minimize life-cycle costs by designing systems and incorporating technologies that require minimal manpower, provide effective training, can be operated and maintained by users, are suitable (habitable and safe with minimal environmental and occupational health hazards), and survivable (for both the user and the equipment).<br />
<br />
'''Support Considerations''': Support features cannot be easily "added-on" after the design is established. Consequently supportability should be a high priority early in the program's planning and integral to the system design and development process. Support features cut across reliability, maintainability, and the supply chain to facilitate detection, isolation, and timely repair/replacement of system anomalies. These include features for servicing and other activities necessary for operation and support including resources that contribute to the overall support of the system. Typical supportability features include diagnostics, prognostics (see CBM+ Guidebook), calibration requirements, many HSI issues (e.g. training, safety, HFE, occupational health, etc.), skill levels, documentation, maintenance data collection, compatibility, interoperability, transportability, handling (e.g., lift/hard/tie down points, etc.), packing requirements, facility requirements, accessibility, and other factors that contribute to an optimum environment for sustaining an operational system.<br />
<br />
==Plan Sustainment Processes==<br />
Process efficiency reflects how well the system can be produced, operated, serviced (including fueling) and maintained. It reflects the degree to which the logistics processes (including the supply chain), infrastructure, and footprint have been balanced to provide an agile, deployable, and operationally effective system. <br />
<br />
Achieving process efficiency requires early and continuing emphasis on the various logistics support processes along with the design considerations. The continued emphasis is important because processes present opportunities for improving operational effectiveness even after the "design-in" window has passed via lean-six sigma, supply chain optimization and other continuous process improvement (CPI) techniques. <br />
<br />
==Sustainment Analysis (Product Support Package)==<br />
<br />
The product support package documents the output of supportability analysis and includes details related to the following topics (links below are to excerpts from (NATO RTO 2001):<br />
<br />
*Product/IT System/Medical System Support Management (integrated life cycle sustainment planning)<br />
**Product/IT System/Medical System Support Strategies<br />
**Lifecycle sustainment planning<br />
**Requirements Management<br />
**Total Ownership Costs (TOC) / Life Cycle Cost (LCC) planning & management<br />
**Integration and management of product support activities<br />
**Configuration Management<br />
**Production & Distribution<br />
**Energy, Environmental, Safety and Health (EESH) management<br />
**Policies & Guidance<br />
**Risk Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-12.pdf Design Interface]<br />
**Reliability<br />
**Maintainability<br />
**Supportability<br />
**Affordability<br />
**Configuration Management<br />
**Safety requirements<br />
**Environmental and HAZMAT requirements<br />
**Human Systems Integration<br />
**Calibration<br />
**Anti-Tamper<br />
**Habitability<br />
**Disposal<br />
**Legal requirements<br />
*Sustaining Engineering<br />
**Failure Reporting, Analysis, and Corrective Action System (FRACAS)<br />
**Value Engineering<br />
**Diminishing Manufacturing Sources and Material Shortages<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-06.pdf Supply Support (materiel planning)]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-03.pdf Maintenance Planning]<br />
**Reliability Centered Maintenance (RCM)<br />
**Maintenance Concepts<br />
**Levels of Maintenance (Level of Repair Analysis)<br />
**Conditioned Based Maintenance<br />
**Prognostics & Health Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-05.pdf Support Equipment]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-07.pdf Technical Data]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-04.pdf Manpower & Personnel]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-08.pdf Training & Training Support]<br />
*[http://www.decisionlens.com/docs/WP_Strategic_Facilities_and_Infrastructure_Planning.pdf Facilities & Infrastructure]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-11.pdf Packaging, Handling, Storage, & Transportation]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-09.pdf Computer Resources]<br />
<br />
==Sustainment Implementation==<br />
Once the system becomes operational, the results of sustainment planning effort needs to implemented. Systems engineering supports the execution of the twelve integrated product support elements of a sustainment program that strives to ensure the system meets operational performance requirements in the most cost-effective manner over its total remaining life cycle.<br />
<br />
[[File:Sustainment_Implementation_Illustration_Logistics_Roedler.jpg|thumb|center|600px|Figure 2. Sustainment Implementation Illustration (DAU Guidebook 2012) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
Once a system is put into use, systems engineering is often required to correct problems that degrade continued use, and/or to add new capabilities to improve product performance in the current or a new environment. In the context of integrated product support, these systems engineering activities correspond to the IPS element “Sustaining Engineering.” Changes made to fielded systems to correct problems or increase performance should include any necessary adjustments to the IPS elements, and should consider the interrelationships and integration of the elements to maintain the effectiveness of system’s support strategy.<br />
<br />
The degree of change required to the product support elements varies with the severity of the problem. Minor problems may require a simple adjustment to a maintenance procedure, a change of supplier, a training course modification or a change to a technical manual. In contrast, problems that require system or component redesign may require engineering change proposals and approvals, IPS element trade studies, Business Case Analysis, and updates to the product support strategy. The focus is to correct problems that degrade continued use, regardless of the degree of severity.<br />
<br />
Evolutionary systems provide a strategy for acquisition of mature technology; the system delivers capabilities incrementally, planning for future capability enhancements. For these systems a System of Systems perspective is required to synchronize the Primary and Sustainment Systems.<br />
<br />
For more information refer to: An Enterprise Framework for Operationally Effective System of Systems Design.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
NATO RTO. 2001. ''Logistics Test and Evaluation in Flight Test''. Flight Test Techniques Series – Volume 20. Quebec, Canada: North Atlantic Treaty Organization (NATO) Research and Technology Organization (RTO). RTO-AG-300 Vol. 20, AC/323(SCI-010)TP/38. Table of contents available at: http://ftp.rta.nato.int/public//PubFullText/RTO/AG/RTO-AG-300-V20///AG-300-V20-$$TOC.pdf<br />
<br />
===Primary References===<br />
Blanchard, B.S. 1998. ''[[Logistics Engineering and Management]].'' Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
Blanchard, B. and Fabrycky, W. 2011. ''[[Systems Engineering and Analysis]],'' 5th Ed. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Bobinis, J. and Herald, T. 2012. “An Enterprise Framework for Operationally Effective System of Systems Design.” Journal of Enterprise Architecture May 2012, Volume 8, Number 2. Available at: https:// www.mendling.com/publications/JEA12-2.pdf.<br />
<br />
Daganzo, C. 2005. ''[[Logistics Systems Analysis]].'' 4th Edition. New York, NY, USA: Springer.<br />
<br />
Fabrycky, W.J. and B.S. Blanchard. 1991. ''[[Life-Cycle Cost and Economic Analysis]]''. Upper Saddle River, NJ, USA: Prentice-Hall.<br />
<br />
Ghiani, G., Laporte, G., and Musmanno, R. 2004. ''[[Introduction to Logistics Systems Planning and Control]].'' Hoboken, NJ, USA: Wiley-Interscience.<br />
<br />
Jones, J.V. 1995. ''[[Integrated Logistics Support Handbook]].'' New York, NY, USA: McGraw Hill.<br />
<br />
===Additional References===<br />
Barros, L.L. 1998. "The Optimization of Repair Decision Using Life-Cycle Cost Parameters." ''IMA Journal of Management Mathematics.'' 9(4): 403.<br />
<br />
Berkowitz, D., et al. 2005. ''Defining and Implementing Performance-Based Logistics in Government''. Washington, DC, USA: Defense Technical Information Center. Accessed 6 Sept 2011. Available at: http://handle.dtic.mil/100.2/ADP018510.<br />
<br />
Gajpal, P.P., L.S. Ganesh, and C. Rajendran. 1994. "Criticality Analysis of Spare Parts Using the Analytic Hierarchy Process." ''International Journal of Production Economics'' 35(1-3): 293-297. <br />
<br />
MITRE. 2011. "Integrated Logistics Support." ''Systems Engineering Guide.'' Accessed 11 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/acquisition_systems_engineering/integrated_logistics_support/]].<br />
<br />
Murthy, D.N.P. and W.R. Blischke. 2000. "Strategic Warranty Management: A Life-Cycle Approach." ''Engineering Management'' 47(1): 40-54.<br />
<br />
Northrop Grumman Corporation. 2000. ''Logistics Systems Engineering''. Accessed 6 Sept 2011. Available at: www.es.northropgrumman.com/solutions/navlogistics/.../nsd_logistics.pdf.<br />
<br />
Solomon, R., P.A. Sandborn, and M.G. Pecht. 2000. "Electronic Part Life Cycle Concepts and Obsolescence Forecasting." ''IEEE Transactions on Components and Packaging Technologies'' 23(4): 707-717. <br />
<br />
Spengler, T. and M. Schroter. 2003. "Strategic Management of Spare Parts in Closed-Loop Supply Chains: A System Dynamics Approach." ''Interfaces'' p. 7-17.<br />
<br />
----<br />
<center>[[System Maintenance|< Previous Article]] | [[System Deployment and Use|Parent Article]] | [[Systems Engineering Management|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Deployment and Use]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Logistics&diff=37984Logistics2012-08-06T17:33:38Z<p>Groedler: /* Sustainment Planning */</p>
<hr />
<div>There are several definitions for logistics within systems engineering and the definition used will determine what activities are considered part of logistics. The SEBoK defines [[logistics (glossary)]] as “the science of planning and implementing the acquisition and use of the resources necessary to sustain the operation of a system.”<br />
<br />
==Overview==<br />
The ability to “sustain the operation of a system” is determined by the inherent supportability of the system (a function of design) and the processes used to sustain the functions and capabilities of the system in the context of the end user. <br />
<br />
[[File:Affordable_Sys_Ops_Effect_DAU_GB_Roedler.jpg|thumb|600px|center|Figure 1. Affordable System Operational Effectiveness (DAU Guidebook 2012, pg. 385 ) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
==Sustainment Planning==<br />
The focus of sustainment planning is to influence the inherent supportability of the system and to plan the sustainment capabilities and processes that will be used to sustain system operations.<br />
Influence Inherent Supportability (Operational Suitability)<br />
<br />
Sustainment influence requires an understanding of the concept of operations, system missions, mission profiles, and system capabilities to understand the rationale behind functional and performance priorities. Understanding the rationale paves the way for decisions about necessary tradeoffs between system performance, availability, and [[Life Cycle Cost (LCC) (glossary)|Life Cycle Cost (LCC)]], with impact on the cost effectiveness of system operation, maintenance, and logistics support. There is no single list of sustainment considerations or specific way of grouping them as they are highly inter-related. They range from: compatibility, interoperability; transportability; reliability; maintainability; manpower; human factors; safety; natural environment effects (including occupational health; habitability); diagnostics & prognostics (including real-time maintenance data collection); and corrosion protection & mitigation. The following are key design considerations:<br />
<br />
'''Architecture Considerations''': The focus on openness, modularity, scalability, and upgradeability is critical to implementing an incremental acquisition strategy. In addition, the architecture attributes that expand system flexibility and affordability can pay dividends later when obsolescence and end-of-life issues are resolved through a concerted technology refreshment strategy. However trade-offs are required relative to the extent each attribute is used.<br />
<br />
'''Reliability Considerations''': Reliability is critical because it contributes to a system's effectiveness as well as its suitability in terms of logistics burden and the cost to fix [[Failure (glossary)|failures]]. For each system, there is a level of basic reliability that must be achieved for the system to be considered useful. Reliability is also one of the most critical elements in determining the logistics infrastructure and footprint. Consequently, system reliability should be a primary focus during design (along with system technical performance, functions, and capabilities). The primary objective is to achieve the necessary probability of operational success and minimize the risk of failure within defined availability, cost, schedule, weight, power, and volume constraints. While performing such analyses, trade-offs should be conducted and dependencies should be explored with system maintainability and integrated with the supportability analysis that addresses support event frequency (i.e. Reliability), event duration and event cost. Such a focus will play a significant role in minimizing the necessary logistics footprint, while maximizing system availability.<br />
<br />
'''Maintainability Considerations''': The design emphasis on maintainability is to reduce the maintenance burden and supply chain by reducing the time, personnel, tools, test equipment, training, facilities and cost to maintain the system. Maintainability engineering includes the activities, methods, and practices used to design minimal system maintenance requirements (designing out unnecessary and inefficient processes) and associated costs for preventive and corrective maintenance as well as servicing or calibration activities. Maintainability should be a designed-in capability and not an add-on option because good maintenance procedures cannot overcome poor system and equipment maintainability design. The primary objective is to reduce the time it takes for a properly trained maintainer to detect and isolate the failure (coverage and efficiency) and affect repair. Intrinsic factors contributing to maintainability are:<br />
<br />
*''Modularity'': Packaging of components such that they can be repaired via remove and replace action vs. on-board repair. Care should be taken not to "over modularize" and trade-offs to evaluate replacement, transportation, and repair costs should be accomplished to determine the most cost effective approach.<br />
*''Interoperability'': The compatibility of components with standard interface protocols to facilitate rapid repair and enhancement/upgrade through black box technology using common interfaces. Physical interfaces should be designed so that mating between components can only happen correctly.<br />
*''Physical accessibility'': The designed-in structural assurance that components requiring more frequent monitoring, checkout, and maintenance can be easily accessed. This is especially important in Low Observable platforms. Maintenance points should be directly visible and accessible to maintainers, including access for corrosion inspection and mitigation.<br />
*Designs that require ''minimum preventative maintenance'' including corrosion prevention and mitigation. Emphasis should be on balancing the maintenance requirement over the life cycle with minimal user workload.<br />
*''Embedded training and testing'' when it is determined to be the optimal solution from a [[Total Ownership Cost (glossary)|Total Ownership Cost (TOC)]] and Materiel Availability perspective.<br />
*''[[Human Systems Integration (HSI)(glossary)|Human Systems Integration (HSI)]]'' to optimize total system performance and minimize life-cycle costs by designing systems and incorporating technologies that require minimal manpower, provide effective training, can be operated and maintained by users, are suitable (habitable and safe with minimal environmental and occupational health hazards), and survivable (for both the user and the equipment).<br />
<br />
'''Support Considerations''': Support features cannot be easily "added-on" after the design is established. Consequently supportability should be a high priority early in the program's planning and integral to the system design and development process. Support features cut across reliability, maintainability, and the supply chain to facilitate detection, isolation, and timely repair/replacement of system anomalies. These include features for servicing and other activities necessary for operation and support including resources that contribute to the overall support of the system. Typical supportability features include diagnostics, prognostics (see CBM+ Guidebook), calibration requirements, many HSI issues (e.g. training, safety, HFE, occupational health, etc.), skill levels, documentation, maintenance data collection, compatibility, interoperability, transportability, handling (e.g., lift/hard/tie down points, etc.), packing requirements, facility requirements, accessibility, and other factors that contribute to an optimum environment for sustaining an operational system.<br />
<br />
==Plan Sustainment Processes==<br />
Process efficiency reflects how well the system can be produced, operated, serviced (including fueling) and maintained. It reflects the degree to which the logistics processes (including the supply chain), infrastructure, and footprint have been balanced to provide an agile, deployable, and operationally effective system. <br />
<br />
Achieving process efficiency requires early and continuing emphasis on the various logistics support processes along with the design considerations. The continued emphasis is important because processes present opportunities for improving operational effectiveness even after the "design-in" window has passed via lean-six sigma, supply chain optimization and other continuous process improvement (CPI) techniques. <br />
<br />
==Sustainment Analysis (Product Support Package)==<br />
<br />
The product support package documents the output of supportability analysis and includes details related to the following topics (links below are to excerpts from (NATO RTO 2001):<br />
<br />
*Product/IT System/Medical System Support Management (integrated life cycle sustainment planning)<br />
**Product/IT System/Medical System Support Strategies<br />
**Lifecycle sustainment planning<br />
**Requirements Management<br />
**Total Ownership Costs (TOC) / Life Cycle Cost (LCC) planning & management<br />
**Integration and management of product support activities<br />
**Configuration Management<br />
**Production & Distribution<br />
**Energy, Environmental, Safety and Health (EESH) management<br />
**Policies & Guidance<br />
**Risk Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-12.pdf Design Interface]<br />
**Reliability<br />
**Maintainability<br />
**Supportability<br />
**Affordability<br />
**Configuration Management<br />
**Safety requirements<br />
**Environmental and HAZMAT requirements<br />
**Human Systems Integration<br />
**Calibration<br />
**Anti-Tamper<br />
**Habitability<br />
**Disposal<br />
**Legal requirements<br />
*Sustaining Engineering<br />
**Failure Reporting, Analysis, and Corrective Action System (FRACAS)<br />
**Value Engineering<br />
**Diminishing Manufacturing Sources and Material Shortages<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-06.pdf Supply Support (materiel planning)]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-03.pdf Maintenance Planning]<br />
**Reliability Centered Maintenance (RCM)<br />
**Maintenance Concepts<br />
**Levels of Maintenance (Level of Repair Analysis)<br />
**Conditioned Based Maintenance<br />
**Prognostics & Health Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-05.pdf Support Equipment]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-07.pdf Technical Data]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-04.pdf Manpower & Personnel]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-08.pdf Training & Training Support]<br />
*[http://www.decisionlens.com/docs/WP_Strategic_Facilities_and_Infrastructure_Planning.pdf Facilities & Infrastructure]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-11.pdf Packaging, Handling, Storage, & Transportation]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-09.pdf Computer Resources]<br />
<br />
==Sustainment Implementation==<br />
Once the system becomes operational, the results of sustainment planning effort needs to implemented. Systems engineering supports the execution of the twelve integrated product support elements of a sustainment program that strives to ensure the system meets operational performance requirements in the most cost-effective manner over its total remaining life cycle.<br />
<br />
[[File:Sustainment_Implementation_Illustration_Logistics_Roedler.jpg|thumb|center|600px|Figure 2. Sustainment Implementation Illustration (DAU Guidebook 2012) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
Once a system is put into use, systems engineering is often required to correct problems that degrade continued use, and/or to add new capabilities to improve product performance in the current or a new environment. In the context of integrated product support, these systems engineering activities correspond to the IPS element “Sustaining Engineering.” Changes made to fielded systems to correct problems or increase performance should include any necessary adjustments to the IPS elements, and should consider the interrelationships and integration of the elements to maintain the effectiveness of system’s support strategy.<br />
<br />
The degree of change required to the product support elements varies with the severity of the problem. Minor problems may require a simple adjustment to a maintenance procedure, a change of supplier, a training course modification or a change to a technical manual. In contrast, problems that require system or component redesign may require engineering change proposals and approvals, IPS element trade studies, Business Case Analysis, and updates to the product support strategy. The focus is to correct problems that degrade continued use, regardless of the degree of severity.<br />
<br />
Evolutionary systems provide a strategy for acquisition of mature technology; the system delivers capabilities incrementally, planning for future capability enhancements. For these systems a System of Systems perspective is required to synchronize the Primary and Sustainment Systems.<br />
<br />
For more information refer to: An Enterprise Framework for Operationally Effective System of Systems Design.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
NATO RTO. 2001. ''Logistics Test and Evaluation in Flight Test''. Flight Test Techniques Series – Volume 20. Quebec, Canada: North Atlantic Treaty Organization (NATO) Research and Technology Organization (RTO). RTO-AG-300 Vol. 20, AC/323(SCI-010)TP/38. Table of contents available at: http://ftp.rta.nato.int/public//PubFullText/RTO/AG/RTO-AG-300-V20///AG-300-V20-$$TOC.pdf<br />
<br />
===Primary References===<br />
Blanchard, B.S. 1998. ''[[Logistics Engineering and Management]].'' Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
Blanchard, B. and Fabrycky, W. 2011. ''[[Systems Engineering and Analysis]],'' 5th Ed. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Bobinis, J. and Herald, T. 2012. “An Enterprise Framework for Operationally Effective System of Systems Design.” Journal of Enterprise Architecture May 2012, Volume 8, Number 2. Available at: https:// www.mendling.com/publications/JEA12-2.pdf.<br />
<br />
Daganzo, C. 2005. ''[[Logistics Systems Analysis]].'' 4th Edition. New York, NY, USA: Springer.<br />
<br />
Fabrycky, W.J. and B.S. Blanchard. 1991. ''[[Life-Cycle Cost and Economic Analysis]]''. Upper Saddle River, NJ, USA: Prentice-Hall.<br />
<br />
Ghiani, G., Laporte, G., and Musmanno, R. 2004. ''[[Introduction to Logistics Systems Planning and Control]].'' Hoboken, NJ, USA: Wiley-Interscience.<br />
<br />
Jones, J.V. 1995. ''[[Integrated Logistics Support Handbook]].'' New York, NY, USA: McGraw Hill.<br />
<br />
===Additional References===<br />
Barros, L.L. 1998. "The Optimization of Repair Decision Using Life-Cycle Cost Parameters." ''IMA Journal of Management Mathematics.'' 9(4): 403.<br />
<br />
Berkowitz, D., et al. 2005. ''Defining and Implementing Performance-Based Logistics in Government''. Washington, DC, USA: Defense Technical Information Center. Accessed 6 Sept 2011. Available at: http://handle.dtic.mil/100.2/ADP018510.<br />
<br />
Gajpal, P.P., L.S. Ganesh, and C. Rajendran. 1994. "Criticality Analysis of Spare Parts Using the Analytic Hierarchy Process." ''International Journal of Production Economics'' 35(1-3): 293-297. <br />
<br />
MITRE. 2011. "Integrated Logistics Support." ''Systems Engineering Guide.'' Accessed 11 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/acquisition_systems_engineering/integrated_logistics_support/]].<br />
<br />
Murthy, D.N.P. and W.R. Blischke. 2000. "Strategic Warranty Management: A Life-Cycle Approach." ''Engineering Management'' 47(1): 40-54.<br />
<br />
Northrop Grumman Corporation. 2000. ''Logistics Systems Engineering''. Accessed 6 Sept 2011. Available at: www.es.northropgrumman.com/solutions/navlogistics/.../nsd_logistics.pdf.<br />
<br />
Solomon, R., P.A. Sandborn, and M.G. Pecht. 2000. "Electronic Part Life Cycle Concepts and Obsolescence Forecasting." ''IEEE Transactions on Components and Packaging Technologies'' 23(4): 707-717. <br />
<br />
Spengler, T. and M. Schroter. 2003. "Strategic Management of Spare Parts in Closed-Loop Supply Chains: A System Dynamics Approach." ''Interfaces'' p. 7-17.<br />
<br />
----<br />
<center>[[System Maintenance|< Previous Article]] | [[System Deployment and Use|Parent Article]] | [[Systems Engineering Management|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Deployment and Use]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Logistics&diff=37982Logistics2012-08-06T17:31:10Z<p>Groedler: /* Sustainment Planning */</p>
<hr />
<div>There are several definitions for logistics within systems engineering and the definition used will determine what activities are considered part of logistics. The SEBoK defines [[logistics (glossary)]] as “the science of planning and implementing the acquisition and use of the resources necessary to sustain the operation of a system.”<br />
<br />
==Overview==<br />
The ability to “sustain the operation of a system” is determined by the inherent supportability of the system (a function of design) and the processes used to sustain the functions and capabilities of the system in the context of the end user. <br />
<br />
[[File:Affordable_Sys_Ops_Effect_DAU_GB_Roedler.jpg|thumb|600px|center|Figure 1. Affordable System Operational Effectiveness (DAU Guidebook 2012, pg. 385 ) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
==Sustainment Planning==<br />
The focus of sustainment planning is to influence the inherent supportability of the system and to plan the sustainment capabilities and processes that will be used to sustain system operations.<br />
Influence Inherent Supportability (Operational Suitability)<br />
<br />
Sustainment influence requires an understanding of the concept of operations, system missions, mission profiles, and system capabilities to understand the rationale behind functional and performance priorities. Understanding the rationale paves the way for decisions about necessary tradeoffs between system performance, availability, and [[Life Cycle Cost (LCC) (glossary)|Life Cycle Cost (LCC)]], with impact on the cost effectiveness of system operation, maintenance, and logistics support. There is no single list of sustainment considerations or specific way of grouping them as they are highly inter-related. They range from: compatibility, interoperability; transportability; reliability; maintainability; manpower; human factors; safety; natural environment effects (including occupational health; habitability); diagnostics & prognostics (including real-time maintenance data collection); and corrosion protection & mitigation. The following are key design considerations:<br />
<br />
'''Architecture Considerations''': The focus on openness, modularity, scalability, and upgradeability is critical to implementing an incremental acquisition strategy. In addition, the architecture attributes that expand system flexibility and affordability can pay dividends later when obsolescence and end-of-life issues are resolved through a concerted technology refreshment strategy. However trade-offs are required relative to the extent each attribute is used.<br />
<br />
'''Reliability Considerations''': Reliability is critical because it contributes to a system's effectiveness as well as its suitability in terms of logistics burden and the cost to fix [[Failure (glossary)|failures]]. For each system, there is a level of basic reliability that must be achieved for the system to be considered useful. Reliability is also one of the most critical elements in determining the logistics infrastructure and footprint. Consequently, system reliability should be a primary focus during design (along with system technical performance, functions, and capabilities). The primary objective is to achieve the necessary probability of operational success and minimize the risk of failure within defined availability, cost, schedule, weight, power, and volume constraints. While performing such analyses, trade-offs should be conducted and dependencies should be explored with system maintainability and integrated with the supportability analysis that addresses support event frequency (i.e. Reliability), event duration and event cost. Such a focus will play a significant role in minimizing the necessary logistics footprint, while maximizing system availability.<br />
<br />
'''Maintainability Considerations''': The design emphasis on maintainability is to reduce the maintenance burden and supply chain by reducing the time, personnel, tools, test equipment, training, facilities and cost to maintain the system. Maintainability engineering includes the activities, methods, and practices used to design minimal system maintenance requirements (designing out unnecessary and inefficient processes) and associated costs for preventive and corrective maintenance as well as servicing or calibration activities. Maintainability should be a designed-in capability and not an add-on option because good maintenance procedures cannot overcome poor system and equipment maintainability design. The primary objective is to reduce the time it takes for a properly trained maintainer to detect and isolate the failure (coverage and efficiency) and affect repair. Intrinsic factors contributing to maintainability are:<br />
<br />
*''Modularity'': Packaging of components such that they can be repaired via remove and replace action vs. on-board repair. Care should be taken not to "over modularize" and trade-offs to evaluate replacement, transportation, and repair costs should be accomplished to determine the most cost effective approach.<br />
*''Interoperability'': The compatibility of components with standard interface protocols to facilitate rapid repair and enhancement/upgrade through black box technology using common interfaces. Physical interfaces should be designed so that mating between components can only happen correctly.<br />
*''Physical accessibility'': The designed-in structural assurance that components requiring more frequent monitoring, checkout, and maintenance can be easily accessed. This is especially important in Low Observable platforms. Maintenance points should be directly visible and accessible to maintainers, including access for corrosion inspection and mitigation.<br />
*Designs that require ''minimum preventative maintenance'' including corrosion prevention and mitigation. Emphasis should be on balancing the maintenance requirement over the life cycle with minimal user workload.<br />
*''Embedded training and testing'' when it is determined to be the optimal solution from a [[Total Ownership Cost (TOC)(glossary)|Total Ownership Cost (TOC)]] and Materiel Availability perspective.<br />
*''[[Human Systems Integration (HSI)(glossary)|Human Systems Integration (HSI)]]'' to optimize total system performance and minimize life-cycle costs by designing systems and incorporating technologies that require minimal manpower, provide effective training, can be operated and maintained by users, are suitable (habitable and safe with minimal environmental and occupational health hazards), and survivable (for both the user and the equipment).<br />
<br />
'''Support Considerations''': Support features cannot be easily "added-on" after the design is established. Consequently supportability should be a high priority early in the program's planning and integral to the system design and development process. Support features cut across reliability, maintainability, and the supply chain to facilitate detection, isolation, and timely repair/replacement of system anomalies. These include features for servicing and other activities necessary for operation and support including resources that contribute to the overall support of the system. Typical supportability features include diagnostics, prognostics (see CBM+ Guidebook), calibration requirements, many HSI issues (e.g. training, safety, HFE, occupational health, etc.), skill levels, documentation, maintenance data collection, compatibility, interoperability, transportability, handling (e.g., lift/hard/tie down points, etc.), packing requirements, facility requirements, accessibility, and other factors that contribute to an optimum environment for sustaining an operational system.<br />
<br />
==Plan Sustainment Processes==<br />
Process efficiency reflects how well the system can be produced, operated, serviced (including fueling) and maintained. It reflects the degree to which the logistics processes (including the supply chain), infrastructure, and footprint have been balanced to provide an agile, deployable, and operationally effective system. <br />
<br />
Achieving process efficiency requires early and continuing emphasis on the various logistics support processes along with the design considerations. The continued emphasis is important because processes present opportunities for improving operational effectiveness even after the "design-in" window has passed via lean-six sigma, supply chain optimization and other continuous process improvement (CPI) techniques. <br />
<br />
==Sustainment Analysis (Product Support Package)==<br />
<br />
The product support package documents the output of supportability analysis and includes details related to the following topics (links below are to excerpts from (NATO RTO 2001):<br />
<br />
*Product/IT System/Medical System Support Management (integrated life cycle sustainment planning)<br />
**Product/IT System/Medical System Support Strategies<br />
**Lifecycle sustainment planning<br />
**Requirements Management<br />
**Total Ownership Costs (TOC) / Life Cycle Cost (LCC) planning & management<br />
**Integration and management of product support activities<br />
**Configuration Management<br />
**Production & Distribution<br />
**Energy, Environmental, Safety and Health (EESH) management<br />
**Policies & Guidance<br />
**Risk Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-12.pdf Design Interface]<br />
**Reliability<br />
**Maintainability<br />
**Supportability<br />
**Affordability<br />
**Configuration Management<br />
**Safety requirements<br />
**Environmental and HAZMAT requirements<br />
**Human Systems Integration<br />
**Calibration<br />
**Anti-Tamper<br />
**Habitability<br />
**Disposal<br />
**Legal requirements<br />
*Sustaining Engineering<br />
**Failure Reporting, Analysis, and Corrective Action System (FRACAS)<br />
**Value Engineering<br />
**Diminishing Manufacturing Sources and Material Shortages<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-06.pdf Supply Support (materiel planning)]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-03.pdf Maintenance Planning]<br />
**Reliability Centered Maintenance (RCM)<br />
**Maintenance Concepts<br />
**Levels of Maintenance (Level of Repair Analysis)<br />
**Conditioned Based Maintenance<br />
**Prognostics & Health Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-05.pdf Support Equipment]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-07.pdf Technical Data]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-04.pdf Manpower & Personnel]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-08.pdf Training & Training Support]<br />
*[http://www.decisionlens.com/docs/WP_Strategic_Facilities_and_Infrastructure_Planning.pdf Facilities & Infrastructure]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-11.pdf Packaging, Handling, Storage, & Transportation]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-09.pdf Computer Resources]<br />
<br />
==Sustainment Implementation==<br />
Once the system becomes operational, the results of sustainment planning effort needs to implemented. Systems engineering supports the execution of the twelve integrated product support elements of a sustainment program that strives to ensure the system meets operational performance requirements in the most cost-effective manner over its total remaining life cycle.<br />
<br />
[[File:Sustainment_Implementation_Illustration_Logistics_Roedler.jpg|thumb|center|600px|Figure 2. Sustainment Implementation Illustration (DAU Guidebook 2012) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
Once a system is put into use, systems engineering is often required to correct problems that degrade continued use, and/or to add new capabilities to improve product performance in the current or a new environment. In the context of integrated product support, these systems engineering activities correspond to the IPS element “Sustaining Engineering.” Changes made to fielded systems to correct problems or increase performance should include any necessary adjustments to the IPS elements, and should consider the interrelationships and integration of the elements to maintain the effectiveness of system’s support strategy.<br />
<br />
The degree of change required to the product support elements varies with the severity of the problem. Minor problems may require a simple adjustment to a maintenance procedure, a change of supplier, a training course modification or a change to a technical manual. In contrast, problems that require system or component redesign may require engineering change proposals and approvals, IPS element trade studies, Business Case Analysis, and updates to the product support strategy. The focus is to correct problems that degrade continued use, regardless of the degree of severity.<br />
<br />
Evolutionary systems provide a strategy for acquisition of mature technology; the system delivers capabilities incrementally, planning for future capability enhancements. For these systems a System of Systems perspective is required to synchronize the Primary and Sustainment Systems.<br />
<br />
For more information refer to: An Enterprise Framework for Operationally Effective System of Systems Design.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
NATO RTO. 2001. ''Logistics Test and Evaluation in Flight Test''. Flight Test Techniques Series – Volume 20. Quebec, Canada: North Atlantic Treaty Organization (NATO) Research and Technology Organization (RTO). RTO-AG-300 Vol. 20, AC/323(SCI-010)TP/38. Table of contents available at: http://ftp.rta.nato.int/public//PubFullText/RTO/AG/RTO-AG-300-V20///AG-300-V20-$$TOC.pdf<br />
<br />
===Primary References===<br />
Blanchard, B.S. 1998. ''[[Logistics Engineering and Management]].'' Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
Blanchard, B. and Fabrycky, W. 2011. ''[[Systems Engineering and Analysis]],'' 5th Ed. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Bobinis, J. and Herald, T. 2012. “An Enterprise Framework for Operationally Effective System of Systems Design.” Journal of Enterprise Architecture May 2012, Volume 8, Number 2. Available at: https:// www.mendling.com/publications/JEA12-2.pdf.<br />
<br />
Daganzo, C. 2005. ''[[Logistics Systems Analysis]].'' 4th Edition. New York, NY, USA: Springer.<br />
<br />
Fabrycky, W.J. and B.S. Blanchard. 1991. ''[[Life-Cycle Cost and Economic Analysis]]''. Upper Saddle River, NJ, USA: Prentice-Hall.<br />
<br />
Ghiani, G., Laporte, G., and Musmanno, R. 2004. ''[[Introduction to Logistics Systems Planning and Control]].'' Hoboken, NJ, USA: Wiley-Interscience.<br />
<br />
Jones, J.V. 1995. ''[[Integrated Logistics Support Handbook]].'' New York, NY, USA: McGraw Hill.<br />
<br />
===Additional References===<br />
Barros, L.L. 1998. "The Optimization of Repair Decision Using Life-Cycle Cost Parameters." ''IMA Journal of Management Mathematics.'' 9(4): 403.<br />
<br />
Berkowitz, D., et al. 2005. ''Defining and Implementing Performance-Based Logistics in Government''. Washington, DC, USA: Defense Technical Information Center. Accessed 6 Sept 2011. Available at: http://handle.dtic.mil/100.2/ADP018510.<br />
<br />
Gajpal, P.P., L.S. Ganesh, and C. Rajendran. 1994. "Criticality Analysis of Spare Parts Using the Analytic Hierarchy Process." ''International Journal of Production Economics'' 35(1-3): 293-297. <br />
<br />
MITRE. 2011. "Integrated Logistics Support." ''Systems Engineering Guide.'' Accessed 11 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/acquisition_systems_engineering/integrated_logistics_support/]].<br />
<br />
Murthy, D.N.P. and W.R. Blischke. 2000. "Strategic Warranty Management: A Life-Cycle Approach." ''Engineering Management'' 47(1): 40-54.<br />
<br />
Northrop Grumman Corporation. 2000. ''Logistics Systems Engineering''. Accessed 6 Sept 2011. Available at: www.es.northropgrumman.com/solutions/navlogistics/.../nsd_logistics.pdf.<br />
<br />
Solomon, R., P.A. Sandborn, and M.G. Pecht. 2000. "Electronic Part Life Cycle Concepts and Obsolescence Forecasting." ''IEEE Transactions on Components and Packaging Technologies'' 23(4): 707-717. <br />
<br />
Spengler, T. and M. Schroter. 2003. "Strategic Management of Spare Parts in Closed-Loop Supply Chains: A System Dynamics Approach." ''Interfaces'' p. 7-17.<br />
<br />
----<br />
<center>[[System Maintenance|< Previous Article]] | [[System Deployment and Use|Parent Article]] | [[Systems Engineering Management|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Deployment and Use]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Logistics&diff=37977Logistics2012-08-06T17:21:08Z<p>Groedler: /* Sustainment Planning */</p>
<hr />
<div>There are several definitions for logistics within systems engineering and the definition used will determine what activities are considered part of logistics. The SEBoK defines [[logistics (glossary)]] as “the science of planning and implementing the acquisition and use of the resources necessary to sustain the operation of a system.”<br />
<br />
==Overview==<br />
The ability to “sustain the operation of a system” is determined by the inherent supportability of the system (a function of design) and the processes used to sustain the functions and capabilities of the system in the context of the end user. <br />
<br />
[[File:Affordable_Sys_Ops_Effect_DAU_GB_Roedler.jpg|thumb|600px|center|Figure 1. Affordable System Operational Effectiveness (DAU Guidebook 2012, pg. 385 ) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
==Sustainment Planning==<br />
The focus of sustainment planning is to influence the inherent supportability of the system and to plan the sustainment capabilities and processes that will be used to sustain system operations.<br />
Influence Inherent Supportability (Operational Suitability)<br />
<br />
Sustainment influence requires an understanding of the concept of operations, system missions, mission profiles, and system capabilities to understand the rationale behind functional and performance priorities. Understanding the rationale paves the way for decisions about necessary tradeoffs between system performance, availability, and Life Cycle Cost (LCC), with impact on the cost effectiveness of system operation, maintenance, and logistics support. There is no single list of sustainment considerations or specific way of grouping them as they are highly inter-related. They range from: compatibility, interoperability; transportability; reliability; maintainability; manpower; human factors; safety; natural environment effects (including occupational health; habitability); diagnostics & prognostics (including real-time maintenance data collection); and corrosion protection & mitigation. The following are key design considerations:<br />
<br />
'''Architecture Considerations''': The focus on openness, modularity, scalability, and upgradeability is critical to implementing an incremental acquisition strategy. In addition, the architecture attributes that expand system flexibility and affordability can pay dividends later when obsolescence and end-of-life issues are resolved through a concerted technology refreshment strategy. However trade-offs are required relative to the extent each attribute is used.<br />
<br />
'''Reliability Considerations''': Reliability is critical because it contributes to a system's effectiveness as well as its suitability in terms of logistics burden and the cost to fix [[Failure (glossary)|failures]]. For each system, there is a level of basic reliability that must be achieved for the system to be considered useful. Reliability is also one of the most critical elements in determining the logistics infrastructure and footprint. Consequently, system reliability should be a primary focus during design (along with system technical performance, functions, and capabilities). The primary objective is to achieve the necessary probability of operational success and minimize the risk of failure within defined availability, cost, schedule, weight, power, and volume constraints. While performing such analyses, trade-offs should be conducted and dependencies should be explored with system maintainability and integrated with the supportability analysis that addresses support event frequency (i.e. Reliability), event duration and event cost. Such a focus will play a significant role in minimizing the necessary logistics footprint, while maximizing system availability.<br />
<br />
'''Maintainability Considerations''': The design emphasis on maintainability is to reduce the maintenance burden and supply chain by reducing the time, personnel, tools, test equipment, training, facilities and cost to maintain the system. Maintainability engineering includes the activities, methods, and practices used to design minimal system maintenance requirements (designing out unnecessary and inefficient processes) and associated costs for preventive and corrective maintenance as well as servicing or calibration activities. Maintainability should be a designed-in capability and not an add-on option because good maintenance procedures cannot overcome poor system and equipment maintainability design. The primary objective is to reduce the time it takes for a properly trained maintainer to detect and isolate the failure (coverage and efficiency) and affect repair. Intrinsic factors contributing to maintainability are:<br />
<br />
*''Modularity'': Packaging of components such that they can be repaired via remove and replace action vs. on-board repair. Care should be taken not to "over modularize" and trade-offs to evaluate replacement, transportation, and repair costs should be accomplished to determine the most cost effective approach.<br />
*''Interoperability'': The compatibility of components with standard interface protocols to facilitate rapid repair and enhancement/upgrade through black box technology using common interfaces. Physical interfaces should be designed so that mating between components can only happen correctly.<br />
*''Physical accessibility'': The designed-in structural assurance that components requiring more frequent monitoring, checkout, and maintenance can be easily accessed. This is especially important in Low Observable platforms. Maintenance points should be directly visible and accessible to maintainers, including access for corrosion inspection and mitigation.<br />
*Designs that require ''minimum preventative maintenance'' including corrosion prevention and mitigation. Emphasis should be on balancing the maintenance requirement over the life cycle with minimal user workload.<br />
*''Embedded training and testing'' when it is determined to be the optimal solution from a Total Ownership Cost (TOC) and Materiel Availability perspective.<br />
*''Human Systems Integration (HSI)'' to optimize total system performance and minimize life-cycle costs by designing systems and incorporating technologies that require minimal manpower, provide effective training, can be operated and maintained by users, are suitable (habitable and safe with minimal environmental and occupational health hazards), and survivable (for both the user and the equipment).<br />
<br />
'''Support Considerations''': Support features cannot be easily "added-on" after the design is established. Consequently supportability should be a high priority early in the program's planning and integral to the system design and development process. Support features cut across reliability, maintainability, and the supply chain to facilitate detection, isolation, and timely repair/replacement of system anomalies. These include features for servicing and other activities necessary for operation and support including resources that contribute to the overall support of the system. Typical supportability features include diagnostics, prognostics (see CBM+ Guidebook), calibration requirements, many HSI issues (e.g. training, safety, HFE, occupational health, etc.), skill levels, documentation, maintenance data collection, compatibility, interoperability, transportability, handling (e.g., lift/hard/tie down points, etc.), packing requirements, facility requirements, accessibility, and other factors that contribute to an optimum environment for sustaining an operational system.<br />
<br />
==Plan Sustainment Processes==<br />
Process efficiency reflects how well the system can be produced, operated, serviced (including fueling) and maintained. It reflects the degree to which the logistics processes (including the supply chain), infrastructure, and footprint have been balanced to provide an agile, deployable, and operationally effective system. <br />
<br />
Achieving process efficiency requires early and continuing emphasis on the various logistics support processes along with the design considerations. The continued emphasis is important because processes present opportunities for improving operational effectiveness even after the "design-in" window has passed via lean-six sigma, supply chain optimization and other continuous process improvement (CPI) techniques. <br />
<br />
==Sustainment Analysis (Product Support Package)==<br />
<br />
The product support package documents the output of supportability analysis and includes details related to the following topics (links below are to excerpts from (NATO RTO 2001):<br />
<br />
*Product/IT System/Medical System Support Management (integrated life cycle sustainment planning)<br />
**Product/IT System/Medical System Support Strategies<br />
**Lifecycle sustainment planning<br />
**Requirements Management<br />
**Total Ownership Costs (TOC) / Life Cycle Cost (LCC) planning & management<br />
**Integration and management of product support activities<br />
**Configuration Management<br />
**Production & Distribution<br />
**Energy, Environmental, Safety and Health (EESH) management<br />
**Policies & Guidance<br />
**Risk Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-12.pdf Design Interface]<br />
**Reliability<br />
**Maintainability<br />
**Supportability<br />
**Affordability<br />
**Configuration Management<br />
**Safety requirements<br />
**Environmental and HAZMAT requirements<br />
**Human Systems Integration<br />
**Calibration<br />
**Anti-Tamper<br />
**Habitability<br />
**Disposal<br />
**Legal requirements<br />
*Sustaining Engineering<br />
**Failure Reporting, Analysis, and Corrective Action System (FRACAS)<br />
**Value Engineering<br />
**Diminishing Manufacturing Sources and Material Shortages<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-06.pdf Supply Support (materiel planning)]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-03.pdf Maintenance Planning]<br />
**Reliability Centered Maintenance (RCM)<br />
**Maintenance Concepts<br />
**Levels of Maintenance (Level of Repair Analysis)<br />
**Conditioned Based Maintenance<br />
**Prognostics & Health Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-05.pdf Support Equipment]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-07.pdf Technical Data]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-04.pdf Manpower & Personnel]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-08.pdf Training & Training Support]<br />
*[http://www.decisionlens.com/docs/WP_Strategic_Facilities_and_Infrastructure_Planning.pdf Facilities & Infrastructure]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-11.pdf Packaging, Handling, Storage, & Transportation]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-09.pdf Computer Resources]<br />
<br />
==Sustainment Implementation==<br />
Once the system becomes operational, the results of sustainment planning effort needs to implemented. Systems engineering supports the execution of the twelve integrated product support elements of a sustainment program that strives to ensure the system meets operational performance requirements in the most cost-effective manner over its total remaining life cycle.<br />
<br />
[[File:Sustainment_Implementation_Illustration_Logistics_Roedler.jpg|thumb|center|600px|Figure 2. Sustainment Implementation Illustration (DAU Guidebook 2012) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
Once a system is put into use, systems engineering is often required to correct problems that degrade continued use, and/or to add new capabilities to improve product performance in the current or a new environment. In the context of integrated product support, these systems engineering activities correspond to the IPS element “Sustaining Engineering.” Changes made to fielded systems to correct problems or increase performance should include any necessary adjustments to the IPS elements, and should consider the interrelationships and integration of the elements to maintain the effectiveness of system’s support strategy.<br />
<br />
The degree of change required to the product support elements varies with the severity of the problem. Minor problems may require a simple adjustment to a maintenance procedure, a change of supplier, a training course modification or a change to a technical manual. In contrast, problems that require system or component redesign may require engineering change proposals and approvals, IPS element trade studies, Business Case Analysis, and updates to the product support strategy. The focus is to correct problems that degrade continued use, regardless of the degree of severity.<br />
<br />
Evolutionary systems provide a strategy for acquisition of mature technology; the system delivers capabilities incrementally, planning for future capability enhancements. For these systems a System of Systems perspective is required to synchronize the Primary and Sustainment Systems.<br />
<br />
For more information refer to: An Enterprise Framework for Operationally Effective System of Systems Design.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
NATO RTO. 2001. ''Logistics Test and Evaluation in Flight Test''. Flight Test Techniques Series – Volume 20. Quebec, Canada: North Atlantic Treaty Organization (NATO) Research and Technology Organization (RTO). RTO-AG-300 Vol. 20, AC/323(SCI-010)TP/38. Table of contents available at: http://ftp.rta.nato.int/public//PubFullText/RTO/AG/RTO-AG-300-V20///AG-300-V20-$$TOC.pdf<br />
<br />
===Primary References===<br />
Blanchard, B.S. 1998. ''[[Logistics Engineering and Management]].'' Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
Blanchard, B. and Fabrycky, W. 2011. ''[[Systems Engineering and Analysis]],'' 5th Ed. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Bobinis, J. and Herald, T. 2012. “An Enterprise Framework for Operationally Effective System of Systems Design.” Journal of Enterprise Architecture May 2012, Volume 8, Number 2. Available at: https:// www.mendling.com/publications/JEA12-2.pdf.<br />
<br />
Daganzo, C. 2005. ''[[Logistics Systems Analysis]].'' 4th Edition. New York, NY, USA: Springer.<br />
<br />
Fabrycky, W.J. and B.S. Blanchard. 1991. ''[[Life-Cycle Cost and Economic Analysis]]''. Upper Saddle River, NJ, USA: Prentice-Hall.<br />
<br />
Ghiani, G., Laporte, G., and Musmanno, R. 2004. ''[[Introduction to Logistics Systems Planning and Control]].'' Hoboken, NJ, USA: Wiley-Interscience.<br />
<br />
Jones, J.V. 1995. ''[[Integrated Logistics Support Handbook]].'' New York, NY, USA: McGraw Hill.<br />
<br />
===Additional References===<br />
Barros, L.L. 1998. "The Optimization of Repair Decision Using Life-Cycle Cost Parameters." ''IMA Journal of Management Mathematics.'' 9(4): 403.<br />
<br />
Berkowitz, D., et al. 2005. ''Defining and Implementing Performance-Based Logistics in Government''. Washington, DC, USA: Defense Technical Information Center. Accessed 6 Sept 2011. Available at: http://handle.dtic.mil/100.2/ADP018510.<br />
<br />
Gajpal, P.P., L.S. Ganesh, and C. Rajendran. 1994. "Criticality Analysis of Spare Parts Using the Analytic Hierarchy Process." ''International Journal of Production Economics'' 35(1-3): 293-297. <br />
<br />
MITRE. 2011. "Integrated Logistics Support." ''Systems Engineering Guide.'' Accessed 11 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/acquisition_systems_engineering/integrated_logistics_support/]].<br />
<br />
Murthy, D.N.P. and W.R. Blischke. 2000. "Strategic Warranty Management: A Life-Cycle Approach." ''Engineering Management'' 47(1): 40-54.<br />
<br />
Northrop Grumman Corporation. 2000. ''Logistics Systems Engineering''. Accessed 6 Sept 2011. Available at: www.es.northropgrumman.com/solutions/navlogistics/.../nsd_logistics.pdf.<br />
<br />
Solomon, R., P.A. Sandborn, and M.G. Pecht. 2000. "Electronic Part Life Cycle Concepts and Obsolescence Forecasting." ''IEEE Transactions on Components and Packaging Technologies'' 23(4): 707-717. <br />
<br />
Spengler, T. and M. Schroter. 2003. "Strategic Management of Spare Parts in Closed-Loop Supply Chains: A System Dynamics Approach." ''Interfaces'' p. 7-17.<br />
<br />
----<br />
<center>[[System Maintenance|< Previous Article]] | [[System Deployment and Use|Parent Article]] | [[Systems Engineering Management|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Deployment and Use]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Logistics&diff=37971Logistics2012-08-06T17:14:20Z<p>Groedler: /* Primary References */</p>
<hr />
<div>There are several definitions for logistics within systems engineering and the definition used will determine what activities are considered part of logistics. The SEBoK defines [[logistics (glossary)]] as “the science of planning and implementing the acquisition and use of the resources necessary to sustain the operation of a system.”<br />
<br />
==Overview==<br />
The ability to “sustain the operation of a system” is determined by the inherent supportability of the system (a function of design) and the processes used to sustain the functions and capabilities of the system in the context of the end user. <br />
<br />
[[File:Affordable_Sys_Ops_Effect_DAU_GB_Roedler.jpg|thumb|600px|center|Figure 1. Affordable System Operational Effectiveness (DAU Guidebook 2012, pg. 385 ) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
==Sustainment Planning==<br />
The focus of sustainment planning is to influence the inherent supportability of the system and to plan the sustainment capabilities and processes that will be used to sustain system operations.<br />
Influence Inherent Supportability (Operational Suitability)<br />
<br />
Sustainment influence requires an understanding of the concept of operations, system missions, mission profiles, and system capabilities to understand the rationale behind functional and performance priorities. Understanding the rationale paves the way for decisions about necessary tradeoffs between system performance, availability, and LCC, with impact on the cost effectiveness of system operation, maintenance, and logistics support. There is no single list of sustainment considerations or specific way of grouping them as they are highly inter-related. They range from: compatibility, interoperability; transportability; reliability; maintainability; manpower; human factors; safety; natural environment effects (including occupational health; habitability); diagnostics & prognostics (including real-time maintenance data collection); and corrosion protection & mitigation. The following are key design considerations:<br />
<br />
'''Architecture Considerations''': The focus on openness, modularity, scalability, and upgradeability is critical to implementing an incremental acquisition strategy. In addition, the architecture attributes that expand system flexibility and affordability can pay dividends later when obsolescence and end-of-life issues are resolved through a concerted technology refreshment strategy. However trade-offs are required relative to the extent each attribute is used.<br />
<br />
'''Reliability Considerations''': Reliability is critical because it contributes to a system's effectiveness as well as its suitability in terms of logistics burden and the cost to fix [[Failure (glossary)|failures]]. For each system, there is a level of basic reliability that must be achieved for the system to be considered useful. Reliability is also one of the most critical elements in determining the logistics infrastructure and footprint. Consequently, system reliability should be a primary focus during design (along with system technical performance, functions, and capabilities). The primary objective is to achieve the necessary probability of operational success and minimize the risk of failure within defined availability, cost, schedule, weight, power, and volume constraints. While performing such analyses, trade-offs should be conducted and dependencies should be explored with system maintainability and integrated with the supportability analysis that addresses support event frequency (i.e. Reliability), event duration and event cost. Such a focus will play a significant role in minimizing the necessary logistics footprint, while maximizing system availability.<br />
<br />
'''Maintainability Considerations''': The design emphasis on maintainability is to reduce the maintenance burden and supply chain by reducing the time, personnel, tools, test equipment, training, facilities and cost to maintain the system. Maintainability engineering includes the activities, methods, and practices used to design minimal system maintenance requirements (designing out unnecessary and inefficient processes) and associated costs for preventive and corrective maintenance as well as servicing or calibration activities. Maintainability should be a designed-in capability and not an add-on option because good maintenance procedures cannot overcome poor system and equipment maintainability design. The primary objective is to reduce the time it takes for a properly trained maintainer to detect and isolate the failure (coverage and efficiency) and affect repair. Intrinsic factors contributing to maintainability are:<br />
<br />
*''Modularity'': Packaging of components such that they can be repaired via remove and replace action vs. on-board repair. Care should be taken not to "over modularize" and trade-offs to evaluate replacement, transportation, and repair costs should be accomplished to determine the most cost effective approach.<br />
*''Interoperability'': The compatibility of components with standard interface protocols to facilitate rapid repair and enhancement/upgrade through black box technology using common interfaces. Physical interfaces should be designed so that mating between components can only happen correctly.<br />
*''Physical accessibility'': The designed-in structural assurance that components requiring more frequent monitoring, checkout, and maintenance can be easily accessed. This is especially important in Low Observable platforms. Maintenance points should be directly visible and accessible to maintainers, including access for corrosion inspection and mitigation.<br />
*Designs that require ''minimum preventative maintenance'' including corrosion prevention and mitigation. Emphasis should be on balancing the maintenance requirement over the life cycle with minimal user workload.<br />
*''Embedded training and testing'' when it is determined to be the optimal solution from a TOC and Materiel Availability perspective.<br />
*''Human Systems Integration (HSI)'' to optimize total system performance and minimize life-cycle costs by designing systems and incorporating technologies that require minimal manpower, provide effective training, can be operated and maintained by users, are suitable (habitable and safe with minimal environmental and occupational health hazards), and survivable (for both the user and the equipment).<br />
<br />
'''Support Considerations''': Support features cannot be easily "added-on" after the design is established. Consequently supportability should be a high priority early in the program's planning and integral to the system design and development process. Support features cut across reliability, maintainability, and the supply chain to facilitate detection, isolation, and timely repair/replacement of system anomalies. These include features for servicing and other activities necessary for operation and support including resources that contribute to the overall support of the system. Typical supportability features include diagnostics, prognostics (see CBM+ Guidebook), calibration requirements, many HSI issues (e.g. training, safety, HFE, occupational health, etc.), skill levels, documentation, maintenance data collection, compatibility, interoperability, transportability, handling (e.g., lift/hard/tie down points, etc.), packing requirements, facility requirements, accessibility, and other factors that contribute to an optimum environment for sustaining an operational system.<br />
<br />
==Plan Sustainment Processes==<br />
Process efficiency reflects how well the system can be produced, operated, serviced (including fueling) and maintained. It reflects the degree to which the logistics processes (including the supply chain), infrastructure, and footprint have been balanced to provide an agile, deployable, and operationally effective system. <br />
<br />
Achieving process efficiency requires early and continuing emphasis on the various logistics support processes along with the design considerations. The continued emphasis is important because processes present opportunities for improving operational effectiveness even after the "design-in" window has passed via lean-six sigma, supply chain optimization and other continuous process improvement (CPI) techniques. <br />
<br />
==Sustainment Analysis (Product Support Package)==<br />
<br />
The product support package documents the output of supportability analysis and includes details related to the following topics (links below are to excerpts from (NATO RTO 2001):<br />
<br />
*Product/IT System/Medical System Support Management (integrated life cycle sustainment planning)<br />
**Product/IT System/Medical System Support Strategies<br />
**Lifecycle sustainment planning<br />
**Requirements Management<br />
**Total Ownership Costs (TOC) / Life Cycle Cost (LCC) planning & management<br />
**Integration and management of product support activities<br />
**Configuration Management<br />
**Production & Distribution<br />
**Energy, Environmental, Safety and Health (EESH) management<br />
**Policies & Guidance<br />
**Risk Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-12.pdf Design Interface]<br />
**Reliability<br />
**Maintainability<br />
**Supportability<br />
**Affordability<br />
**Configuration Management<br />
**Safety requirements<br />
**Environmental and HAZMAT requirements<br />
**Human Systems Integration<br />
**Calibration<br />
**Anti-Tamper<br />
**Habitability<br />
**Disposal<br />
**Legal requirements<br />
*Sustaining Engineering<br />
**Failure Reporting, Analysis, and Corrective Action System (FRACAS)<br />
**Value Engineering<br />
**Diminishing Manufacturing Sources and Material Shortages<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-06.pdf Supply Support (materiel planning)]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-03.pdf Maintenance Planning]<br />
**Reliability Centered Maintenance (RCM)<br />
**Maintenance Concepts<br />
**Levels of Maintenance (Level of Repair Analysis)<br />
**Conditioned Based Maintenance<br />
**Prognostics & Health Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-05.pdf Support Equipment]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-07.pdf Technical Data]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-04.pdf Manpower & Personnel]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-08.pdf Training & Training Support]<br />
*[http://www.decisionlens.com/docs/WP_Strategic_Facilities_and_Infrastructure_Planning.pdf Facilities & Infrastructure]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-11.pdf Packaging, Handling, Storage, & Transportation]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-09.pdf Computer Resources]<br />
<br />
==Sustainment Implementation==<br />
Once the system becomes operational, the results of sustainment planning effort needs to implemented. Systems engineering supports the execution of the twelve integrated product support elements of a sustainment program that strives to ensure the system meets operational performance requirements in the most cost-effective manner over its total remaining life cycle.<br />
<br />
[[File:Sustainment_Implementation_Illustration_Logistics_Roedler.jpg|thumb|center|600px|Figure 2. Sustainment Implementation Illustration (DAU Guidebook 2012) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
Once a system is put into use, systems engineering is often required to correct problems that degrade continued use, and/or to add new capabilities to improve product performance in the current or a new environment. In the context of integrated product support, these systems engineering activities correspond to the IPS element “Sustaining Engineering.” Changes made to fielded systems to correct problems or increase performance should include any necessary adjustments to the IPS elements, and should consider the interrelationships and integration of the elements to maintain the effectiveness of system’s support strategy.<br />
<br />
The degree of change required to the product support elements varies with the severity of the problem. Minor problems may require a simple adjustment to a maintenance procedure, a change of supplier, a training course modification or a change to a technical manual. In contrast, problems that require system or component redesign may require engineering change proposals and approvals, IPS element trade studies, Business Case Analysis, and updates to the product support strategy. The focus is to correct problems that degrade continued use, regardless of the degree of severity.<br />
<br />
Evolutionary systems provide a strategy for acquisition of mature technology; the system delivers capabilities incrementally, planning for future capability enhancements. For these systems a System of Systems perspective is required to synchronize the Primary and Sustainment Systems.<br />
<br />
For more information refer to: An Enterprise Framework for Operationally Effective System of Systems Design.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
NATO RTO. 2001. ''Logistics Test and Evaluation in Flight Test''. Flight Test Techniques Series – Volume 20. Quebec, Canada: North Atlantic Treaty Organization (NATO) Research and Technology Organization (RTO). RTO-AG-300 Vol. 20, AC/323(SCI-010)TP/38. Table of contents available at: http://ftp.rta.nato.int/public//PubFullText/RTO/AG/RTO-AG-300-V20///AG-300-V20-$$TOC.pdf<br />
<br />
===Primary References===<br />
Blanchard, B.S. 1998. ''[[Logistics Engineering and Management]].'' Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
Blanchard, B. and Fabrycky, W. 2011. ''[[Systems Engineering and Analysis]],'' 5th Ed. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Bobinis, J. and Herald, T. 2012. “An Enterprise Framework for Operationally Effective System of Systems Design.” Journal of Enterprise Architecture May 2012, Volume 8, Number 2. Available at: https:// www.mendling.com/publications/JEA12-2.pdf.<br />
<br />
Daganzo, C. 2005. ''[[Logistics Systems Analysis]].'' 4th Edition. New York, NY, USA: Springer.<br />
<br />
Fabrycky, W.J. and B.S. Blanchard. 1991. ''[[Life-Cycle Cost and Economic Analysis]]''. Upper Saddle River, NJ, USA: Prentice-Hall.<br />
<br />
Ghiani, G., Laporte, G., and Musmanno, R. 2004. ''[[Introduction to Logistics Systems Planning and Control]].'' Hoboken, NJ, USA: Wiley-Interscience.<br />
<br />
Jones, J.V. 1995. ''[[Integrated Logistics Support Handbook]].'' New York, NY, USA: McGraw Hill.<br />
<br />
===Additional References===<br />
Barros, L.L. 1998. "The Optimization of Repair Decision Using Life-Cycle Cost Parameters." ''IMA Journal of Management Mathematics.'' 9(4): 403.<br />
<br />
Berkowitz, D., et al. 2005. ''Defining and Implementing Performance-Based Logistics in Government''. Washington, DC, USA: Defense Technical Information Center. Accessed 6 Sept 2011. Available at: http://handle.dtic.mil/100.2/ADP018510.<br />
<br />
Gajpal, P.P., L.S. Ganesh, and C. Rajendran. 1994. "Criticality Analysis of Spare Parts Using the Analytic Hierarchy Process." ''International Journal of Production Economics'' 35(1-3): 293-297. <br />
<br />
MITRE. 2011. "Integrated Logistics Support." ''Systems Engineering Guide.'' Accessed 11 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/acquisition_systems_engineering/integrated_logistics_support/]].<br />
<br />
Murthy, D.N.P. and W.R. Blischke. 2000. "Strategic Warranty Management: A Life-Cycle Approach." ''Engineering Management'' 47(1): 40-54.<br />
<br />
Northrop Grumman Corporation. 2000. ''Logistics Systems Engineering''. Accessed 6 Sept 2011. Available at: www.es.northropgrumman.com/solutions/navlogistics/.../nsd_logistics.pdf.<br />
<br />
Solomon, R., P.A. Sandborn, and M.G. Pecht. 2000. "Electronic Part Life Cycle Concepts and Obsolescence Forecasting." ''IEEE Transactions on Components and Packaging Technologies'' 23(4): 707-717. <br />
<br />
Spengler, T. and M. Schroter. 2003. "Strategic Management of Spare Parts in Closed-Loop Supply Chains: A System Dynamics Approach." ''Interfaces'' p. 7-17.<br />
<br />
----<br />
<center>[[System Maintenance|< Previous Article]] | [[System Deployment and Use|Parent Article]] | [[Systems Engineering Management|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Deployment and Use]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Logistics&diff=37970Logistics2012-08-06T17:12:58Z<p>Groedler: /* Sustainment Implementation */</p>
<hr />
<div>There are several definitions for logistics within systems engineering and the definition used will determine what activities are considered part of logistics. The SEBoK defines [[logistics (glossary)]] as “the science of planning and implementing the acquisition and use of the resources necessary to sustain the operation of a system.”<br />
<br />
==Overview==<br />
The ability to “sustain the operation of a system” is determined by the inherent supportability of the system (a function of design) and the processes used to sustain the functions and capabilities of the system in the context of the end user. <br />
<br />
[[File:Affordable_Sys_Ops_Effect_DAU_GB_Roedler.jpg|thumb|600px|center|Figure 1. Affordable System Operational Effectiveness (DAU Guidebook 2012, pg. 385 ) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
==Sustainment Planning==<br />
The focus of sustainment planning is to influence the inherent supportability of the system and to plan the sustainment capabilities and processes that will be used to sustain system operations.<br />
Influence Inherent Supportability (Operational Suitability)<br />
<br />
Sustainment influence requires an understanding of the concept of operations, system missions, mission profiles, and system capabilities to understand the rationale behind functional and performance priorities. Understanding the rationale paves the way for decisions about necessary tradeoffs between system performance, availability, and LCC, with impact on the cost effectiveness of system operation, maintenance, and logistics support. There is no single list of sustainment considerations or specific way of grouping them as they are highly inter-related. They range from: compatibility, interoperability; transportability; reliability; maintainability; manpower; human factors; safety; natural environment effects (including occupational health; habitability); diagnostics & prognostics (including real-time maintenance data collection); and corrosion protection & mitigation. The following are key design considerations:<br />
<br />
'''Architecture Considerations''': The focus on openness, modularity, scalability, and upgradeability is critical to implementing an incremental acquisition strategy. In addition, the architecture attributes that expand system flexibility and affordability can pay dividends later when obsolescence and end-of-life issues are resolved through a concerted technology refreshment strategy. However trade-offs are required relative to the extent each attribute is used.<br />
<br />
'''Reliability Considerations''': Reliability is critical because it contributes to a system's effectiveness as well as its suitability in terms of logistics burden and the cost to fix [[Failure (glossary)|failures]]. For each system, there is a level of basic reliability that must be achieved for the system to be considered useful. Reliability is also one of the most critical elements in determining the logistics infrastructure and footprint. Consequently, system reliability should be a primary focus during design (along with system technical performance, functions, and capabilities). The primary objective is to achieve the necessary probability of operational success and minimize the risk of failure within defined availability, cost, schedule, weight, power, and volume constraints. While performing such analyses, trade-offs should be conducted and dependencies should be explored with system maintainability and integrated with the supportability analysis that addresses support event frequency (i.e. Reliability), event duration and event cost. Such a focus will play a significant role in minimizing the necessary logistics footprint, while maximizing system availability.<br />
<br />
'''Maintainability Considerations''': The design emphasis on maintainability is to reduce the maintenance burden and supply chain by reducing the time, personnel, tools, test equipment, training, facilities and cost to maintain the system. Maintainability engineering includes the activities, methods, and practices used to design minimal system maintenance requirements (designing out unnecessary and inefficient processes) and associated costs for preventive and corrective maintenance as well as servicing or calibration activities. Maintainability should be a designed-in capability and not an add-on option because good maintenance procedures cannot overcome poor system and equipment maintainability design. The primary objective is to reduce the time it takes for a properly trained maintainer to detect and isolate the failure (coverage and efficiency) and affect repair. Intrinsic factors contributing to maintainability are:<br />
<br />
*''Modularity'': Packaging of components such that they can be repaired via remove and replace action vs. on-board repair. Care should be taken not to "over modularize" and trade-offs to evaluate replacement, transportation, and repair costs should be accomplished to determine the most cost effective approach.<br />
*''Interoperability'': The compatibility of components with standard interface protocols to facilitate rapid repair and enhancement/upgrade through black box technology using common interfaces. Physical interfaces should be designed so that mating between components can only happen correctly.<br />
*''Physical accessibility'': The designed-in structural assurance that components requiring more frequent monitoring, checkout, and maintenance can be easily accessed. This is especially important in Low Observable platforms. Maintenance points should be directly visible and accessible to maintainers, including access for corrosion inspection and mitigation.<br />
*Designs that require ''minimum preventative maintenance'' including corrosion prevention and mitigation. Emphasis should be on balancing the maintenance requirement over the life cycle with minimal user workload.<br />
*''Embedded training and testing'' when it is determined to be the optimal solution from a TOC and Materiel Availability perspective.<br />
*''Human Systems Integration (HSI)'' to optimize total system performance and minimize life-cycle costs by designing systems and incorporating technologies that require minimal manpower, provide effective training, can be operated and maintained by users, are suitable (habitable and safe with minimal environmental and occupational health hazards), and survivable (for both the user and the equipment).<br />
<br />
'''Support Considerations''': Support features cannot be easily "added-on" after the design is established. Consequently supportability should be a high priority early in the program's planning and integral to the system design and development process. Support features cut across reliability, maintainability, and the supply chain to facilitate detection, isolation, and timely repair/replacement of system anomalies. These include features for servicing and other activities necessary for operation and support including resources that contribute to the overall support of the system. Typical supportability features include diagnostics, prognostics (see CBM+ Guidebook), calibration requirements, many HSI issues (e.g. training, safety, HFE, occupational health, etc.), skill levels, documentation, maintenance data collection, compatibility, interoperability, transportability, handling (e.g., lift/hard/tie down points, etc.), packing requirements, facility requirements, accessibility, and other factors that contribute to an optimum environment for sustaining an operational system.<br />
<br />
==Plan Sustainment Processes==<br />
Process efficiency reflects how well the system can be produced, operated, serviced (including fueling) and maintained. It reflects the degree to which the logistics processes (including the supply chain), infrastructure, and footprint have been balanced to provide an agile, deployable, and operationally effective system. <br />
<br />
Achieving process efficiency requires early and continuing emphasis on the various logistics support processes along with the design considerations. The continued emphasis is important because processes present opportunities for improving operational effectiveness even after the "design-in" window has passed via lean-six sigma, supply chain optimization and other continuous process improvement (CPI) techniques. <br />
<br />
==Sustainment Analysis (Product Support Package)==<br />
<br />
The product support package documents the output of supportability analysis and includes details related to the following topics (links below are to excerpts from (NATO RTO 2001):<br />
<br />
*Product/IT System/Medical System Support Management (integrated life cycle sustainment planning)<br />
**Product/IT System/Medical System Support Strategies<br />
**Lifecycle sustainment planning<br />
**Requirements Management<br />
**Total Ownership Costs (TOC) / Life Cycle Cost (LCC) planning & management<br />
**Integration and management of product support activities<br />
**Configuration Management<br />
**Production & Distribution<br />
**Energy, Environmental, Safety and Health (EESH) management<br />
**Policies & Guidance<br />
**Risk Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-12.pdf Design Interface]<br />
**Reliability<br />
**Maintainability<br />
**Supportability<br />
**Affordability<br />
**Configuration Management<br />
**Safety requirements<br />
**Environmental and HAZMAT requirements<br />
**Human Systems Integration<br />
**Calibration<br />
**Anti-Tamper<br />
**Habitability<br />
**Disposal<br />
**Legal requirements<br />
*Sustaining Engineering<br />
**Failure Reporting, Analysis, and Corrective Action System (FRACAS)<br />
**Value Engineering<br />
**Diminishing Manufacturing Sources and Material Shortages<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-06.pdf Supply Support (materiel planning)]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-03.pdf Maintenance Planning]<br />
**Reliability Centered Maintenance (RCM)<br />
**Maintenance Concepts<br />
**Levels of Maintenance (Level of Repair Analysis)<br />
**Conditioned Based Maintenance<br />
**Prognostics & Health Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-05.pdf Support Equipment]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-07.pdf Technical Data]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-04.pdf Manpower & Personnel]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-08.pdf Training & Training Support]<br />
*[http://www.decisionlens.com/docs/WP_Strategic_Facilities_and_Infrastructure_Planning.pdf Facilities & Infrastructure]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-11.pdf Packaging, Handling, Storage, & Transportation]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-09.pdf Computer Resources]<br />
<br />
==Sustainment Implementation==<br />
Once the system becomes operational, the results of sustainment planning effort needs to implemented. Systems engineering supports the execution of the twelve integrated product support elements of a sustainment program that strives to ensure the system meets operational performance requirements in the most cost-effective manner over its total remaining life cycle.<br />
<br />
[[File:Sustainment_Implementation_Illustration_Logistics_Roedler.jpg|thumb|center|600px|Figure 2. Sustainment Implementation Illustration (DAU Guidebook 2012) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
Once a system is put into use, systems engineering is often required to correct problems that degrade continued use, and/or to add new capabilities to improve product performance in the current or a new environment. In the context of integrated product support, these systems engineering activities correspond to the IPS element “Sustaining Engineering.” Changes made to fielded systems to correct problems or increase performance should include any necessary adjustments to the IPS elements, and should consider the interrelationships and integration of the elements to maintain the effectiveness of system’s support strategy.<br />
<br />
The degree of change required to the product support elements varies with the severity of the problem. Minor problems may require a simple adjustment to a maintenance procedure, a change of supplier, a training course modification or a change to a technical manual. In contrast, problems that require system or component redesign may require engineering change proposals and approvals, IPS element trade studies, Business Case Analysis, and updates to the product support strategy. The focus is to correct problems that degrade continued use, regardless of the degree of severity.<br />
<br />
Evolutionary systems provide a strategy for acquisition of mature technology; the system delivers capabilities incrementally, planning for future capability enhancements. For these systems a System of Systems perspective is required to synchronize the Primary and Sustainment Systems.<br />
<br />
For more information refer to: An Enterprise Framework for Operationally Effective System of Systems Design.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
NATO RTO. 2001. ''Logistics Test and Evaluation in Flight Test''. Flight Test Techniques Series – Volume 20. Quebec, Canada: North Atlantic Treaty Organization (NATO) Research and Technology Organization (RTO). RTO-AG-300 Vol. 20, AC/323(SCI-010)TP/38. Table of contents available at: http://ftp.rta.nato.int/public//PubFullText/RTO/AG/RTO-AG-300-V20///AG-300-V20-$$TOC.pdf<br />
<br />
===Primary References===<br />
Blanchard, B.S. 1998. ''[[Logistics Engineering and Management]].'' Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
Blanchard, B. and Fabrycky, W. 2011. ''[[Systems Engineering and Analysis]],'' 5th Ed. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Daganzo, C. 2005. ''[[Logistics Systems Analysis]].'' 4th Edition. New York, NY, USA: Springer.<br />
<br />
Fabrycky, W.J. and B.S. Blanchard. 1991. ''[[Life-Cycle Cost and Economic Analysis]]''. Upper Saddle River, NJ, USA: Prentice-Hall.<br />
<br />
Ghiani, G., Laporte, G., and Musmanno, R. 2004. ''[[Introduction to Logistics Systems Planning and Control]].'' Hoboken, NJ, USA: Wiley-Interscience.<br />
<br />
Jones, J.V. 1995. ''[[Integrated Logistics Support Handbook]].'' New York, NY, USA: McGraw Hill.<br />
<br />
===Additional References===<br />
Barros, L.L. 1998. "The Optimization of Repair Decision Using Life-Cycle Cost Parameters." ''IMA Journal of Management Mathematics.'' 9(4): 403.<br />
<br />
Berkowitz, D., et al. 2005. ''Defining and Implementing Performance-Based Logistics in Government''. Washington, DC, USA: Defense Technical Information Center. Accessed 6 Sept 2011. Available at: http://handle.dtic.mil/100.2/ADP018510.<br />
<br />
Gajpal, P.P., L.S. Ganesh, and C. Rajendran. 1994. "Criticality Analysis of Spare Parts Using the Analytic Hierarchy Process." ''International Journal of Production Economics'' 35(1-3): 293-297. <br />
<br />
MITRE. 2011. "Integrated Logistics Support." ''Systems Engineering Guide.'' Accessed 11 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/acquisition_systems_engineering/integrated_logistics_support/]].<br />
<br />
Murthy, D.N.P. and W.R. Blischke. 2000. "Strategic Warranty Management: A Life-Cycle Approach." ''Engineering Management'' 47(1): 40-54.<br />
<br />
Northrop Grumman Corporation. 2000. ''Logistics Systems Engineering''. Accessed 6 Sept 2011. Available at: www.es.northropgrumman.com/solutions/navlogistics/.../nsd_logistics.pdf.<br />
<br />
Solomon, R., P.A. Sandborn, and M.G. Pecht. 2000. "Electronic Part Life Cycle Concepts and Obsolescence Forecasting." ''IEEE Transactions on Components and Packaging Technologies'' 23(4): 707-717. <br />
<br />
Spengler, T. and M. Schroter. 2003. "Strategic Management of Spare Parts in Closed-Loop Supply Chains: A System Dynamics Approach." ''Interfaces'' p. 7-17.<br />
<br />
----<br />
<center>[[System Maintenance|< Previous Article]] | [[System Deployment and Use|Parent Article]] | [[Systems Engineering Management|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Deployment and Use]]<br />
{{DISQUS}}</div>Groedlerhttps://sandbox.sebokwiki.org/index.php?title=Logistics&diff=37960Logistics2012-08-06T17:09:28Z<p>Groedler: /* Sustainment Implementation */</p>
<hr />
<div>There are several definitions for logistics within systems engineering and the definition used will determine what activities are considered part of logistics. The SEBoK defines [[logistics (glossary)]] as “the science of planning and implementing the acquisition and use of the resources necessary to sustain the operation of a system.”<br />
<br />
==Overview==<br />
The ability to “sustain the operation of a system” is determined by the inherent supportability of the system (a function of design) and the processes used to sustain the functions and capabilities of the system in the context of the end user. <br />
<br />
[[File:Affordable_Sys_Ops_Effect_DAU_GB_Roedler.jpg|thumb|600px|center|Figure 1. Affordable System Operational Effectiveness (DAU Guidebook 2012, pg. 385 ) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
==Sustainment Planning==<br />
The focus of sustainment planning is to influence the inherent supportability of the system and to plan the sustainment capabilities and processes that will be used to sustain system operations.<br />
Influence Inherent Supportability (Operational Suitability)<br />
<br />
Sustainment influence requires an understanding of the concept of operations, system missions, mission profiles, and system capabilities to understand the rationale behind functional and performance priorities. Understanding the rationale paves the way for decisions about necessary tradeoffs between system performance, availability, and LCC, with impact on the cost effectiveness of system operation, maintenance, and logistics support. There is no single list of sustainment considerations or specific way of grouping them as they are highly inter-related. They range from: compatibility, interoperability; transportability; reliability; maintainability; manpower; human factors; safety; natural environment effects (including occupational health; habitability); diagnostics & prognostics (including real-time maintenance data collection); and corrosion protection & mitigation. The following are key design considerations:<br />
<br />
'''Architecture Considerations''': The focus on openness, modularity, scalability, and upgradeability is critical to implementing an incremental acquisition strategy. In addition, the architecture attributes that expand system flexibility and affordability can pay dividends later when obsolescence and end-of-life issues are resolved through a concerted technology refreshment strategy. However trade-offs are required relative to the extent each attribute is used.<br />
<br />
'''Reliability Considerations''': Reliability is critical because it contributes to a system's effectiveness as well as its suitability in terms of logistics burden and the cost to fix [[Failure (glossary)|failures]]. For each system, there is a level of basic reliability that must be achieved for the system to be considered useful. Reliability is also one of the most critical elements in determining the logistics infrastructure and footprint. Consequently, system reliability should be a primary focus during design (along with system technical performance, functions, and capabilities). The primary objective is to achieve the necessary probability of operational success and minimize the risk of failure within defined availability, cost, schedule, weight, power, and volume constraints. While performing such analyses, trade-offs should be conducted and dependencies should be explored with system maintainability and integrated with the supportability analysis that addresses support event frequency (i.e. Reliability), event duration and event cost. Such a focus will play a significant role in minimizing the necessary logistics footprint, while maximizing system availability.<br />
<br />
'''Maintainability Considerations''': The design emphasis on maintainability is to reduce the maintenance burden and supply chain by reducing the time, personnel, tools, test equipment, training, facilities and cost to maintain the system. Maintainability engineering includes the activities, methods, and practices used to design minimal system maintenance requirements (designing out unnecessary and inefficient processes) and associated costs for preventive and corrective maintenance as well as servicing or calibration activities. Maintainability should be a designed-in capability and not an add-on option because good maintenance procedures cannot overcome poor system and equipment maintainability design. The primary objective is to reduce the time it takes for a properly trained maintainer to detect and isolate the failure (coverage and efficiency) and affect repair. Intrinsic factors contributing to maintainability are:<br />
<br />
*''Modularity'': Packaging of components such that they can be repaired via remove and replace action vs. on-board repair. Care should be taken not to "over modularize" and trade-offs to evaluate replacement, transportation, and repair costs should be accomplished to determine the most cost effective approach.<br />
*''Interoperability'': The compatibility of components with standard interface protocols to facilitate rapid repair and enhancement/upgrade through black box technology using common interfaces. Physical interfaces should be designed so that mating between components can only happen correctly.<br />
*''Physical accessibility'': The designed-in structural assurance that components requiring more frequent monitoring, checkout, and maintenance can be easily accessed. This is especially important in Low Observable platforms. Maintenance points should be directly visible and accessible to maintainers, including access for corrosion inspection and mitigation.<br />
*Designs that require ''minimum preventative maintenance'' including corrosion prevention and mitigation. Emphasis should be on balancing the maintenance requirement over the life cycle with minimal user workload.<br />
*''Embedded training and testing'' when it is determined to be the optimal solution from a TOC and Materiel Availability perspective.<br />
*''Human Systems Integration (HSI)'' to optimize total system performance and minimize life-cycle costs by designing systems and incorporating technologies that require minimal manpower, provide effective training, can be operated and maintained by users, are suitable (habitable and safe with minimal environmental and occupational health hazards), and survivable (for both the user and the equipment).<br />
<br />
'''Support Considerations''': Support features cannot be easily "added-on" after the design is established. Consequently supportability should be a high priority early in the program's planning and integral to the system design and development process. Support features cut across reliability, maintainability, and the supply chain to facilitate detection, isolation, and timely repair/replacement of system anomalies. These include features for servicing and other activities necessary for operation and support including resources that contribute to the overall support of the system. Typical supportability features include diagnostics, prognostics (see CBM+ Guidebook), calibration requirements, many HSI issues (e.g. training, safety, HFE, occupational health, etc.), skill levels, documentation, maintenance data collection, compatibility, interoperability, transportability, handling (e.g., lift/hard/tie down points, etc.), packing requirements, facility requirements, accessibility, and other factors that contribute to an optimum environment for sustaining an operational system.<br />
<br />
==Plan Sustainment Processes==<br />
Process efficiency reflects how well the system can be produced, operated, serviced (including fueling) and maintained. It reflects the degree to which the logistics processes (including the supply chain), infrastructure, and footprint have been balanced to provide an agile, deployable, and operationally effective system. <br />
<br />
Achieving process efficiency requires early and continuing emphasis on the various logistics support processes along with the design considerations. The continued emphasis is important because processes present opportunities for improving operational effectiveness even after the "design-in" window has passed via lean-six sigma, supply chain optimization and other continuous process improvement (CPI) techniques. <br />
<br />
==Sustainment Analysis (Product Support Package)==<br />
<br />
The product support package documents the output of supportability analysis and includes details related to the following topics (links below are to excerpts from (NATO RTO 2001):<br />
<br />
*Product/IT System/Medical System Support Management (integrated life cycle sustainment planning)<br />
**Product/IT System/Medical System Support Strategies<br />
**Lifecycle sustainment planning<br />
**Requirements Management<br />
**Total Ownership Costs (TOC) / Life Cycle Cost (LCC) planning & management<br />
**Integration and management of product support activities<br />
**Configuration Management<br />
**Production & Distribution<br />
**Energy, Environmental, Safety and Health (EESH) management<br />
**Policies & Guidance<br />
**Risk Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-12.pdf Design Interface]<br />
**Reliability<br />
**Maintainability<br />
**Supportability<br />
**Affordability<br />
**Configuration Management<br />
**Safety requirements<br />
**Environmental and HAZMAT requirements<br />
**Human Systems Integration<br />
**Calibration<br />
**Anti-Tamper<br />
**Habitability<br />
**Disposal<br />
**Legal requirements<br />
*Sustaining Engineering<br />
**Failure Reporting, Analysis, and Corrective Action System (FRACAS)<br />
**Value Engineering<br />
**Diminishing Manufacturing Sources and Material Shortages<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-06.pdf Supply Support (materiel planning)]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-03.pdf Maintenance Planning]<br />
**Reliability Centered Maintenance (RCM)<br />
**Maintenance Concepts<br />
**Levels of Maintenance (Level of Repair Analysis)<br />
**Conditioned Based Maintenance<br />
**Prognostics & Health Management<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-05.pdf Support Equipment]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-07.pdf Technical Data]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-04.pdf Manpower & Personnel]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-08.pdf Training & Training Support]<br />
*[http://www.decisionlens.com/docs/WP_Strategic_Facilities_and_Infrastructure_Planning.pdf Facilities & Infrastructure]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-11.pdf Packaging, Handling, Storage, & Transportation]<br />
*[http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-09.pdf Computer Resources]<br />
<br />
==Sustainment Implementation==<br />
Once the system becomes operational, the results of sustainment planning effort needs to implemented. Systems engineering supports the execution of the twelve integrated product support elements of a sustainment program that strives to ensure the system meets operational performance requirements in the most cost-effective manner over its total remaining life cycle.<br />
<br />
[[File:Sustainment_Implementation_Illustration_Logistics_Roedler.jpg|thumb|center|600px|Figure 2. Sustainment Implementation Illustration (DAU Guidebook 2012) Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD)]]<br />
<br />
Once a system is put into use, systems engineering is often required to correct problems that degrade continued use, and/or to add new capabilities to improve product performance in the current or a new environment. In the context of integrated product support, these systems engineering activities correspond to the IPS element “Sustaining Engineering.” Changes made to fielded systems to correct problems or increase performance should include any necessary adjustments to the IPS elements, and should consider the interrelationships and integration of the elements to maintain the effectiveness of system’s support strategy.<br />
<br />
The degree of change required to the product support elements varies with the severity of the problem. Minor problems may require a simple adjustment to a maintenance procedure, a change of supplier, a training course modification or a change to a technical manual. In contrast, problems that require system or component redesign may require engineering change proposals and approvals, IPS element trade studies, Business Case Analysis, and updates to the product support strategy. The focus is to correct problems that degrade continued use, regardless of the degree of severity.<br />
<br />
Evolutionary systems provide a strategy for acquisition of mature technology; the system delivers capabilities incrementally, planning for future capability enhancements. For these systems a System of Systems perspective is required to synchronize the Primary and Sustainment Systems.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
NATO RTO. 2001. ''Logistics Test and Evaluation in Flight Test''. Flight Test Techniques Series – Volume 20. Quebec, Canada: North Atlantic Treaty Organization (NATO) Research and Technology Organization (RTO). RTO-AG-300 Vol. 20, AC/323(SCI-010)TP/38. Table of contents available at: http://ftp.rta.nato.int/public//PubFullText/RTO/AG/RTO-AG-300-V20///AG-300-V20-$$TOC.pdf<br />
<br />
===Primary References===<br />
Blanchard, B.S. 1998. ''[[Logistics Engineering and Management]].'' Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
Blanchard, B. and Fabrycky, W. 2011. ''[[Systems Engineering and Analysis]],'' 5th Ed. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Daganzo, C. 2005. ''[[Logistics Systems Analysis]].'' 4th Edition. New York, NY, USA: Springer.<br />
<br />
Fabrycky, W.J. and B.S. Blanchard. 1991. ''[[Life-Cycle Cost and Economic Analysis]]''. Upper Saddle River, NJ, USA: Prentice-Hall.<br />
<br />
Ghiani, G., Laporte, G., and Musmanno, R. 2004. ''[[Introduction to Logistics Systems Planning and Control]].'' Hoboken, NJ, USA: Wiley-Interscience.<br />
<br />
Jones, J.V. 1995. ''[[Integrated Logistics Support Handbook]].'' New York, NY, USA: McGraw Hill.<br />
<br />
===Additional References===<br />
Barros, L.L. 1998. "The Optimization of Repair Decision Using Life-Cycle Cost Parameters." ''IMA Journal of Management Mathematics.'' 9(4): 403.<br />
<br />
Berkowitz, D., et al. 2005. ''Defining and Implementing Performance-Based Logistics in Government''. Washington, DC, USA: Defense Technical Information Center. Accessed 6 Sept 2011. Available at: http://handle.dtic.mil/100.2/ADP018510.<br />
<br />
Gajpal, P.P., L.S. Ganesh, and C. Rajendran. 1994. "Criticality Analysis of Spare Parts Using the Analytic Hierarchy Process." ''International Journal of Production Economics'' 35(1-3): 293-297. <br />
<br />
MITRE. 2011. "Integrated Logistics Support." ''Systems Engineering Guide.'' Accessed 11 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/acquisition_systems_engineering/integrated_logistics_support/]].<br />
<br />
Murthy, D.N.P. and W.R. Blischke. 2000. "Strategic Warranty Management: A Life-Cycle Approach." ''Engineering Management'' 47(1): 40-54.<br />
<br />
Northrop Grumman Corporation. 2000. ''Logistics Systems Engineering''. Accessed 6 Sept 2011. Available at: www.es.northropgrumman.com/solutions/navlogistics/.../nsd_logistics.pdf.<br />
<br />
Solomon, R., P.A. Sandborn, and M.G. Pecht. 2000. "Electronic Part Life Cycle Concepts and Obsolescence Forecasting." ''IEEE Transactions on Components and Packaging Technologies'' 23(4): 707-717. <br />
<br />
Spengler, T. and M. Schroter. 2003. "Strategic Management of Spare Parts in Closed-Loop Supply Chains: A System Dynamics Approach." ''Interfaces'' p. 7-17.<br />
<br />
----<br />
<center>[[System Maintenance|< Previous Article]] | [[System Deployment and Use|Parent Article]] | [[Systems Engineering Management|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Deployment and Use]]<br />
{{DISQUS}}</div>Groedler