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.