Design News, May 2013

Issue link:

Contents of this Issue


Page 70 of 110

Design Hardware & Software 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. 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 . We'll make YOU a fan. Smart Fans That Put You in Control Lowest Cost Short Fan Tray Slides into any ÃÌ>`>À`Ê£»ÊÀ>V 3-Position AC Tray Series #: OA300ST Size: 432x203x44.5mm Air Flow: 310 CFM Replace your existing fans with smart AC or DC fans and fan trays from Orion. Temperature control fans reduce energy costs by cooling only when you need to. UÊ,i`ÕViÊiiÀ}ÞÊVÃÌÃÊLÞÊÎä¯ÊÊ UÊ,i`ÕViÊÃi UÊ ÝÌi`Êv>Êvi UÊSimple to install with no additional connections UÊ Û>>LiÊvÀÊÃÌVÊ>ÌÊ"ÀÊ >à Shortest lead time Great prices More control U Lower energy consumption U Longer fan life Start saving money with smart fans and trays from Orion Fans. AC Fans U DC Fans U Fan Trays U Accessories nää°ÎÓΰÓ{ÎÊUÊÓ£{°Î{ä°äÓÈx Design News | MAY 2013 | w w w. d e s i g n n e w s . c o m –52– magenta cyan yellow black ES246213_DN1305_052.pgs 05.03.2013 22:05 UBM

Articles in this issue

Links on this page

Archives of this issue

view archives of DesignNews - Design News, May 2013