Bookmark and Share
Blog powered by Typepad
Member since 03/2007

Become a Fan

« Effective Verification - an Important Quality Metric | Main | Requirements Traceability »

September 07, 2010


Feed You can follow this conversation by subscribing to the comment feed for this post.


You can argue for a very long time about good requirements. Especially with their authors. Some thoughts:

Good requirements are developed from the higher level. They're not invented and later justified by tracing to something that looks fairly similar. Good requirements trace like a charm.

Good requirements have a consistent level of granularity. Unfortunately, this tends to be inherited by the higher level of requirements. If you start with system requirements that vary heavily in granularity, this problem will flow down.

Good requirements are written and reviewed by commitee. This should include verification, safety, system and software experts.

Good requirements follow a good requirements standard. This may sound obvious, but it's a challenge.

Good requirements are functional, i.e. verifiable by test. "The SW shall be written in C." is not a good requirement. It belongs into a plan, not into a requirements document.

alpha male

This is a sort of blog we can have loads of information i would like to appreciate the intelligence of this blog's owner


Good point Eric. I haven't seen another area that is as subjectively judged as requirements. Even within our group, we will create a requirement by committee and a month down the line wonder why it was created that way and change it.

Having V&V in the informal reviews at the beginning is essential.


@Eric, thanks for your comments. I will need to create some "good" and "bad" requirement examples to explain what I mean.
However, going by DO-178B's prescription, any requirement that is easily verifiable is a good requirement. If I need to write an extremely complex test case or refer to other requirements distributed randomly all across a document, then that definitely is a bad requirement.

Eric Bresie

Maybe this goes with the "requirements by committee, but I often times find one person's "good requirement" is another person's "bad requirements".

Do you have some publicly available examples of "good requirements" vs "bad requirements".

The comments to this entry are closed.

My Photo

Life sometimes turns on a dime. Especially when you are actively looking out for a change. I now work at HCL Technologies. And all I am looking for is to make a difference. By the way, the blog contents remain my own. It does not reflect the official position of HCL.

Your email address:

Powered by FeedBlitz