INCOSE Systems Engineering Handbook Chapter4.pdf

4 TECHNICAL PROCESSES The ISO/IEC/IEEE 15288 technical processes and supporting process activities are invoked throughout the life cycle stages of a system. Technical processes are defined in ISO/IEC/IEEE 15288 as follows: [6.4] The Technical Processes are used to define the requirements for a syst...

4 TECHNICAL PROCESSES The ISO/IEC/IEEE 15288 technical processes and supporting process activities are invoked throughout the life cycle stages of a system. Technical processes are defined in ISO/IEC/IEEE 15288 as follows: [6.4] The Technical Processes are used to define the requirements for a system, to transform the requirements into an effective product, to permit consistent reproduction of the product where necessary, to use the product to provide the required services, to sustain the provision of those services and to dispose of the product when it is retired from service. Technical processes enable systems engineers to coordinate the interactions between engineering specialists, other engineering disciplines, system stakeholders and operators, and manufacturing. They also address conformance with the expectations and legislated requirements of society. These processes lead to the creation of a sufficient set of requirements and resulting system solutions that address the desired capabilities within the bounds of performance, environment, external interfaces, and design constraints. Without the technical processes, the risk of project failure would be unacceptably high. As illustrated in Figure 4.1, the technical processes begin with the development of needs and requirements (Ryan, 2013): r Needs—Per the Oxford English Dictionary, a need is a thing that is wanted or required. For a system, needs are often capabilities or things that are lacking but wanted or desired by one or more stakeholders. These can be viewed in at least three contexts in which SE is performed: (i)) projects with customers internal to the enterprise that is doing the engineering, (ii) development under an agreement with an external entity, and (iii) entrepreneurial product development in anticipation of future sales. r Requirements—Requirements are formal structured statements that can be verified and validated. There may be more than one requirement defined for each need. Note: One underlying principle illustrated by Figure 4.1 is that when a decision is made to satisfy a need, that need gives rise to a corresponding requirement or set of requirements. ISO/IEC/IEEE 15288 includes 14 technical processes, the roles of the first four of which are illustrated in Figure 4.1: r Business or mission analysis process—Requirements definition begins with the business vision of the INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, Fourth Edition. Edited by David D. Walden, Garry J. Roedler, Kevin J. Forsberg, R. Douglas Hamelin and Thomas M. Shortell. © 2015 John Wiley & Sons, Inc. Published 2015 by John Wiley & Sons, Inc. 47 For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 48 TECHNICAL PROCESSES Enterprise Business management Concept of operations (ConOps) Preliminary life-cycle concepts: Operational (OpsCon), acquisition, deployment, support, retirement Enterprise strategies Business needs Business requirements Business requirements specification (BRS) Business or mission analysis process (Section 4.1) Stakeholder requirements Stakeholder requirements specification (StRS) Stakeholder needs and requirements definition Process (Section 4.2) System requirements System requirements specification (SyRS) System Architecture requirements definition process process (Section 4.3) (Section 4.4) System element requirements System element requirements specifications System Architecture requirements definition process process (Section 4.3) (Section 4.4) Analysis Business operations System System element Life-cycle concepts: OpsCon, acquisition, deployment, support, retirement Stakeholder needs Analysis System life-cycle concepts: OpsCon, acquisition, deployment, support, retirement System needs System element life-cycle concepts: OpsCon, acquisition, deployment, support, retirement System element needs Analysis Analysis Needs view Requirements view FIGURE 4.1 Transformation of needs into requirements. Reprinted with permission from Mike Ryan. All other rights reserved. organization or enterprise, the concept of operations (ConOps), and other organization strategic goals and objectives from which business management define business needs (aka mission needs). These needs are supported by preliminary life cycle concepts—acquisition concept, deployment concept, operational concept (OpsCon), support concept, and retirement concept—see Section 4.1.2.2 for a detailed description of the roles of the ConOps and the OpsCon. Business needs are then elaborated and formalized into business requirements, which are often captured in a Business Requirements Specification (BRS). r Stakeholder needs and requirements definition process—Using the enterprise‐level ConOps from the acquiring enterprise and the system‐level preliminary OpsCon from the development enterprise as guidance, requirements engineers lead stakeholders from business operations 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 by requirements engineers into a formal set of stakeholder requirements, which are often captured in a Stakeholder Requirements Specification (StRS). r System requirements definition process—The stakeholder requirements in the StRS are then transformed by requirements engineers into system requirements, which are often contained in a System Requirements Specification (SyRS). r Architecture definition process—Alternative system architectures are defined and one is selected. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. BUSINESS OR MISSION ANALYSIS PROCESS r Design definition process—System elements are defined in sufficient detail to enable implementation consistent with the selected system architecture. r System analysis process—Mathematical analysis, modeling, and simulation are used to support the other technical processes. r Implementation process—System elements are realized to satisfy system requirements, architecture, and design. r Integration process—System elements are combined into a realized system. r Verification process—Evidence is provided that the system, the system elements, and the work products in the life cycle meet the specified requirements. r Transition process—The system moves into operations in a planned, orderly manner. r Validation process—Evidence is provided that the system, the system elements, and the work products in the life cycle will achieve their intended use in the intended operational environment. r Operation process—The system is used. r Maintenance process—The system is sustained during operations. r Disposal process—The system or system elements are deactivated, disassembled, and removed from operations. 4.1 BUSINESS OR MISSION ANALYSIS PROCESS 4.1.1 4.1.1.1 Overview Purpose As stated in ISO/IEC/IEEE 15288, [6.4.1.1] The purpose of the Business or Mission Analysis process is to define the business or mission problem or opportunity, characterize the solution space, and determine potential solution class(es) that could address a problem or take advantage of an opportunity. 4.1.1.2 Description Business or mission analysis initiates the life cycle of the system of interest (SOI) by defining the problem domain; identifying major stakeholders; identifying environmental conditions and constraints that bound the solution domain; developing preliminary life cycle concepts for acquisition, operations, deployment, support, and retirement; and developing the 49 business requirements and validation criteria. Figure 4.2 is the IPO diagram for the business or mission analysis process. 4.1.1.3 Inputs/Outputs Inputs and outputs for the business or mission analysis process are listed in Figure 4.2. Descriptions of each input and output are provided in Appendix E. 4.1.1.4 Process Activities The business or mission analysis process includes the following activities and tasks: r Prepare for business or mission analysis. – Establish a strategy for business or mission analysis, including the need for and requirements of any enabling systems, products, or services. r Define the problem or opportunity space. – Review identified gaps in the organization strategy with respect to desired organization goals or objectives. – Analyze the gaps across the trade space. – Describe the problems or opportunities underlying the gaps. – Obtain agreement on the problem or opportunity descriptions. r Characterize the solution space. – Nominate major stakeholders (individuals or groups). Business owners nominate the major stakeholders who are to be involved in the acquisition, operation, support, and retirement of the solution. – Define preliminary OpsCon. An OpsCon describes how the system works from the operator’s perspective. The preliminary OpsCon summarizes the needs, goals, and characteristics of the system’s user and operator community. The OpsCon also identifies the system context and system interfaces (i.e., the operational environment; see Elaboration for more detail). – Define other preliminary life cycle concepts. The business owners identify preliminary life cycle concepts in so far as they may wish to scope any aspect of the acquisition, deployment, support, and retirement of the solution. – Establish a comprehensive set of alternative solution classes. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 50 TECHNICAL PROCESSES Controls Inputs • Organization strategic plan • ConOps • Source documents • Life cycle constraints • Project constraints • Stakeholder requirements traceability Activities Outputs • Prepare for business or mission analysis • Define the problem or opportunity space • Characterize the solution space • Evaluate alternative solution classes • Manage the business or mission analysis • Business or mission analysis strategy • Major stakeholder identification • Preliminary life cycle concepts • Problem or opportunity statement • Business requirements • Alternative solution classes • Preliminary validation criteria • Preliminary MOE needs • Preliminary MOE data • Business requirements traceability • Business or mission analysis record Enablers FIGURE 4.2 IPO diagram for business or mission analysis process. INCOSE SEH original figure created by Shortell and Walden. Usage per the INCOSE Notices page. All other rights reserved. r Evaluate alternative solution classes. – Evaluate the set of alternative solution classes and select the preferred class(es). Appropriate modeling, simulation, and analytical techniques help determine the feasibility and value of the alternative candidate solutions. – Ensure that the preferred alternative solution class(es) has been validated in the context of the proposed business or mission strategy. Feedback on feasibility, market factors, and alternatives is also provided for use in completing the organization strategy and further actions. r Manage the business or mission analysis. – Establish and maintain traceability of analysis results, such as requirements and preliminary life cycle concepts. – Provide baseline information for configuration management. 4.1.2 Elaboration 4.1.2.1 Nominate Major Stakeholders Although the detailed identification of stakeholders is undertaken in the stakeholder needs and requirements definition process, during business and mission analysis, the business managers are responsible for nominating major stakeholders and often for establishing a stakeholder board. It is fundamentally a business management function to ensure stakeholders are available and willing to contribute to the system development—most stakeholders are heavily occupied in business operations and must be given permission to expend effort and resources on other than their operational tasks. 4.1.2.2 ConOps and OpsCon ANSI/AIAA G‐043A‐ 2012 states that the terms “concept of operations” and “operational concept” are often used interchangeably but notes that an important distinction exists in that each has For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. BUSINESS OR MISSION ANALYSIS PROCESS a separate purpose and is used to meet different ends. This handbook uses these terms so that they are consistent with ANSI/AIAA G‐043A‐2012 and ISO/IEC/IEEE 29148:2011, the same way in which they are used in the US Department of Defense (DoD) and many other defense forces. ISO/IEC/IEEE 29148 describes the ConOps as 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 of the business with using 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 the future business and systems, for the project to understand its background, and for the users of [ISO/IEC/IEEE 29148] to implement the stakeholder requirements elicitation. ISO/IEC/IEEE 29148 describes the OpsCon as A System Operational Concept (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. Both the ConOps and the OpsCon are prepared by the organization that has the business need for the SOI. The ConOps is developed by/for the leadership at the enterprise level of the organization using the SOI. In some acquisitions, the ConOps may not be formalized, but rather implied by other business concepts and/or strategies. The OpsCon is prepared at the business level. Business management begins with the preparation of the preliminary OpsCon, which summarizes business needs from an operational perspective for the solution classes that address the problem or opportunity. The preliminary OpsCon is then elaborated and refined by business operations into the OpsCon by engagement with the nominated stakeholders during the stakeholder needs 51 and requirements definition process—the final OpsCon therefore contains both the business needs and the stakeholder needs. The OpsCon may be iteratively refined as a result of feedback obtained through the conduct of the system requirements definition and architecture definition processes. 4.1.2.3 Other Life Cycle Concepts The OpsCon is just one of the life cycle concepts required to address the stakeholder needs across the system life cycle. Preliminary concepts are established in the business or mission analysis process to the extent needed to define the problem or opportunity space and characterize the solution space. These concepts are further refined in the stakeholder needs and requirements definition process. In addition to the operational aspects, other related life cycle concepts are required to address: r Acquisition concept—Describes the way the system will be acquired including aspects such as stakeholder engagement, requirements definition, design, production, and verification. The supplier enterprise(s) may need to develop more detailed concepts for production, assembly, verification, transport of system, and/or system elements. r Deployment concept—Describes the way the system will be validated, delivered, and introduced into operations, including deployment considerations when the system will be integrated with other systems that are in operation and/or replace any systems in operation. r Support concept—Describes the desired support infrastructure and manpower considerations for supporting the system after it is deployed. A support concept would address operating support, engineering support, maintenance support, supply support, and training support. r Retirement concept—Describes the way the system will be removed from operation and retired, including the disposal of any hazardous materials used in or resulting from the process and any legal obligations—for example, regarding IP rights protection, any external financial/ownership interests, and national security concerns. 4.1.2.4 Business Requirements and Validation Specify business requirements—It is often helpful to specify business requirements as part of the business and For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 52 TECHNICAL PROCESSES mission analysis process. Business requirements are often contained in a BRS, which the Guide to the Business Analysis Body of Knowledge (IIBA, 2009) calls the business requirement document. The term “specification” has some variation in use in various industries, but it is used here to be synonymous with “document”—that is, business requirements are captured in the BRS, stakeholder requirements in the StRS, and system requirements in the SyRS. Define business validation criteria The business must define how it will know that the solution provided will meet the OpsCon. Validation criteria establish critical and desired system performance—thresholds and objectives for system performance parameters that are critical for system success and those that are desired but may be subject to compromise to meet the critical parameters. 4.2 STAKEHOLDER NEEDS AND REQUIREMENTS DEFINITION PROCESS 4.2.1 4.2.1.1 Overview After identifying the stakeholders, this process elicits the stakeholder needs that correspond to a new or changed capability or new opportunity. These needs are analyzed and transformed into a set of stakeholder requirements for the operation and effects of the solution and its interaction with the operational and enabling environments. The stakeholder requirements are the primary reference against which the operational capability is validated. To achieve good results, systems engineers involve themselves in nearly every aspect of a project, pay close attention to interfaces where two or more systems or system elements work together, and establish an interaction network with stakeholders and other organizational units of the organization. Figure 4.3 shows the critical interactions for systems engineers. The stakeholder requirements govern the system’s development and are an essential factor in further defining or clarifying the scope of the development project. If an organization is acquiring the system, this process provides the basis for the technical description of the deliverables in an agreement—typically in the form of a system‐level specification and defined interfaces at the system boundaries. Figure 4.4 is the IPO diagram for the stakeholder needs and requirements definition process. Purpose As stated in ISO/IEC/IEEE 15288, [6.4.2.1] The purpose of the Stakeholder Needs and Requirements Definition process is to define the stakeholder requirements for a system that can provide the capabilities needed by users and other stakeholders in a defined environment. 4.2.1.2 Description Successful projects depend on meeting the needs and requirements of the stakeholders throughout the life cycle. A stakeholder is any entity (individual or organization) with a legitimate interest in the system. When nominating stakeholders, business management will take into account all those who may be affected by or able to influence the system—typically, they would consider users, operators, organization decision makers, parties to the agreement, regulatory bodies, developing agencies, support organizations, and society at large (within the context of the business and proposed solution). When direct contact is not possible, systems engineers find agents, such as marketing or nongovernmental organizations, to represent the concerns of a class of stakeholders, such as consumers or future generations. 4.2.1.3 Inputs/Outputs Inputs and outputs for the stakeholder needs and requirements definition process are listed in Figure 4.4. Descriptions of each input and output are provided in Appendix E. 4.2.1.4 Process Activities The stakeholder needs and requirements definition process includes the following activities: r Prepare for stakeholder needs and requirements definition. – Determine the stakeholders or classes of stakeholders who will participate with systems engineering to develop and define the stakeholder needs and translate these into system requirements, phased throughout the entire life cycle. Capture these results in the ConOps. – Determine the need for and requirements of any enabling systems, products, or services. r Define stakeholder needs. – Elicit stakeholder needs from the identified stakeholders. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. Project management and control Production management Product assurance, quality and safety FIGURE 4.3 reserved. Business engineering and procurement Systems engineering environment Stakeholders, customers, markets Interfaces–involvement interaction Operations, maintenance, servicing Software/ hardware engineering Key SE interactions. From Stoewer (2005). Figure reprinted with permission from Heinz Stoewer. All other rights Controls Inputs • Source documents • Project constraints • Major stakeholders identification • Preliminary life cycle concepts • Problem or opportunity statement • Business requirements • Alternative solution classes • Preliminary validation criteria • Validated requirements • Preliminary MOE needs • Preliminary MOE data • Business requirements traceability • Life cycle constraints • Stakeholder needs • System requirements traceability Activities • Prepare for stakeholder needs and requirements definition • Define stakeholder needs • Develop the operational concept and other life cycle concepts • Transform stakeholder needs into stakeholder requirements • Analyze stakeholder requirements • Manage the stakeholder needs and requirements definition Outputs • Stakeholder needs and requirements definition strategy • Life cycle concepts • System function identification • Stakeholder requirements • Validation criteria • MOE needs • MOE data • Stakeholder requirements traceability • Initial RVTM • Stakeholder needs and requirements definition record Enablers FIGURE 4.4 IPO diagram for stakeholder needs and requirements definition process. INCOSE SEH original figure created by Shortell and Walden. Usage per the INCOSE Notices page. All other rights reserved. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 54 TECHNICAL PROCESSES – Prioritize the stakeholder needs to identify which to focus on. – Specify the stakeholder needs. r Develop the operational concept and other life cycle concepts. – Identify the expected set of operational scenarios and associated capabilities, behaviors, and responses of the system or solution and environments across the life cycle (in acquisition, deployment, operations, support, and retirement). The scenarios are built to define the life cycle concept documents; the range of anticipated uses of system products; the intended operational environment and the systems’ impact on the environment; and interfacing systems, platforms, or products. Scenarios help identify requirements that might otherwise be overlooked. Social and organizational influences also emerge from using scenarios. – Define the interactions of the system or solution with the users and the operating, support, and enabling environments. r Transform stakeholder needs into stakeholder requirements. – Identify constraints on the solution (imposed by agreements or interfaces with legacy or interoperating systems). The constraints need to be monitored for any interface changes (external or internal) that could alter the nature of the constraint. – Specify health, safety, security, environment, assurance, and other stakeholder requirements and functions that relate to critical qualities. – Specify stakeholder requirements, consistent with scenarios, interactions, constraints, and critical qualities. r Analyze stakeholder requirements. – Define validation criteria for stakeholder requirements. Stakeholder validation criteria include measures of effectiveness (MOEs) and measures of suitability (MOSs), which are the “operational” measures of success that are closely related to the achievement of the mission or operational objective being evaluated, in the intended operational environment under a specified set of conditions (i.e., how well the solution achieves the intended purpose). These measures reflect overall customer/user satisfaction (e.g., performance, safety, reliability, availability, maintainability, and workload requirements). – Analyze the set of requirements for clarity, completeness, and consistency. Include review of the analyzed requirements to the applicable stakeholders to ensure the requirements reflect their needs and expectations. – Negotiate modifications to resolve unrealizable or impractical requirements. r Manage the stakeholder needs and requirements definition. – Establish with stakeholders that their requirements are expressed correctly. – Record stakeholder requirements in a form suitable for maintenance throughout the system life cycle (and beyond for historical or archival purposes). – Establish and maintain through the life cycle a traceability of stakeholder needs and requirements (e.g., to the stakeholders, other sources, organizational strategy, and business or mission analysis results). – Provide baseline information for configuration management. 4.2.2 Elaboration Within the context of ISO/IEC/IEEE 15288, requirements (business, stakeholder, and system) are drivers for the majority of the system life cycle processes. Depending on the system development model, stakeholder requirements capture should be conducted nominally once near the beginning of the development cycle or as a continuous activity. Regardless, the reason for eliciting and analyzing requirements is the same—understand the needs of the stakeholders well enough to support the architecture definition and design definition processes. 4.2.2.1 Identify Stakeholders Systems engineers engage with legitimate stakeholders of the system. The major stakeholders at the business management level will have been nominated during the business or mission analysis process—here, systems engineers are interested in identifying stakeholders from the business operations level. One of the biggest challenges in system development is the identification of the set of stakeholders from whom For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. STAKEHOLDER NEEDS AND REQUIREMENTS DEFINITION PROCESS requirements should be elicited. Customers and eventual end users are relatively easy to identify, but regulatory agencies and other interested parties that may reap the consequences of the deployed system should also be sought out and heard. Stakeholders can include the stakeholders of interoperating systems and enabling systems as these will usually impose constraints that need to be identified and considered. In sustainable development, this includes finding representation for future generations. 4.2.2.2 Elicit Stakeholder Needs Determining stakeholder needs requires the integration of a number of disparate views, which may not necessarily be harmonious. As the SE process is applied, a common paradigm for examining and prioritizing available information and determining the value of added information should be created. Each of the stakeholder’s views of the needed systems can be translated to a common top‐level system description that is understood by all participants, and all decision‐making activities recorded for future examination. Under some circumstances, it may not be practical to elicit needs from the stakeholder but rather from the marketing organization or other surrogates. There may be stakeholders who oppose the system. These stakeholders or detractors of the system are first considered in establishing consensus needs. Beyond this, they are addressed through the risk management process, the threat analysis of the system, or the system requirements for security, adaptability, or resilience. Systems engineering should support program and project management in defining what must be done and gathering the information, personnel, and analysis tools to elaborate the business requirements. This includes gathering stakeholder needs, system/project constraints (e.g., costs, technology limitations, and applicable specifications/legal requirements), and system/project “drivers,” such as capabilities of the competition, military threats, and critical environments. The outputs of the stakeholder needs and requirements definition process should be sufficient definition of the business and stakeholder needs and requirements to gain authorization and funding for program initiation through the portfolio management process. The output should also provide necessary technical definition to the acquisition process to generate a request for proposal (RFP) if the system is to be acquired through a contract acquisition process or to gain authorization to develop 55 and market the system if market driven. These outputs can be captured in life cycle concept documents (particularly the OpsCon) and the StRS, which often are used to support the generation of a statement of work (SOW), and/or an RFP, both of which are artifacts of the acquisition process. Contributing users rely on well‐defined completion criteria to indicate the successful definition of user and stakeholder needs: r User organizations have gained authorization for new system acquisition. r Program development organizations have prepared a SOW, StRS, and gained approval for new system acquisition. If they are going to use support from outside the company, they have issued an RFP and selected a contractor. r Potential contractors have influenced the acquisition needs, submitted a proposal, and have been selected to develop and deliver the system. r If the system is market driven, the marketing group has learned what consumers want to buy. For expensive items (e.g., aircraft), they have obtained orders for the new systems. r If the system is market and technology driven, the development team has obtained approval to develop the new system from the corporation. Since requirements come from multiple sources, eliciting and capturing requirements constitutes a significant effort on the part of the systems engineer. The OpsCon describes the intended operation of the system to be developed and helps the systems engineer understand the context within which requirements need to be captured and defined. Techniques for requirements elicitation include interviews, focus groups, the Delphi method, and soft systems methodology, to name a few. Trade‐off analysis and simulation tools can also be used to evaluate mission operational alternatives and select the desired mission alternative. Tools for capturing and managing requirements are many and varied. The source requirements captured by carrying out this activity are only a portion of the total stakeholder requirements. As such, source requirements will be expanded by a number of activities designed to break down the broad requirement statements and reveal the need for additional clarification, which will lead to either revision of the written source material or additional source documents, such as meeting minutes. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 56 TECHNICAL PROCESSES 4.2.2.3 Initialize the Requirements Database It is essential to establish a database of baseline requirements traceable to the source needs (and subsequently to system requirements) to serve as a foundation for later refinement and/or revision by subsequent activities in the SE process. The requirements database must first be populated with the source documents that provide the basis for the total set of system requirements that will govern its design. 4.2.2.4 Develop the Life Cycle Concepts The word “scenario” is often used to describe a single thread of behavior; in other cases, it describes a superset of many single threads operating concurrently. Scenarios and what‐if thinking are essential tools for planners who must cope with the uncertainty of the future. Scenario thinking can be traced back to the writings of early philosophers, such as Plato and Seneca (Heijden et al., 2002). As a strategic planning tool, scenario techniques have been employed by military strategists throughout history. Building scenarios serves as a methodology for planning and decision making in complex and uncertain environments. The exercise makes people think in a creative way, observations emerge that reduce the chances of overlooking important factors, and the act of creating the scenarios enhances communications within and between organizations. Scenario building is an essentially human activity that may involve interviews with operators of current/similar systems, potential end users, and meetings of an Interface Working Group (IFWG). The results of this exercise can be captured in many graphical forms using modeling tools and simulations. Creation or upgrade of a system shares the same uncertainty regarding future use and emergent properties of the system. The stakeholder needs and requirements definition process captures the understanding of stakeholder needs in a series of life cycle concept documents, each focused on a specific life cycle stage: acquisition concept, deployment concept, OpsCon, support concept, and retirement concept. Each of these categories of life cycle concepts is discussed in Section 4.1.2.3. A primary goal of a concept document is to capture, early in the system life cycle, an implementation‐free understanding of stakeholder needs by defining what is needed, without addressing how to satisfy the need. It captures behavioral characteristics required of the system in the context of other systems with which it interfaces, and captures the manner in which people will interact with the system for which the system must provide capabilities. Understanding these operational needs typically produces: r A source of specific and derived requirements that meet the needs and objectives of the customer and user r Invaluable insight for SE and designers as they define design, develop, verify, and validate the system r Diminished risk of latent system defects in the delivered operational systems If the system is for a military customer, there may be several required views of the system driven by architectural frameworks. These are defined, for example, in the US Department of Defense Architecture Framework (DoDAF, 2010) and in the UK Ministry of Defense Architecture Framework (MoDAF, n.d.) (OMG, 2013a). The primary objective is to communicate with the end user of the system during the early specification stages to ensure that stakeholder needs (particularly the operational needs) are clearly understood and the rationale for performance requirements is incorporated into the decision mechanism for later inclusion in the system requirements and lower‐level specifications. Interviews with operators of current/similar systems, potential users, interface meetings, IPO diagrams, functional flow block diagrams (FFBD), timeline charts, and N2 charts provide valuable stakeholder input toward establishing a concept consistent with stakeholder needs. Other objectives are as follows: 1. To provide traceability between operational needs and the captured source requirements 2. To establish a basis for requirements to support the system over its life, such as personnel requirements, support requirements, etc. 3. To establish a basis for verification planning, system‐level verification requirements, and any requirements for environmental simulators 4. To generate operational analysis models to test the validity of external interfaces between the system and its environment, including interactions with external systems 5. To provide the basis for computation of system capacity, behavior under‐/overload, and mission‐ effectiveness calculations For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. SYSTEM REQUIREMENTS DEFINITION PROCESS 6. To validate requirements at all levels and to discover implicit requirements overlooked from other sources Since the preliminary life cycle concepts have provided a broad description of system behavior, a starting point for further developing the concept is to begin by identifying outputs generated by external systems (modified as appropriate by passing through the natural system environment), which act as stimuli to the SOI and cause it to take specified actions and produce outputs, which in turn are absorbed by external systems. These single threads of behavior eventually cover every aspect of operational performance, including logistical modes of operation, operation under designated conditions, and behavior required when experiencing mutual interference with multiobject systems. Aggregation of these single threads of behavior represents a dynamic statement of what the system is required to do and how it is to be acquired, deployed, operated, supported, and retired. No attempt is made at this stage to define a complete OpsCon or to allocate functions to hardware or software elements (this comes later during architectural design). The life cycle concepts are essentially definitions of the functional concepts and rationale from the stakeholder perspective. The life cycle concepts are further developed as follows: 1. Start with the source operational requirements; deduce a set of statements describing the higher‐ level, mission‐oriented needs. 2. Review the system needs with stakeholders and record the conflicts. 3. Define and model the operational boundaries. 4. For each model, generate a context diagram to represent the model boundary. 5. Identify all of the possible types of observable input and output events that can occur between the system and its interacting external systems. 6. If the inputs/outputs are expected to be significantly affected by the environment between the system and the external systems, add concurrent functions to the IPO diagram to represent these transformations and add input and output events to the database to account for the differences in event timing between when an output is emitted and when an input is received. 57 7. Record the existence of a system interface between the system and the environment or external system. 8. For each class of interaction between a part of the system and an external system, create a functional flow diagram to model the sequence of interactions as triggered by the stimuli events generated by the external systems. 9. Add information to trace the function timing from performance requirements and simulate the timing of the functional flow diagrams to confirm operational correctness or to expose dynamic inconsistencies. Review results with users and operational personnel. 10. Develop timelines, approved by end users, to supplement the source requirements. 4.2.2.5 Generate the StRS A draft StRS should be generated to formally represent the stakeholder requirements. The StRS should be traceable to the stakeholder needs and to the BRS. 4.3 SYSTEM REQUIREMENTS DEFINITION PROCESS 4.3.1 4.3.1.1 Overview Purpose As stated in ISO/IEC/IEEE 15288, [6.4.3.1] The purpose of the System Requirements Definition process is to transform the stakeholder, user‐ oriented view of desired capabilities into a technical view of a solution that meets the operational needs of the user. 4.3.1.2 Description System requirements are the foundation of the system definition and form the basis for the architecture, design, integration, and verification. Each requirement carries a cost. It is therefore essential that a complete but minimum set of requirements be established from defined stakeholder requirements early in the project life cycle. Changes in requirements later in the development cycle can have a significant cost impact on the project, possibly resulting in cancellation. The system requirements definition process generates a set of system requirements from the supplier’s perspective using the stakeholder requirements that reflect the user’s perspective as the basis. The system For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 58 TECHNICAL PROCESSES requirements specify the system characteristics, attributes, functions, and performance that will meet the stakeholder requirements. Requirements definition is both iterative and recursive (see Section 3.4.1). According to ISO/IEC/IEEE 29148, Requirements engineering (2011), system in the system structure to arrive at a more detailed or mature set of outcomes. Such an approach adds value to successive systems in the system structure. When the application of the same process or set of processes is repeated on the same level of the system, the application is referred to as iterative. Iteration is not only appropriate but also expected. New information is created by the application of a process or set of processes. Typically this information takes the form of questions with respect to requirements, analyzed risks or opportunities. Such questions should be resolved before completing the activities of a process or set of processes. Thus, iteration between this process and others is expected as more information is available and analysis is performed. This process continues to be recursively applied to define the requirements for each system element. The output of the process must be compared for traceability to and consistency with the stakeholder requirements, without introducing implementation biases, before being used to drive the architecture definition process. The system requirements definition process adds the verification criteria to the defined system requirements. Figure 4.5 is the IPO diagram for the system requirements definition process. When the same set of processes or the same set of process activities are applied to successive levels of system elements within the system structure, the application form is referred to as recursive. The outcomes from one application are used as inputs to the next lower (or higher) 4.3.1.3 Inputs/Outputs Inputs and outputs for the system requirements definition process are listed in Figure 4.5. Descriptions of each input and output are provided in Appendix E. Controls Inputs • Life cycle concepts • System function identification • Stakeholder requirements • Stakeholder requirements traceability • Initial RVTM • Architecture traceability • Final RVTM • Life cycle constraints Activities • Prepare for system requirements definition • Define system requirements • Analyze system requirements • Manage system requirements Outputs • System requirements definition strategy • System function definition • System requirements • System functional interface identification • Verification criteria • MOP needs • MOP data • System requirements traceability • Updated RVTM • System requirements definition record Enablers FIGURE 4.5 IPO diagram for the system requirements definition process. INCOSE SEH original figure created by Shortell and Walden. Usage per the INCOSE Notices page. All other rights reserved. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. SYSTEM REQUIREMENTS DEFINITION PROCESS 4.3.1.4 Process Activities The system requirements definition process includes the following activities: r Prepare for system requirements definition. – Establish the approach for defining the system requirements. This includes system requirements methods, tools, and the need for and requirements of any enabling systems, products, or services. – In conjunction with the architecture definition process, determine the system boundary, including the interfaces, that reflects the operational scenarios and expected system behaviors. This task includes identification of expected interactions of the system with systems external to the system (control) boundary as defined in negotiated interface control documents (ICDs). r Define system requirements. – Identify and define the required system functions. These functions should be kept implementation independent, not imposing additional design constraints. Define conditions or design factors that facilitate and foster efficient and cost‐effective life cycle functions (e.g., acquisition, deployment, operation, support, and retirement). Also, include the system behavior characteristics. – Identify the stakeholder requirements or organizational limitations that impose unavoidable constraints on the system and capture those constraints. – Identify the critical quality characteristics that are relevant to the system, such as safety, security, reliability, and supportability. – Identify the technical risks that need to be accounted for in the system requirements. – Specify system requirements, consistent with stakeholder requirements, functional boundaries, functions, constraints, critical performance measures, critical quality characteristics, and risks. System requirements may be captured in the SyRS. Additionally, a documentation tree may be developed to define the hierarchy of system definition products being developed. The documentation tree evolves with the interaction of the system requirements definition, architecture definition, and design definition processes. Capture the associated rationale, as the requirements are specified. 59 r Analyze system requirements. – Analyze the integrity of the system requirements to ensure that each requirement or set of requirements possess overall integrity. (See Section 4.3.2.2 for characteristics of a good requirement or set of requirements.) – Provide analysis results to applicable stakeholders to ensure that the specified system requirements adequately reflect the stakeholder requirements. – Negotiate modifications to resolve issues identified in the requirements. – Define verification criteria—critical performance measures that enable the assessment of technical achievement. System verification criteria include measures of performance (MOPs) and technical performance measures (TPMs), which are the “implementation” measures of success that should be traceable to the MOEs and MOSs (operational perspective) with the relationships defined. r Manage system requirements. – Ensure agreement among key stakeholders that the requirements adequately reflect the stakeholder intentions. – Establish and maintain traceability between the system requirements and the relevant elements of the system definition (e.g., stakeholder requirements, architecture elements, interface definitions, analysis results, verification methods or techniques, and allocated, decomposed, and derived requirements.) – Maintain throughout the system life cycle the set of system requirements together with the associated rationale, decisions, and assumptions. – Provide baseline information for configuration management. 4.3.2 Elaboration This section elaborates and provides “how‐to” information on the requirements analysis and management. Other key information on requirements can be found in ISO/ IEC TR 19760, Systems engineering—A guide to the application of ISO/IEC 15288 (2003), and ISO/IEC/IEEE 29148, Requirements engineering (2011), and in EIA 632, Standard—Processes for engineering a system For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 60 TECHNICAL PROCESSES (ANSI/EIA, 2003), Requirements 14, 15, and 16, and Annex C3.1 a, b, and c. 4.3.2.1 Requirements Definition and Analysis Concepts Requirements definition and analysis, like the set of SE processes, is an iterative activity in which new requirements are identified and constantly refined as the concept develops and additional details become known. The requirements are analyzed, and deficiencies and cost drivers are identified and reviewed with the customer to establish a requirements baseline for the project. An objective of requirements analysis is to provide an understanding of the interactions between the various functions and to obtain a balanced set of requirements based on user objectives. Requirements are not developed in a vacuum. An essential part of the requirements development process is the OpsCon, the implicit design concept that accompanies it, and associated demands of relevant technology. Requirements come from a variety of sources, including the customer/users, regulations/codes, and corporate entities. This complex process employs performance analysis, trade studies, constraint evaluation, and cost– benefit analysis. System requirements cannot be established without determining their impact (achievability) on lower‐level elements. Therefore, requirements definition and analysis is an iteration and balancing process that works both “top‐down” (called allocation and flowdown) and “bottom‐up.” Once the top‐level set of system requirements has been established, it is necessary to allocate and flow them down to successively lower levels. As the allocation and flowdown process is repeated, it is essential that traceability be maintained to ensure that all system‐ level requirements are satisfied in the resulting design. The resulting requirements database usually contains many attributes for each requirement and is also used in verification. Although it is an objective to avoid requirements that constrain or define aspects of the system implementation, it is not always possible. There are often necessary constraints that need to be reflected. This includes the following: r Standards—Identify standards required to meet quality or design considerations imposed as defined stakeholder requirements or derived to meet organization, industry, or domain requirements. r Utilization environments—Identify the utilization environments and all environmental factors (natural or induced) that may affect system performance, impact human comfort or safety, or cause human error for each of the operational scenarios envisioned for system use. r Essential design considerations—Identify design considerations including human systems integration (e.g., manpower, personnel, training, environment, safety, occupational health, survivability, habitability), system security requirements (e.g., information assurance, antitamper provisions), and potential environmental impact. r Design constraints—Identify design constraints including physical limitations (e.g., weight, form/fit factors), manpower, personnel, and other resource constraints on operation of the system and defined interfaces with host platforms and interacting systems external to the system boundary, including supply, maintenance, and training infrastructures. 4.3.2.2 Characteristics and Attributes of Good Requirements In defining requirements, care should be exercised to ensure the requirement is appropriately crafted. The following characteristics should be considered for every requirement based on ISO/IEC/IEEE 29148, Systems and software engineering—Life cycle processes—Requirements engineering (2011), and the INCOSE Guide for Writing Requirements (INCOSE RWG, 2012): r Necessary—Every requirement generates extra effort in the form of processing, maintenance, and verification. Only necessary requirements should therefore be included in specifications. Unnecessary requirements are of two varieties: (i) unnecessary specification of design, which should be left to the discretion of the designer, and (ii) a redundant requirement covered in some other combination of requirements. r Implementation independent—Customer requirements may be imposed at any level they desire; however, when customer requirements specify design, it should be questioned. A proper requirement should deal with the entity being specified as a “black box” by describing what transformation is to be performed by the “box.” The requirement should specify “what” For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. SYSTEM REQUIREMENTS DEFINITION PROCESS r r r r r is to be done at that level, not “how” it is to be done at that level. Unambiguous—Requirements must convey what is to be done to the next level of development. Its key purpose is to communicate. Is the requirement clear and concise? Is it possible to interpret the requirement in multiple ways? Are the terms defined? Does the requirement conflict with or contradict another requirement? Each requirement statement should be written to address one and only one concept. Requirements with “and,” “or,” “commas,” or other forms of redundancy can be difficult to verify and should be avoided as it can be difficult to ensure all personnel have a common understanding. Requirements must therefore be written with extreme care. The language used must be clear, exact, and in sufficient detail to meet all reasonable interpretations. A glossary should be used to precisely define often‐used terms or terms, such as “process,” that could have multiple interpretations. Complete—The stated requirement should be complete and measurable and not need further amplification. The stated requirement should provide sufficient capability or characteristics. Singular—The requirement statement should be of only one requirement and should not be a combination of requirements or more than one function or constraint. Achievable—The requirement must be technically achievable within constraints and requires advances in technology within acceptable risk. It is best if the implementing developer participate in requirements definition. The developer should have the expertise to assess the achievability of the requirements. In the case of items to be subcontracted, the expertise of potential subcontractors is very valuable in the generation of the requirements. Additionally, participation by manufacturing and customers/users can help ensure achievable requirements. When it is not possible to have the right mix of developer, subcontractor, and/or manufacturing expertise during the requirements generation, it is important to have their review at the first point possible to ensure achievability. Verifiable—Each requirement must be verified at some level by one of the four standard methods (inspection, analysis, demonstration, or test). A 61 customer may specify, “The range shall be as long as possible.” This is a valid but unverifiable requirement. This type of requirement is a signal that a trade study is needed to establish a verifiable maximum range requirement. Each verification requirement should be verifiable by a single method. A requirement requiring multiple methods to verify should be broken into multiple requirements. There is no problem with one method verifying multiple requirements; however, it indicates a potential for consolidating requirements. When the system hierarchy is properly designed, each level of specification has a corresponding level of verification during the verification stage. If element specifications are required to appropriately specify the system, element verification should be performed. r Conforming—In many instances, there are applicable government, industry, and product standards, specifications, and interfaces with which compliance is required. An example might be additional requirements placed on new software developments for possible reusability. Another might be standard test interface connectors for certain product classes. In addition, the individual requirements should conform to the organization’s standard template and style for writing requirements—when all requirements within the same organization have the same look and feel, each requirement is easier to write, understand, and review. Note: ISO/IEC/IEEE 29148 uses the term “consistent” instead of “conforming,” stating that the requirement must be free of conflicts with other requirements. While that is correct, a requirement cannot, in and of itself, be consistent—consistency is more correctly a characteristic of the set of requirements (as described in the following paragraph). In addition to the characteristics of individual requirements, the characteristics of a set of requirements as a whole should be addressed to ensure that the set of requirements collectively provides for a feasible solution that meets the stakeholder intentions and constraints. These include: r Complete—The set of requirements contains everything pertinent to the definition of system or system element being specified. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 62 TECHNICAL PROCESSES r Consistent—The set of requirements is consistent in that the requirements are not contradictory nor duplicated. Terms and abbreviations are used consistently in all requirements, in accordance with the glossary. r Feasible/affordable—The set of requirements can be satisfied by a solution that is obtainable within LCC, schedule, and technical constraints. Note: ISO/IEC/IEEE 29148 uses the term “affordable” instead of “feasible,” stating that the set of requirements are feasible within the life cycle constraints of cost, schedule, technical, and regulatory. The INCOSE Guide for Writing Requirements (INCOSE RWG, 2012) includes the word “feasible,” stating that “Feasible/Affordable is a more appropriate title for this characteristic of the requirement set.” r Bounded—The set of requirements define the required scope for the solution to meet the stakeholder needs. Consequently, all necessary requirements must be included; irrelevant requirements must be excluded. r r r In addition to the characteristics listed above, individual requirement statements may have a number of attributes attached to them (either as fields in a database or through relationships with other artifacts): r Trace to parent—A child requirement is one that has been derived or decomposed from the parent— the achievement of all the children requirements will lead to the achievement of the parent requirement. Each of the children requirements must be able to be traced to its parent requirement (and thence to any antecedent requirement and ultimately to the system need/mission). r Trace to source—Each requirement must be able to be traced to its source—this is different from tracing to a parent because it identifies where the requirement came from and/or how it was arrived at (rather than which other requirement is its parent). r Trace to interface definition—The interactions between two systems are described in interface definitions that are often contained in a document that has