Consider other_Fall


System4evel Validation Testing

Continued Design

Fig. 4-8. Iterative Performance Budgeting and Validation. The initial performance budget is a point of departure for later evaluation of segment design and validation testing. The design will converge to a validated value which may require system-level budget adjustments to match the changes.

can meet its requirements. Thus, both procedural and data interfaces must be identified and documented. In addition, mission operations must take into account the spacecraft's system for attitude control to keep from misusing it when scheduling operations. Likewise, in scheduling calibration or alignment, the mission operators must know the sensor payload and other electronic package performance characteristics to prevent accidental maneuvers. System and segment specifications provide system and interface requirements, and lower-level specifications provide design requirements, but in fact, the system engineer and segment designers must interact at all design levels.

It should be noted that initial budget estimates almost never correspond with design considerations at lower levels. Gearly, the early budgets are starting points for negotiation and budget adjustment, to reconcile early system allocations with segment estimates of design and performance. As we reconcile requirements, we should document them in a requirements reference which changes only with full traceability and visibility for all stakeholders such as segment designers, system engineers, and program managers. (A number of tools may be useful: these include the previously noted QFDs, plus software packages ranging from Excel to QSS DOORS and Ascent Logic's RDD 100.) Each of these critical performance parameters matches an established system and segment budget These budgets can and normally do change as developers proceed on the design and validate performance.

At this stage of budgeting, design margin becomes an issue; specifically, how much is reasonable to keep, who knows where it is, and who has the authority to adjust it? Typically, margin is statistical (e.g., two-sigma error requirements), so as it cascades to various levels of design it can produce significant overdesign and cost Design engineers can complicate appropriate adjustment by keeping margin at lower tiers of design, where it tends not to be visible or usable for reallocation. Here prescription cannot substitute for judgment Sometimes, margins can provide robustness against on-orbit failures, but can also cause problems. For example, too much margin in communication links could actually saturate receivers. Key system requirements must also have margins, which we can trade or allocate downward, so as to permit meeting realistic performance and reliability with minimum risk.

Once the first cycle of interactions between system and segments personnel has established the best controlled estimate of key performance budgets we must continue to test the design we are developing. Configurations should be validated via simulations or prototypes. These early exercises in system integration are important in developing a consensus that continues through the initial design phase.

At all times a baseline of common requirements must support this process of analyzing and estimating performance requirements, interacting and negotiating with segment implementors, and validating the key performance drivers early in the design phase. The validation exercises use many specific scenarios or point situations to evaluate performance. Meeting performance budgets in these point situations is comforting, but not sufficient Scenarios designed to stress one aspect of system performance may not provide adequate coverage of other aspects. TTie converging, controlled system requirements captured in requirements documents, interfaces, and standards are often the only reference for system functions and performance. The requirements documentation must match the phase of system development in maturity, but it must always reflect the results of analyses, performance budget negotiations, and validation exercises—faithfully, openly, and quickly.

43 Requirements Documentation and Specifications

In dealing with criteria for requirements documents, we should note the references governing much of today's systems engineering practice in the aerospace industry. With the deletion of most military standards in the United States as contractual requirements, internal documents meet often establish and govern system design and engineering practices. These documents, however, are based largely upon either the previously controlling MIL-STD-499 or its successor (not issued but available in final draft) 499b, or newer civil organization standards. These include the Electronics Industries Association (in conjunction with the International Council on Systems Engineering) EIA/IS 632, Systems Engineering and the Institute of Electrical and Electronic Engineering (IEEE) Trial Use standard, and Application and Management of the Systems Engineering Process, IEEE 1220. Most recently, the International Standards Organization OSO) moved to incorporate systems engineering in the growing body of international standards and to develop ISO Standard 1S288, System Life Cycle Processes, which can serve as a framework for activities in the increasingly global context of the aerospace industry. All of these documents place mission and requirements development and management at the head of system design processes.

Effective requirements documents must be consistent and complete relative to the maturity of the system in its development cycle. Consistency means that we should write a performance requirement only once, keep it in a logical place, and position it appropriately in the hierarchy of established requirements. Completeness depends on the system's phase of development, but it means that at every level of requirement we must ensure that we satisfy the next higher level. As an example of completeness, the geolocation requirement of the FireS at mission should address all error sources both in segment and interface documents.

Requirements Traceability

Requirements must be rigorously traceable as we develop, allocate and decompose or derive them. While computer support tools exist which link and show dependencies and derivations among requirements, the complexity of the product should govern the form of the documentation. This form can range from notebooks for small projects to sophisticated database systems. We must base every design and decision task on requirements, and trade studies at any level must take into account all related requirements, while considering the impact of changes throughout the product (and system) architecture. Any indexing method will suffice, so long as it permits traceability upwards as well as across all elements. Requirements documents should specify this tracing method, however, and the basis for derived requirements must be clearly identifiable. The specific requirements document may be purely electronic, possibly using the database features of the computer tools. Whatever the documentation form, it must have a concise entry for every requirement Each entry should index the documents and specific paragraphs from which we traced the requirement Where analysis produced a derived requirement, it should reference the specific technical memo or report showing the results of the analysis for future use.

Traceability emphasizes the need for effective requirements to be unambiguous and verifiable to avoid misinterpretation and exploitation. Words such as "optimize" or "minimize" in specifications cannot govern die design, and they defy verification.

We should note that requirements reviews are necessary corollaries to design reviews and issues must have the same weight as design issues in readiness decisions by a program to proceed to its next step of development We sometimes call these "gates." Requirements assessments at such review points are critical. They may identify the need to reassess project drivers, including:

• Accelerate or emphasize particular design areas

• Relax design budgets

• Reallocate requirements

• Consider operational work-arounds

• Acknowledge a program slip

• Revise funding profiles

Requirements documentation notionally falls into nine classes (Fig. 4-9). These are often designated as specifications. The figure also shows descriptive or supporting documents which need to be current with the requirements baseline.

Based on mission needs, analyses, and validation exercises, the system requirements document (usually called "system requirements specification") should cover every relevant aspect of what the system should do {functions) and how well it should do it {performance requirements). It should address every aspect of system performance. Since ideally system requirements are the basis for segment requirements, they

* Requirements specifications

Fig. 4-9. Requirements Documentation Hierarchy or System Specification.

* Requirements specifications

Fig. 4-9. Requirements Documentation Hierarchy or System Specification.

should come before the latter. However, once segments are defined, there may be trade-offs required at the system level in response to cost, interface issues, performance limitations, or schedules related to segment designs.

We should note that among the system plans derived from requirements are test plans which will reflect validation and verification of these requirements in qualification and acceptance processes. These characteristically are reflections from test specifications which identify objectives, environments and levels of assembly at which tests are to be performed.

It should be remembered that requirements specifications, at system and lower levels, are potentially subject to change. Therefore, they should be designated, "preliminary" prior to reviews at each stage of design. During formal design phases, while requirements may have to be traded, the specifications must, like design documents, be subject to rigorous change control.

In addition, when requirements specifications at a top level govern more than one system segment, tailoring to accommodate the specific character of a segment may be appropriate. This is particularly so with requirements not directly associated with system performance.

Interface Management

Often, developers overlook or assume external interfaces in the early stages of system development, but they must be carefully considered with the total system architecture. Internal to the system, documenting interfaces between segments, usually through interface control documents or 7CZ>s, is the key to integrating and maintaining relationships between these segments. The system level ICD may be referred to or included in the system specification. Documents covering critical interfaces, such as the spacecraft-to-ground segment for FireSat, can become highly complex. Two guidelines are important in developing and refining interface documents. Each document normally covers only two segments, although multiple elements within segments may require consideration of relationships with other segments. In general, we should avoid designs necessitating such added complexity.

In all cases, we must document these agreements at every level of design, usually in ICDs. At the system level, project managers or system engineers control these, while internal to segments, this is the responsibility of individual element leaders (see Chap. 16). Although the content and format of interface documents vary significantly with products and organizations, elements always addressed include physical and data or signal interfaces and interactions. Thus pin connections and message formats clearly must be defined in interface documents; but the characteristics of gyro drift and star sensor performance (such as nonlinearities of the transfer function, output axis coupling or star sensor noise) require the same definition level so that the mission ground station can correctly calibrate them.

4.4 Summary: The Steps to a Requirements Baseline

We have commented that we cannot prescribe a single means for establishing requirements. This chapter does, however, present guidelines for establishing a requirements baseline in approximately sequential order. This baseline is a reference not only for establishing the premises for functional design, but also a means of continually assessing the impact of design decisions on requirements validation. We can predetermine some requirements, such as constraints on a system. (One example could be the requirement to use existing NASA ground facilities.) We must recognize that requirements can and do change and that flexibility in the design process is necessary to accommodate such change, as in the need to iterate the relationships among design, functions and requirements. Documentation is also a critical aspect of the requirements process, for sustaining the baseline reference, as well as providing the translation for system development of the mission objectives.

TABLE 4-4. Steps to Developing a Requirements Baseline.

1. Identify the customer and user of the product or services. A customer may be a procuring agent but not the ultimate user and both must be understood.

2. Identify and prioritize customer/user objectives and needs for the mission to be accomplished.

3. Define internal and external constraints.

4. Translate customer/user needs into functional attributes and system characteristics. Quality Function Deployment is one tool to do this.

5. Establish functional requirements for system and provide for decomposition to elements.

6. Establish functional flow and representative for its performance of functions.

7. Translate functional attributes into technical characteristics which will become the requirements for the physical system.

8. Establish quantifiable requirements from all the above steps.

9. Through the use of block diagrams expressing interfaces and hardware/software/data relationships for the system level.

10. From the architecture expressed by step 9 at the system level, decompose the functional requirements and characteristics sets to successive lower levels. I.e., the next level defining the basis of the elements of the system.

11. At all the steps above, iteration with preceding activities is necessary both to test the assumptions made and to reconcile higher levels of requirements and functional Implementation.

In the steps which relate to determining requirements, every requirement must have at least the following three components: first, "what" the system is to do (the function); second, "how well" it is to perform the function (performance requirement); last, how we verify the requirement (verification). This last component should be of particular concern to us early in the requirements development process, and we should translate it into a verification and validation plan which will govern the quality and qualification test programs.

Table 4-4 lists ten steps to establishing a requirements baseline in the early ¡díase of a development program. It emphasizes activities concerned with analyzing and validating system requirements versus the design of segments, subsystems, or components. These activities produce a hierarchical baseline of requirements which lead to allocation throughout a decomposed system.

0 0

Post a comment