next up previous contents
Next: 7 Architecture Design Process Detailed Description Up: Appnotes Index Previous:5 RASSP Design Process Description

RASSP Methodology Application Note

6.0 System Design Process Detailed Description

A similar description to the one that follows is in the System Design Process Application Note. This application note also discusses the design automation tools that were developed to support this activity. It also contains an application description for the use of the process and tools on one of the benchmark programs. If your interest is in the System process flows and a general description of the tasks and products of this part of the design process then explore this discussion further. If your interest is more to the details of what and how this part of the process works along with the EDA tools, then proceed to the application note.

The RASSP methodology provides several key improvements over traditional system processes. The output of the system definition process is a set of executable specifications for the signal processor design activity. The definition and functions encompassed by the executable specification is receiving focused attention on the RASSP program. A hierarchical set of simulations is performed at each design level, and the results of these simulations are back annotated in the higher-level simulations. In RASSP, we emphasize considering LCC early in the design process and the reuse of library elements at the system and subsystem-levels.

The system design process is a front-end engineering task in which signal processing concepts are developed to meet customer requirements and top-level tradeoffs are performed to define the signal processing subsystem requirements. Depending upon one's perspective, a system could represent a platform, sensor system, signal processor or processing board. For RASSP, a system is defined at the signal processor level. For this document, a "system" represents a signal processing system and a "subsystem" represents a major component of the signal processor. The system design process for RASSP starts after the requirements have been established for the signal processing system. A multidiscipline Product Development Team (PDT) performs the functions specified by the system design process. The specific roles of the PDT team members are described in Section 6.4.3.

The inputs to the system design process include all the customer documentation detailing the processing system specification. The outputs of this process include the functional, performance, and physical requirements for each signal processing subsystem. Typical signal processing requirements include system mode functional descriptions (search, track, waveforms, algorithms), performance requirements (processing gain, timeline and precision requirements), physical constraints (size, weight, power, cost, reliability, maintainability, testability, etc.), and interface requirements. The system definition process is iterative, requiring constant interaction with the customer and the product development team members as the impact of system-level decisions on LCC are significant.

The system design process is shown in Figure 6 - 1. Top-level trade-offs are performed to determine how the system will operate and what set of subsystems are required. System-level functional and timeline simulations are developed to characterize system behavior. The output of the system design process is a set of functional, performance and physical requirements for each subsystem. As the subsystem designs progress, key subsystem parameters are back annotated, and system-level simulations are re-run to ensure that performance is maintained.

Figure 6 - 1: System Design Process.

