Horizontal traceability of functional requirements.
Vertical traceability, from parent requirement to child requirement, has long been considered an important part of requirements analysis. Horizontal traceability is a new concept that has only recently become feasible.
Functional requirements take input data, do some kind of processing, and produce an output data item. If there are no missing requirements, all of the system outputs can be traced back through a series of requirements, to the system inputs.
The "trace" is done by noting that every input data item must be the output of some other requirement. Thus the requirements are horizontally connected, input to output. Missing connections mean missing requirements.
Verifying the horizontal traceability of more than a handful of requirements "by hand" is simply infeasible. Using a spreadsheet macro to do the analysis makes it possible to easily find most of the missing requirements.
It is very new and not well known. I wrote an Excel macro to partialy automate the process. It is available for free at http://www.barbarabea.com/?page_id=11
There is also a tutorial and user guide.
I have used it on a few projects. One of the projects had a mature set of requirements, i.e. a product based on those requirements had been completed and shipped. When those reqs were put in the spreadsheet we found that there were a lot of reqs missing. (~40%) Another project used it to write new functional requirements. For the new reqs, the graphical output was the most important part. Seeing how all the reqs tied together helped identify which reqs should be written next and which needed to be modified because they did not fit well with the rest.
I do have another idea. But it is more academic than practical. It is also written up at the Barbara Bea blog.
One of the characteristics of a good requirement, we are told, is that it is unambiguous. This is usually defined as having only one possible interpretaion. Any high level requirement that has child requirements is ambiguous. Otherwise it would not need child requirements.
But how do you go about deciding whether or not a requirement is ambiguous? I have created an objective test to determine if a functional requirement is ambiguous. If you start with a set of functional requirements that are horizontally connected, then each functional requirement is unambiguous if, and only if, the processing step is an algorithm.
Told you it was academic. But it is also the only objective test for ambiguity that I have ever seen.