Assurance Plan for Complex Electronics:

Assurance Process: Requirements

This printer-friendly page contains the following sections:

• Requirements Phase Overview
• Developing Requirements for Complex Electronics
• Assurance Activities for Complex Electronics Requirements
• Requirements Engineering

Requirements Phase

This Overview page for the Requirements Phase contains the following sections:

• Overview
• Requirements Process
• Entrance Criteria
• Exit Criteria
• Roles and Responsibilities
• Requirements Site Map

Overview

This assurance plan for complex electronics assumes that the system requirements have been developed, assessed, and baselined (formalized). The system requirements should have been provided to individual components of the system, and decomposed sufficiently so that the component requirements provide sufficient detail for the designers to know what they need to create.

The engineering group creates the requirements and the assurance group verifies and validates the requirements. Both sides require a thorough knowledge of the system, including the environment where the system will operate and the expected operational scenarios. The two groups need to work closely together in the process of creating and verifying the requirements. The diagram below shows the requirements process for complex electronics. The Develop Requirements page describes the engineering process to create the requirements. The Assurance Process page describes the activities to assess and verify the requirements.

A general summary of requirements engineering is provided in the Requirements Engineering page.

Requirements Process:

Entrance Criteria:

The following criteria should be met prior to beginning the development and assurance of requirements for complex electronics.

• The system requirements should be complete and baselined. In reality, the requirements must be sufficiently complete to allow derivation of requirements for sub-systems and the complex electronics.
• Sub-system requirements for the sub-system(s) the complex electronics reside in should be complete and baselined. As with the system requirements, the level of fidelity must be sufficient to allow derivation of the complex electronics requirements to commence.
• The Configuration Management process is defined and in operation.
• The Assurance process is defined and operational. The assurance engineers responsible for the complex electronics have been identified.
• The proposed technology set (e.g., FPGA, ASIC, SoC, chip family) is identified at a high level.

Exit Criteria:

At the end of the requirements development phase, the following criteria should be met:

• Requirements for complex electronics are baselined and under configuration control.

Roles and Responsibilities

The table below describes typical activities during the Requirements Phase for both engineers and assurance personnel.

Requirements Phase
Role	Typical Activities
Systems Engineer	Decompose system requirements to sub-systems and components. They may delegate this task to electronics engineers for the complex electronics requirements.
Electronics Designer	Help the systems engineer in the process of creating requirements for complex electronics. Assess the requirements for design impacts.
CE specialist (optional)	Either helps develop the requirements for complex electronics, or assess the requirements for designability with the chosen technology. Any problems should be worked out with the systems engineer. Select tools for design, implementation, and test activities.
System Safety	Perform Preliminary Hazard Analysis to identify system hazards, and the system components that contribute to the hazard, or help prevent it from occurring. If complex electronic devices are involved, include design-related failures as well as hardware failures in the analysis.
Quality Assurance	Assess the complex electronics requirements. Verify that all requirements are testable (or otherwise verifiable). Ensure that all CE requirements trace back to system, safety, or other higher-level requirements.
CE Process Assurance (new category)	Assess the complex electronics requirements against knowledge of the technology and design process. Verify that the requirements are attainable. Assess the verification activities that will be required, and ensure that the device can be verified to the level required. Assess any tools that will be used to design, implement, and test the CE.

Requirements Site Map

The table below describes the information contained on the other pages in the Requirements section.

Requirements Site Map
Overview	This page
Develop Requirements	The process of developing requirements for complex electronics. This section includes a listing of requirements that should be considered for complex electronic devices. Because complex electronics may not have a sufficiently detailed requirements specification, assurance engineers may have to derive an appropriate set of requirements in order to complete future assurance tasks.
Assurance Process	Describes the assurance process for complex electronics requirements, with links to specific techniques.
Requirements Engineering	Requirements engineering summary, including: Levels of requirements Types of requirements Requirements derivation Qualities of good requirements Requirements flowdown Sources of requirements for complex electronics Traceability of the requirements to higher level requirements, and into the design and verification process.

Developing Requirements for Complex Electronics

This section is about developing the requirements for complex electronics, which is usually performed by the systems or electronics engineer. The associated assurance activities are described in the Assurance Process page. An assurance engineer, however, needs to be cognizant of the types of requirements that should be included in the specification. Assurance engineers also need to understand the overall process of requirements development for complex electronics, both to guide that development and to ensure that the resulting requirements are adequate.

