Next: 3 Application Example Up: Appnotes Index Previous:1 Introduction
Next: 3 Application Example
Up: Appnotes Index
Previous:1 Introduction
Many types of requirements can exist for a given project. They can establish minimum technical performance standards, component attributes, goals, conformance to existing generic specifications, the need for project-specific deliverables such as prototypes and documentation, and cost or time limitations. The relative importance of requirements is determined by the customer according to the type of project. For example, a weight limit would be a significant requirement for an airborne equipment, or a minimum battery amp-hour rating would be an important requirement for equipment intended for unserviceable operation. Regardless of their type, requirements must pass certain tests before they can be attached to a system. The kind of test depends upon the system characteristic to which the requirement is assigned.
Qualitative requirements are requirements which state system needs or goals which cannot be a priori assigned a value, e.g., design shall be reproducible by any competent manufacturer, or, design shall include a self-test capability which will test functionality of each circuit board separately. A special case is the merit requirement which defines a set of rules by which a numerical quantity (figure of merit - FOM) is to be assigned to some combination of quality factors.
The importance of these properties was established in the RASSP Design For Testability (DFT) Methodology V1.0 document, which addressed requirements independently of their format (executable or otherwise). Each proposed requirement must meet the three criteria for it to be included as any part of a requirement document. Satisfaction of these criteria ensures that tests will be available to validate conformance to requirements established at the outset of a project.
Requirement specifications are the "documents" that a contractor uses to define system requirements. One example is the classic MIL-Spec which details what conformance to selected standards means and how it is measured. The definitions are generic and are to be applied to any proposed hardware/software implementation. Such specifications are assigned by the customer at the start of the contract. Design specifications quantify how the collection of specific system components will meet the requirement targets.
RASSP methodology uses VHDL-based simulation to design and evaluate signal processors prior to commitment to hardware. The goal of first pass success is supported by many tools which produce and analyze virtual hardware designs prior to hardware fabrication. With tool-based hardware/software codesign, requirements can be introduced into the RASSP methodology effectively by using an executable requirement. This will not only support requirement conformance measurement during simulations but also after physical hardware fabrication.
The executable requirement specification is a preferred format for requirements which can be transmitted to the contractor(s) for both bidding and fabrication purposes. Interpretation of the requirements is minimal since the ER-spec establishes a standard basis for validation by anyone with appropriate testing means. Furthermore, the ER-spec can be backed up with a test case executable design specification (ED-spec) which serves as a reference to establish that the ER-spec has a solution, that is, it defines a realizable system. This generality represents significantly improved ambiguity control relative to conventional written requirement sets which may be open to interpretation.
Another driver for the use of executable requirements and specifications is the compatibility of these formats with reuse in the RASSP model year architecture concept. Projects maintain currency with technology by admitting updates to the system components as technology advances. There is no obsolescence caused by rigid commitment to the technology in existence at the time of project inception. The ER-spec and ED-spec provide a complete definitive reference to previous work which can be readily updated to accept new or additional component characteristics while preserving the bulk of the work which has been previously verified. The need to create new requirements and assign new specifications is minimized and advancement of capabilities for a system becomes an evolutionary process rather than a new design. The economic benefits for this approach are significant since only new elements of the design must be validated.
Accessibility must be accompanied by ease of distribution and update. The electronic storage nature of ER-spec components, files, etc., supports electronic distribution from a central source. If used properly, a single source for requirements can limit references to outdated documentation. This is a common problem with large projects and paper documentation where design/fabrication/integration are carried out in separated geographical regions. On line availability and version control are available to manage distribution for executable documentation.
The requirement set consists of a set of executable statements that express the customer desired needs of a project in terms of its characteristics. Included are quantitative requirements such as weight and signal-to-noise ratio as well as qualitative requirements such as ease of use. Both quantitative and qualitative requirements are conveniently expressed as conditional statements that are easy to evaluate. In some cases, qualitative statements may be preprocessed to yield a figure of merit (FOM) value before they are tested by a conditional. The FOM is typically an accumulated sum obtained from a qualitative/semi-quantitative evaluation of a specific set of system parameters. Such preprocessing is appropriate for comparing the relative effectiveness of different design solutions. Both requirement types are conveniently written as pseudocode statements which are readily converted to any desired language suited to a specific application. Requirements are generic and do not necessarily suggest a design solution.
The design specifications are shown in Design Solution N boxes. There can and will likely be more than one design solution, especially during the bidding phase of a project. Each set of design specifications labeled 0-N consists of a set of pseudocode statements that indicate how a proposed solution will conform to the requirement it supports. The example case shown in Figure 2 indicates that the system weight W will be the sum of the weights of two subsystems, Wa and Wb. The example solution also states that S/N shall be calculated as the results of a call to the function representing an algorithm which is exercised during simulation. The results of both calculations along with others can be supplied as inputs during execution of the requirement statements to determine whether the requirement is satisfied. The requirements in the ER-spec are specified as conditional expressions and if results for a proposed system design instance (represented by an ED-spec) are computed according to the rules in the ED-spec and entered into the conditional expression as compare parameters, execution of the ER-spec can generate an evaluation list of satisfied and non-satisfied requirements. Only those items which are true requirements are included in the ER-spec code. Peripheral issues such as additional capabilities or conditions are not included as requirement specifications. The ER-spec can serve as a testbench for the requirement set in the manner shown in Fig. 2 - 2. The ER-spec is the stimulus for the test (ED-spec) and the response of the proposed solution to the stimulus is measured in the ER-spec execution.
In addition to the requirement and design specifications, the box Other Spec Type is included to illustrate extensibility of the specification concept. The sections below will explore in more detail the range of contents that can be included/used as parts of executable requirements and design specifications.
The content of these requirement documents is subject to a great deal of product-dependent variability. For large systems, both can be quite extensive in detailing a long list of requirements. For smaller systems, the content can be significantly less. Because of the wide range of systems covered, a preferred approach to the design of an ER-spec is to define a set of core components and to allow enhancement of this core set according to the needs of a specific project. Use of a core set of components allows valuable standardization which can be applied from project to project. Users of any executable requirement could expect critical components to be presented in a known format using common language. The discussions below will identify elements which should be considered as core elements of an ER-spec.
For both RASSP and non-RASSP projects, the basic Written Requirement Statement (WRS), functionally equivalent to the classic requirements list containing a Statement Of Work (SOW) for a project, is typically created by the customer. It is often developed in stages through a refinement process. Initially, the contractor will likely contribute little, if any, contents during its drafting, unless the Statement is prepared as a result of a contractor's unsolicited proposal for a project and the customer agrees to use the contractor's proposal as the basis for a procurement. The WRS will be the first expression of system requirements and will likely be updated as needed to become a reference for the current quantitative and qualitative requirement descriptions for a project. It will contain as core elements technical details of project hardware, software, and simulation code descriptions including the execution sequence of code supplied with the executable requirement. Directions for compiling supplied source code will also be included. Another core element of the WRS is the expression of the intent of the customer in selected areas where definitive specifications may not yet be assignable. "TBD" items are frequently present in requirements statements. The basic Written Requirement Statement will contain a Consolidated Test Requirement document generated for the testability analysis and a CAD tool based requirements database file, i.e. RDD-100 or RTM, which is developed by system engineering.
The formal executable requirement specification will contain mathematical representations of the written requirements. Its core elementswill typically be processing algorithm definitions and expected performance capabilities during execution of these algorithms for test cases, physical characteristics, and component models and testbenches for environments in which components are to be tested. Other representations such as detailed performance level vs. operational mode specifications can be substituted as an alternative. Execution of the ER-spec corresponds to demonstrating the results expected of the project hardware/software suite. Satisfaction of requirements for a project can then be validated by measuring the quantities assigned to system properties and comparing them to the ER-spec values. The formal ER-spec can be generated solely by the customer or by interaction with contractor(s) actually (post-award) or potentially (pre-award) involved with the project. In either case, it represents a standard against which conformance can be unambiguously established.
Typical core executable components of an ER-spec are :
Support components for an ER-spec for a signal processor can assume existence of data files in specific formats. Where these are necessary to the core executable components, they become core components also. Typical data sets will consist of :
The ER-spec is typically supported by a customer-generated reference system-level executable design specification (ED-spec0), which is one solution instanceof the executable requirement specification that serves the purpose of proving by example that the ER-spec will admit a solution to the signal processing problem being addressed. The contractor will develop a hardware/software-specific executable generic design specification (ED-spec0) to provide a working solution instance. ED-spec0 is not intended to be hardware or software definitive. This is done in order to allow design freedom to contractors. It is Also used primarily as a consistency and realizability check for the executable requirement specification. ED-spec0 is developed by the customer as part of ER-spec generation process, and, depending on circumstances, may or may not be supplied to the contractor(s).
Use of a reference executable design specification (ED-spec0) offers control over potential problems arising during the requirements generating phase of a project by serving as a reference solution to the requirements set. For signal processing systems, for example, ED-spec0 could contain a high level source code implementation of an algorithm which will accept a set of behavioral system parameter values written into the requirements. If the parameters are realizable for a real system, and the code demonstrates that use of these values produces a required performance level, then ED-spec0 serves as proof that the desired performance is achievable with at least one set of system parameters. Requirement practicality is thus established.
Since its major purpose is proof of concept, the ED-spec0 may or may not be supplied to the contractor(s). It can serve as a means of clarifying concern or explaining details in some cases but it is not intended to recommend preferred approaches to contractors. It is constructed by the creators of the requirement documentation and is not a replacement for the system definition task normally performed by the contractor. This is the role of the contractor executable design specifications (ED-spec).
The formal executable design specification is constructed by converting generic mathematical statements from the ER-spec into system-specific mathematical expressions which can be evaluated. The result will typically take the form of compilable source code (HLL such as C, C++, JAVA, Matlab, or VHDL) which expresses desired relationships among system parameter values. The optimum base format for executable requirement statements is yet to be determined but work in the area of formal methods suggests that Boolean expressions are equivalent to formal specifications (This conclusion is proposed in "Specifications, Programs, and Total Correctness" by Eric Hehner, which gives an indication of the type of effort occurring in this area. Others have advanced predicate statements and mathematical expressions.) Boolean expressions also appeal on the non-theoretical level and make conversion from a natural language like English relatively straightforward.
An ED-spec is executable in the sense that it defines an executable procedure for calculating values for system properties which will be compared to system requirements. The procedure will typically consist of a collection of high level language compilable and executable files for computing system performance characteristics. For the power example above, the (Boolean) expression :
could express the result of an executable test. The ED-spec files can be standalone expressions of relationships or simulations which can be extrapolated for use during system design. The latter case will become more prevalent when reuse becomes more integrated with the design process. For signal processors, execution will typically take the form of running a sequence of programs with parameter inputs selected by the contractor to represent his version of the system. Unless dictated by the customer (unusual circumstance), the ED-spec is assembled by the contractor who is responsible for details of hardware fabrication and software development. Typically, the methods for calculating system properties are supplied by the contractor to the customer as part of a proposal or design review package.
The discussion below describes how executable requirements and specifications can be created and used within the RASSP methodology at all levels of packaging. The intent is to show the value of the ER-spec and ED-spec and how their distribution among packaging levels provides control of a project throughout its life cycle. The target system is a generic RASSP signal processor to be built by a single contractor. Two bidders will be assumed to illustrate the role of the ER-spec in the competition process. This section should be compared with the Application Example described in the SAIP Benchmark 4 case study to contrast recommendations with an actual application that used an ER-spec in a limited manner. The purpose of the present discussion is to demonstrate the range of applicability of the ER-spec and ED-spec to all phases of a project.
A project begins with a system definition and a generation of a set of system requirements. The Written Requirement Statement is the first document generated by the customer. When this has been refined to a sufficient level of detail, the first version of the ER-spec is created. Refinement continues and an ED-spec0 is developed by the customer to validate the parameter values which populate the ER-spec. The ED-spec0 becomes a proof of concept when it substantiates the system parameter values in the ER-spec. When this occurs, the ER-spec becomes available for formal release to the contractors bidding on the job.
When the contractors receive the bid package, each responds with a system design (ED-spec) which attempts to satisfy requirements received in the ER-spec (including the Written Requirement Statement). Each potential contractor has the opportunity to demonstrate their ability to satisfy the requirements of the system by creating an ED-spec specialized to their respective proposed design. The ED-specs and supplemental material are supplied to the customer, who awards a contract following possible discussions with the bidders. ED-specs at this time include system level specifications and present architecture level details only as required to indicate a likely hardware/software implementation of the system. Extensive architecture trades cannot be presumed at this point.
The successful bidder now begins the system analysis phase which leads to a complete system level specification. The ER-spec and ED-spec are updated and made more complete as system definition moves to the architecture selection and verification phases. During these phases, a RASSP-designed system will produce its virtual prototype along with its variants which represent architecture trades which can be used to verify conformance with requirements. The architecture level VP will consist of behavioral VHDL models and other high level code which will be tested on a system testbench. Execution of the testbench code along with execution of the ER-spec and ED-spec demonstrate whether the system will conform to the requirements.
As the system is broken down into subsystems, boards, etc., requirements assigned at the system level must be interpreted and allocated to the more detailed lower packaging levels. A corresponding level specific ED-spec development parallels generation of the levels of ER-specs. Each level must be assigned its own specific ER-spec (ED-spec) which must be consistent with and be a contributor to the ER-spec of the level above it. Each ER-spec is executable and contains an accompanying Written Requirement Statement like the system ER-spec. The ER-specs become more detailed as the packaging level proceeds toward board and/or MCM level where fabrication will occur. The process of generating ER-specs and ED-specs for lower packaging levels is a flow down process similar to software functional decomposition. A similar consistency requirement exists also since each lower level requirement is a contributor to a higher level requirement and each high level requirement is made up from a collection of lower level requirements.
Several tool-specific commercial alternatives have been used for distributing requirements among the different packaging levels for a project. The RDD-100 data base tool by Ascent Logic has been used to capture and distribute requirements for the RASSP benchmark projects. RTM (Requirements and traceability Management) by Integrated Chipware is another tool which formulates requirements as objects and manages them as elements of a data base. It has been used by Lockheed Martin on the F22 Program to provide requirement traceability and flowdown. Neither of these tools creates executable requirements or specifications, and both require training for the user and development of a degree of skill to make effective use of the requirement management features of the products. This skill must be acquired by all project team members if requirements are to be distributed and readily accessible to concerned parties working at all packaging levels. Acquisition of this skill base can represent a considerable training investment dedicated to a specific tool. In addition, use of specific commercial tools for requirement distribution presumes accessibility and continued vendor support for the tool used by any current or future activity (e.g., model year update by another vendor) using the ER-spec.
An alternative to strong coupling to a specialized requirement and design specification management tool is use of a general purpose multiple-spreadsheet-based application. In the area of test, RASSP used test strategy diagrams (TSDs) implemented with EXCEL workbooks and worksheets to describe the flow down of test requirements through the packaging hierarchy. This approach uses an "open" , relatively simple, environment to flow testing requirements to all packaging levels. Data entry is natural language based and the level of skill required for linking requirements hierarchically is moderate and widespread. Success of the multilevel TSD structure suggests that such an approach could serve as a model for a requirements hierarchy. Both Written and executable requirements can be accommodated in this scheme. Reference to an executable file is included in the same manner as a written statement. A consequence of the simplicity of this scheme is that no storage intelligence exists, that is, what a viewer sees is exactly and only what was entered.
An example of a coupled worksheet hierarchy of requirements is shown in Figure 2 - 3.
The top row shows the system level components of an executable requirement and executable design specification as a set of spreadsheets. Other rows show the relationships of other spreadsheets at subsystem level and below. Actual entries on the spreadsheets can consist of data available directly or references to external data and executable files - any of the possible components of a requirement or specification set. Written requirements statements can be implemented as an external reference.
Horizontal arrows indicate a conformity evaluation path among the requirements and design specifications at any given level. A listing of level-specific requirements is available and a design specification defining methods by which the hardware and software will satisfy the requirements has been established. Both requirements and design specifications can be placed into separate regions on the same spreadsheet. Conformance at any level can be determined by simple cell-based comparison of the requirements and design specifications at that level.
Vertical arrows indicate a derivation relationship which covers flow down of requirements or design specifications from the next higher level and the mapping of lower level requirements at any level to the next higher upward level. Entries for multiple packaging levels can be displayed on the same spreadsheet or, more likely, because of complexity and number of entries, each packaging level can be displayed on a separate spreadsheet. In either case, relationships among entries can be implemented via cell-based or inter-sheet comparison. Thus, a mechanism for requirement distribution and traceability is created.
Next: 3 Application Example
Up: Appnotes Index
Previous:1 Introduction