RASSP Definition and Role of Executable Requirement (ER-SPEC) and Design (ED-SPEC) Specifications Application Note

2.1 Requirements and Their Properties

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.

• Realizable requirement are achievable and measurable with current simulation and test technology.
• Consistent requirements are derivable from higher packaging (Level refers to the RASSP hierarchy of packaging : System, Subsystem, Board, MCM, Chip. Requirements set for any given level must support established requirements for the next higher level of packaging) level requirements and do not contradict other requirements at their own or higher levels.
• Valid requirements are predictable, verifiable by simulation, and measurable.

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 Written Requirement Statement (WRS)
• the formal executable requirement specification consisting of supporting data and/or executable files which are to be used during execution of the ER-spec by the contractor

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 :

• code which when executed demonstrates expected system or component performance for a set of values assigned to system parameters, e.g., initialized high level representations of algorithms. The purpose of this code is to generate reproducible results which define performance and the effects of parameter variations. The code itself is not necessarily a definitive representation of the implementation of the process it represents.
• software which will execute on the project hardware during normal system operation
• simulation testbench for verifying performance of a design
• structural and behavioral models of system components such as logic devices or memories
• structural and behavioral models of test-related support components such as FPGA-based memory BIST subsystems
• FPGA designs and/or synthesizable models of FPGA circuitry

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 :

• test program sets (TPS) consisting of test vectors and instructions/expected results
• operational test input and result sets for demonstration of operation in selected scenarios (test cases)
• drawing sets (CAD mechanical and schematic) and parts lists

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 :

if (PTOTAL < 100) PASS else FAIL ;

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.

• Customer establishes need for a project - converts requests from field units into requirements documentation and an ER-spec which can be passed onto a fabricator. (An ED-spec0 may also be created.)
• Contractor accepts and verifies requirement specification (reality check) - generates cost - Interacts with customer as needed to create final set of requirement specifications - amendments to the original customer requirements list are made if necessary - generates ED-specs
• Contractor monitors conformance to requirements and reports to customer - uses flowed down version of ER-specs and ED-specs as basis for a design at all packaging levels and fabricates product - customer verifies performance of contractor design
• After fabrication, contractor and customer perform acceptance testing to verify conformance to requirements
• Customer becomes user and verifies performance in field deployment