Hardware/software design requirements planning: Part 3 - Performance requirements analysis - Embedded.com

Hardware/software design requirements planning: Part 3 – Performance requirements analysis

Performance requirements define what the system or item must do and how well it must do those things. Precursors of performance requirements take the form of function statements or functional requirements (quantified function statements). These should be determined as a result of a functional analysis process that decomposes the customer need as noted earlier using an appropriate flow diagramming technique.

Many organizations find that they fail to develop the requirements needed by the design community in a timely way. They keep repeating the same cycle on each program and fail to understand their problem.

This cycle consists of receipt of the customer’s requirements or approval of their requirements in a specification created by the contractor, followed by a phony war on requirements where the systems people revert to documentation specialists and the design community creates a drawing release schedule in response to management demand for progress. As the design becomes firm, the design people prepare an in-house requirements document that essentially characterizes the preexisting design.

Commonly, the managers in these organizations express this problem as, “We have difficulty flowing down system requirements to the designers.”

The problem is that the flowdown strategy is only effective for some specialty engineering and environmental design constraints. It is not a good strategy for interface and performance requirements. It is no wonder these companies have difficulty.

There is no one magic bullet for requirements analysis. One needs the whole toolbox described in this series. Performance requirements are best exposed and defined through the application of a structured process for exposing needed functionality and allocation of the exposed functionality to things in the product entity structure. You need not stop at the system level in applying this technique. It is useful throughout the hierarchy of the system.

Performance requirements are traceable to (and thus flow from) the process from which they are exposed much more effectively than in a vertical sense through the product entity structure.

They trace to the problem or functional plane. Constraints are generally traceable within the physical or solution plane. This point is lost on many engineers and managers, and thus they find themselves repeating failed practices indefinitely.

Given that we have an effective method for identifying valid performance requirements as described under functional analysis above, we must have a way to associate them with quantitative values. In cases where flowdown is effective, within a single requirement category, such as weight, reliability, or cost, a lower-tier requirement value can be determined by allocating the parent item value to all its child items in the product entity structure.

This process can be followed in each discipline, creating a value model for the discipline. Mass properties and reliability math models are examples. In the case of performance requirements, we commonly do not have this clean relationship, so allocation is not always effective in the same way.

Often the values for several requirements are linked into a best compromise, and to understand a good combination we must evaluate several combinations and observe the effect on selected system figures of merit like cost, maximum flight speed of an aircraft, automobile operating economy, or land fighting vehicle survivability.

This process can best and most quickly be accomplished through a simulation of system performance where we are allowed to control certain independent parameters and observe the effects on dependent variables used to base a selection upon. We select the combination of values of the independent variables that produces the best combination of effects in the dependent variables.

Budget accounts can also be used effectively to help establish sound values for performance requirements. For example, given a need to communicate across 150 miles between the Earth’s surface and a satellite in low Earth orbit, we may allocate gain (and loss) across this distance, the antenna systems on both ends, connecting cables, receiver, and transmitter. Thus the transmitter power output requirement and the receiver sensitivity requirement are determined through a system-level study of the complete communications link.

Design Constraints Analysis
Design constraints are boundary conditions within which the designer must remain while satisfying performance requirements. All of them can be grouped into the three kinds, described below.

Performance requirements can be defined prior to the identification of the things to which they are ultimately allocated. Design constraints generally must be defined subsequent to the definition of the item to which they apply. Performance requirements provide the bridge between the problem and solution planes through allocation.

Once we have established the product entity structure, we can apply three kinds of constraints analysis to these items. In the case of each constraint category, we need a special tool set to help us understand in some organized way what characteristics we should seek to control.

Interface Requirements Analysis. Systems consist of things. These things in systems must interact in some way to achieve the need. A collection of things that do not in some way interact are a simple collection of things, not a system. An interface is a relationship between two things in a system.

This relationship may be completed through many different media, such as wires, plumbing, a mechanical linkage, or a physical bolt pattern. These interfaces are also characterized by a source and a destination—that is, two terminals, each of which is associated with one thing in the system.

Our challenge in developing systems is to identify the existence of interfaces and then to characterize them, each with a set of requirements mutually agreed upon by those responsible for the two terminals. Note the unique difference between the requirements for things in the system and interfaces. The things in systems can be clearly assigned to a single person or team for development. Interfaces must have a dual responsibility where the terminals are things with different responsibilities.

This complicates the development of systems because the greatest weakness is at the interfaces, and accountability for these interfaces can be avoided by one terminal party, the other, or both if the program does not apply a sound interface development management approach.

The opportunities for accountability avoidance can be reduced by assignment of teams responsible for development as a function of the product entity structure rather than the departments of the functional organization.

This results in perfect alignment between the product cross-organizational interfaces (interfaces with different terminal organizational responsibilities) and the development team communication patterns that must take place to develop them. Responsibility and accountability is very clear.

