6.3 Requirements Analysis

Requirements Analysis starts with the inputs defined in Section 6.2 of the previous post and analyzes the mission and associated environments to establish a Requirements Database.  Figure 6.4 in the second previous post shows that the Requirements Analysis Task is carried out iteratively with Functional Analysis/Allocation, with Technical Management and with Verification tasks. The NASA and IEEE handbooks define the subtasks of Requirements Analysis with flowcharts. The DoD SEF lists the 15 subtasks named in the IEEE flowchart and provides a description of each. Figure 6.5 below is a streamlined version of the IEEE flowchart; listing the 15 tasks using the IEEE and DoD SEF numbering. Several of the tasks are renamed to explicitly include analyzing the entire life cycle for environments, scenarios and modes rather than just those associated with the system in its operational mode. Task 13 is retitled from Technical Performance Measures (TPM) to broaden the scope to include TPMs, Key Performance Parameters (KPP) and any other metrics or Measures of Effectiveness (MOE) the team or customers believe are needed.

There are five types of requirements as defined in the DoD SEF:

•           Functional Requirements - The necessary task, action or activity that must be accomplished. Functional (what has to be done) requirements identified in requirements analysis will be used as the top level functions for functional analysis.

•           Performance Requirements - The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness.

•           Design Requirements - The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals.

•           Derived Requirements - Requirements that are implied or transformed from higher-level requirement.

•           Allocated Requirements - A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements.

The 15 tasks are structured so that all necessary requirements of each type are identified and documented in the Requirements Database. Each requirement must be traceable back to the input documentation or to a mission need derived from analyzing mission needs to ensure that no extraneous requirements are added.

The requirements analysis process is presented as a sequential process. These steps typically overlap and work previously completed may need to be adjusted as the detailed knowledge of all the requirements becomes more fully understood. Tasks are grouped in Figure 6-5 because the tasks in a group don’t need to be done in any specific order and some can be done in parallel. Tasks 1 to 9 and 12 to 15 analyze the system as a single entity. Tasks 10 and 11 begin the decomposition of the system into logical functional components (task 10) and begin to allocate performance parameters to these components (task 11). Tasks 10 and 11 feed directly into the Functional Analysis/Allocation and Systems Analysis tasks and receives information back from these associated tasks as indicated in the figure.

Executing the 15 tasks involves making many decisions and defining many relationships. As the many decisions are made and relationships are examined, it is critical that they are documented and tracked to facilitate updating tasks as new information is available.

Attempting to do requirements analysis without the use of supporting methods and diagrams is like trying to do math without equations and special symbols. It is possible but much more difficult and leads to more mistakes. The methods and diagrams selected for discussion in the following sections are not meant to be the only possible choices or a complete set; rather those presented are selected because they illustrate an important part of systems thinking or offer alternatives to conventional approaches covered in standard handbooks.

A principle behind offering alternatives is that when there are two ways to do a systems engineering task or two ways to present the results it is often beneficial to use both ways. This is because one offers a self-check on the other and some reviewers are able to critique one way better than another when the work is presented to peer reviewers. Once something is complete in one format or by using one tool repeating it in another format or with another tool takes little more time than carefully reviewing the accuracy of the first way and is much better at catching errors.

Inputs and Outputs for Defining a System

The tools and processes used to define the system via the steps of requirements analysis, functional analysis, design synthesis and verification can be divided into those that treat the system as a single element, i.e. treat the relationships and interfaces between the system and its environment and other entities; and those that decompose the system into subsystems and treat the relationships and interfaces between the subsystems.  (Verification is treated in a subsequent chapter as a systems engineering task called Verifying the Technical Performance.) Think of Figure 6-4 in the previous post being the process for a system as a single entity and then think of this process being repeatedly applied to each decomposed element of the system hierarchy.

The INCOSE Handbook defines a system hierarchy as:

• System
• Element
• Subsystem
• Assembly
• Subassembly
• Component
• Part

