Finding missing requirements
I went to a two day requirements training course the last week which did a great job of covering the basics of requirements. The course was taught by Cheryl Hill at Compliance Automation http://www.complianceautomation.com. I thought the content was great, but that there was a hole in their methodology for finding missing requirements. They felt that using a traceability matrix was the main way to find missing requirements. In my experience, the traceability matrix is a good way to ensure that you have at least some low level requirements mapped to high level requirements. However to truly find missing requirements you really need something more.
Imagine that you have a jumble of letters in front of you and you have to find out which letters of the alphabet are missing. If you just stare at the jumble or even line them up in a row, it is going to be incredibly difficult to find the missing letters. However, if you order the letters alphabetically, all of a sudden the missing letters jump right out.
The key to finding missing requirements is to take advantage of the fact that each requirement is related to other requirements in some way. It is virtually impossible to find missing requirements given a list of shall statements, but if you add some structure to the requirements that take advantage of their relationship, it becomes a lot easier.
Some examples of models that help to create structure around the requirements are use cases, decision trees, decision tables, data flow diagrams, click-action-response tables, flow charts and many more. Most people writing requirements have never heard of many of these!
One key concept to keep in mind that using these models doesn't absolve you of the need to write shall statements, they are simply used to provide context to create order around the requirements. We have seen many organizations try to use use cases as the requirements rather than as a model with which to find missing requirements.
Keep dropping by as we discuss these models in depth.
Imagine that you have a jumble of letters in front of you and you have to find out which letters of the alphabet are missing. If you just stare at the jumble or even line them up in a row, it is going to be incredibly difficult to find the missing letters. However, if you order the letters alphabetically, all of a sudden the missing letters jump right out.
The key to finding missing requirements is to take advantage of the fact that each requirement is related to other requirements in some way. It is virtually impossible to find missing requirements given a list of shall statements, but if you add some structure to the requirements that take advantage of their relationship, it becomes a lot easier.
Some examples of models that help to create structure around the requirements are use cases, decision trees, decision tables, data flow diagrams, click-action-response tables, flow charts and many more. Most people writing requirements have never heard of many of these!
One key concept to keep in mind that using these models doesn't absolve you of the need to write shall statements, they are simply used to provide context to create order around the requirements. We have seen many organizations try to use use cases as the requirements rather than as a model with which to find missing requirements.
Keep dropping by as we discuss these models in depth.
posted by Anthony C. at 12/10/2005 07:01:00 AM
2 Comments:
The best tools for tracing requirements employ a relational database to store both the requirement and successor and predecessor links to other requirements.
The most ancient of these were the manufacturing bill of materials databases. Think of the successor relationships as "used-on" and the predecessor relationships as the "where-used" links.
As old algorithms find new uses, history repeats itself.
Tools that work best for requirements tracing employ a relational database back end.
The ancient (1960's) format best suited is an extended bill of material-like database that holds the requirements in a single identity table with Successor (used-on) links and Predecessor (where-used) links.
As old algorithms are used for a different purpose, history repeats itself.
Good tools also let you classify requirements as functional, constraints, data, etc.
Post a Comment
<< Home