Editor’s Note: In this series of articles, Jeffrey O. Grady, author of “System Verification,” delineates the basics of requirements planning and analysis, an important tool for using Agile programming techniques to achieve better code quality and reliability in complex embedded systems software and hardware projects.
This series of articles is about the process of developing good specifications for any hardware or software development project. In the English-speaking world, requirements are phrased in English sentences that cannot be distinguished structurally from English sentences constructed for any other purpose.
Yes, specifications are full of sentences. It is relatively easy to write sentences once you know what to write them about. A requirement is simply a statement in the chosen language that clearly defines an expectation placed on the design process prior to implementing the creative design process.
Requirements are intended to constrain the solution space to solutions that will encourage small-problem solutions that synergistically work together to satisfy the large-problem (system) solution.
Requirements are formed from the words and symbols of the chosen language. They include all of the standard language components arranged in the way that a good course in that language, commonly studied in the lower grades in school, specifies.
Those who have difficulty writing requirements experience one of three problems:
(1) fundamental problems expressing themselves in the language of choice, which can be corrected by studying the language,
(2) technical knowledge deficiency that makes it difficult to understand the technical aspects of the subject about which the requirements are phrased that can be corrected through study of the related technologies, and
(3) difficulty in deciding what to write requirements about.
The solution to the latter problem is the possession, on a personal, program, and company basis, of a complete toolbox of effective requirements modeling tools and the knowledge and experience to use the tools effectively individually and collectively.
Providing the toolbox should be the function of the system engineering functional department, recognizing that some departments outside of the system engineering department will contribute people to programs and these people will apply a department-unique method that should be coordinated with the intended systems approach.
This toolbox must encourage the identification of product characteristics that must be controlled and selection of numerical values appropriate to those characteristics. So, this toolbox must help us to understand what to write requirements about. We must accomplish requirements identification and requirements definition where we determine the values appropriate for those requirements.
Requirements definition through modeling gives us a list of characteristics that we should control to encourage synergism within the evolving system definition. If the analyst had a list of characteristics and a way to value them for specific items, language knowledge, and command of the related technologies, he or she would be in a very good position to write a specification that hit the target that is to capture all of the essential characteristics and no additional content.
One approach to a solution to this problem on what to write requirements about is boilerplate, and this is essentially what specification standards such as MIL-STD-490A provided for many years. Its replacement, MIL-STD-961D Appendix A and later the E Revision that integrated the content of Appendix A into the body of the document, is likely to do so for many more years within the context of military systems. In the boilerplate approach, you have a list of paragraph numbers and titles, and you attempt to define how each title relates to the item of interest.
This results in a complete requirement statement that becomes the text for the paragraph stating that requirement. The problem with this approach is that there are many kinds of requirements that cannot be specifically identified in such a generic listing.
One could create a performance requirements boilerplate that covered every conceivable performance requirement category with some difficulty, only to find that it was more difficult to weed out those categories that did not apply to a specific item than it would have been to have determined the appropriate categories from scratch.
This is why one would find no lower level of detail in a specification standard than performance even though there may evolve 50 pages of performance requirements during the analysis for a particular specification. Interfaces are another area where boilerplate is not effective at a lower level of detail.
Many design engineers complain that their system engineers fail to flow down the customer requirements to their level of detail in a timely way. Their solution is to begin designing at their level of detail without requirements because their management has imposed a drawing release schedule they dare not violate.
These engineers are often right about the failure of their system engineers but wrong to proceed in a vacuum as if they know what they are doing. The most common failure in requirements analysis is the gap between system requirements defined in a system specification given to the contractor and the component-level requirements in the performance requirements area. In organizations in trouble, the goal in the engineering organization is often stated as getting the system performance requirements flowed down to the design level or deriving design requirements from system requirements.
Unfortunately, no one seems to know quite how to do that, and avoidable errors creep into the point design solutions in that void that develops. Flow down is a valid requirements analysis strategy, as is boilerplate (which the author refers to as one form of cloning); they are just not completely effective tools across all of the kinds of requirements that must be defined, and particularly not effective for performance requirements.
Flowdown is composed of two subordinate techniques: allocation (or partitioning) and derivation. Allocation is applied where the child requirement has the same units as the parent requirement and we partition the parent value into child values in accordance with some mathematical rule. Where the child requirement has different units than the parent requirement, the value may have to be derived from one or more parent requirements through parametric analysis, use of mathematical models, or use of simulation techniques.
The problem in the flowdown strategy is that you must have a set of parent requirements in order to perform requirements analysis. One may ask, where did the parent requirements come from? This difficulty is solved by applying some form of modeling that leads to the identification of characteristics that the item must have.
The model should be extensible with respect to the problem represented by the system being developed such that it can be used to identify needed functionality and be iteratively expanded for lower tiers of the problem. Functional analysis (described later in this series) is an example of a means to identify performance requirements.
Once the physical hierarchy of the product structure is established through functional analysis and allocation, other models can be applied to identify design constraints and appropriate values in interface, environmental, and specialty engineering areas. In the latter two cases, requirements allocation can be very effective in a requirements hierarchy sense.
Our toolbox should help us understand what to write requirements about and what characteristics we should seek to control. Once we have this list of characteristics, we must pair each with an appropriate numerical value and weave words around them to make the meaning very clear.
We need to quantify our requirements because we will want to be able to determine whether or not a particular design solution satisfies the requirement. This is very hard to do when the requirement is not quantified. As we shall see, this is the reason why the author encourages simultaneous definition of requirements and the companion test and analysis, or verification, requirements for proving the solution satisfies them.
Our system requirements analysis process should clearly tell us what kinds of characteristics we should seek to write requirements about and provide a set of tools to help us add characteristics to our list. We also need to have the means to quantify them.
We seek a list of characteristics that is complete, in that it does not omit any necessary characteristics, and minimized, since we wish to provide the maximum possible solution space for the designer. We would like to have a more specific understanding of how this requirements analysis solution is characterized by completeness and minimization, but there is no easy answer.
The best prescription the author can offer is to apply an organized approach that connects specific models up with specific requirements categories and apply the tools with skill based on knowledge derived in practice or through training. Figure 1.3-1 below offers an overall taxonomy of every kind of requirement that one would ever have to write in the form of a three-dimensional Venn diagram.
Figure 1.3-1 Requirements taxonomy
The top layer, Part I in MIL-STD-490A or the performance specifications in the context of MIL-STD-961E, corresponds to development requirements, often called design-to requirements, that must be clearly understood before design. The lower layer, Part II in 490A context or detailed specifications under 961E, corresponds to product requirements, commonly called build-to requirements.
The portion of the construct below the heavy middle line is for product specifications, in which we are primarily interested in this series. The requirements above this line correspond to process requirements captured in statements of work and plans. Many of the same techniques discussed in this series for specifications apply to process requirements, but most of the book specifically concerns product specifications and proving that the design satisfies their content.
Development requirements can be further categorized, as shown in Figure 1.3-1 above, as performance requirements and design constraints of three different kinds. Performance requirements tell what an item must do and how well it must do it.
Constraints form boundary conditions within which the designer must remain while satisfying the performance requirements. The toolbox offered in this book evolves all performance requirements from the customer need statement, the ultimate system function, through a product functional analysis process that identifies functional requirements.
These functional requirements are allocated to things in the evolving system physical model, commonly a hierarchical architecture, and expanded into performance requirements for that item. Functional analysis provides one set of tools. We will identify three other sets for the three kinds of constraints.
As noted in the earlier figure, verification requirements are not illustrated in the diagram because they are paired with the item requirements in our imagination. One could construct another dimension for design and verification requirements, but it would be very hard to envision and draw in two dimensions. This solution corresponds to the fundamental notion that flows through this whole book that a design requirement should always be paired with a verification requirement at the time the design requirement is defined.
The reason for this is that it results in the definition of much better design requirements when you are forced to tell how you will determine whether or not the resultant design has satisfied that design requirement. If nothing else, it will encourage quantifying requirements because you will find it very difficult to tell how it will be verified without a numerical value against which you can measure product characteristics.
Before moving on to the toolbox for the other categories illustrated in Figure 1.3-1, we must agree on the right timing for requirements analysis. Some designers reacted to the rebirth of the concurrent design approach with acceptance because they believed it meant that it was finally okay to simultaneously develop requirements and designs.
That is not the meaning at all, of course. The systems approach, and the concurrent development approach that has added some new vocabulary to an old idea, seeks to develop all of the appropriate requirements for an item prior to the commitment to design work. We team the many specialists together to first understand the problem phrased in a list of requirements. We then team together to create a solution to that problem in the form of a product design and coordinated process (material, manufacturing, quality, test, and logistics) design.
The concurrency relates to the activity within each fundamental step in the systematic development of product accomplished in three serial steps (requirements, design, and verification) not to all of these steps simultaneously. Even in the spiral sequence we rotate between these steps serially repeatedly.
It is true that we may be forced by circumstances to pursue design solutions prior to fully developing the requirements (identifying the problem), as discussed earlier under development environments, but requirements before design is the intent.
A case where this is appropriate is when we wish to solve a problem before we have sufficient knowledge about the problem and it is too hard to define the requirements in our ignorance.
A physical model created in a rapid prototyping activity can provide great insights into appropriate requirements that would be very difficult to recognize through a pure structured approach. This is what we do in a spiral model, of course, but it really is a case of requirements (to the extent that we understand them) before design repeated as we gain a better understanding of the requirements each spiral.
Using traditional structured analysis
The very first requirement for every system is the customer’s need, which is a simple statement describing the customer’s expectations for the new, modified, or reengineered system.
Unfortunately, the need is seldom preserved once a system specification has been prepared, and thus system engineers fail to appreciate a great truth about their profession. That truth is that the development process should be characterized by logical continuity from the need throughout all of the details of the system.
The models discussed here are designed to expand upon the need statement to fully characterize the problem space. The exposed functionality is allocated to things and translated into performance requirements for those things identified in the physical plane. We then define design constraints appropriate to those things.
All of our verification actions will map back to these requirements. In this series the assumption is made that the problem space will be entered using traditional structured analysis employing some form of functional flow diagram, a requirements analysis sheet in which to capture the requirements and allocate them to product entities, a product entity structure to identify the things the system is composed of, and a set of design constraints models for specialty engineering, environmental, and interface requirements.
The need statement seldom provides sufficient information by itself to ignite this analytical process, so it may be followed by contractor efforts to understand the customer’s need and the related mission or desired action or condition. In military systems this may take the form of a mission analysis. In commercial product developments we may seek to understand customer needs through surveys, focus groups, and conversations with selected customer representatives.
This early work is focused on two goals.
First, we seek to gain expanded knowledge of the need. In the process we seek to ignite the functional decomposition process targeted on understanding the problem represented by the need and making decisions about the top-level elements of the solution by allocating performance requirements derived from top-level functionality to major items in the product entity structure. Some system engineers refer to this process as requirements analysis, but it is more properly thought of as the beginning of the system development process involving some functional analysis, some requirements analysis, and some synthesis and integration.
Second, we seek to validate that it is possible to solve the problem stated in the need. We are capable of thinking of needs that are not possible to satisfy. The problem we conceive may be completely impossible to solve, or it may only be impossible with the current state of the art. In the latter case, our study may be accomplished in parallel with one or more technology demonstrations that will remove technological boundaries, permitting development to proceed beyond the study.
This early activity should include some form of functional analysis as a precursor to the identification of the principal system items. These top-level allocations may require one or more trade studies to make a knowledge-driven selection of the preferred description of the solution.
This process begins with the recognition that the ultimate function is the need statement and that we can create the ultimate functional flow diagram (one of several decomposition techniques) by simply drawing one block for this function F that circumscribes a simplified version of the need statement. The next step is to craft a life cycle model which will be the same for every system they ever develop. But the step to follow is a creative one that cannot be easily prescribed.
Given this ultimate function, we seek to identify a list of subordinate functions such that the accomplishment of the related activities in some particular sequence assures that the need is satisfied. We seek to decompose the grand problem represented by the need into a series of smaller, related problems and determine what kinds of resources could be applied to solving these smaller problems in a way that their synergism solves the greater problem.
If our need is to transport assigned payloads to low Earth orbit, we may identify such lower-order problems, or functions, as illustrated in Figure 1.3-2 below. The particular sequence of lower-tier functions illustrated is keyed to the use of some kind of chemical rocket launched from the Earth’s surface.
If we chose to think in terms of shooting payloads into orbit from a huge cannon, our choice of lower-tier functionality would be a little different, as it would be if we elected the Orbital Science Corporation’s Pegasus solution of airborne launch.
Figure 1.3-2 Space launch system use system function
If our need was the movement of 500,000 cubic yards of naturally deployed soil per day in 1935, we might have thought in terms of past point design solutions involving a steam shovel and dump trucks. At some point in our history, some one considered other alternatives, thus inventing the earth mover.
So, the major functions subordinate to the need are interrelated with the mission scenario, and we cannot think of the two independently. The thought process that is effective here is to brainstorm several mission scenarios and develop corresponding top-level functional flow diagrams (called master flow diagrams or zero level diagrams by some) at the highest level for these scenarios.
We may then determine ways of selecting the preferred method of stating the problem by identifying key parameters that can be used to examine each scenario. This is essentially a requirements analysis activity to define quantified figures of merit useful in making selections between alternative scenarios.
As noted above, we may have to run trade studies to select the most effective problem statement as a precursor to allocation of top-level functionality to things. We may also have to accomplish trade studies as a means to derive a solution based on facts for the most appropriate allocation of particular functions. Finally, we may have to trade the design concept for particular things conceived through the allocation process.
Trade studies are but organized ways to reach a conclusion on a very difficult question that will not yield to a simple decision based on the known facts. All too often in engineering, as in life in general, we are forced to make decisions based on incomplete knowledge. When forced to do so, we should seek out a framework that encourages a thorough, no systematic, evaluation of the possibilities, and the trade study process offers that.
The customer need statement need not be focused on a new unprecedented problem, as suggested in the preceding comments. The customer’s need may express an alteration of a problem previously solved through earlier delivery of a system.
The early study of this kind of problem may involve determining to what extent the elements of existing systems can be applied and to what extent they must be modified or elements replaced or upgraded. This is not a radically different situation. It only truncates the development responsibilities by including within the product entity things that do not require new development.
Those items that do require new development will respond to the structured approach expressed in this chapter at their own level of difficulty. This early analytical process may start with no more than an expression of the customer need in a paragraph of text. The products with which we should conclude our early mission analysis work include the following:
1. A master functional flow diagram (or equivalent diagrammatic treatment) coordinated with a planned mission scenario briefly described in text and simple cartoonlike graphics.
2. A product entity block diagram defining the physical model at the top level.
3. A top-level schematic block diagram or n-square diagram that defines what interfaces must exist between the items illustrated on the product entity block diagram.
4. Design concept sketches for the major items in the system depicted on the product entity block diagram.
5. A record of the decision-making process that led to the selection of the final system design concept.
6. A list of quantified system requirements statements. These may be simply listed on a single sheet of paper or captured in a more formal system or operational requirements document.
So, this mission analysis activity is but the front end of the system development process using all of the tools used throughout the development down stroke. It simply starts the ball rolling from a complete stop and develops the beginning of the system documentation. It also serves as the first step in the requirements validation activity.
Through the accomplishment of this work, we either gain confidence that it is possible to satisfy this need or conclude that the need cannot be satisfied with the available resources at our disposal.
We may conclude, based on our experience, that we should proceed with development, await successful efforts to acquire the necessary resources, focus on enabling technology development for a period of months or years, or move on to other pursuits that show more promise.
In the case of commercial products, this decision process may focus on marketing possibilities based on estimates of consumer demand and cost of production and distribution.
Next in Part 2: Decomposition using structured analysis
About the author:
Jeffrey O. Grady is president of JOG Systems Engineering, Inc. and Top of Form Adjunct Professor, University of California, San Diego, Ca. He was a founding member of the International Council on Systems Engineering (INCOSE).
Used with permission from Newnes, a division of Elsevier. Copyright 2011, from "System Verification" by Jeffrey O. Grady. For more information about this title and other similar books, please visit www.elsevierdirect.com.