Requirements Definition

Stanley I. Weiss, Massachusetts Institute of Technology Michael S. Williams, Lockheed Martin Global Telecommunications

4.1 Role of Requirements in System Development Quality Function Deployment—A Tool for Requirements Development

4.2 Requirements Analysis and Performance Budgeting Functioned Analysis; Initial Performance Budgets; Refining and Negotiating the Performance Budgets

4.3 Requirements Documentation and Specifications

4.4 Summary:The Steps to a Requirements Baseline

An early adage in systems engineering was "requirements before analysis, requirements before design." This emphasizes the importance of defining and developing requirements as the front-end process for system design, development, and deployment Regardless of size and complexity, and whatever the formality and scope of this process, it should follow the general pattern described in this chapter.

All requirements must begin with succinct but well defined user and customer mission needs, focusing on the critical functional and operational requirements, without unnecessarily constraining or dictating the design. Section 4.1 shows that the requirements derived from these mission needs and progressively allocated to lower levels of the design are central to meeting a program's performance commitments. Section 4.2 describes the process of analyzing requirements and budgeting performance. As we derive functions and the associated performance requirements, we must document them to provide the basis for developing, producing, deploying, and operating the system, as well as a referencable history governing the development Section 4.3 shows the role of requirements documentation. Finally, Sec. 4.4 summarizes a brief step-by-step method of establishing requirements for typical space mission programs.

This traditional approach to systems engineering is to first define the requirements and then design the system to meet those requirements at minimum cost and risk. More recently a number of authors and organizations have advocated "trading on requirements" as a formal process intended to provide a compromise between what the user wants and what the buyer can afford. This process is discussed in detail by Wertz and Larson [1996].

4.1 Role of Requirements in System Development

To this point, the book has dealt with the mission analysis and concept development process which ideally drives the system design. The mission objectives and system concepts we have adopted have involved five basic measures: (1) required performance, (2) cost, (3) development and deployment schedule, (4) implicit and explicit constraints, and (5) risk. The same measures continue to apply during the entire system engineering process, from concept to implementation. Through this process, we decompose and allocate the central system-derived requirements (sometimes expressed as system specifications) to individual segments or system elements, interfaces between these as well as interfaces external to the system. To define the total system, therefore, users, customers, system engineers, and segment developers must constantly interact Although we initiate the process in a "top-down" fashion, we typically must continually reconcile system level requirements with technology and lower-level design development.

A healthy tension often exists between the user and development communities. Developers may consider the user wedded to current operational approaches and insensitive to how over-specified requirements constrain design. Users often believe that developers favor new technology and ignore the practical needs associated with operating a system and exploiting the mission data. Thus, the developer may establish mission requirements without consulting the user, or the user may produce "non-negotiable stone tablets" and carry them down from the mountain too late or too over-specified for actual use. Because both sides have valid concerns, however, they must cooperate from the start in developing the mission's operational requirements. We may implement this cooperation through so-called IPTs (Integrated Product Teams) involving both users/customers and developers.

Typically, developers wanting to build as soon as possible drive prematurely toward low-level detail. Sometimes they underemphasize the original mission drivers —requirements which dominate performance, cost, and schedule risk. Customers often constrain system development with overly specific requirements at levels below the critical requirements that determine most of a program's cost and risk. While the level of formality and detail may vary depending upon system maturity, complexity, and size, critical requirements must remain in the forefront during design, development, and validation of the system.

Overzealous requirements can also find their way into mission statements. For example, a user may specify the scan rate and swath width under payload and coverage performance. Clearly, these constraints on sensor design and constellation are inappropriate in this case, prior to establishing a system which meets the key requirements, i.e., timely data with enough accuracy and resolution. Specifications on launch rate, launch responsiveness, and spacecraft reliability are also common. But so long as a system meets availability and maximum outage needs, the developer should be able to allocate requirements for reliability, maintenance, and replacement Mission requirements concerning launch, operation, or maintenance may establish the design domain, but not dictate the design. On the other hand, the user must also be a party to the system design as it converges, to identify design characteristics likely to produce operational problems.

Table 1-5 in Sec. 1.4 shows essential requirements for the FireSat mission. These requirements neither dictate nor impose needless constraints on design, but they do specify what is essential to perform the mission and operate the system. Hie table contains enough information to derive the specific design characteristics with sufficient controls on the user's essential requirements. Also, the table includes no unverifiable terms or goals such as "maximize," "sufficient," or "optimize," because these words have no quantifiable interpretations. Requirements which we are asked to implement only if no "impact" results, are in fact goals and we cannot treat them as design drivers. Every meaningful requirement bears cost and will have an impact

