8.2.1 Putting It All Together: Entity Relationships Between Requirements, Components of System Design, and Verification to Requirements

Abstract

This paper outlines entity relationships for the information used in the development of requirements and system architecture. These entity relationships can and have been used for database development to organize the information in various meaningful and useful ways. We have done this using inexpensive tools which is necessary in our industry, medical devices. Requirements at the system level are developed from hierarchical Functional Flow Block Diagrams (FFBDs) and measures of effectiveness. Requirement documents are modelled as “Input-Process-Output-How_Well” constructs in which the various components of the requirements are extracted from the entity which represents the information. Architectural information is viewed at the highest level as System Transforms which relate to the FFBDs. The system is further modelled as a collaboration of modules, each with Module Transform that relates to the System Transforms which they are implementing. We call this collaboration a “Module Path.” In all cases the measures of “how-well” contained in the requirements “flow down” to the Module Transforms so that information is not replicated. These measures, which we call “measures of effectiveness” (MOEs), are also hierarchical so that allocation and budgeting of requirements is supported. Similar to system requirements documents, module requirements documents are modelled as constructs of combinations of information extracted from the various tables. Finally, verification to requirements is seen as a number of test cases which relate to one or more functions and/or measures. Test cases may test system requirements, modules requirements or a combination. In this way, test cases may be examined for test coverage and duplication. and the impact of inevitable changes in requirements during the development process may be examined.