6.3.2.2 Define Life Cycle System Modes

Most texts, e.g. the NASA SE Handbook, use the terms states and modes.  These terms are often confused because both have transition diagrams and are often used interchangeably. It is preferable that they are not the same thing and are not interchangeable. Both state and mode diagrams define a condition of the system identified as a box, with a transition between them. In both cases, the transition is labeled with a system event which triggers the transition. The difference between a state and a mode is the definition of the box. States define an exact operating condition of a system, where modes define the set of capabilities or functions which are valid for the current operating condition. Let's use a simple example of a diagram for a television with two conditions OFF and ON. There are two transitions between them, one pointing to ON labeled as remote control ON detected, and a second pointing to OFF labeled remote control OFF detected. This diagram can represent a State or a Mode diagram. So what's the difference? If it is a Mode diagram, there is a data dictionary defining what functions can be supported in each condition. The TV in OFF mode must perform the function to sense the IR signal from the remote control to turn on. The TV in the ON mode must perform functions to change channels, adjust volume, and sense the IR signal from the remote control to return the TV to off. Knowing the TV is in the ON mode does not provide knowledge of what exact function the TV is performing. If this is a state diagram, there is no understanding of what functions the TV can perform. The state diagram details a single flip flop that toggles state based on the inputs of remote control ON, or remote control OFF. The output of this flip flop probably is used to activate primary power. In a more complex state diagram, there are many more memory elements but the key point is, in a given state, the condition of every memory element is explicitly known.

System modes have a hierarchy similar to functions. Modes can be decomposed into sub modes, which are also called modes, just as functions can be decomposed into lower level functions. Modes and the transitions between modes can be shown in a hierarchy of diagrams and matrices. The top level diagram or matrix should contain all modes in the life cycle of the system from assembly to an end of life mode. An example of a simple life cycle mode diagram for a commercial product for home use is shown in Figure 6-10. In this figure the event that determines transitioning from one top level mode to another is included as a labeled arrow on the diagram. It's important to define and examine the modes for all of a systems life cycle rather than just it's "in Use" mode. Sometimes there are requirements that are necessary for integration and test, storage or end mode that are not included in the modes for the "in Use" mode and the life cycle mode diagram is useful in identifying such requirements.

Diagrams or matrices can be developed for each of the top level modes that has sub modes to define the functions required in each mode and the allowed transitions between functions. Thus the top level mode diagrams identify lower level modes that are then examined during functional analysis to assist in defining all of the functions required in every mode of the life cycle of the system. This topic is revisited after discussion of functions and functional decomposition.

Transitions between sub modes are usually more complicated than between the top level life cycle modes. A very simple example that illustrates this is shown in Figure 6-11 where the transitions among the three modes of the IN USE mode of the product having the life cycle modes shown in Figure 6-10. The transitions are not labeled in this diagram at this point because the events causing these transitions can be dependent upon the physical design. It is only necessary at this point to define the allowed and required transitions between modes.

Figure 6-10 An example top level life cycle mode diagram for a simple commercial product.

Figure 6-11 A mode transition diagram for a simple commercial product in its IN USE mode.

---

  

Parameter Diagrams Help Define Functional Requirements

6.3.2 Define Functional Requirements

The context diagram and the concept of operations provide an understanding of the static and dynamic interactions of the system with the external world. Identifying functional requirements requires that we begin to examine what the system does. This first involves looking at the system as a complete entity and then decomposing top level functions to lower level functions. It includes examining the modes that a system exists in throughout its life cycle. These analyzes set the stage for allocating functions to physical elements; the work of the design loop. A useful tool for examining function for the system as a single entity is the Parameter Diagram.

6.3.2.1 Parameter Diagrams - The Parameter Diagram (P-diagram) supports requirements analysis by determining and communicating the function of the system or any design element, defining those parameters that can cause undesired performance (noise factors) and defining the control factors the element has (or should have) whose values are selected to achieve the desired performance of the ideal function and to minimize the sensitivity to the noise factors. P-diagrams are useful at any level of product design, from mission level to part level. The form of a P-diagram is shown in Figure 6-9.