In this material the INCOSE hierarchy is followed with one exception; the term element is left out of the hierarchy and is used for which ever level of the hierarchy is being considered. That is the term design element refers to the system, subsystem, assembly, subassembly, component or part being analyzed or designed.

As elements become less complex the systems engineering work for each loop becomes less and less but does not vanish. For example, the functional analysis needed for a fastener is rudimentary but it is necessary to think through, if not document,  whether the fastener is required to maintain stability of the parts it is holding in three dimensions, allow translation in one or two dimensions or rotation around its axis. This is one of the reasons it is troublesome to distinguish between systems engineers and design engineers. The design engineers must execute the processes defined in Figure 6-4 to some degree depending on the complexity of the element they are designing.

Although a key methodology for requirements analysis, Use Case analysis is treated only lightly in this chapter. It is covered in more detail in a separate chapter because it is particularly important for supporting model based approaches. Assessment and management of risk is such an important technical management process that it is also treated in a subsequent chapter, as is the trade study task of selecting the preferred design.

It is hoped that the complexity of treating systems engineering processes via a different set of tasks rather than the obvious choice defined by the DoD diagram shown in Figure 6-4 is offset by the benefits to the reader of having to think about systems engineering in more than one way and that this will encourage thinking that may lead to new and better methods that will be needed in the future as systems continue to become more and more complex.

6.2 Inputs and Outputs of the Systems Engineering Process

Before beginning to describe the methods and tools used to execute each block and loop in the systems engineering process as defined in Figure 6-4 it is helpful to define the inputs to the overall process and the desired outputs.  A partial list of inputs is provided in Figures 3-1 and 4.2 of the DoD SEF. These inputs are partitioned into the three categories: Inputs to be converted to Outputs, Controls and Enablers. A more complete list of inputs in these three categories plus a fourth category of Constraints Imposed by Internal Resources includes:

• Inputs to be Converted to Outputs:
• Customer Needs/Objectives/Requirements (Part of The Voice of the Customer)
• Missions
• Measures of Effectiveness (MOE)
• Sys. Eng. Output Documentation (Patterns and Templates), Models, Simulations from Prior Development Efforts and from Internal Investments
• Controls:
• Technology Base available from Strategic Partners, Teammates, Suppliers and from Internal Investments
• Requirements Applied Through Specifications and Standards
• Laws and Organizational Policies and Procedures
• Customer Imposed Constraints (Budgets, Schedules, Documentation & Reporting Requirements, Other)
• Integration & Test and Utilization Environments
• Product/Competitive Strategies
• Program Decision Requirements (How the customer will make decisions; including which requirements are most important to the customer.)
• Enablers:
• Decision and Requirements Data Bases from Prior Development Efforts
• Multi-disciplinary Product Development Teams
• Development Organization’s Domain Knowledge
• Constraints Imposed by Internal Resources
• Engineering and Production Skills Availability
• Production Process Availability and Maturity
• Integration,  Test and Production Facilities and Capital Budget

This list does not include two items from Figure 4-2 of the DoD SEF. Maintenance Concept and Other Life-Cycle Function Planning is assumed here to be included in Customer Needs/Objectives/Requirements. System Analysis and Control is viewed here as part of the Systems Engineering Process rather than an enabler.

The list includes items contained in documentation supplied by the customer and items that are related to the organization’s capabilities. The inputs are usually incomplete in that there are requirements that are necessary but not initially known. These requirements must be derived during the systems engineering work. It is not unusual for the customer’s statement of needs, objectives and requirements to be incomplete, ambiguous or even contradictory when examined in detail.

As discussed in chapter 1 sometimes customers expect the development organization to complete the development of the input requirements, working closely with the customer, as part of the system development. Also, sometimes customers specify mission level requirements so that considerable systems analysis is needed to define system requirements that will satisfy the mission needs. Any constraints imposed by the enterprise’s product/competitive strategies and internal resources that impact the product design should be identified and documented in the IMP during the project planning. Finally, note that some of the items on the list are easily defined, e.g. specifications and the internal constraints listed, and some are not, e.g. the organization’s domain knowledge (Domain knowledge is the detailed knowledge of the customer’s mission and of the systems used to satisfy this mission).