The reader is encouraged to refer to the author’s System Requirements Analysis for a thorough discussion of schematic block and n-square diagramming techniques. As a result of having applied these techniques during the product entity structure synthesis of allocated functionality, the system engineer will have exposed the things about which interface requirements must be written.

Once again, the purpose of our tools is to do just this, to help us understand what to write requirements about. The use of organized methods encourages completeness and avoidance of extraneous requirements that have the effect of increasing cost out of proportion to their value.

Once it has been determined what interfaces we must respect, it is necessary to determine what technology will be used to implement them, such as electrical wiring, fluid plumbing, or physical contact, for example. Finally, the resultant design in the selected media is constrained by quantified requirements statements appropriate to the technology and media.

Each line on a schematic block diagram or intersection on an n-square diagram must be translated into one or more interface requirements that must be respected by the persons or teams responsible for the two terminal elements.

The development requirements for the two terminal items may be very close to identical, such as a specified data rate, degree of precision, or wire size. The product requirements, however, will often have an opposite nature to them, such as male and female connectors, bolt hole or captive bolt and threaded bore hole, or transmitter and receiver.

Environmental Requirements Analysis
One of the most fundamental questions in system development involves the system boundary. We must be able to unequivocally determine whether any particular item is in the system or not in the system.

If it is not in the system, it is in the system environment. If an item is in the system environment, it is either important to the system or not. If it is not, we may disregard it in an effort to simplify the system development. If it is important to the system, we must define the relationship to the system as an environmental influence.

We may categorize all system environmental influences in the five following classes:

1. Natural environment —Space, time, and the natural elements such as atmospheric pressure, temperature, and so forth. This environment is, of course, a function of the locale and can be very different from that with which we are familiar in our immediate surroundings on Earth, as in the case of Mars or the Moon.

2. Hostile systems environment —Systems under the control of others that are operated specifically to counter, degrade, or destroy the system under consideration.

3. Noncooperative environment —Systems that are not operated for the purpose of degrading the system under consideration but have that effect unintentionally.

4. Cooperative systems environment —Systems not part of the system under consideration that interact in some planned way. Generally, these influences are actually addressed as interfaces between the systems rather than environmental conditions because there is a person from the other system with whom we may cooperate to control the influences.

5. Induced environment —Composed of influences that would not exist but for the presence of the system. These influences are commonly initiated by energy sources within the system that interact with the natural environment to produce new environmental effects.

As noted above, cooperative environmental influences can be more successfully treated as system interfaces. Hostile and noncooperative influences can be characterized through the identification of threats to system success and the results joined with the natural environmental effects.

The induced environment is best understood through seeking out system energy sources and determining if those sources will interact with the natural environment in ways that could be detrimental to the system. The natural environment is defined in standards for every conceivable parameter for Earth, space, and some other heavenly bodies.

The challenge to the system engineer is to isolate on those parameters that are important and those that are not, and then to select parameter ranges that are reasonable for those parameters that will have an impact on our system under development. The union of the results of all of these analyses form the system environmental requirements. It is not adequate to stop at this point in the analysis, however.

Systems are composed of many things that we can arrange in a family hierarchy. Items in this hierarchy that are physically integrated in at least some portions of their system operational use, such as an aircraft in an aircraft system or a tank in a ground combat system, can be referred to as end items.

We will find that these end items in operational use will have to be used in one or more environments influenced by the system environment but, in some cases, modified by elements of the system. For example, an aircraft will have to be used on the ground, in the air through a wide range of speed and altitude, and in hangers.

These are different environments that we can characterize as subsets of the system environment definition. The best way to do this is to first define the system process in terms of some finite number of physical analogs of system operation. We may then map the system end items to these process steps at some level of indenture.

Next, we must determine the natural environmental subsets influencing each process step. This forms a set of environmental vectors in three-space. In those cases where a particular end item is used in more than one process, we will have to apply some rule for determination of the aggregate effect of the environments in those different process steps. The rule may be worst case or some other one. This technique is called environmental use profiling.

Definition of component requirements
The final step in environmental requirements analysis involves definition of component environmental requirements. These components are installed in end items. The end items can be partitioned into zones of common environmental parameters as a function of the end item structure and energy sources that will change natural environmental influences.

We define the zone environments and then map the components into those zones. In the process, we may find that we have to provide an environmental control system in one or more of the zones to reduce the design difficulty of some components.

We may also conclude, given that we must have at least one such system, that we should relocate one or more components into the space thus controlled. So, the environmental requirements for a component are predetermined by the zone in which it is located, and we may derive its environmental requirements by copying (cloning) the zone requirements.

Component environmental requirements may have to be adjusted for shipping and other noninstalled situations. In summary, this set of three tools (standards, environmental use profiling, and end item zoning) may be used to fully characterize the environmental requirements for all system items from the system down through its components.

