Spider Diagrams

6.3.3.2 Spider Diagrams - Another useful diagram is the spider diagram; named from its shape.  Spider charts are useful for tracking progress of requirements that are interrelated so that careful attention is needed to avoid improving one at the expense of others. An “ility” diagram is a good example of a spider chart that tracks progress toward goals or requirements for selected ilities; i.e. reliability, maintainability, reparability, etc. An ility diagram treats the system or product as a single entity. It is constructed by selecting and ranking in importance eight ilities as described by Bart Huthwaite in his book “Strategic Design” cited earlier. Initially measures and goals are established for each ility. Later, as the system design takes form initial estimates or calculations of each ility are made and plotted on the diagram. As system design trades progress and the design is refined the progress toward goals in tracked. By including the most important eight ilities and tracking their measures on a chart the design team has a clear picture of how well the design is progressing and if any ility is being sacrificed for the benefit of some other ility or performance parameter. An example ility chart as it might appear in the middle of system trades is shown in Figure 6-18. Here the eight ilities are numbered in rank order of importance so that if tradeoffs cannot be avoided the most important ilities are favored over less important one. The line connecting the eight legs is the CBE for each ility. Trends can be indicated by keeping the previous three or four CBEs.

Figure 6-18 An example of the form of an “ility” chart that tracks progress toward goals for eight ilities ranked in importance from 1 to 8.

6.3.4 Balancing Customer Needs

A major goal of requirement analysis is to ensure the set of requirements are complete, accurate, and non-redundant. An additional activity during the requirement analysis is to identify opportunities to optimize the customer’s desires and needs. This task is considered part of the Technical Management task shown in Figure 6-4 in a previous post. Working with the customer to adjust requirements often presents an opportunity to save cost or schedule with little impact on the customer. This may also provide significant improvements in a highly desired performance parameter with little impact on a lesser desired parameter. These changes are best identified during requirement analysis. As the program moves into the architecture, then design phase, changes become more costly providing less opportunity for savings. The understanding that a very large percentage of the program cost and schedule are established very early in the program is an important responsibility of the system engineer. Requirements drive the system architecture trades, and once the architecture is defined, the opportunity for savings is a small percentage of the opportunity early in the program. Pugh diagrams (to be described in Chapter 8) and QFD tables (defined in Chapter 7) are valuable tools for assessing these opportunities.

Processes for Technical Performance Measures (TPM)

6.3.3 Define Performance and Design Constraint Requirements

Tasks 11, 13 and 14 shown in Figure 6-5, posted Wed. Dec. 29, 2010, are related to performance and design characteristics and are discussed together here. During the analysis of market data, customer documentation and user needs, and in constructing P-Diagrams and Quality Function Deployment (QFD) QT-1 tables the top level system performance parameters and key design characteristics such as size, mass, power and data rates are identified.  These parameters must be quantified and metrics must be defined that enable the team, management and customers to track progress toward meeting these important requirements. It is also necessary to judge which design characteristics are rigid constraints and which can be modified in design trade studies if necessary.

6.3.3.1 Define Tracking Metrics (KPPs & TPMs) Developing a consistent process for constructing and updating KPPs, TPMs and any other tracking metrics needed is essential to providing confidence to both the team and their managers and customers that work is progressing satisfactorily or if critical requirements are at risk. It is good practice, as defined by IEEE task 11, to begin the selection of tracking metrics and setting up tracking procedures during the requirements analysis task even though the design work is not yet dealing with physical design. One widely used process is presented here. Only TPMs are discussed but the process can be used for other metrics as well.  The benefits of TPMs include:

• Keeping focus on the most important requirements (often called Cardinal Requirements).
• Providing joint project team, management and customers reliable visibility on progress.
• Showing current and historical performance Vs. specified performance
• Providing early detection and prediction of problems via trends
• Being a key part of a design margin management process
• Monitoring identified Risk areas
• Documenting key technical assumptions and direction

The steps in generating TPMs include:

1. Identify critical parameters to trend (e.g., from a QT-1)
2. Identify specification & target values and the design margin for each parameter
3. Determine the frequency for tracking and reporting the TPMs (e.g. monthly)
4. Determine the current parameter performance values by modeling, analysis, estimation or measurement (or combination of these)
5. Plot the TPMs as a function of time throughout the development process
6. Emphasize trends over individual estimates
7. Analyze trends and take appropriate action  

Some systems have a very large number of TPMs and KPPs. Rather than report every metric in such cases develop a summary metric that reports the number or percent of metrics within control limits and having satisfactory trends. Metrics not within control limits or having unsatisfactory trends are presented and analyzed for appropriate actions. This approach works well if those reviewing the metrics trust the project team’s process.

It is recommended to track and report both margin and contingency with the current best estimate (CBE). Unfortunately there are no standard definitions for these parameters. Example definitions are shown in Figure 6-13.

Figure 6-13 Example definitions for margin and contingency where contingency is defined as the current best estimate plus/minus one sigma.

An example of a TPM tracked monthly for a characteristic for which smaller-is-better, e.g. mass or power, is shown in Figure 6-14 with the plotted points being the CBE plus contingency.

Figure 6-14 An example TPM chart for a characteristic for which smaller-is-better.

Included in the chart is the specification value, shown as a horizontal line, a target value selected by the project team and plotted as a point at the planned end of the development cycle, a margin depletion line, upper and lower control limits as well as the plotted values of CBE plus a contingency. Selecting the target value, slope of the margin depletion line and the control limits is based on the judgment of the project team.

