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

1 comment:

  1. Anonymous12:16 pm


    These are excellent points.

    The test-driven projects I've worked on have been consistently smoother and easier throughout all phases. Interestingly, after the first few test-driven projects were deployed, most people suddenly became used to the lack of serious bugs found in testing. The cost savings were tremendous. More importantly, it really contributed to better relationships and teamwork between business analysts, testers and developers.