Requirements are very important for any project, or sub-section of a project, because they define what will be built. Many problems found during design, testing, or operation of a system are the result of incorrect, incomplete, or missing requirements. Therefore, verifying that the requirements are right is an important function of the assurance engineer.
This section provides an overview of requirements engineering for assurance engineers who are unfamiliar with the concepts. The page has the following sections:
Requirements solicitation, analysis, and management are key elements of a successful and safe development process for any system. Many costly and critical system failures can ultimately be traced back to missing, incorrect, misunderstood, or incompatible requirements.
Requirements are statements of need that define what a system will do and how well it must perform those tasks. At lower levels of the system, such as for a complex electronic device, the requirements will include specifics on what the device must do (and how well), how the device will interface to other parts of the system, and what part the device will play in overarching requirements, such as safety.
Systems are usually conceptualized as having levels of structure. The highest level defines the interface between the system and the outside world. The system itself is a black box at this level. Requirements for this level describe how the users (people or other systems) will interact with the system, and what the system will do in response to those inputs. Constraints that are imposed on the system from outside entities, including the environment the system must operate in, also influence the requirements specification.
Once the system is conceptually broken up into a set of interacting elements, the process of requirements decomposition (or derivation) begins. Some of the higher-level requirements will be implemented in whole by a particular element. Other requirements will be partitioned between several components. The process of requirements decomposition continues as the system is further sub-divided, until the lowest practical level is reached. The stopping point for requirement decomposition will vary across systems. For systems with complex electronic devices, a separate requirements document for the complex electronics is preferred. In reality, only the most critical devices have requirements separate from a higher-level assembly.
Requirements can also be classified by the role they play in the system. This classification will vary, depending on the organization or project. The following list of requirements types is commonly used in many government organizations.
- Functional requirements describe the capabilities of the product or system (what the system must do).
- Performance requirements describe how well the product or system must perform a function. Performance requirements complement the functional requirements, and these are sometimes combined into single requirements.
- Interface requirements specify how the system will interact or interoperate with an adjacent system.
- Safety, Quality, Reliability, Maintainability, etc. (the “ilities”) – this set of requirements relate to overarching system questions, such as “how long will it work without breaking” and “can it hurt me”. Some “ility” requirements can be decomposed into specific functional and performance requirements. Others essentially put constraints on the design, implementation, manufacturing, or production processes.
- Constraint requirements are a limitation that a product or system must stay within.
Higher level requirements, either for the system or a sub-system, need to be matched to the chosen system architecture and components. Not every system-level requirement is implemented in a particular component. Also, higher-level requirements may be met by multiple components, each of which performs part of the functions.
When a system-level requirement is allocated to system components, the component requirements need to specify what that component does to support the system requirement. For example, a mobile system has a requirement to stop the system within 5 seconds of a user request. Components of the system that related to motion, such as a motor controller, braking sub-system, and speed detection sub-system, all have a part to play. Other sub-systems, such as for imaging or communications, have no requirements that relate to the system requirement.
Requirement decomposition stops at whatever level the project considers appropriate. Factors that define what level is appropriate include:
- System size and complexity
- Level of insight required by designers
- Requirements imposed by external organizations
- Internal organization policy
For many projects that include complex electronics, the requirements decomposition stops somewhere higher than the device level. When a requirements document exists for complex electronics, it may still be less-specific than desired. In particular, the document may be lacking in complete interface specifications, requirements imposed by technology constraints, and testability requirements.
Because the higher-level system design is taking place concurrently with the decomposition of requirements to the component level, the requirements specification for complex electronics may be a moving target. However, it is important that everyone involved have a clear understanding of what the complex electronic device will, and will not, perform, and to what levels, voltages, timing, etc. the device has to operate.
Characteristics of Requirements
Good requirements have the following attributes:
- Necessary. The product/system cannot meet the real needs of the user without it.
- Unambiguous. If a requirement has multiple interpretations, the system that is built may not match what the user wanted. Clarity is very important.
- Complete. It is impossible to know all of a system's future requirements, but all of the known ones should be specified.
- Consistent. Requirements must not conflict with each other.
- Traceable. The source of each requirement should be identified.
- Verifiable. Each requirement must be able to be verified by test, analysis, inspection, or demonstration. Avoid negative requirements where possible. Example - The component shall not overheat.
Requirements Flowdown and Traceability
Requirements for complex electronics come from system and sub-system requirements, safety, and the constraints imposed by the chosen architecture, the technology and tools used, the environment the device will operate in, and the process to manufacture (for an ASIC) or program (an FPGA, CPLD) a device. For many NASA systems, safety is an especially important source of requirements. Safety requirements may feed into the system requirements, and then flow down to the complex electronics, or are directly invoked at each level of requirements decomposition. The figure below shows the various sources of requirements for complex electronics.
Traceability is a link or definable relationship between two entities. Requirements are linked from their more general form (e.g., the system specification) to their more concrete form (e.g., subsystem specifications). They are also linked forward to the design and test scenarios. Traceability allows you to verify that all higher-level requirements are implemented by the appropriate lower-level component, and that each lower-level component only implements requirements that were approved by the customer or user (i.e., the component does not implement additional functionality).
The key benefits of tracing requirements include:
- Verification that all user needs are implemented and adequately tested. Full requirements test coverage is virtually impossible without some form of requirements traceability.
- Verification that there are no "extra" system behaviors that cannot be traced to a user requirement.
- Improved understanding of the impact of changing requirements or design on other elements of the system. With good tracing, it is much easier to define the level of regression testing needed after a change.