Ideally, the complex electronics (FPGA, ASIC, CPLD, etc.) will have a separate requirements document. In less complicated systems, the requirements for the device may be included in a higher-level document (such as for a circuit board or electronic sub-system). In the situations where the requirements are not considered adequate (by the assurance engineer), a certain amount of additional requirement derivation will need to be performed. This is covered in the Reverse Engineering of Requirements section of the assurance process page.

This section covers:

• Requirements Capture and Derivation
• Feasibility Assessment
• Requirements review

Requirements Capture and Derivation

The specific requirements for a complex electronic device will derive from the system requirements, safety analyses, system architecture, performance requirements, and the operational environment. The objectives of the requirements capture and derivation/decomposition process are:

• Identify, derive, and document the requirements for complex electronics
• Assess derived requirements as part of the system requirements engineering processes
• Correct omissions and errors in requirements

The process of deriving requirements for complex electronics is basically the same as for any sub-system. The steps are out-lined below, with the addition of complex electronics-specific issues to consider:

• Allocate system and/or sub-system requirements to complex electronics. This is usually more than a cut-and-paste of the higher-level requirements, because those requirements are often implemented by multiple sub-systems. The requirements have to be decomposed to state the specific requirements for the complex electronics.
• Assess the safety, reliability, maintainability, and similar requirements for their implications for the complex electronics. Derive any specific requirements for the complex electronics. For example, the complex electronics may need to meet a particular Mean-Time-To-Failure (MTTF) requirement. Or, there may be an overall safety requirement that all sub-systems must have a built-in self test capability.
• Consider the effects of the chosen system and sub-system architecture, the selected electronics, standards, procedures, and processes. Derive any requirements for the complex electronics that are necessary. For example, the manufacturing process for an ASIC may constrain the design options. These constraints should be included as derived requirements. Also, the selection of a communications method between sub-systems may generate specific requirements for a complex electronic device that uses the communications method.
• Consider the effects of faults and anomalies in the complex electronic device on other system components, and also the effect of failures elsewhere in the system on the complex electronic device. If a Failure Modes and Effects Analysis (FMEA) was performed, use that as a starting point. Ask yourself:
• Should anomalies in the complex electronics be handled by the device itself or by a higher-level component?
• What anomalies or faults can be tolerated (i.e. no action is taken)?
• If the device has an anomaly or failure, will it affect the safety of the system?
• What failures or faults elsewhere in the system will have an impact on the device? How severe would the impact be? What actions should this device take?
• Identify all interfaces between the complex electronics and other parts of the system. Specify requirements for signal levels and timing. Specify data formats and protocols.
• Consider environmental constraints, such as radiation, thermal environment, and mission duration. Does the system need a mitigation strategy for Single Event Upsets and/or total radiation dose? If so, what part will the complex electronics play in that strategy? Has the complex electronic device been allocated a power dissipation budget?
• Consider any testability requirements, and how they will be met for the complex electronics. What testing can be done on the bench? What testing will require a system component, or the complete system? Do any special access pins or ports need to be defined, to aid in testing?
• Assess any off-the-shelf design components (e.g., IP cores) that will be used. Consider the functions of the component, and whether any will remain unused. Assess any unused functions for impact on the system if they were inadvertently executed, and add requirements to prevent this situation if appropriate. Add derived requirements for any constraints imposed by the off-the-shelf component on the complex electronics design.
• Are there any constraints imposed by the tools used to develop the complex electronics? If so, these constraints should be captured as derived requirements.

Specific requirements for complex electronics are detailed in the Requirements Review checklist. This checklist can be used as an aid in creating requirements for complex electronics, or in reviewing a set of requirements for the devices.

Feasibility Assessment

Once the requirements are developed, or concurrent with the development process, a feasibility assessment should be performed. The goal of the assessment is to determine if the requirements can be met with the anticipated technology. A secondary goal is to define certain strategies, such as mitigation for single event upsets, which will constrain the design.

The feasibility assessment should determine if the required functionality and performance can be met by the chosen technology, for all planned and anticipated off-nominal operational scenarios. If the requirements cannot be met, then the project needs to determine if the requirements should be modified, or if another technology is more appropriate.

The feasibility assessment process includes the following steps. The information produced by the assessment process should be documented in a report.

