I am reading these briefs to assess whether projects have been successfully delivered or not. What I found is that some project briefs are better aligned to high-level business goals and it is the same ones that are best articulated so I can see whether a project has been successful or not.
The techniques that have been most helpful to me are:
- A clear alignment from top to bottom of goals to activities,
- A consistent use of phrases that are easy to identify as done or not done
This second technique ties in with the idea that everything from requirements to units of code should be testable in a very black and white – binary – way. This idea is encapsulated in the test centric V-model of software development, agile's test driven development and other methods and ideas. Everyone agrees that testable requirements and solutions are a key success factor.
Why then are professional, educated analysts failing to deliver testable requirements? One hunch I have is that everyone is too rushed to accommodate a peer review of requirement specs.
Well people, the industry numbers are in – peer review of requirements cuts defects massively. The time you invest today will save a large swathe of time in the future when the solution is reworked to cover the gaps and holes left by poor requirements.