The outputs of the systems engineering process are dependent on the level of the system hierarchy and include:

·         Baseline Design (System Specification, ICD, Functional Diagrams, & Physical Diagrams)

·         System Design Database

o   Requirements database

o   System Design Document (SDD) that captures Baseline Design Diagrams and:

§  Updated Information Architecture and Document Tree

§  Various diagrams, tables and matrices used to analyze, derive and verify requirements (e.g. context diagrams, Concept of Operation/Use Case diagrams and QFD tables)

§  TPMs, KPPs, MOEs for Baseline Design

§  Design Verification Plans

§  Failure Analysis Database

o   Configuration Management Database

o   Decision Database

o   Data Dictionary

·         Updated Pattern &Template Database

·         Expanded/Refined Models & Simulations

·         Updated Risk Register

·         Refined Technology Base Knowledge, including Updates to Qualified Supplier Capabilities

·         Updates to Manufacturing, System Integration and Test Process/Facility Plans

Some of the outputs are new documentation, some are updates to existing documentation/databases, some are updates or new data for organizations supporting the engineering team and some is captured only in the skills and domain knowledge of the development team. Comparing the list of inputs and outputs for the systems engineering process begins to reveal the breadth and depth of work and the thousands upon thousands of decisions being made in the systems engineering work. Without the use of modern methods and tools this work can be time consuming, expensive and error prone. Shortchanging this work often causes product design problems that are far more costly than thorough systems engineering and does not build the capabilities of the enterprise for future product developments.

The system design process is fundamentally a requirements analysis process even though it is divided into the tasks shown in Figure 6-4. The output requirements are expressed in three different ways or from three different perspectives as defined in the DoD SEF. These different perspectives are called the Operational, Functional and Physical views:

·         The Operational view describes the operational behavior of the system; how it does its job, how well and under what conditions.

·         The Functional view describes what the system must do to achieve the required operational behavior.

·         The Physical view describes how the system is constructed and how it interfaces with other systems and system operators.

The collection of documentation, diagrams, etc. developed under the Requirements Analysis task constitutes the Operational view. Similarly the products resulting from the Functional Analysis and Allocation task are the Functional view and the products resulting from the Design Synthesis task are the Physical view. Readers are referred to Chapter 4 of the DoD SEF for a listing of information that might typically be included in each view. Our emphasis here is on the rational for the systems engineering tasks and describing methods and tools useful in these tasks rather than trying to exhaustively list every task and every output.

Processes and Tools for Defining a System

6.0 Introduction - In Chapter 3 the product development cycle was defined in the simplest possible terms as “define, design, build, test and produce”. Four systems engineering tasks were defined to be carried out over the development cycle although there is not a one to one correspondence between the five steps in the development cycle and the four systems engineering tasks. Chapter 4 discussed processes and tools for the first systems engineering task, Plan the Program. This chapter addresses the second systems engineering task, Define the System. Chapters 8 and 9 address the remaining two tasks, Selecting the Preferred Design and Verifying the Technical Performance. After some introductory material this chapter and chapters 8 and 9 cover the systems engineering process as  described  in Figure 3-1 of the DoD SEF handbook. Because of the four task approach being followed in this text the flow does not follow the DoD systems engineering process step by step. However, this text follows the DoD nomenclature as much as possible and adds some useful tools. It is hoped that the reader studies both this text and the DoD SEF handbook and that, by studying the process in two different ways, gains deeper insight into systems engineering.

6.1 Overview of System Development and System Engineering Processes

System  development is a complex process and there are almost as many diagrams defining this process as there are handbooks of systems engineering. Before showing diagrams illustrating the Define the System task it is helpful to examine some of the more popular diagrams. Rather than repeat the detailed diagrams, which are available in the referenced handbooks, simplified diagrams are presented here that just show the approach to defining the development process or the systems engineering portion of the development process. The reader should always keep in mind the five fundamental steps of define, design, build, test and produce to keep oriented when examining these diagrams.