Figure 6-9 A P-diagram defines the ideal function of a design element and lists the noise factors and control factors that must be controlled in the design to achieve as close as practical the ideal function.

Defining the ideal input and the control factors is usually straight forward. The real work comes in defining the ideal response of a design element, the undesired responses and the noise factors that cause the undesired response(s). The design element, labeled “system” in the figure, is treated as a single entity and the control factors selected as appropriate for the level of the design element. Thus, if the design element is at a mission level the control factors relate to the various systems that interact to fulfill the mission. It isn’t helpful to list screw thread size as a control factor for a mission or complex system design element but screw thread size may be a control factor for a design element at the component level.

Consider the P-diagram for a pencil. The ideal response to the input of hand motion is a line on a writing surface of a uniform density and width. However, a pencil has another ideal response that is important to users. It should sharpen to a fine, uniform point in response to being sharpened. Undesired responses include skipping, tearing paper and the point breaking during sharpening. Control factors include parameters like graphite composition, hardness and diameter and the type of wood used for the casing. Noise factors include writing surface roughness, writing surface material, type of pencil sharpener, sharpness/dullness of pencil sharpener blade(s), temperature, humidity and aging. These lists aren’t meant to be complete but to illustrate the principles involved. Note that variations in composition or trace impurities are not listed as noise factors since the purity and composition are controllable. Sometimes it is difficult to decide whether a parameter is a noise or control factor. It’s best not to waste time trying to be to pure with definitions; capture the parameter as one or the other and ensure it is taken into account during the design.

Generating the P-diagram is a simple and convenient method for the engineer, whether a system engineer or a design engineer, to think about the effects of the environments the design element faces in its life of use, the types and influence of other elements it interacts with in test, use and storage; the ways in which the element is used (intended and otherwise) and the expectations of users. Thus the P-diagram complements the context diagram and the concept of operations and thereby supports requirements analysis as well as functional analysis.

The reason for listing the undesired responses of a design element is that the preferred method of controlling undesired responses is to optimize the ideal response in the presence of the noise factors. This is the essence of robust design practice discussed in the books of Clausing and Phadke previously cited. Design practices prior to robust design often attempted to reduce the undesirable responses directly. Directly minimizing one undesired response can result in redirecting the energy causing that undesirable response so that it causes another undesired response. In contrast robust design practices maximize the ideal response in the presence of the noise factors so that all the undesired responses are controlled.

One of the benefits of developing a P-diagram is that it defines the parameters to be considered in robust design. Another is its communication value. The P-diagram communicates essential parts of the design problem to both the design team and to any reviewers of the design work. If the design element is of the same family as something that the team has designed before then it takes little time to edit the pattern P-diagram from a previous design by adding any new factors and deleting any factors that don’t apply to the new design element. It is likely that the ideal inputs, ideal responses and undesired responses are very similar and take only minutes to edit. However, it is the differences between the new design element and those the team has designed before that are important to define at the outset. The P-diagram is a quick way to define and capture those differences.

If the design element is entirely new to the team then the P-diagram is critical to identifying all of the noise factors that must be accounted for in the design. Often the effects of noise factors on the performance of a design element are analyzed individually or in groups. Color coding the noise factors on a P-diagram is a quick way to remind reviewers of which noise factors are under consideration in a particular analysis, which ones have been previously evaluated and which ones remain to be analyzed. Using robust design practices such as Taguchi design of experiments noise factors can be grouped or compounded to speed the analysis. The P-diagram is again a good communication tool to describe the structure of a Taguchi analysis of variance experiment. (Taguchi design of experiments is described in detail in the book by Phadke cited earlier.)

 Examining the interactions on the context diagram leads to the identification of the functions performed by the system in addition to the ideal function and undesired interactions defined in the P-diagram. Each interaction on the context diagram is reviewed to define the inputs and outputs from the system. The transformations performed on the inputs, and driving the outputs establish the functions performed by the system. Functions should be defined following the classic engineering view that outputs are defined as a transform on one or more inputs. When defining system functions, the requirements must define every output that is produced from every combination of the legal set of inputs. The definition of the function transformations must be comprehensive and accurate. The functions must provide exhaustive definitions. Requirements often are not exhaustive by not covering all possible outputs that can be produced.

