Design News, May 2013

Issue link:

Contents of this Issue


Page 68 of 110

Design Hardware & Software Traceability Brings Visibility & Clarity to Embedded Projects All product stakeholders benefit through better tracking of artifacts from test cases to defects and back to nonfunctional safety requirements. By Peter Varhol, Seapine Software A s embedded devices in areas such as medical visibility into the relationship between requirements and risk. devices, automotive systems, and consumer This visibility becomes even more important and valuable as electronics become more sophisticated and projects move from marketing complex, product development groups are Teams with clear visibility into safety risks and mitigations, faced with the need to better understand and communicate and how they may change over time, will better meet their project information across the range of stakeholders. There's business requirements and be able to better demonstrate comalso a need to ensure that requirements are being success- pliance to any applicable regulatory agencies.They will also ulfully implemented, safety risks are identified and mitigated, timately produce higher quality products that are demonstratesting is verified, and intended use is validated and docu- bly more reliable and safe, improving the chances of delivering mented. Safety risks include the potential for fire or electro- a successful product. cution, the catastrophic failure of critical components such as automobile braking systems, or the possibility of applying Requirements and Safety Risk the wrong treatment with a medical device. Most embedded product development teams identify and Development organizations must manage risks to the safety evaluate safety risks as a part of the analysis and requirements of users and operators of many types of devices, adding layers for a new or modified product. Often the requirements 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 Teams can determine harms from product requirements, which can be linked to potential effectively, product teams need clear hazards that may cause those harms. Design News | MAY 2013 | w w w. d e s i g n n e w s . c o m –50– magenta cyan yellow black ES246211_DN1305_050.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