• Assess the probability that the requirements can be met by the chosen technology. Consider whether the design will reach any technical limitations, such as number of gates, complexity, operating frequency, and packaging limitations (e.g. number of pins).
• Check the availability of the selected technology. Consider how long the chip and tools will be supported, in relation to mission duration. When will the parts be obsolete? Also consider the availability of technical support.
• Estimate the design complexity
• Estimate the power consumption
• Perform a preliminary timing analysis to assess the feasibility of speed requirements
• Select a radiation hardening approach
• Select a production test approach and verify feasibility against all requirements
• Identify and evaluate suitability and qualification status of complex electronic technologies
• Identify suitable packaging; make a baseline selection
• Determine availability and status of design and test tools and libraries; necessary personnel; and IP cores

Requirements review

Once the requirements for the complex electronic device are defined, they need to be reviewed by a variety of people. Each person will bring a viewpoint to the review that will identify gaps or errors in the requirements set. The requirements review can be a formal review (such as part of the Preliminary Design Review), an informal review, or the result of many individual reviews.

Details on Requirements Review can be found in the Techniques section.

Assurance Activities for Complex Electronics Requirements

As the engineers develop and derive the requirements for complex electronics, the assurance engineer(s) works alongside to assess the processes and the product (requirements). These two activity streams are opposite sides of the same coin, and result in a validated set of requirements.

Use the Tailoring chart to determine which activities or analyses are required for a particular criticality classification. Activities that are not required may still be performed, if desired. The assurance activities for complex electronic requirements include:

• Risk analysis
• Requirements Evaluation
• Requirements Review (formal or informal)
• Interface Analysis
• Traceability Analysis
• Modeling
• Simulation
• Formal Methods
• UML
• Criticality Mapping
• Decision Tables/Trees
• Reverse Engineering of Requirements
• Fault Tree Analysis
• Failure Modes and Effects Analysis

Every method listed above does not have to be applied to every project. The table below uses the Complex Electronics Classification to map the activities, and depth of each activity, against the classification. This table allows for easy tailoring of the assurance activities to the device complexity and criticality.

Tailoring Guidance for Assurance Activities - Requirements Phase
	Low	Moderate	High
Risk analysis	Informal	Informal	Formal
Requirements Evaluation	Check for main characteristics	All main characteristics plus assess for completeness	Complete evaluation against all criteria
Requirements Review	Informal	Informal or Formal	Formal
Interface Analysis	Informal Assessment	Focus on key interfaces and critical timing	Detailed analysis, all interfaces. Includes timing
Traceability Analysis	Trace from higher-level requirements	Trace from higher-level requirements. Verify derived requirements correctly trace	Trace from higher to CE and from CE to higher level requirements Full assessment of derived requirements
Modeling Create model, or assess model if it exists. Models can be in UML, diagrams, or special languages.	Not performed	Some diagrams are created to assess requirements	Complete modeling of the requirements
Simulation	Not performed	Not performed, or only performed on aspects that are in question	If model is executable, simulations should be designed for nominal and error conditions
Criticality Mapping Determine what parts of the CE map to specific safety or mission critical requirements	Not performed	Complete mapping	Complete mapping
Decision Tables or Trees	Not performed	Performed with most important conditions only	All inputs and conditions
Reverse Engineering of Requirements	Performed only if no requirements document available from project	Performed only if no requirements document available from project	Independent derivation of requirements used as a tool to assess requirements document.
Fault Tree Analysis If FTA exists for system, check for failures related to CE problems	Minimal	Minimal	Add design failures for CE to FTA, if not already included
Failure Modes and Effects Analysis If FMEA exists for system, check for failures related to CE problems	Minimal	Ensure that FMEA addresses CE failures	Add design failures for CE to FMEA, if not already included

Risk Analysis

A risk analysis is performed at the Requirements phase to identify the most critical risks to a successful completion of the complex electronics. Identifying potential problems early on allows the project to apply resources in an intelligent manner. Risks can be prioritized, so that the critical risks receive the most effort in mitigating. Some risks may only be monitored unless there is a significant change in the factors that determine the risk. For unlikely, but critical, risks, a contingency plan may be developed.

From an assurance point-of-view, the risk analysis points to the critical areas of project development for monitoring. For example, if requirement volatility is a major risk, then the assurance engineer should be closely watching how changes to requirements are input, agreed to, and analyzed for impacts. The assurance engineer can proactively suggest requirements management tools that may be of help and ensure that project plans and processes address how to add, delete, or modify requirements.