6.1.1System Development Diagrams - Perhaps the most popular diagram historically is the “VEE” diagram, which is shown in the NASA Systems Engineering Handbook SP610S of June 1995 and attributed to Kevin Forsberg and Harold Mooz, A Commitment to Success, Proceedings of the first annual meeting of the National Council for Systems Engineering and the 12th annual meeting of the American Society for Engineering Management, Chattanooga, TN, 20-23 October 1991. The VEE diagram describes the overall development process as a downward flow of decomposition and definition, connected to an upward flow of integration and verification as shown in the simplified diagram in Figure 6-1. The decomposition and definition starts at the top left with the “requirements analysis” task and ends with a tested system at the top right. This diagram is appealing because it illustrates both the “flow down” and “flow up” aspects and the sequential progress of the overall process with a rightward flow suggesting time or schedule. The time flow enables listing sequential tasks or design reviews along each leg of the V.

Figure 6-1 A VEE diagram illustrates tasks in two of the main activities of system development.

The 2007 version of the NASA handbook replaces the VEE with a more detailed diagram that adds the technical management and control aspects of the development process and changes some of the nomenclature. A simplified version of this diagram is shown in Figure 6-2. Although the 2007 diagram lacks some of the ascetic appeal of the VEE diagram it is more representative of the complexity of the overall process. This diagram also substitutes the more abstract descriptions  “system design processes” and “product realization processes” for the more descriptive and simple terms “decomposition and definition” and “integration and verification” used in the VEE diagram. This tendency to abstract the processes for completeness at the expense of clarity is a primary reason to keep coming back to the simplest terms of define, design, build, test and produce.

6.1.2 System Engineering Process Diagrams - The IEEE 1220-1998 and DoD handbooks focus on the system design part of the overall development process and provide more detail on this part. A simplified version of the IEEE system engineering process diagram is

Figure 6-2 The system development process as defined in the NASA Systems Engineering Handbook SP-2007-6105 Rev 1, Dec 2007 includes the technical management processes.

shown in Figure 6-3.  This diagram more explicitly brings in the important trade studies and assessment activities that are necessary for achieving a good system design and lumps the technical control processes into one box labeled Control.

Finally, the DoD handbook illustrates the system engineering process with a diagram that includes the important iterative nature of system design. A modified version of the DoD diagram that includes the technical management processes from the NASA diagram is shown in Figure 6-4. It also explicitly includes trade studies as in the IEEE diagram.

The DoD diagram more explicitly represents the iterative rather than sequential nature of systems design. One aspect of design that isn’t obvious in these standard diagrams is the option for design synthesis being either top down, bottoms up, or a combination of top down and bottoms up. An example of the bottoms up design approach is designing a new car model by choosing from sets of available engines, transmissions, suspension systems and other major subsystems. Many of the requirements analysis, trade studies and assessments involved in top down design are still needed to ensure a balanced design and verify the design but the overall development process is streamlined by having proven subsystems available for the class of system being developed. An experienced systems engineer can interpret the loops in the DoD diagram as allowing for starting a process at any point on a loop but this isn’t apparent to the novice. The remaining discussion in this chapter treats the system design processes as top down for convenience but should not be interpreted as endorsing only a top down design approach.

Figure 6-3 A simplified version of the IEEE 1220 diagram defining the systems engineering process illustrating the three types of trade studies and analysis central to systems design.

Figure 6-4 A Combination of the NASA and DoD diagrams of the systems engineering process includes the technical management processes, the three verification processes and illustrates the iterative nature of requirements analysis, design synthesis.

By now the reader should have concluded that the system design process is sufficiently complicated that it isn’t easily defined in any one diagram. Similarly, systems are sufficiently complicated that many diagrams are needed to adequately define them. It isn’t wise to attempt to define a fixed list of diagrams and documents needed to define systems either because the complexity of a system and the maturity of the development team usually determine what diagrams are necessary.