Constraints are those requirements for a system which we cannot trade, usually under any circumstances. They may pertain to performance when levels of capability of a system must have a certain value to be useful. One example is the necessity for a resolution level of an optical or RF signal, above which the desired information could not be derived or would not be sufficiently better than existing systems to justify new development A related, fixed requirement could also be coverage and timeliness of data, clearly a major Consideration for FireSat Another might be cost—a constraint increasingly important to the financial success of a new mission. Thus, if a cost ceiling of N millions could not be met for a new development, the feasibility, design attributes or method of achieving a mission would be directly affected. The term "design to cost" applies directly to a cost constraint Schedule may also be a constraint, and many technically worthwhile projects get scrubbed because developers could not solve some problems soon enough to be competitive—this is often called a "time to market" constraint Others, but by no means all, include environmental and safety issues, legal and political mandates, fixed asset usage, involvement of geographically distributed or foreign offset contractors.

An alternative view of "goals" vs. "requirements" is that the former represent design margin. Any firm requirement must result in a level of margin in the design, and we can regard the "goal" as specifying the desired margin. As the design matures, the margin represents the trade space available to decision-makers. The user must ultimately decide whether the additional performance is worth its associated incremental cost

Designers often focus on performance areas, such as operating the payload and distributing the mission data, and underemphasize the more mundane requirements, such as availability and accommodation to the external environment Yet these can be critical to cost and risk. For example, availability can demand increased component reliability and therefore raise development costs. It can drive maintenance concepts, including replenishment and on-orbit support It can also affect production time, especially for critical components. Likewise, ignoring external interfaces can produce a system design without the external support needed to deploy and operate the mission.

When space systems perform more than one mission, planners must develop requirements which account for each mission. For example, the IR surveillance payload on FireSat may serve other users with its performance in IR imaging and radiometric measurement. If the increased cost and risk are acceptable, their requirements could lead to more payload bands, added coverage, and added distribution requirements. That is why we must establish all valid missions early in requirements definition, or we should incorporate accommodations for new missions in future upgrades to a system's capabilities.

While we must address system requirements throughout all aspects of the development cycle, the role and characteristics of requirements change in each development phase. Consequently, we should use specific structure and language early in the process without premature detail. Table 4-1 shows how the requirements converge during system development Concept development must continue to reflect the driving requirements, including internal and external interfaces. Top level or mission requirements drive early activities—developing the system concept and assessing technology. We must be prepared to modify these as the concepts and design mature and cause re-evaluation.

TABLE 4-1. Evolution of Requirements Activities and Products. Each development phase tends to focus on specific requirement and design considerations.

Needs Analysis

• Defining mission requirements

• Defining environment

• Identifying mission drivers and constraints

• Technology programs

Concept Development

• Identifying critical driving requirements and associated risks

• Developing operations and design concepts

• Cost estimates

• Functional analysis and major interfaces

• System studies and simulations

• Prototyping and assessing technology

Concept Validation

• Tailored system and segment definitions

• Preliminary internal Interface requirements

• Preliminary system standards

• Preliminary requirements flowdown

• Integrated system validation including test planning

• Transition planning

• Validating technology

Design and Implementation

• Detailed requirements flowdown

• Developing formal design documentation and Interface control

• Integrating and testing the system

• Demonstrating and verifying the system

• Test procedures and reports

During concept development, we normally cany forward and evaluate many design options, so we need to specify and document requirements in critical areas in a flexible fashion. We generally don't require forma] specifications complying with acquisition standards and serving as the legal basis for the system until full-scale development At that point, we need to have solved the critical program risk areas. Until then, however, there are no set prescriptions for the requirements products other than what the program finds applicable and workable.

We should, of course, recognize that the spectrum of valid approaches for requirements development and application is broad. Significant differences exist among NASA, DoD, ESA, NASDA and other development agencies, as well as their contractors, and even among locations within the same organization. For example, all

NASA organizations conduct Phase A and Phase B studies which result ultimately in a Request for Proposal, including top-level specifications. But they vary widely in their approaches to conducting these studies and their requirements products. For DoD organizations, the rituals of MIL-STD-499 have often overwhelmed arguments based on unique program needs, and requirements become over-detailed and over-formal-ized too early. In full-scale development, most of the requirements activities center on integrating program interfaces (inter-segment and external to the system) and resolving ways of carrying out specific requirements at segment level. Solving major system issues at this point can be expensive and risky. Usually, we freeze requirements once the system passes into production. Rarely can a program afford to accept changes at this point, opting far more often to accept limits to the system as designed or to defer the change to a later upgrade.

