29 October 2008

Two useful techniques for requirements and project briefs

I was just reading a handful of project briefs (or project scope docs) and noticed a pattern I wanted to share.

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:
  1. A clear alignment from top to bottom of goals to activities,
  2. A consistent use of phrases that are easy to identify as done or not done
The first technique – aligning the technology to business is a massive issue in (not just our) industry today, and sloppy analysis and design work is as much a part of the problem as no analysis and design. Possibly more. (http://leansoftwareengineering.com/ksse/scrum-ban/)

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 inpeer 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.
Photo by snapperwolf* cc @ Flickr

Search This Blog