Getting Started with Pattern Based Systems Engineering

 Developing Patterns and Templates - An enterprise that sets out to develop patterns for the diagrams, documents and models used in their product lines has several possible approaches. One is to assign a team of highly experienced systems engineers to develop the patterns for a family of systems from scratch. This is an effective approach but it can be an expensive approach, even if experienced consultants are used to facilitate the process. However, it does achieve the desired patterns in a few weeks or months so that the patterns are available for near term design efforts. Often the expense is justified because having the patterns provides a competitive advantage over enterprises not used PBSE by significantly reducing the cost of the systems engineering portion of developing new products. If the experienced engineers are waiting for a new job to start then they can work on developing patterns at no additional cost to the enterprise.

A second approach is to save copies of the diagrams from a previous design effort and treat the copies as draft patterns. The diagrams for a current design effort are developed in two steps. First, all new items are added to the draft pattern diagram and none of the items in the draft pattern are deleted even if they don’t apply to the current design. The resulting diagrams and models are saved as revised draft patterns. Second, the revised draft patterns are edited to delete items that don’t apply to the new design effort. These diagrams and models are saved as the working documentation for the new design effort. This approach can take considerable time to develop patterns that are complete but it has the advantage of being nearly cost free.

Of course it is possible to combine the two approaches by initiating the second approach and then assigning experienced engineers that are temporarily between jobs to continuing the development of patterns. In all three approaches it is critical to thoroughly peer review the resulting patterns in order to have confidence that the patterns evolve to become complete and accurate.

Specific examples of models that should become patterns are presented in the following chapters as part of the description of the tasks systems engineers perform in carrying out the systems engineering process. This is a somewhat awkward way to present PBSE but it avoids having to present two versions of all of the models used in the systems engineering process. In some cases two or more methods are described for the same task; the intent is that the different methods can be used to verify the accuracy of work. Also individual engineers may have preferences for diagrams over matrices or vice versa. All methods should be considered candidates for patterns. Finally, in the version of PBSE presented here we include templates for text documentation as part of PBSE so that we extend the definition of PBSE beyond pure MBSE. We do this because many customers require text documents for items such as specifications, and because some documentation e.g. plans and data dictionaries are done in text documents. Using templates speeds the production of text documents and improves their accuracy just as using patterns speeds the production of labeled graphical models and improves their accuracy.

Candidate Models and Documents for Patterns – Listed here are example models and documents that are candidates for developing patterns and templates that support PBSE. Some are planning documents previously describes, some are described in subsequent chapters and some are outside of the scope of systems engineering. Not all apply to every type of system development but many do and not all possible candidates are listed.  It is suggested that readers consider how to develop plans discussed in previous postings as templates. As systems engineering models and documents are described in the following chapters consider how these items can be developed as patterns for their specific organizations and systems.

Pattern Diagrams for a Family of Products:

• Parameter Diagrams at System and Key Subsystem Levels
• Context (or Domain) Diagram
• Logical Architecture Diagram
• Modes Diagram
• Sub Modes Diagrams
• Functional Flow Block Diagrams at Top and Second Level
• N-Squared Interface Diagram
• System Block Diagram
• Control Electronics Block Diagram (For products have digital processors and/or digital controllers)

Document Templates for Family of Products:

• Integrated Management Plan and SEMP
• Information Architecture (Document tree)
• System Specification
• Interface Control Document
• Mapping and Transition Matrices
• Top Level Quality Control/Mission Assurance Document
• Subordinate Quality Control/Mission Assurance Plans
• Design Description Document
• Typically Used Electronics Sub Systems Specifications
• Any Subsystems likely in most Products in Family
• Dictionary of Definitions

Consider what fraction of the total cost of a system development is involved in developing the models and documents listed. The cost likely varies with the type of system and organization but suppose it’s ten percent. If using patterns and templates saves half the time and cost, a very conservative estimate based on the authors’ experience, then the use of PBSE gives an organization a five percent cost advantage over its competition. If an organization doesn’t adopt PBSE and its competitors do then the organization is likely to be at least at a five percent cost disadvantage. In today’s global competitive environment cost advantages translate directly into bottom line profits or into increased market share with even greater contributions to the bottom line profits. Thus there is a high return on the investment necessary to develop and manage a pattern and template database.