The concept of operations (Con-Ops) does not provide an exhaustive understanding of all operations of the system, so the identification of all functions must rely on the context and P-diagrams. Additionally, interactions on the context diagram may be involved in multiple functions. Involvement of the user in the function definition provides confidence that all system functions are identified. Con-Ops and P-Diagrams typically focus on the functions which produce the target outputs which the user desires from the system. However, there are often other functions that must be performed to support the operation of the system but that don’t directly produce the target outputs desired by the user. For example, data systems typically employ error correction algorithms to ensure the desired data performance is achieved. Users typically do not request an error correction function as part of the system. The system engineer must provide the broad vision, based on his understanding of the user needs, to recognize this is a necessary function which the system must perform in order to ensure the algorithm performance requirements are specified. This highlights an important value of the context diagram. Examining all interactions of the system with the external world usually identifies functions the system must perform that are not typically identified as requirements by the user.

 When examining the interactions on the context diagram, it is also important to remember that some of the interactions will map to a real physical interface. Data flowing in and out of the system usually represents a physical interface. However, some interactions, such as radiated EMI, are not mapped to a physical interface. It would be a lot easier to design a system if the radiated EMI interactions could be allocated to a specific connector but in this case, the functions need to be specified with the understanding that many mechanical characteristics have requirements that address this function. Functions that do not deal with explicit physical interfaces are often difficult to specify.

The detailed understanding of system interactions is translated into the final functional requirements. For each function, each individual parameter for performance, behavior, and visibility becomes an independent, unique requirement. Having identified functions, detailed understanding ultimately leads to functional requirements. The specifics of the performance, behavior, and visibility associated with the input, transform, and output must be included. Performance aspects include tolerances, uncertainties, response times, bandwidth, data structures, etc. Behavior includes considerations of how functions are affected by the operating state of the system, other functional results, and environmental conditions. Visibility defines how much knowledge is known about how the function is performed. For example, an error correction function may be required by the system. This error correction function may be defined simply by the ability to perform a specified level of error correction, or the system may need to implement a specific algorithm.

When all functions are defined, the customer must review and agree on the result at a System Requirements Review (SRR) or System Functional Review (SFR). Other tools and methods useful in identifying functional requirements include Quality Function Deployment (QFD), defining system modes and Kano diagrams. These are described in the following sections or chapters.

Concept of Operations

6.3.1.2 Life Cycle Concept of Operations - The context diagram defines what the system interacts with in the external world. However, this is a static view. A dynamic view of the system is also necessary to understand how the system interacts with the external world. This dynamic view is provided with the concept of operations (Con-Ops) description.  Although the emphasis is on scenarios describing normal operation of the system sometimes scenarios describing operations in unique conditions or non-operational conditions should be included. Examples might be if the system has unique operations during testing, maintenance or at end of life that add to the system requirements.

The concept of operations includes a number of scenarios that in total convey an overall understanding of the system behavior. It does not include an exhaustive list of every operating mode of the system, but provides a broad view that the systems engineer uses as the basis for defining the details necessary in the design requirements. Each scenario provides a single thread of sequential events that starts at a typical predefined state, and completes when a primary set of operations is complete.  Scenarios are success oriented, providing a linear flow for operation of the processes of interest, and do not include alternate processing in the flow. Following the completion of the scenario, faults can be described as an alternate flow describing how the system may react should a fault occur. During the scenario, the flow may describe interactions with the operator. The flow assumes a particular input from the user thus providing the singular linear flow. Should alternate inputs provide important understanding of the system, they need to be described in separate scenarios. If there are many variations of processes that all start with a common flow then it may be convenient to describe the initial common portion as one scenario, and the multiple variations as independent flows. 