Subsystem requirements are constantly monitored to make sure the development risks are balanced among the subsystems. There is a feedback path back to the system-level from each subsystem design; this path is used whenever cost-effective subsystem designs cannot be obtained. System requirements are then reexamined and new analyses is performed to determine a refined partitioning of the requirements. By clicking on the system design process box in the IDEF figure the next level of system design can be explored. The IDEF process model of this second level will be presented and textual descriptions of each subprocess may be obtained by clicking on the text button or by clicking on the link below. This level consists of three main subprocesses:

  1. Section 6.1 Systems Requirements Analysis and Refinement

    The operational and procurement requirements are initially examined to ensure that all requirements are well understood. There is close interaction with the customer to clarify any confusion with the requirements. A traceable path must be established when requirements are allocated to functions and components. Both mission and threat analyses are performed to understand how the signal processing system should behave. The system is defined by describing the system modes, functions and interfaces. Measures of effectiveness (cost, performance, risk, testability, etc.) are established for the system to provide metrics to compare different system configurations. Operational scenarios are also develop to assist in determining system performance.

  2. Section 6.2 Functional Analysis

    The system is decomposed into its functional elements while establishing the requirements. This functional analysis is performed by determining what functions are required to implement each system requirement. Functions are described by defining the inputs to the function, the algorithm performed by the function, and the outputs of the function. Constraints and timing requirements are identified for each function. The top-level system behavior is modeled to determine the functional performance of the system. Signal-to-noise ratios, detection ranges, probability of detection, and probability of false alarms are several examples of system-level behavior for a signal processing system. System test and maintenance concepts are developed. All functions within the system must be traced back to the system requirements.

  3. Section 6.3 System Partitioning

    The functions of the system are allocated to subsystems as the functional requirements are established. At this point, various system configurations are developed and characterized to determine the baseline system. Trade-off analyses are typically performed for the following areas: reliability, availability and maintainability; testability; LCC; schedule and technical risk; integrated logistics support; human factors; and system safety. All system requirements must be traceable to both functions and subsystems. The output of the system partitioning process is a set of executable specifications for each signal processing subsystem.

    Other items that need to be considered during this phase of the process are considered below:

    6.1 System Requirements Analysis

    System requirements analysis converts a user need into a combination of elements that satisfies that need. It involves analyzing customer documentation and conducting discussions with the customer to refine the purpose and manner in which users will operate the system. It is designed to determine what the system is to do and how the system is to be used. The system requirements are thus developed from a user's point of view. External interfaces to the system, usage scenarios, and capacities are developed, and methods are determined to verify each requirement statement. The process iterates with functional analysis and system partitioning efforts to assess feasibility and to structure the requirements cost-effectively. Unnecessary implied designs should not be incorporated in the requirement statements. This iteration also makes the verification process more accurate and cost effective by eliminating ambiguity in the requirements statements.

    Baselines are used to control the development process. The functional baseline is established following the system design phase, which prescribes:

    • all functional and performance characteristics
    • all tests required to demonstrate achievement of functional and performance characteristics
    • interfaces between subsystems and their functional characteristics
    • design constraints.
    Although the functional baseline is not established during the system requirements analysis phase, preliminary data is provided. The RASSP reuse library is examined to determine whether any functional elements are applicable for this baseline. Several baselines can be maintained simultaneously while system alternatives are being evaluated. Typically, the initial baseline is in the form of a requirements database. Formal configuration management is not used until a single baseline has been established. The baseline will be reopened whenever the subsequent design, integration, or test activities indicate the requirements cannot be supported or when customer change requests result in a modification to the requirements.

    By clicking on the system requirements analysis and refinement process box in the IDEF figure, the last level of the system design process can be explored. The IDEF process model of this third level will be presented and textual descriptions of each subprocess may be obtained by clicking on the text button or by clicking on the link below. The system requirements analysis process is composed of three primary subprocesses:

    6.1.1 System Requirements Development

    In this process step, the system requirements are checked for completeness and consistency using the steps in Figure 6 - 2. Each step is performed iteratively to determine the system requirements. A complete set of customer documents must be used to determine the system requirements because the contractor must understand how users intend to use the system. The system gets defined in terms of its system modes, states, functions, and interfaces. Trade-offs establish alternative performance and functional requirements to meet customer needs. Any potential conflicts in the trade-off results with the system requirements are resolved. A workoff plan is created for all TBD/TBR items that identifies the responsible individual, schedule for resolution, risk analysis, and key trade-offs to be performed. Traceability of system requirements and decisions ensures that the trade-off decisions made in generating the system requirements can be tracked and that these requirements are completely and accurately reflected in the final design. Traceability is also used to assess the impact of changes at any level of the system. All system-level requirements are traced to their source during this process. --

    Figure 6 - 2: System requirements analysis

    6.1.2 System Specification Generation

    The signal processing system specification contains:
    • the technical requirements for the system
    • allocates requirements to functional areas
    • documents design constraints
    • defines interfaces between functional areas
    It also states all necessary requirements in terms of performance, including test provisions to ensure that all requirements are achieved. Essential physical constraints and requirements for application of any known specific equipment must be included. The use of the system engineering tools, described in the system process application note, assist in automating this task.

    6.1.3 System Requirements Review

    A System Requirements Review (SRR) is conducted to ascertain the adequacy of the contractor's efforts in defining the processing requirements. It is conducted when a significant portion of the system functional requirements have been established.

    6.2 System Design Functional Analysis

    Concurrent with the establishment of the system requirements, the system configuration (the components within the processing system) is defined through iteration of the functional analysis and the system partitioning processes. Functional analysis is designed to identify the functions, decompose the functions into requirements, and allocate these requirements to lower-level functions. System partitioning takes the functions from the functional analysis process and allocates them to entities within candidate configurations. These allocations are analyzed to determine the performance, cost, and schedule impacts of the alternatives. Unsuccessful allocations and configurations are eliminated. Multiple other alternatives are carried to the next phase as the final best configuration may not be determinable until the Architecture design phase is completed.

    The functional analysis process describes the requirements as a set of verifiable (simulatable) statements that can be used as a basis for system design. The functions, constraints and performance statements are decomposed to a detailed level that can be allocated to specific candidate design configurations. The output of this process is a functional baseline that describes the system functionality and is the basis for eventual customer sell-off. The functional analysis process is shown in Figure 6 - 3. This process is composed of two steps, functional identification and functional decomposition, which are described in the following paragraphs.

    Figure 6 - 3: System Functional Analysis and Partitioning

    By clicking on the functional analysis process box in the IDEF figure, the last level of the system design process can be explored. The IDEF process model of this third level will be presented and textual descriptions of each subprocess may be obtained by clicking on the text button or by clicking on the link below. The system functional analysis process is composed of three primary subprocesses:

    6.2.1 Functional Identification

    The functional identification process translates system requirements, customer heritage, and customer rationale into functional block diagrams that are used by subsequent processes to create and evaluate system configurations. This step refines and decomposes the functions identified from the system requirements analysis step. Functional identification also develops the design constraints under which the system must operate. Functional elements within the RASSP reuse library are examined to determine whether existing library elements can be used. The key steps in the functional identification process include:
    • analyzing system requirements
    • identifying top-level system functions
    • developing functional block diagrams
    • identifying constraints
    • establishing performance timelines
    • developing alternative functional configurations
    • evaluating the functional baseline for consistency and completeness
    • performing traceability of the functions to the system requirements
    • providing the rationale for the top-level functional description

    6.2.2 Functional Decomposition

    Functional decomposition creates lower-level functions, constraints, performance, and interfaces from those that currently exist. This more detailed information is used by the subsequent partitioning and architectural trade process. This process is structured and accomplished iteratively to eliminate poor allocation decisions as early in the analytic process as possible. Functional elements within the RASSP reuse library are examined to determine whether existing library elements can be used. If any of the system functions cannot be described by existing library elements, then we identify new primitives for development. The specific steps in functional decomposition include:
    • performing trade studies to eliminate poor system configurations
    • identifying the next-tier functions and functional block diagrams
    • identifying next-tier constraints
    • establishing next-tier performance timelines
    • performing traceability to the upper level tier functions and requirements
    • providing the technical rational for the functional decomposition.

    6.2.3 Informal Functional Analysis Design Review

    At this time no formal design review is required with the customer. However. it is recommended that an internal informal review be conducted to examine the decomposition that has been accomplished and the initial partitioning that is concurrently being performed. This peer review ensures that requirements and functionality have not been overlooked and that assumptions are valid before beginning the architecture design process phase.

    6.3 System Partitioning

    During the system partitioning process, we define and evaluate candidate system configurations to determine which configurations most effectively meet the functional and system requirements. As many configurations as feasibly possible should be evaluated in enough detail to rank the alternatives. A structured method must be developed to quickly identify the feasibility of a specific candidate configuration. We typically develop measures of effectiveness for a specific program as the basis to evaluate trade studies. The output of the system partitioning process is the set of functional, performance, and physical requirements for each subsystem in the baseline configurations. For RASSP, an executable specification for each signal processing subsystem is the starting point for the architecture selection process. This executable specification is the first virtual prototype (VP0) of the subsystem. As shown in Figure 6 - 3, the system partitioning process is composed of three subprocesses: functional allocation, performance verification, and system design review. Each of these subprocesses is described in the following paragraphs.

    6.3.1 Functional Allocation

    The functional allocation process allocates functions from the functional block flows and constraints to entities in a specific candidate design. This process iterates until an allocated baseline can be established. This process is complete when all functions are allocated to subsystems and all requirements and constraints are mapped through functions to subsystems. This process may require many iterations to refine the system configuration. Trade-off analyses assess the risk and LCC impacts for each alternative system configuration. A key feature in RASSP methodology is the ability to quickly assess the LCC for various system configurations. Design decisions and rationale must be documented as the functions are allocated. The specific steps in the functional allocation process include: creating candidate system configurations; allocating functions and constraints to components; identifying interfaces between the subsystems; performing traceability of the system configuration to system and functional requirements; and providing the technical rationale for the functional allocation.

    6.3.2 Performance Verification

    The performance verification process supports the system synthesis process by providing evaluation criteria to determine which candidate configuration provides more effective performance. This effort must consider all factors of interest to the product development team: technical performance, risk, LCC, producibility, supportability, testability, etc. Critical inputs to the evaluation process are the operational concept, operational scenarios, operational maintenance concept, and usage rates expected by the user. The performance evaluation must reflect objective, demonstrable evaluation metrics and must assure the customer we considered all alternatives. The functional verification process models the allocated functions of candidate configurations to determine whether performance requirements are met. The set of mathematical elements within the RASSP reuse library is used (whenever possible) to quickly construct the functional-level simulation to verify technical performance. This process iterates with the functional allocation process until the performance of a candidate configuration meets the completion criteria established during the systems requirements analysis process. If no candidate configuration meets the completion criteria, the procedure reverts back to the functional decomposition process for an updated decomposition. If no candidate configuration meets the completion criteria for multiple decompositions, the process reverts back to the system requirements analysis process for requirement refinements. The specific steps in the performance verification process include: developing metrics, models and scenarios; configuring models; estimating unknown parameters; executing models; evaluating results; eliminating poor configurations; reiterating process if completion criteria is not met; performing traceability to requirements; documenting results; supporting the make or buy decision for each subsystem; identifying candidate prototyping activities to reduce program risk; and conducting an internal review.

    The RASSP architecture selection process transforms the processing requirements for each processing subsystem into a candidate processing architecture of hardware and software elements. The architecture selection process overlaps with the system definition process during the later portions of the system partitioning activity. A set of executable specifications is used to transfer the signal processor requirements to the architecture selection process. A hierarchical set of simulations is performed at each design level, and the results of these simulations are back annotated in the higher-level simulations to verify that performance is maintained.

    6.3.3 System Design Review

    A System Design Review (SDR) is conducted to ascertain the adequacy of the contractor's effort in defining the baseline system. This review is held after the performance of the candidate system configuration has been verified to meet system requirements.

    6.4 Other Considerations during System Design

    6.4.1 Use of VHDL in System Design Process

    The output of the system definition process is the set of executable specifications for the DSP system. The signal processor specification contains requirements that can be divided into three categories:
    1. Timing/Performance (e.g. processing latency, throughput, I/O timing)
    2. Function (e.g., algorithms, control strategies)
    3. Physical constraints (e.g. size, weight, power, cost, reliability, maintainability, testability, scalability, temperature, vibration)

    VHDL is applicable for conveying system function, timing, and performance information and is used to develop a test bench and model of the signal processing system. Many efforts, some of which are being funded under RASSP, are focusing on conventions for associating physical information with VHDL models. As they become available, the methodology will expand to include their use with VHDL.

    The system model captures the specification for the timing, performance, and function of the DSP system and its interfaces. It also contains a structural specification of its interfaces.

    The test bench provides system stimulus and checks that the applicable system requirements are satisfied. As in all cases, the VHDL test bench is developed before the model it is intended to test. This ensures a thorough analysis and understanding of the requirements before and during design. In essence, the test bench is an interpretation of the aspects of the system requirements that can be described in VHDL, while the system model is an expression of the design solution that satisfies the requirements.

    The system model forms an executable specification at the system definition level. The executable specification supports design-for-test (DFT), since the system test concepts must be considered and developed for its verification. The performance model is periodically back annotated with timing and performance data from the more detailed design levels. To continually ensure that system requirements are being met, the performance model is executed within the test-bench to verify continued compliance with the system requirements.

    The executable specification consists of a test bench and a system model described in the following paragraphs.

    • Test Bench
      The test bench provides test procedures, stimuli, and expected responses for verifying that the system model meets system requirements. The test bench is developed before, and is executed on, the system model.

    • System Model
      The system model describes: system timing, performance, and, when possible, system functionality and physical constraints in a way that facilitates automatic testing to verify compliance with system requirements. Elements within the system model are summarized in Table 6 - 1. The algorithm descriptions are in terms of the basic arithmetic operations to be performed. The arithmetic operation sequence is typically expressed in the form of a data flow graph (DFG) that indicates control flow and data dependencies.

    Table 6 - 1: Elements within the system model

    6.4.2 Design For Test Tasks in System Definition

    Requirements are derived from customer and/or parent system requirements and maintained during the system definition process. All of the functions including test functions such as BIST are partitioned into processor system and subsystem functions. An overall model of the processor system is developed which is referred to as VP0. This model together with testbenches represents the inputs, outputs and transformations of the inputs by the processor system including latency. Key outputs of the DFT efforts are the consolidated test requirements (which promotes a singular test strategy across design verification, manufacturing test and field support), preliminary test strategy diagram, TSD0, and testability architecture, TA0. Figure 6 - 3 shows the DFT steps which occur during the system definition step. The key step, requirements analysis, is shown in more detail in Figure 6 - 4.

    Figure 6 - 4: DFT steps in system definition flow diagram

    Figure 6 - 5: DFT requirements analysis flow diagram

    The presence of COTS may throttle attempts to reach a singular life cycle test strategy. One reason is that black box COTS elements are usually tested functionally (for defect detection and isolation), while most of the rest of the design that is not black box oriented is usually tested using a great deal of structural testing and some functional testing. An analysis of the degree of anticipated COTS usage and the extent to which current COTS incorporates test features, would tend to allow an early, preliminary assessment of what plateau of test architectures might be possible

    The impact of using COTS components during system definition is to place practical limitations on the test requirements and subsequent test strategies. For example, it does not make sense today to specify a requirement that can only be achieved with 100% boundary-scan, if a large part of the system will use COTS boards that do not come in boundary-scan versions.

    The development of the fault model in this step is also affected by the presence of COTS, particularly if the COTS element is a "black box" in terms of its structural composition. Several options exist for handling fault models for black box COTS elements:

    1. Establish a structural fault model, in which the "node" is the lowest level input or output for which a description exists. This level will usually be at the inputs and outputs of blocks at the block diagram level or could be simply the inputs or outputs of the package itself (such as a chip) or board.

    2. Attempt to define a "functional fault model." This is a fault model based on the function, rather than the structure of the item; and it describes the erroneous functional behavior that would occur in the presence of a fault. While this approach will work for simple functions, it is not likely to be practical for large VLSI based components or boards.
    Refer to the     Design-for-test application note for further discussion of DFT and other references.

    6.4.3 Role of the PDT in System Definition Process

    A multifunctional PDT is required to perform the system definition process. The disciplines needed for this process in RASSP include systems, architecture, software, digital hardware, mechanical, manufacturing, test, producibility, sourcing, logistics support, and cost analysis. The role for each discipline is described in the following paragraphs.
    • Team Leader - The team leader for the system definition process is the technical director for the project. The technical director is responsible for the overall integrity of the system-level design. The technical director coordinates all activities during the system definition process. The technical director leads system integration and technical management activities.

    • Systems - The systems engineers have the lead role in performing the system definition process. The system engineers perform the system-level design, interpret the customer requirements, control development of the subsystem specifications, and coordinate system and subsystem trade studies.

    • Architecture - The architecture engineers perform the hardware/software trade-offs to determine the processing architecture within the signal processor subsystem. During the system definition process, the architecture engineers participate in the system-level trade-offs that allocate the system functional requirements to each processing subsystem. The architecture engineers determine the impact on LCC on the signal processor for various functional and physical requirement allocations to the processor.

    • Software - Software engineers have a limited role during the system definition process since allocation of functional requirements to software elements is not performed during this process. The hardware/software codesign activity is performed during the architecture selection process in the RASSP design methodology. During the system definition process, the software engineers analyze the system-level software requirements to determine the impact of these requirements on the system design.

    • Digital Hardware - Digital hardware engineers have a limited role during the system definition process since allocation of functional requirements to hardware elements is not performed during this process. The hardware/software codesign activity is performed during the architecture selection process in the RASSP design methodology. During the system definition process, the hardware engineers analyze the system-level hardware requirements to determine the impact of these requirements on the system design.

    • Mechanical - The mechanical engineers ensure the structural and thermal integrity for the system during all phases of the product's life cycle. During the system definition process, mechanical engineers analyze the operational requirements for the system and perform the top-level tradeoffs to determine the structural and packaging requirements for each subsystem. The mechanical engineers assess the impact of various packaging approaches on LCC. The mechanical engineers monitor the structural and thermal trade studies performed during the subsystem designs.

    • Manufacturing - Manufacturing personnel define the integrated manufacturing program used to build the system. During the system definition process, manufacturing personnel examine the functional and physical requirements allocation to each subsystem and assess the impact of these requirements on current manufacturing processes. Manufacturing personnel participate in the make/buy decisions for each subsystem during the system definition process.

    • Test - The test engineers develop the test procedures for the product throughout the life cycle. During the system definition process, the test engineers examine and determine the system-level test requirements needed to determine whether the product is functional working on the manufacturing floor, in the depot, and in the operational environment. The system-level test requirements are then decomposed and allocated to each subsystem during the system definition process. These test requirements must be an integral part of the entire design process for the system and each subsystem.

    • Producibility - The producibility engineers ensure that the system can be safely built and maintained. During the system definition process, the producibility engineers examine the allocation of functional and physical requirements to each subsystem to make sure that the resulting system-level designs are producible. The producibility engineers ensure that the system meets all reliability and maintainability (R&M) requirements. Producibility engineers analyze the R&M requirements and perform top-level trade-offs to allocate these requirements to each subsystem. Producibility engineers work with each of the PDTs throughout all phases of the design to make sure that producibility issues are considered as the design matures.

    • Sourcing - Sourcing personnel acquire the materials and purchased services needed to design and fabricate the system. During the system definition process, sourcing personnel develop the overall sourcing plan for the project. Sourcing personnel participate in the make/buy decisions for each subsystem during the system definition process.

    • Logistics Support - Logistics support personnel ensure that the system is supportable throughout its entire life cycle. During the system definition process, logistic support personnel examine the supportability operational requirements and perform trade-offs to determine the supportability requirements for each subsystem. Logistic support personnel participate in the LCC analyses for the system.

    • Cost Analysis - The cost analysts analyze the LCC throughout the design cycle. During the system definition process, the cost analysts support the trade-off studies by performing cost estimates for each candidate processing system. Development, unit production, and support costs are estimated for each processing subsystem in the candidate baseline system configurations. These costs are tracked and refined throughout the design process.

    6.4.4 Design Reviews in System Definition Process

    Periodic technical reviews are held to demonstrate that required accomplishments have been successfully completed before proceeding beyond critical events and key program milestones. There are two main design reviews during the system definition process: System Requirements Review (SRR) and System Design Review (SDR). In addition, the system members of the PDT participate in the three design reviews during the signal processor development activities: Architecture Design Review (ADR), Detailed Design Review (DDR), and Production Readiness Review (PRR). The plan for conducting each of these reviews is contained within the system engineering management plan (SEMP). Each major review should address the following issues:
    • System engineering process outputs and traceability to customer needs, requirements and objectives
    • Product and process risks
    • Risk management approach
    • Cost, schedule, performance, and risk trade-offs performed
    • Critical parameters that are design cost drivers or have a significant impact on readiness, capability and LCC
    • Trade studies conducted to balance requirements
    • Confirmation that accomplishments in the systems engineering management schedule (SEMS) have been completed.
    A multidisciplinary team from the government, contractor, and applicable subcontractors should be involved in the design review process. The two design reviews conducted during the system definition process are described in the following paragraphs.

    System Requirements Review (SRR)
    The objective of the SRR is to determine that the customer requirements have been properly analyzed and translated into system specific functional and performance requirements. Typically, the SSR is held after the requirements have been analyzed, a preliminary functional analysis performed, and the requirements initially allocated to subsystems. During the SRR, we identify and quantify risks, and address approaches to manage these risks. We identify key technologies essential to system success and candidate technologies not viable for the system. We present the progress of on-going technical verifications, the preliminary functional analysis of the system, and the draft allocation of requirements to subsystems. The draft system specification is reviewed. During the SSR, we establish understanding of the customer requirements by identifying a complete functional baseline.

    System Design Review (SDR)
    The objective of the SDR is to ensure that the process used to determine the functional and performance requirements for the system is complete. We accomplish this by addressing the primary product and processes, by demonstrating a balanced and integrated approach to the development of the functional and performance requirements, by reviewing the audit trail established from the customer requirements, and by substantiating any requirement changes made since the SRR. The SDR is held after all system-level trade-offs have been performed, which resulted in an optimum allocation of requirements and functions to each subsystem.

    During the SDR, we verify the performance, availability, and design suitability for critical products and process technology. We assess the adequacy, completeness and achievability of proposed system functional and performance requirements and present evidence to confirm that the system requirements can be met by the proposed system. The functional baseline for the system is established. We identify the draft specification tree, work breakdown structure, and risk handling approach for the next phase of the program. Pre-planned product and process improvements and acquisition strategies are presented.

    next up previous contents
    Next: 7 Architecture Design Process Detailed Description Up: Appnotes Index Previous:5 RASSP Design Process Description

    Approved for Public Release; Distribution Unlimited Dennis Basara