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

The RASSP Benchmark 4 (BM4) project involved construction of two hardware subsystems that would execute a specified set of image data processing algorithms. The subsystems are called High Definition Imaging (HDI) subsystem and Mean Square Error (MSE) classifier subsystem.

In support of the two subsystems to be fabricated, MIT Lincoln Laboratory supplied an "executable requirement" to Lockheed Martin ATL as the basis for design of hardware and the integration of software for the HDI and MSE subsystems. The MIT-LL "executable requirement" was not the same as the ER-spec as described in this application note. A Technical Description document was also provided. These documents were titled :

RASSP Benchmark 4 Technical Description (BTD) (January 9, 1998)
RASSP Benchmark 4 Executable Requirement User Manual (ERUM)

The BTD described the HDI and MSE in their roles within a semiautomated image processing system (SAIP). This document was not explicitly given a requirements-related name but it did contain a significant number of requirement descriptions that made it an indispensable part of the overall requirements description. Requirements contained in the BTD were not "executable", but rather supplied in conventional written format. Section 2 is called "Processor Requirements" and describes the processing algorithms and the image processing modes. Included are :

physical requirements (size, weight)
image accuracy (comparison with supplied standard code)
algorithm requirements (which algorithms shall be executed)
power supply characteristics
Fault detection, isolation and testing, including acceptance testing documentation
reporting (project management)

Other sections were devoted to describing metrics for cost, performance and quality as well as the project deliverables. The BTD thus assumed the role of a traditional requirements document including a statement of work (SOW). It however, was not a complete requirements document, since it did not contain detailed descriptions of the algorithms which were to be used which would be needed to ensure conformance to expected algorithm execution. Detailed descriptions were contained in the ERUM document. For BM4, separate requirements documentation sources were used to isolate restricted design data, primarily in the algorithm area, from general requirements information. Nonetheless, the BTD was de facto a major vehicle for requirements delivery. Its non-executable nature indicates that the overall requirement documentation for BM4 was a hybrid between traditional and executable requirements.

The ERUM included a very detailed description of the algorithms to be used for processing images. Mathematical details as well as versions of source code implementing the algorithms was provided down to the level of C structures for the system parameters and the C functions which manipulate these structures. The ERUM was accompanied by a collection of files which defined and demonstrated by execution the required operation of the HDI and MSE subsystems. The ERUM was the Written requirements statement for the executable algorithmic portion of the "executable requirement" for the project and the file set contained or could generate (after appropriate compilation) the "executable" requirements. The variety of executable information supplied is illustrated by the directory listings for the files. The files *.c and *.h are C language source code files which will demonstrate algorithm behavior when used with instructions supplied in the ERUM.

File Directory For HDI

Makefile, README_LL, bool.h, boolean.h, calldgesvd.f, callsgesvd.f, center_data.c, cfftb.f, cfftf.f, cffti.f, chip_gate.c, dgesvd.f, do_image_fcn.c, est_centers2.c, est_rwin.c, est_xrwin.c, filtr_and_dec2.c, gauss_gate.c, gen_vecs.c, hdi.c, hdi.h, invert_image.c, iostream.h, linalg.h, main.C, main.jou, make-970305.log, ake_filter.c, make_look_index.c, make_real_looks.c, make_real_vecs.c, make_syn_looks.c, make_vecs.c, mlm_clipm.c, mlm_coher.c, mlm_confm.c, music.c, param, param.jou, refocus_iqdata.c, sgesvd.f, svdr.c, tools.C, tools.c, tools.h, tools.jou, unwindow.c, unwindow_squint.c, utils.c, utils.jou, zfftb.f, zfftf.f, zffti.f

File Directory For MSE

README_LL, algo.h, array.h, array.jou, bool.h, ds.h, ds_vars.h, function.h, h_files_diff.out, hdi.h, iostream.h, iterator.h, main-1.log, main-2.log, main-3.log, main-4.log, main.C, main.bak, main.jou, make-970306.log, makefile, mse.C, mse.h, mse.jou, pair.h, stringClass.h, tools.C, tools.c, tools.h, tools.jou, vector.h, vector.jou

The number and variety of file types for the BM4 "executable requirement" suggests that an ER-spec, even a partial ER-spec, can have many components, and that a clear detailed description of the files supplied and how to use them is essential.

3.2.1 Creation of the Written Requirement Specification

physical
performance
environmental
general performance and acceptance testing

Physical and environmental requirements are determined by the mission of the project. Equipment intended for aircraft installation will have characteristics different from those of shipboard equipment. Benchmark 4 hardware consisting of signal processing circuit boards was to be installed in a van environment (ground, benign) to accompany the SAIP equipment it is used with. Operating temperature and physical size are typical requirements in this class.

Examination of the intent of a project and the nature of the tasks to be performed identify the performance items that should be included within an ER-spec. Mathematical descriptions of these algorithms are translatable into the code which can be entered into an executable requirement. For RASSP BM4, performance requirements were supplied as a set of files containing C source code initialized with system parameters which exhibited the performance required when the HDI and MSE algorithms executed.

The category of testing requirements establishes methods for determining whether all other requirements conform to the assigned values or level of performance and also establish a mechanism for ensuring reliability of produced equipment. A separate RASSP study, Benchmark 3 DFT Shadow Report, examined testing and testability and has established a methodology for handling testing requirements which optimizes testability of a product over its life cycle. Part of that study defined a method for consolidating test requirements.

The test requirements consolidation process forces consideration of the practicality of assigned requirements and contributes primarily to the Written Requirement Statement. The test requirements can be included in the executable requirement list in cases where simulations and use of test vectors are involved.

The Benchmark 4 Consolidated Test Requirements document consists of a collection of requirement templates for each of the derived requirements and a listing of the conformance-related test requirements.

Each template identifies a fault (including a fault model), test means applied to the fault, a definition of a fault coverage metric, and a quantitative value for the fault coverage. The templates are placed into three categories to cover design, manufacturing and field testing. Conformance test requirements expand the requirements listed in the Written Requirement Statement by identifying the type of test that will be assigned to verify conformance to a requirement.

Both classes of requirements are treated as equally necessary based on the philosophy that execution of algorithms on unreliable or untestable equipment is not acceptable.

A interesting conformance requirement for Benchmark 4 was inclusion of built in self test (BIST) capabilities. The IEEE 1149.1 (JTAG) bus was to be the primary BIST means. This is a good example of a requirement which is not simple to quantify without a thorough examination of the consequences of its inclusion. Assignment of percentage of coverage can have a significant impact upon the cost of a project as well as the technical detailed design. For example, COTS boards could be eliminated by imposition of a substantial JTAG-based BIST requirement, and custom design freedom could be restricted by the need to use only JTAG-compliant components. For BM4, the original version of the Written Requirement Statement did require BIST as the primary performance monitoring means. A consequence of flow down of this requirement was possible elimination of COTS boards as hardware candidates. The lower cost of an existing board design could not be used to advantage. The undesirability of this restriction forced reconsideration of the imposition of the original requirement and a change to allow exclusion of COTS boards from the JTAG capability was suggested.