If requirements ask for it, it had better be there

Engineers are known for their attention to detail and precision in thinking, but sometimes still struggle during compliance audits. This is especially true the longer a list of requirements becomes, especially unstructured lists kept in spreadsheets and on Post-It notes.

It gets even more complicated, because in defense circles with standards like DO-254, one has to understand the process and “the customer”. I had a boss in the defense industry leave me with a piece of advice I’ve never forgotten, applied to the fine art of proposal writing:

Don’t put one thing in there they didn’t ask for.

At first, I thought that was silly. How do we differentiate our proposal as being better than those from the competition? However, having survived some big projects and audits, the wisdom became clear. Our job was to instill confidence that we understood the stated requirements, and covered them in the least amount of time, space, weight, and power, at the right cost.

If the program office had wanted something else in there, they would have asked for it. Auditors have a keen understanding of that principle, and will zoom in on anything that even looks like it sticks just a little out of the box. We usually got into more trouble justifying requirements we dreamt up than we did by sticking to the stated requirements.

The other inexcusable sin is missing a requirement the customer cares about intensely, which is basically each and every one of them they took the time to write down. Auditors have zero tolerance for this. The compliance audit process for most activities, after stripping away the specifics of the standards and technology involved, can be reduced to one sentence:

Tell me what you were required to do, and then prove to me you did it.

Most audits trip on missing artifacts, usually not on implementation minutia. What reviewers are really looking for is coverage: requirements were recognized and addressed in designs, tests were performed and documented, and corrective actions were initiated and closed.

The moral of this story is the requirement that blows up your audit will be the one you can’t trace to completion. Keeping requirements in an unstructured document might seem organized, but connecting all those notes in the comment fields to the right places can fail miserably when the auditor is looking at his watch.

Last year, we introduced you to Spec-TRACER, the Aldec application for requirements management of FPGA and ASIC designs. In the latest release, improvements have been made to speed up the ability to store, annotate, and track requirements, with tools to get more information out of Word or Excel or Post-It or cerebral cortex, and into efficient reviews guided by menus and reports.

Spec-TRACER 2013.12 has a new Reviewer tab, which provides a check list with user-defined rules and standards, along with review status information – pending, rejected, or approved, including comments. It also has something called Full Traceability View, which can overtly include or exclude relationships of importance.

A project in Spec-TRACER is connected all the way from system requirement to HDL code and waveforms. Other new features support traceability to block diagram and finite state machine elements, allowing drag-and-drop of tags which are carried into the generated HDL code, and automated reporting of verification coverage pulling simulation results from the Aldec Coverage Database (ACDB) shared with other Aldec tools. There is also a Test Sessions tool, focused on regressions and scenarios including blocks and motives.

Users familiar with Spec-TRACER helped drive these improvements with Aldec, but a new user will find help in implementing the tool in the form of an ARINC 429 Receiver sample design that suggests how to organize projects. Other project templates supporting DO-254 reviews are included as well: project status, review status, test history, and test session.

For more on Aldec’s DO-254 expertise and tools, a live January 30[SUP]th[/SUP] webinar with two sessions for global viewers may be of interest (if you’re here after that date, follow the link and click the Recorded Events button to find the title):

Elemental Analysis: DO-254 Additional Verification for Levels A and B

Even if you’re not engaged with DO-254, any FPGA or ASIC design project can benefit from better requirements traceability and support for audits, internal or external.

More Articles by Don Dingee…..

lang: en_US