We often hear that requirements drive technology programs, but in fact, new technologies frequently make systems possible. For example, improvements in bandwidth for communications processing have permitted greater use of real-time data downlinks. But relying on new technologies or production abilities can be risky. New technologies which allow us to reduce design specifications for power, weight, and volume can improve system performance and cost We must, however, monitor the technology and production base and carry backup plans, in case program risk management demands changes to basic design requirements and interfaces to reallocate performance.

Although the success of every program hinges on performance, cost, and schedule, cost is typically the most constraining. One reaction to cost emphasis is the design-to-cost practice by which a fixed dollar amount affects possible design solutions. Thus, progressive design development may, under cost limitations, cause review of requirements, with attendant trades between cost and performance. This has clearly been a factor in the design and functions of the International Space Station (ISS). We can do much to control program costs while analyzing requirements. For instance, over-specified requirements may be "safe," but evaluation of necessary design margins early via close interaction between the developer and the requirements specifier permits us to make timely trades.

As discussed earlier, defining requirements without attending to production and operational support is also costly. Thus, with every major decision, we must consider which performance option meets essential requirements while minimizing cost

Sometimes, standardizing can reduce costs and improve operability. For example, particularly in the commercial communications industry, use of a "standard bus" or basic vehicle can yield lower costs for many programs. We sometimes call this process "platform-based design." In addressing approaches to standardization, however, we must always consider trade-offs between reduced cost and increased development risk.

As shown in Chaps. 1-3, mission development is an iterative process. Although each stage seems to cascade forward without hesitation, each requires significant feedback and adjustments. Typically, most of die feedback occurs between adjacent phases of development However, some situations may demand feedback across multiple phases, such as when an element design falls short on a particular requirement and causes a change in the design and operations concept, and possibly a change to the original schedule.

An aside on requirements and cost control is imperative here. Solutions to constraining cost (e.g., design-to-cost specification, imposed standardization) are difficult to implement in truly innovative space systems. In fact, well-intentioned approaches early in the design cycle may result in serious cost growth later in design and operation. But this difficulty in explicit cost control does not imply we should avoid the challenge. The growth in cost from the early estimates performed during Concept Development is typically driven by a few controllable problems. First, not fully accounting for all elements of cost in these early estimates is common. Frequently, not consulting with designers and manufacturers who will develop the system and the operators who will control the system results in misunderstanding cost or missing elements of cost Second, overspecifying the system inhibits trades which we can focus on cost reduction. Finally (and probably the most prevalent problem), heavy and uncontrolled changes to requirements as the system proceeds through latter stages of design can create major growth in cost due to constant redesign and related material and time waste. Worse, the loss of a fully understood system baseline becomes more likely and potentially very costly later in the program. The process of defining and flowing down requirements affects cost more than any other program activity.

Then, too, on several occasions, customer requirements accepted without rational challenge have led to unjustifiable project costs and, in two well-documented cases, eventually caused cancellation. One of the authors once had the opportunity to convince a customer that a new requirement that was inserted after program start would not enhance the mission; millions of dollars were saved and the customer's belief in our integrity was solidified.

4.1.1 Quality Function Deployment—A Tool for Requirements Development

While there are several structured approaches to developing requirements from the customer/user needs, the most commonly used tool is Quality Function Deployment, or QFD. Its application is not product limited; we also use it in developing of requirements for processes and services.

Quality Function Deployment derives from three Japanese words or characters meaning (1) quality or features, (2) function or mechanization, and (3) deployment or evaluation. Symbolically we define the combination as "attribute and function development" It involves a series of matrices organized to define system characteristics and attributes and can be applicable over multiple areas of decomposition. The first level, connecting customer needs or requirements to technical attributes or requirements, we often called the House of Quality and configure it in its simplest form as in Fig. 4-1. We often call the left hand column the "Whats" (at this first level, this is called the "voice of the customer") and we call the horizontal attributes the "Hows" This relationship will become apparent as the "Hows" define the means for fulfilling the "Whats."

Weightings are applied to the "what" side of the matrix and are usually graded in three levels to help establish priorities of needs and related technical attributes. While of value in trading requirements, the primary use at this stage should be to define trade space.

Figure 4-2 shows a simplified application to FireS at Referring to Table 1-5 and illustrating with only a few of the identified mission needs, an abbreviated matrix shows some five needs and six relevant attributes. Note the conflicts between competing satellite orbits which could potentially satisfy key requirements. This suggests cariying out extensive analysis and trades. Note also the relative priorities emphasizing technical attributes which assure timely coverage.

Fig. 4-1. Abbreviated House of Quality.

x^^s^ Technical ^S. TSw Attributes

CustomerX^p^v Needs

Low Attitude

0 0

Post a comment