Life Cycle Processes and Enterprise Need
Lead Author: Rick Adcock
The Generic Life Cycle Model describes a simple translation from a need to achieve an outcome to a proposal to realize a new or modified engineered system. This then forms the basis for the decision to invest time, money and other resources in the life cycle of that system-of-interest (SoI). A significant proportion of the SE activities involved in this transformation involve varying levels and types of requirements.
Requirements and Life Cycle
During the concept definition stage of a life cycle, as the enterprise identifies new capabilities that are desired, the business or mission analysis develops a high level set of strategies and needs (which may be expressed as mission or business requirements) that reflect the problem space perspective. As the solution space is explored and solution classes are characterized, stakeholder needs are developed and transformed into stakeholder requirements (from a user perspective). After the solution class has been determined and the specific solution is sought, during the system definition stage of a life cycle, the stakeholder requirements are transformed into system requirements (from a solution perspective). As the system definition recursively defines the lower level detail of the solution, requirements are defined with lower levels of abstraction. At the highest level, the ideal requirement is implementation-independent, and therefore not specific to a solution, allowing for a range of possible solutions. At the lowest level, requirement statements may become more specific to the selected solution.
Concept Definition has further descriptions of business or enterprise and stakeholder needs and requirements. It discusses how the new capability for the business or enterprise is defined as part of the understanding of the problem space. It also discusses the development of the stakeholder needs and their transformation into requirements from the user perspective.
System Definition has further descriptions of requirements and their types (e.g. system requirement, stakeholder requirement, derived requirement). It discusses how different process roles/states, levels, and the nature of requirements apply to the understanding of requirements.
Transforming Enterprise Needs to Requirements
Needs and requirements can exist at a number of levels and the terminology used to describe these levels will vary between application domains and the enterprises which serve them. This can make it difficult to associate generic SE life cycle processes with them. Ryan (2013) proposes a generic model (see Figure 1) in which an enterprise of some kind forms a focus for translating strategic intentions into a system definition. There is an enterprise view in which enterprise leadership sets the enterprise strategies, concepts and plans; a business management view in which business management derives business needs and constraints as well as formalizes their requirements; a business operations view in which stakeholders define their needs and requirements. In the systems view, an engineered system is defined, expanding to views at the lower level of system elements if needed. Note that an engineered system may comprise a number of elements including products, people, and processes. A system architecture can be created to define logical and physical views of how these elements together enable a needed capability for the organization.
In the following discussion, Ryan further defines a set of general terminology to define levels of need and requirements and associates them with generic organizational roles. For a discussion of how this general description might map onto different application contexts or organizational structures, see Part 4 and Part 5 respectively.
The various views in Figure 1 are referred to as layers. At the highest layer, the enterprise has a number of strategies that will guide its future. In the illustration above, for example, a system has its genesis in a Concept of Operations (ConOps) or Strategic Business Plan (SBP) that communicates the leadership’s intentions with regard to the operation of the organization in terms of existing systems and systems to be developed. At this layer the ConOps or SBP defines the enterprise in terms of ‘brand’ and establishes a mission statement and corresponding goals and objectives, which clearly state the reason for the enterprise and its strategy for moving forward.
The Business or Mission Analysis Process begins with the organization’s mission or vision statement, goals and objectives communicated by the ConOps or SBP. Business management uses this guidance to define business needs, largely in the form of life-cycle concepts, which capture the business management’s concepts for acquisition, development, marketing, operations, deployment, support, and retirement. These concepts are then used to define specific needs for that layer.
The business needs contained in the life-cycle concepts are elaborated and formalized into business requirements, which are documented in the Business Requirements Specification (BRS) or Business Requirement Document (BRD). The process by which business needs are transformed into business requirements is called mission analysis or business analysis.
Once business management is satisfied their needs and requirements are reasonably complete, they pass them on to the business operations layer. Here, the Stakeholder Needs and Requirements (SNR) Definition Process uses the ConOps or SBP and concepts contained in the life-cycle concepts as guidance. The Requirements Engineer (RE) or Business Analyst (BA) leads stakeholders from the business operations layer through a structured process to elicit stakeholder needs—in the form of a refined OpsCon or similar document and other life-cycle concepts (see Figure 1). The RE or BA uses a structured process to elicit specific needs, as documented in user stories, use cases, scenarios, system concepts, or operational concepts. For further discussion of the Concept of Operations and the Operational Concept Document, and their interplay, see ANSI/AIAA G-043-2012e, Guide to the Preparation of Operational Concept Documents.
Stakeholder needs are then transformed into a formal set of Stakeholder Requirements, which are documented in the Stakeholder Requirement Specification (StRS) or Stakeholder Requirement Document (StRD). That transformation is guided by a well-defined, repeatable, rigorous, and documented process of requirements analysis. This requirements analysis may involve the use of functional flow diagrams, timeline analysis, N2 Diagrams, design reference missions, modeling and simulations, movies, pictures, states and modes analysis, fault tree analysis, failure modes and effects analysis, and trade studies. In some cases, these requirements analysis methods may make use of views created as part of a high level logical architecture.
At the system layer, in the System Requirements Definition Process, the requirements in the StRS are then transformed by the RE or BA into System Requirements, which are documented in the System Requirement Specification (SyRS) or System Requirement Document (SyRD). As in the previous process, the RE or BA accomplishes the transformation of needs into requirements using the same requirements analysis methods described above to define the requirements. At each layer, the resulting requirements will be documented, agreed-to, baselined, and put under configuration management. As above, the system requirements analysis may also be linked to appropriate logical and physical architecture, either informally or under shared configuration control. Note that some organizations may prepare individual life-cycle concepts for each of a number of systems that are developed to meet the business needs.
Once a set of requirements has been documented, agreed-to, and baselined at one layer, they will flow down to the next layer as shown in Figure 1. At the next layer, the requirements are a result of the transformation process of the needs at that layer as well a result of the decomposition or derivation of the requirements from the previous layer. As such, a number of SyRS or SyRD requirements may be either decomposed from (that is, made explicit by the requirements of) or derived from (that is, implied by the requirements of) the StRS or StRD. The same is true at the subsystem or system element layer, where a number of the subsystem or system element requirements may be either decomposed or derived from the SyRS or SyRD. In all cases, for each layer shown in Figure 1, the set of requirements can be traced back to the requirements at the previous layer from which they were either decomposed or derived. This process continues for the next layer of system elements.
How requirements are expressed differs through these layers, and therefore so do the rules for expressing them. As requirements are developed – and solutions designed – down through the layers of abstraction, we expect statements of requirement to become more and more specific. At the highest level, the ideal requirement is not specific to a particular solution and permits a range of possible solutions. At the lowest level, statements of requirement will be entirely specific to the selected solution. It is important to note that the form of requirements at one layer may not be appropriate for another layer. For example, at the business management layer, there may be a requirement that all products are “safe”. While this is a poor system requirement, it is appropriate for the Business Management layer. At the next layer, business operations, there will be less ambiguous and more detailed requirements that define “safe.” These requirements apply across all product lines. At the system layer, more specific safety requirements will be developed for that specific system. These requirements will then be allocated to the system elements at the next lower layer.
References
Works Cited
Guide to the Preparation of Operational Concept Documents, ANSI/AIAA G-043-2012e.
Dick, J. and J. Chard, “The systems engineering sandwich: Combining requirements, models and design,” INCOSE International Symposium IS2004, July 2004.
Hull, E., K. Jackson, J. Dick, Requirements Engineering, Silver Spring, MD, USA: Springer, 2010.
Ryan, M.J., “An improved taxonomy for major needs and requirements artefacts”, INCOSE International Symposium IS2013, June 2013.
Primary References
Hull, E., K. Jackson, J. Dick, Requirements Engineering, Silver Spring, MD, USA: Springer, 2010.
Ryan, M.J., “An improved taxonomy for major needs and requirements artefacts,” INCOSE International Symposium IS2013, June 2013.
Additional References
None.