Scenarios need to include assumptions about what may have occurred prior to the start of the description, and describe the state of the system at the completion of the description. Environmental conditions need to be defined if they affect the operation of the system.

Use cases, to be described in a later chapter, are an excellent standard tool used to develop scenarios.

Typical operating scenarios include:

            Initialization – The initialization flow starts with the system unpowered and completes when the system is ready to perform its primary function. There may be multiple initialization scenarios. For example, when a computer boots, the computer may prompt the operator for input as to whether to perform a standard boot, or to perform a maintenance ‘safe’ boot. These two scenarios are described separately, both starting the same way with the application of power, but deviating based on the input from the operator.

Operation – Starts at the completion of initialization and completes when a process of the system is complete. The process may be scheduled, initiated by an operator, or the result of some other event detected by the system. An operational scenario may include a number of processes but should be short enough to be easily grasped by someone not familiar with the system. Multiple operational scenarios may be necessary in order to cover all primary processes.

Maintenance – Starts in a normal operating state and completes when the system is returned to the operating state. Assumptions of events leading up to the maintenance action are a particularly important part of these scenarios.

Repair - Starts in a fault condition and completes when the system is returned to the operating state. It is not possible to include scenarios which address every possible fault. The key is to remember is the intent is to provide the systems engineer with the broad understanding of how ‘typical’ faults are handled. This should provide enough understanding to extrapolate the operation of faults not explicitly described.

The content of the concept of operations must be developed with support of the user. This document captures the user expectations for how the system behaves. Additionally, this is the opportunity to guide the user to alternate operation if the behavior can be simplified. In the end, a user review is critical to receiving formal agreement with the final document. This document forms the basis for the system requirements for behavior. Additionally, it is the primary input to any user’s manual.

---

Reflections on Requirements Analysis

Understanding the requirements of a system is an extremely important, but often overlooked aspect of systems engineering.  The nature of engineers is they like to design. Engineers often think ‘I know what to build’, and move right into the exciting part of developing a product. Additionally, programs very rarely have the luxury of a relaxed schedule, so it is often felt for the project to be delivered on time, the design activity must start right away. Both engineers and managers are motivated to minimize the requirements phase of the program.  This is reinforced by the perception that requirements appear straight forward. However, when examined from a systems perspective, requirements are not so simple and impact every aspect of a program. These impacts must be understood to eliminate rework and waste in the subsequent phases of the program.

A critical characteristic of a good systems engineer is always maintaining an integrated view of every task.  Systems engineers must ensure they always look at the whole picture and assess impacts from all aspects of the program. Whereas engineering specialists focus their attention primarily on their individual domain, systems engineering must look across all engineering domains, as well as across the program elements for cost and schedule. When developing requirements, the system engineer must apply this integrated view to understand the impact of each requirement on both the design and the program. This understanding is essential to ensuring that the individual engineering specialists fully understand what drives their design.

System level requirements often have unforeseen impacts on elements of the design. The systems engineer having the ‘system engineering view’ must be able to anticipate these impacts from the high level requirements before the design is initiated. This anticipation is important to program planning to make sure the work is accurately defined and yields a viable program cost and schedule.  It is essential that requirements are balanced in difficulty. This means for example that the imaging performance of a digital camera is balanced between the lens and the detector arrays. If the requirement on the detector arrays is relaxed then the lens may be complex and expensive. Conversely, if the requirements on the lens are relaxed then the requirements on the detector arrays may require inordinately expensive detector arrays.

In the remainder of this chapter numerous diagrams are defined that aid in developing and communicating an understanding of the system being developed. Engineers unfamiliar with systems engineering may ask why so many diagrams are needed in the process of requirements analysis. One way of understanding why is to imagine that no diagrams were developed; rather written requirements were provided to designers and the designers produced a final drawing package. A moderately complex system could have thousands of drawings. Imagine trying to explain to customers that a system build to the drawings would do what the customer intended. Similar difficulties would result in trying to communicate with suppliers and managers. Human cognitive abilities just don’t allow achieving an understanding of a system from large written descriptions or a detailed drawing package with thousands of drawings. Higher levels of abstraction are needed to provide understanding without overwhelming detail. Systems engineers use diagrams at various levels of abstraction to provide the understanding and the communication tools needed in system development.

