Requirements defines a problem to be solved. Testing verifies that a particular solution solves the problem. Traceability is the ability to map tests to requirements to verify that the software really solves the problem. Odd thing though, if I specify form elements in a requirements document:

Enter Patient Address:
  name: text, 60 characters, at 5, 15 on screen
  ...
and I make the tests:

/form/name.type() == "text"
/form/name.length() == 60
  ...

Why is information duplicated in two places? Why not just link the test to the overarching requirement (in this made up example 'Enter Patient Address'). Then traceability is a list of tests mapped to a much coarser requirement.

This really begs a larger question: What is the point of requirements? A Capability Maturity Model, ISO flag waving person will say a requirement document should iterate every single detail so you know what the system does (totally unambiguously). An extreme programmer may not give much value to a requirements document as the system and the tests represents the actual system (how can you ever guarantee traceability to a large detailed requirements document). I personally, think requirements work as a high level contract of work. Something which outlines the problem (coarse requirements) to specific solution guarantees (tests).

Knowing that a requirement is called 'Enter Patient Address' and that the details of that information is 'enter patients name, street, city, state, zip, and email', would be enough detail for me to have a clear idea of the problem to be solved. When implementing the solution, you can ask a domain expert how big the field is and then define a test; then mark it as a test for the 'Enter Patient Information' requirement. This amount of detail in a requirement maps fairly closely to 'Use Case' modelling.

If you live in an all up front world where you must make all decisions before you write software (which maps well to very few actual projects in the universe), then you can just write all your tests before you write the software. Perhaps at this point in time, your test is just an empty failing test, documenting its expected outcome (as a comment in the test code). When you actually have code that can be tested against you implement the test at that point.

Conclusion...Would you rather read a two thousand page requirements documentation full of tables of field lengths and pixel offsets or a document which conveys what the product actually does and more importantly can be read?

The views and opinions expressed in this page are strictly those of the page author.
The contents of this page have not been reviewed or approved by the University of Minnesota.