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.