Systems engineers use diagrams and models to define a system from different viewpoints as well as at different levels of abstraction and detail. An understanding of a system means knowing what it is supposed to do, what it has to be able to do to accomplish what is intended and what it looks like. The term “view” is used for each of these means of understanding. Thus an Operational View consists of diagrams and models that describe what a system is supposed to do. A Functional View consists of diagrams and models that decompose and describe what the system has to be able to do to accomplish what is intended. A Physical View consists of diagrams, models and eventually detailed drawings that describe the physical characteristics of the system.

All of the diagrams and models of the three views can be called system models because each offers some type of model of the system or of part of the system. Thus systems engineers develop system models from different perspectives and at various levels of abstraction or detail to provide the desired understanding of the system. Cognitive scientists tell us that having an understanding of a system means we have a mental model of it that allows us to interpret and make predictions about the system. The many different system models are necessary to enable us to focus on various aspects of the system without being distracted by the detail of the entire system; that is to form various mental models that are fundamental to our understanding.

Different people will form different mental models of a system. The customer’s mental models are likely quite different from those of the manufacturing engineer. The software engineer’s mental models are different from the hardware designer’s. These different mental models are due both to human differences and to people forming mental models appropriate to problems important to them. People interpret models in a way that is correlated with their learning styles. This is one reason it is valuable to develop system models that illustrate the same information in different diagrams or formats.

This section presents an integrated view of requirements analysis rather than discuss each of the 15 tasks, which were listed in the previous post and are defined in the DoD SEF. Effective tools for analyzing the mission and environments include Context or Domain diagrams and Concept of Operations (Con-Ops) description documents. These tools analyze a system as a single entity and are useful in addressing IEEE tasks 4, 6, 7 and 8.

6.3.1.1 Context or Domain Diagrams - The first step in requirement analysis is to understand the context in which the system will be deployed. The context or domain defines the external world that interacts with the system. The elements that the system interacts with include people, other systems, and environments. There is overlap between these elements but considering them separately assists in making sure all interactions are addressed.

The people that interact with the system include all users, operators, and maintenance individuals. Keep in mind that users may be different than operators and have different concerns. An example is the passengers on an airplane have requirements that need to be met but they are very different from the requirements of the pilot. Likewise, the team that maintains the airplane requires very different interactions with the airplane than either the passengers or the pilot. Others that need to be considered are those that install and dispose of the system. When designing a nuclear power plant, understanding how the facility materials are processed at end of life is as important to the design as how the reactor is controlled when it is operational. Lastly, during development, the designers often need access to detailed performance measures to verify correct operation of the system that is not required by anyone else.

Understanding interactions with the external world include physical elements providing input or receiving output from the system. These typically fall into mechanical or electrical areas but many products include other areas. Cameras have an optical interface to the external word. Geiger counters obviously interact with atomic particles and gamma rays via a radiation interface. Most of the interactions are readily apparent, but the context needs to include all interactions ensuring there is no undesired impact on performance. For example, many systems receive power from both batteries and the electric power grid. It is not sufficient to identify the input of power; the context must identify both sources.

Many environments are applicable to nearly all hardware systems. These include temperature, shock, vibration, acceleration, and humidity. When assessing these environments, the operational conditions must be assessed. It is typical that the storage conditions for a product may be different than the operating conditions. There may also be operational scenarios that vary for the product over the life of the product. A satellite for example needs to survive the launch environment for only a very short period of the overall life of the system. Beyond the typical environments, some systems have unique environments such as radiation, biological or chemical exposure, or Electromagnetic Interference (EMI).

