High-assurance design industries such as military/aerospace, automotive and medical, know that failure is not an option. Failure all too often means lives lost; best case, it means a lot of money down the drain. That is why standards, like DO-254, ISO 26262 and IEC 60601, are being applied to more and more programmes.
The key idea behind these standards, and the concept of design assurance in general, is proving that a device performs as intended; nothing more, nothing less. The intended function of a device is specified by its requirements. This is why these design assurance standards are so focused on requirements and the proper management of requirements throughout the process.
In these programmes, requirements must be captured, reviewed and validated, managed and traced to design implementation and verification activities. By incorporating these tasks into the design process, this ensures you have proof that the end product does in fact meet its intent. To meet the requirements based objectives in the design flow, this means you will have to have a mechanism or method to store requirements, a checklist of criteria against which you review the requirements, a means to manage changes to requirements, and a method to link requirements to the design implementation, as well as to verification tests, results and coverage.
That does not sound so difficult, right? But when you consider that requirements can be volatile throughout the process, that the mechanism to capture requirements is disconnected from the design environment and often takes an expert (not a member of the design team) to do any sort of ‘management’ of the requirements, and that the implementation and verification of requirements occurs within a variety of environments and tools, each with their own language, format, process, location and experts, then things get a bit trickier. Then the common approach of running around with a spreadsheet just before an audit becomes the most critical and yet most hated job. Then after a failed audit, management might consider that there must be a better way.
This is where the advent of requirements management tools, such as Mentor Graphics’ ReqTracer, fit in. ReqTracer is an interactive requirements management, tracing and analysis tool that can link requirements from the highest system level to the lowest-level implementations of hardware and software. The tool can interface to requirements information, covering artefacts stored in a wide variety of data formats and file types. These can include enterprise requirements databases (such as IBM’s DOORS), Microsoft Office type documents and source code files, as well as information in ASCII text logs. In addition, ReqTracer provides interfaces to a variety of system/board/chip/software design tools to enable coverage tagging and requirements tracing access to the design and test data managed by these tools.
After initial project setup, ReqTracer provides an ongoing and synchronised requirements-based view of the project. Prior to audits, users generate pushbutton reports that check all the things the auditors will be looking for. Requirements changes, and their downstream impact, are all highlighted in red for easy visibility and understanding. Requirements validation checklists are both built-in and customisable, and information from the reviews can easily be captured as artefacts. Requirements traceability is automated and up-to-date with the design status. Producing that traceability spreadsheet (if one would rather do that than use the tool in audits) is done with a single button push.
Having a good understanding of requirements and a flow built around requirements management and traceability is an essential part of any successful high-assurance design program – whether it is governed by a standard mandating this or not. Certainly high-assurance industries benefit from this approach in terms of its impact on safety. That is why it is in fact mandatory. But any company producing a product can gain from employing these same principles. After all, what company wants to produce a design that does not meet its requirements? What company wants to stand up in front of their customer and say “We have finished your design, but it does not do exactly what you want.” None that want to be profitable or stay in business long! That is why the principles of good requirements management are so universally valuable.
| Tel: | +27 11 315 8316 |
| Email: | info@asic.co.za |
| www: | www.asic.co.za |
| Articles: | More information and articles about ASIC Design Services |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version