As embedded devices in areas such as medical devices, automotive systems, and consumer electronics become more sophisticated and complex, product development groups are faced with the need to better understand and communicate project information across the range of stakeholders.

There's also a need to ensure that requirements are being successfully implemented, safety risks are identified and mitigated, testing is verified, and intended use is validated and documented. Safety risks include the potential for fire or electrocution, the catastrophic failure of critical components such as automobile braking systems, or the possibility of applying the wrong treatment with a medical device.

Development organizations must manage risks to the safety of users and operators of many types of devices, adding layers of complexity to an already difficult development process. The identification, assessment, and management of safety risks means ensuring that risks are identified and appropriately handled in product requirements, tracked throughout the development effort, and tested to ensure that requirements are met. As defects are found, they must be matched to product requirements, including nonfunctional requirements that mitigate safety risks.

Further downstream, changes to approved requirements necessitate a reassessment of risk to determine if additional risks have been created, or older ones have disappeared. To do this effectively, product teams need clear visibility into the relationship between requirements and risk.

This visibility becomes even more important and valuable as projects move from marketing teams with clear visibility into safety risks and mitigations, and how they may change over time, to better meet their business requirements and better demonstrate compliance to any applicable regulatory agencies. They will also ultimately produce higher quality products that are demonstrably more reliable and safe, improving the chances of delivering a successful product.

Requirements and safety risk
Most embedded product development teams identify and evaluate safety risks as a part of the analysis and requirements for a new or modified product. Often, the requirements process and safety risk identification processes are separate, and contained in separate sets of documentation, in separate software systems.

This approach makes the relationship between risk mitigation and requirements unclear and difficult to determine. Unless requirements can be linked to specific risks and hazards, and risks mitigated through changes to requirements, it's a time-consuming and error-prone process to match up risks with requirements. Not only is this an extremely detailed and expensive process, but if risks aren't successfully identified and mitigated, the product may never get to market.

The mitigation of safety risks is expressed as nonfunctional requirements that should be tested for compliance. For testers to be able to understand and write test cases for nonfunctional requirements, they need to have a clear picture of why the requirements exist, where they originated, and how they were derived from the functional requirements.

Further, the separate approach to managing requirements and risks makes it difficult to determine whether risks have been mitigated in the final product. As a product moves from requirements into specifications, development, integration, and testing, significant time may have passed and new team members may have joined the project. If nonfunctional requirements that mitigate safety aren't well understood downstream, they may not be appropriately tested. The passage of time and the loss of clarity of the reason and meaning of certain requirements can increase the potential that some hazards will leak through to the completed product.

Test planning and actual testing are important parts of that process. Ideally, test cases and test runs can be traced back to requirements, so that successful test case execution can also mean full requirements coverage. With traceability back to the safety analysis and risks, teams can also demonstrate that their test suites directly test their risk mitigation strategies.