Details of the risk analysis technique can be found in the Techniques section.

Requirements Evaluation

One of the key assurance activities for any project is expert evaluation and assessment of the requirements. Incorrect, ambiguous, and incomplete requirements have been shown to be the major cause of system failures and accidents. Getting the requirement right is not easy, but it is vital to the success of the project.

For Complex Electronics, the main goals of requirements evaluation are:

• Ensure that all appropriate higher-level requirements are included in the CE requirements specification.
• Identify any inconsistencies or conflicts within the requirements, or with other requirements documents.
• Ensure that the quality of the document (e.g. readable) is adequate for its usage.
• Ensure decomposition of the higher-level requirements into those suitable for the CE device.
• For example, a higher-level requirement to monitor a temperature would be decomposed into requirements for the complex electronics (read a thermistor 10 times a second, average every 10 readings, output the average reading once a second) and for software (receive the thermistor reading once a second, convert it to a temperature, check it against a range of acceptable values, and perform specified operations if it is out of range).

Details of requirements evaluation can be found in the Techniques section. Use the requirements checklist when evaluating the requirements.

Requirements Review

A Requirements Review is a more formalized process that brings together individuals with various understandings of the system and the complex electronics. The goal is to have each person review the requirements against their area of knowledge. By performing a wide review, problems related to interfaces, system operations, etc. are more likely to be found.

Details of requirements review can be found in the Techniques section. Use the requirements checklist when evaluating the requirements.

Interface Analysis

Interface analysis is a static analysis technique used to demonstrate that the interfaces (inputs, outputs) between the complex electronic device and other parts of the system do not contain any errors. This analysis will be performed (updated) at multiple times throughout the life cycle, as more details are available, or when changes are made to the system.