A standard method for capturing the context of the system is with a context or domain diagram.  Here the term context diagram is used. A context diagram places the system at the center, surrounded with all external entities identified by assessing interactions with human, other system, and environments. Each entity is identified separately with the type of interaction between the system and the external entity identified. The interaction identifies what flows as well as the direction of the flow. Interactions between external entities are not necessary to include on the diagram but may be included if they provide clarification. The system is identified as a single entity meaning there is no visibility as to its internal components. An example context diagram for a digital camera is shown in Figure 6-6.

Figure 6-6 A context diagram illustrates the external entities that the design element communicates with and what information is communicated between the design element and each external entity.

A second version of a context diagram groups the information communicated between the system and the external entities according to the type of logical interface. The interfaces are logical at this point rather than physical because the physical interfaces are yet to be defined. An example of a partially complete context diagram with logical interfaces is shown in Figure 6-7. In the example shown in Figure 6-7 a sensor for some type of radiance is hosted on a platform that could be a ground, air or sea platform. If this diagram included labeled arrows for all possible information exchanges between a family of radiance sensors and any host platform then the diagram would be a pattern diagram for the family of radiance sensors.

Having a complete pattern diagram at hand the systems engineers for a specific sensor on a specific host platform can quickly develop the context diagram for their system by examining each arrow and deciding if it belongs or should be deleted. Deleting the arrows not required is much faster than adding arrows to build a diagram and the risk of missing any pertinent information exchange is lower. In constructing a context diagram with logical interfaces it is helpful to color code each interface and the arrows belonging to each interface. The example in Figure 6-7 is not meant to be a complete pattern diagram, but rather to illustrate the approach to constructing a complete pattern for a context diagram representing a family of systems.

Figure 6-7 An example context diagram with logical interfaces for a sensor system mounted on a host platform illustrating the logical interfaces the system has with the external entities.

Interface control drawings or interface control specification documents (the acronym ICD is used here for either the drawing or the document) are an essential part of system design. The ICD captures the quantitative details of the information exchanged. Comparing the context diagram against the ICD is a quick way to check that every arrow to a logical interface on the diagram is accounted for in a specification in the ICD.

Context diagrams help define the design task by confirming the boundaries of the design problem, identifying the logical external interfaces and the information exchanged with all environments and entities external to the system throughout its life cycle; thus laying the ground work for defining functional requirements and developing the ICD.

The information included in a context diagram can also be presented in a matrix format as shown in Figure 6-8. The matrix format has the advantage of being less cluttered and therefore easier to review but it does not include the direction of information without the extra work of adding tiny arrows, the words “from” and/or “to” or color coding each cell.

 

Figure 6-8 The information in a context diagram can also be presented in a matrix of interfaces vs. external entities.

In constructing a context diagram or matrix it isn’t necessary to be quantitative in defining the information exchanged between the system and external entities. The idea is to ensure that all of the information and external entities are captured. It’s ok to use general terms like “commands”, “data” and “loads” if the diagram is highly cluttered. Specific details on such information are to be provided in the ICD, but if it doesn’t make the diagram too cluttered to be useful add qualitative detail. For example differentiate between test commands and operating commands and define the sources and types of loads. Some may find it useful to add more specific information in the information cells of a context matrix or even to add links to cells as reminders for use later in developing the ICD. Some may find it useful to construct both a context diagram and a context matrix as cross checks to ensure complete capture of information exchanged with all environments and all external entities.

Just as for the diagram format if a complete matrix for a family of systems is developed as a pattern then the matrix for any specific system is quickly developed by deleting information exchanges not pertinent from the pattern matrix. A matrix for a specific system can be developed from a pattern matrix in a fraction of the time it takes to generate a new matrix from scratch and is more likely to be accurate.

Following completion of the context diagram, a diagram data dictionary is generated or updated. This dictionary defines all elements of the diagram, as well as all interactions. The dictionary should include as much understanding of the element as possible. The reader of the dictionary needs to be able to understand what is included or not included in each element.

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.