In all cases, we must be careful to phrase these requirements in terms that recognize our inability to control the ultimate natural environment. The discussion above focuses on the effects of the environment on our system. We must also consider the effects of our system on the natural environment.

This is most often referred to as environmental impact analysis. It has not always been so, but today we must be sensitive to a bidirectional nature in our environmental specification.

Our efforts in the distant past were very small compared to the tremendous forces of nature. Today, the scope of our access, control, and application of energy and toxic substances is substantial, and potential damage to local and regional natural environments is a real concern.

Environmental impact requirements are commonly defined in laws and regulations. We can determine in what ways the environment will be exposed to system-generated stress by evaluating all system energy sources, toxic substances used, and any exhaust products.

The author prefers to classify this topic under the banner of environmental requirements analysis, but it could be thought of as a specific specialty engineering discipline.

These effects must be considered both for the life of the system during its use and, perhaps more importantly, for its disposition following its useful life. There can be no better example of how difficult and dangerous this can be than the case of the nuclear weapons cleanup process seriously begun in the 1990s after the end of the nuclear confrontation between the USSR and the United States lasting 40 years.

Throughout the confrontation, both sides were so concerned with survival and the urgency of development that little thought was given to the problems that they may be causing for the future. By the time the problem could no longer be ignored, it was so substantial that a solution was more difficult than the complex scientific and technical problems that had to be solved to create it.

One can be very unpopular expressing interest in system disposition during the heady system development times, especially with one’s proposal or program manager. But, customers will increasingly be concerned with this matter as the problems we attempt to solve become increasingly more general and their scope more pervasive. Computer software environmental requirements are limited.

User environment
The natural environment impinges on the computer hardware within which the software functions but does not in any direct way influence the software itself in the absence of hardware deficiencies that cause computer circuits to fail due to environmental stresses.

The context diagram used to expose the boundary between the software and its environment is the best place to start in determining the appropriateness of any environmental influences directly on the software.

One such requirements category of interest commonly is the user environment, describing how the user will interact with the software. These influences could alternatively be covered under the heading of interface requirements. One must first determine whether the operator is within or outside the system, however, and this is no small question.

The principal element in the software environment is in the form of cooperative systems exposed through interface analysis. What other software and hardware systems will supply information or use information created by the system in question?

The noncooperative system component may exist in very complex software systems but is hard to characterize in terms of an example. A very common and increasingly important environmental factor is the hostile environment. This matter will more commonly be addressed as the specialty engineering discipline called security engineering, however, than as an environmental consideration.

Specialty Engineering Requirements Analysis . The evolution of the systems approach to development of systems to solve complex problems has its roots in the specialization of the engineering field into a wide range of very specialized disciplines for the very good reasons noted earlier.

Our challenge in system engineering is to weld these many specialists together into the equivalent of one all-knowing mind and applying that knowledge base effectively to the definition of appropriate requirements, followed by development of responsive and compliant designs and assessment of those designs for compliance with the requirements as part of the verification activity.

There are many recognized specialized disciplines, including reliability, maintainability, logistics engineering, availability, supportability, survivability and vulnerability, guidance analysis, producibility, system safety, human engineering, system security, aerodynamics, stress, structural dynamics, thermodynamics, and transportability.

For any specific development activity, some or all of these disciplines will be needed to supplement the knowledge pool provided by the more general design staff.

Specialty engineers apply two general methods in their requirements analysis efforts. Some of these disciplines use mathematical models of the system, as in reliability and maintainability models of failure rates and remove and- replace or total repair time.

The values in these system-level models are extracted from the model into item specifications. Commonly these models are built in three layers. First, the system value is allocated to progressively lower levels to establish design goals. Next, the specialty engineers assess the design against the allocations and establish predictions. Finally, the specialists establish actual values based on testing results and customer field use of the product.

Another technique applied is an appeal to authority in the form of customer-defined standards and specifications. A requirement using this technique will typically call for a particular parameter to be in accordance with the standard.

One of these standards may include a hundred requirements, and they all flow into the program specification through reference to the document unless it is tailored.

Specialty engineers must, therefore, be thoroughly knowledgeable about the content of these standards; familiar with their company’s product line, development processes, and customer application of that product; and knowledgeable about the basis for tailoring standards for equivalence to the company processes and preferred design techniques.

To read Part 1 , go to: Laying the ground work
To read Part 2, go to: Decomposition using structured analysis
Next in Part 4 : Computer software approaches

Jeffrey O. Grady is president of JOG SystemsEngineering, Inc. and Top of Form Adjunct Professor, University of California,San Diego, Ca. He was a founding member of the International Council on SystemsEngineering (INCOSE).

Used with permission from Newnes, a division of Elsevier.Copyright 2011, from “System Verification” by Jeffrey O. Grady. For more informationabout this title and other similar books, please visit www.elsevierdirect.com.

This article provided courtesy of Embedded.com andEmbedded Systems DesignMagazine. Sign up for subscriptions and newsletters

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.