At the requirements phase, the main goal of this analysis is to identify input or output signals that are incorrect (wrong range, wrong type), missing, or present but not connected (e.g. an output that doesn't go anywhere). Timing relationships will be looked at as the device is designed.

Details of interface analysis can be found in the Techniques section.

Traceability Analysis

Traceability analysis is the process of linking requirements for a system element to other system elements (higher or lower in the hierarchy), and to the various implementations of the requirements (design, physical components, test procedures). The purpose of this analysis is to ensure that the requirements for the system element (e.g., a complex electronic device) are correct and complete, and that the final implementation of the system element meets those requirements.

Tracing comes in two basic types:

• Forward tracing, from higher level requirements into lower level/derived requirements, and eventually into design (including HDL modules) and test
• Backward tracing from lower-level elements to higher-level requirements

The purpose of forward tracing is to make sure all requirements are completely and correctly implemented in the complex electronics. Backward tracing ensures that additional functionality is not added to the system (i.e., that all system aspects are driven by the requirements). Forward tracing of requirements is the minimal implementation of Traceability Analysis. For critical systems, both types should be used.

Details of traceability analysis can be found in the Techniques section.

Modeling

Modeling is an investigative technique that uses a mathematical or physical representation of a system or sub-system that accounts for all or some of its known properties. Models are often used to test the effects of changes of system components on the overall performance of the system.

Model-based development focuses on creating a complete (and possibly formal) model of the system or sub-system. Models are an abstract and high level description of the system (or system component), expressed as statements in some modeling language or as elements in a modeling tool. Unlike standard requirements documents, models can be executable (able to simulate the process flow within the system).

The standard "requirements, design, implement, unit+ integration+system test" development cycle becomes "requirements, mode, verify (test) and debug, physically implement, system test". Testing is pushed earlier in the life cycle to the modeling phase. In theory, the model-driven approach allows developers to construct, test, and analyze their designs before they start to implement them.

One advantage of model-based development is moving some of the testing activities earlier in the life cycle. If major problems are found, they can be resolved with less impact on the budget or schedule of the project. Disadvantages include a reliance on the automatically generated design (which may not be generated correctly) and the difficulty of knowing how well the model conforms to reality. Interactions between parts of the system may not be evident until the system is operational. Testing on the model should not replace thorough system testing.

Simulation

Simulation is the process of executing the requirements (system) model. In a simulation, the user can provide inputs to the model and see how it reacts. Specific, planned tests can be run to show that the model meets the required behavior, or the simulation can be used in an interactive mode to explore the model reactions.

Simulations can be used to validate the requirements, by showing the customer how things will work. The customer may even be provided a computer program (the simulation) to play with and try out various scenarios. Simulations can also be used to understand system or component behavior under various conditions that are not always easy to produce in the real world, such as signal noise, missing inputs, and invalid combinations of inputs.

The strength of simulations are:

• Early validation of the requirements.
• The ability to test the requirements (system) early and identify any errors or ambiguous situations, when they are easier to correct.
• The ability to explore how the system will react under unexpected or invalid inputs. The model (requirements) can be corrected if the actions are not what are desired.

The main problems with modeling and simulation are:

• The time and expense to create the model. Executable models required for simulations often have to be written in specialized languages.
• The difficulty in creating a model when the system is still abstract.
• Results of simulations may not correspond to the real system. The simpler the model, the more likely it is to vary from the real system. The limitations of modeling and simulation need to be understood, and the results of simulation should be considered in the light of the fidelity of the model.

Formal Methods

When the model is formally defined, it becomes “formal methods”. Formal models can be mathematically proven to hold (or not hold) a particular property. The NASA Formal Methods Guidebook states: “Formal Methods (FM) consists of a set of techniques and tools based on mathematical modeling and formal logic that are used to specify and verify requirements and designs for computer systems and software.” Formal Methods therefore has two parts – formal specification and formal verification.

System and complex electronics requirements are usually written in “human-readable” language. This can lead to ambiguity, when a statement that is clear to one person is interpreted differently by another. To avoid this ambiguity, requirements can be written in a formal, mathematical language. This formal specification is the first step in applying FM.

Formal Specification is useful in shaking out the requirements and ensuring that they are consistent and complete. By creating a Formal Specification, you may find errors such as undocumented assumptions, inadequate off-nominal or boundary case behavior, traceability and inconsistency, imprecise terminology and logic errors. Formal Specifications are also the first step in formally verifying that the CE implementation meets the requirements.

UML

A growing trend in systems engineering is to use the Unified Modeling Language (UML) or SysML (the systems engineering extension) to describe the system. In many cases, tools can take the developed model and automatically generate the hardware description language code or other design elements.

The UML is the industry-standard language for the specification, visualization, construction, and documentation of the components of systems. UML helps to simplify the process of system design by making a model for construction with a number of different views. The UML represents a compilation of best engineering practices which have proven to be successful in modeling large, complex systems, especially at the architectural level.

UML defines twelve types of diagrams, divided into three categories:

• Structural Diagrams which include the Class Diagram, Object Diagram, Component Diagram, and Deployment Diagram
• Behavior Diagrams which include the Use Case Diagram (used by some methodologies during requirements gathering); Sequence Diagram, Activity Diagram, Collaboration Diagram, and Statechart Diagram
• Model Management Diagrams which include Packages, Subsystems, and Models.

Criticality Mapping

Criticality mapping identifies complex electronics requirements and design elements that have safety implications. The method starts with a list of system hazards, and then evaluates each system requirement or component in terms of the safety objectives derived for that component. If a system component includes complex electronics, the criticality mapping process is applied to the functions the complex electronics will perform. The end result should be either a) the complex electronics has no safety related objectives or b) a mapping of the safety objectives to particular parts (or all) of the complex electronic device.

The results and findings of the Criticality Mapping should be fed back to the System Requirements and System Safety Analyses. For all discrepancies identified, either the system requirements should be changed because they are incomplete or incorrect, or else the complex electronics requirements must be altered to match the system requirements. The Criticality Mapping identifies additional hazards that the system analysis did not include, and identifies areas where system or interface requirements were not correctly assigned to the complex electronics.

Details of criticality mapping can be found in the Techniques section.

Decision Tables/Trees

Decision Tables (or Trees) are used to describe the required external behavior of some aspect of a system. These tables can be used to make sure that all combinations of events are accounted for in the behavior of the system. For example, if the complex electronics performs operations based on the state of several input signals, you want to make sure that all combinations of those inputs are addressed in the design.

Decision Tables are easy to produce. They are essentially X-Y tables, with the conditions that can influence the decisions on the left, followed by the set of possible decisions (actions). The possible combinations of conditions are in the columns to the right. Decision Tables make no assumptions about the order in which the conditions are evaluated. In the Techniques section, the Decision Table page provides more details and shows an example.

A Decision Tree is basically a graphical Decision Table. Decision Trees can be drawn as a modified flow chart, where each node (decision) has a yes and no branch leading to either another node or an action (decision). One advantage of Decision Trees is that they provide a sequential way to represent how the various conditions are processed. However, since complex electronics are parallel rather than serial, Decision Tables may be a better choice.