Smaller-is-better characteristics like mass and power consumption tend to increase during the development so initial values should be well under the specification value. Thus a reasonable strategy for selecting the margin depletion line is to link the initial estimate with the final target value. Control limits are selected to provide guidance for when design action is needed. If the characteristic exceeds the upper control limit design modifications may be needed to bring the characteristic back within the control limits. If the characteristic is below the lower control limit then the team should look for ways that the design can be improved by allowing the characteristic to increase toward the margin depletion line value at that time. For example, in Figure 6-14 the first three estimates trend to a point above the upper control limit. The fourth point suggests that the project team has taken a design action to bring the characteristic back close to the margin depletion line.

Many requirements must be broken down into separate components, attributable to each contributing factor; e.g. mass of a system can be broken down into the mass for each subsystem. TPMs for such requirements are a rollup of the contributing components.  A variation on a TPM particularly useful for such requirements is to explicitly include the basis of estimate (BOE) methods of arriving at the CBE value each period. Typical BOE Methods are allocation, estimation, modeling and measurement. Allocation is the process of taking a top-level roll-up and budgeting a specified amount to each contributing component. Estimation, modeling and measurement are methods applied to each contributing component and then combining them to determine the result for the top level requirement. Figure 6-15 is an example of a smaller-is-better characteristic with the CBE shown as a stacked bar with the proportion of the CBE from each method explicitly shown.

Figure 6-15 An example of a TPM chart where the plotted values include the basis of estimate methods to provide more information about the confidence in reported values.

The proportions allocated and estimated drop as modeling and measurements are made, which increases the confidence in the reported CBE value. In the example shown the CBE is the sum of values for each contributing component with different uncertainties and the plotted values, i.e. the top of the stacked bar are the CBE plus the RMS of the uncertainties, i.e. the contingency in this case. For a larger-is-better characteristic the plotted value is the CBE minus the RMS of the uncertainties assuming the definitions in Figure 6-13.

One alternative method of tracking and reporting metrics is using spreadsheet matrices rather than charts. This approach allows the values for each contributing component to be tracked and reported. An example for a smaller-is-better characteristic attributable to three component subsystems is shown in Figure 6-16.

Figure 6-16 An example TPM for a smaller-is-better characteristic attributable to subsystems.

The total allocated value can be either the specification value or the specification value minus a top level margin, i.e. a target value. The BOE methods for each contributing component CBE can be included in additional columns if desired. The disadvantage of a matrix format compared to a time chart is that it isn’t as easy to show trends with time, margin depletion line value and control limits. Matrices are useful for requirements that involve dozens of contributing components; each important enough to be tracked. The detail can be presented in a matrix with color coding to highlight problem areas and either a summary line or summary chart used for presentations to management or customers.

A third alternative for tracking metrics is a tree chart. An example using the data from Figure 6-16 as mass in Kg is shown in Figure 6-17.

Figure 6-17 An example of a TPM in a tree chart format.

A tree chart has similar disadvantages as a matrix compared to a time chart but both trees and matrices have the advantage of showing the values for contributing components. Sometimes it is valuable to use both a time chart and a tree or matrix for very important TPSs or KPPs.

Common sense guidelines to follow in managing tracking metrics include:

• Keep metrics accurate and up to date
• Be flexible with metric categories (add, delete, modify as development progresses)
• Dovetail into customer process
• Plan ahead to achieve maturing Basis Of Estimates (BOE)
• Make performance prediction part of normal design process (flow-up, not run-down)
• Include in program status reports, e.g. monthly.

It should be part of each IPT’s normal work to report or post to a common database the estimates for metrics under their design responsibility. This makes it easy for one of the system engineers to compile up to date and accurate metrics for each reporting period. If this is not standard practice then someone has to run down each person responsible for part of a metric each period to obtain their input; a time consuming and distasteful practice.

6.3.2.3 Kano Diagrams

A Kano diagram is an example of a tool that takes very little of a team’s time but sometimes has a huge payoff. A Kano diagram categorizes system characteristics in the three categories of Must Be, More is Better and Delighters. Each category has a particular behavior on a plot of customer response vs. the degree to which the characteristic is fulfilled. An example Kano diagram is shown in Figure 6-12. The customer response ranges from dissatisfied to neutral to delight. Characteristics that fit the More is Better category fall on a line from dissatisfied to delight depending on the degree to which the characteristic is fulfilled. Characteristics that are classified as Must Be are those the customer expects even if the customer didn’t explicitly request the characteristic. Thus these characteristics can never achieve a customer response above neutral. Characteristics that fit the Delighter category are usually characteristics the customer didn’t specify or perhaps didn’t even know were available. Such characteristics produce a response greater than neutral even if only slightly present. Obviously characteristics can be displayed in a three column list as well as a diagram.

The reasons to construct a Kano diagram are first to ensure that no Must Be characteristics are forgotten and second to see if any Delighters can be identified that can  be provided with little or no impact on cost or performance. Kano diagrams are not intended to be discussed with customers but to assist the development team in defining the best value concept. The “Trend with Time” arrow on this diagram is not part of a Kano diagram but is there to show that over time characteristics move from Delighters, to More is Better to Must Be’s. The usual example used to illustrate this trend with time is cup holders in automobiles. They were Delighters when they first appeared, then they became More is Better and now they are Must Be’s. The “characteristics” included in a Kano diagram may be functions, physical design characteristics, human  factors, levels of performance, interfaces or modes of operation. Thus this simple tool may contribute to many of the 15 IEEE tasks defined in Figure 6-5 in a previous post.

Figure 6-12 A simple example of a Kano diagram that classifies system characteristics into categories of Must Be, More is Better, and Delighters.

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.