Risks, requirements, and testing
Based on the needs of the device or system under development, product teams work to identify potential harms, which are balanced against the likelihood of each individual harm. The team then has to identify the product hazards that may cause those harms, and analyze the causes of those hazards. Risks are the likelihood that the product hazard can harm a user or operator.
For example, a harm in a medical device could be a severe electrical shock, with the hazard being electrical leads. The causes of the hazard may be exposed leads or uninsulated controls. Teams have to work to identify these causes and determine where and how to mitigate them.
Based on that analysis, additional nonfunctional requirements may be added to the list of product requirements. These new requirements help to mitigate the risk of harm because they enable the hardware and software developers to create features in a way that mitigates those harms. Note that nothing has been designed or built yet; the results of the risk analysis typically become new or modified requirements.
Using an automated solution, such as Seapine's TestTrack, makes establishing and maintaining traceability between requirements, safety harms, and downstream artifacts easy.
Then, the new nonfunctional requirements have to be tested to ensure the product properly incorporates them. By analyzing requirements and developing test cases, product testers are able to verify that the product meets the necessary safety standards. Without that verification, no team would be able to release the product to market.
Traceability is a key part of the testing and verification process. Traceability lets teams link product requirements to safety risks, resulting in nonfunctional requirements that mitigate those risks, and downstream artifacts such as test cases and defects. One important value of traceability in embedded product development is that it provides for the communication of safety risks and mitigations among the team and across all stakeholders. Accurate, automated traceability can enable the extended team to work together on a successful product launch.
Hardware and software product developers need this traceability to build mitigations into the actual product. In some cases, product engineers have joined the project after the requirements were developed and safety risks analyzed, and don’t have the understanding of the background and purpose of the nonfunctional requirements. Traceability enables them to easily go back to the original risk documents to better determine what the risk is, and how it can best be handled in the product.
Testing and traceability
Traceability is especially needed from a testing standpoint. Testers have to write test cases to verify that mitigations have been properly implemented in the final product, and that those mitigations meet the safety standards needed to ship the product. Without verification through a comprehensive testing program, the team has no way to confirm that the mitigations are in place and meet the requirements.
The most successful product teams work together on requirements and safety risks, and manage them in an integrated way. In doing so, the team can work directly from requirements to analyze potential hazards and resulting harms, and then determine the best ways to mitigate the risk of harms. At the same time, they can easily create new nonfunctional requirements to reflect that risk mitigation, and add them to the requirements list.
Traceability is the glue that holds the safety mitigation process together. By tracing safety risks forward to requirements, tests, and defects, teams can fully understand the origin of the risks and the best way to implement and test the solution. In the reverse direction, traceability lets testers verify that defects have been addressed and test cases have fully covered nonfunctional safety requirements. The result is a product that’s in compliance with applicable standards and is safe for its intended use.