Decision Tables and Trees are a good analysis for ensuring that all combinations of input conditions have a corresponding action. Unexpected inputs (or combinations thereof) are quite common in complex systems. The designer (and assuror) of complex electronics cannot assume that the world outside the device will always behave as specified.

Reverse Engineering of Requirements

The level of detail of requirements for complex electronics varies. The project may simply use higher-level requirements to define what the complex electronics must do, and document the more detailed specification within the design. In situations where the complex electronics requirements are unavailable or inadequate, the assurance engineer may need to create a requirements specification for the device, in order to support future analyses. The assurance engineer may also wish to follow this process to independently derive the requirements as a cross-check to the project activities.

Requirements reverse engineering assumes that the project is already past the requirements phase and into design (or a later phase). The assurance engineer has available the following resources:

• System requirements
• Sub-system, component, etc. requirements
• Design of the complex electronics (architecture, behavior, detailed, etc.)
• Interface information from the complex electronics to the rest of the system.

The basic process for reverse engineering is to apply an iterative approach, using the “next level up” requirements and the complex electronics design information. Follow the derivation process in Developing Requirements, and then compare the result (complex electronics requirement) against the design. Do they match up? If not, take the design function and create a requirement the design would meet. Consider if that requirement could be a “derived” requirement from the higher-level system element. The end result of this highly manual process is a detailed set of requirements that the complex electronics design meets.

The chances are good that in performing this task you will find areas where higher-level requirements are wrong, ambiguous, or incomplete. You will also likely find some design elements that are incorrect or incomplete with respect to the system requirements. Use the project problem reporting system and/or the requirements change system to iron out the issues and ensure that the appropriate document (requirements or design) is changed.

Fault Tree Analysis

A Fault Tree Analysis (FTA) is a top-down approach to failure analysis that starts with an undesirable event, such as a failure or mishap/accident or malfunction, and then determining all the ways that event can happen. It is a system for identifying causes of hazards, but not the hazards themselves. Fault Trees are often used to look at the hardware aspects of the system for possible failure modes. Traditionally, Fault Trees did not consider software, programmable elements, or operations as possible causes of events.

Fault Tree Analysis should include complex electronics, and consider faults and failures that are design related, as well as actual problems with the silicon chip. The task is to identify all possible events that can lead up to a failure mode. FTAs use a deductive approach to identify critical paths and provide minimal sets of states or critical paths which will lead to the top event.

Including complex electronics in an FTA is a little trickier than strictly addressing hardware failures. The complex electronics can perform multiple functions and operate in many modes or states. It performs different functions at different times.

Details of Fault Tree Analysis can be found in the Techniques section. Specific design issues and faults to consider are being investigated. Guidance for including complex electronics in Fault Trees will be added when the investigation is complete.

Failure Modes and Effects Analysis

Failure Modes and Effects Analysis (FMEA) is a bottom-up method used to find potential system problems while the project is still in the design phase. Each component in the system is examined, and all the ways it can fail are listed. Each possible failure is traced through the system to see what effects it will have, and whether it can result in a hazardous state. The likelihood of the failure is considered, as well as the severity of the system failure.

When complex electronics are included in an FMEA, the key fault modes (ways the design and device can fail) are identified. The effects of abnormalities in the complex electronics on other components in the system, and on the system as a whole are the result of the analysis. This technique is used to uncover system failures from the perspective of the lowest level components. It is a “bottom-up” (or “forward”) analysis, propagating problems from the lowest levels, up to a failure within the broader system.

The FMEA asks “What is the effect if this component operates incorrectly? Failures for the component are postulated, and then traced through the system to see what the final result will be. Not all component failures will lead to system problems. In a good defensive design, many errors will already be managed by the error-handling part of the design.

Details of Failure Modes and Analysis can be found in the Techniques section. Specific design issues and faults to consider are being investigated. Guidance for including complex electronics in FMEAs will be added when the investigation is complete.

Requirements Engineering

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:

• Overview
• Requirement Decomposition
• Characteristics of Requirements
• Requirements Flowdown and Traceability

Overview

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). 
• A performance requirement describes 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.
• A constraint is a limitation that a product or system must stay within. 

Requirement Decomposition

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, usually by test, analysis, inspection, or demonstration.

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.