Requirements Definition

Let me first stress that this is not a particular phase of a project, it is a technique for defining requirements. You'll be getting an early view of business requirements during Requirements Analysis and you'll be finalising them (business ones, at least) during the Requirements Specification phase. In both cases you'll be using the Requirements Definition technique.

The real key to success (and often the most difficult to achieve) is expressing requirements in a solution-independent way. And yet, sometimes there is a need to be a bit "solutiony", if just to give the supplier something concrete to help their understanding. There is also the definition of what is "solutiony" and what not.

Examples:

"Solutiony"

(see the equivalent True Requirement number below)
1. A guestbook is needed so visitors can leave comments about photos
2. A copy of each received order should be placed in an archive folder in Outlook
3. Orders for photo prints placed via the web site should be sent automatically to Photobox's website for fulfillment.

True business requirement

1. Provide a mechanism whereby a visitor can leave comments about each specific photo and other visitors can read them.
   Profane, obscene, racially intolerant or other such comments should be prevented.
   Comments should be maintainable (edit / delete / "always at top") by a suitably authorised person.
2. Each order received should be retrievable in its original received form
   (this allows for orders to be received by email, snail mail, fax, carrier pigeon... consideration would need to be given to the requirements around telephone orders).
3. Orders for photo-based products that can be taken via our web-site are to be passed automatically to the currently set supplier for that product, for fulfillment.

The main tool of the requirements definition technique is the requirements catalogue. Each entry in the catalogue is a requirement - each is usually placed in its own table to hold the details of the requirement in a structured way.

First, consider that there are two types, functional and non-functional. An example:

A requirement might be that prospects are emailshot (careful, that's a bit "solutiony") if they fall into the right category. A non functional aspect of this requirement is that the layout of the communication has to be designed according to house style, and info that would normally go on a flyer or brochure is included somehow. Another non-functional aspect is that this is to be done monthly to approximately 12,000 people.

Ok, so how do you go about identifying and collecting requirements? Well, actually doing the analysis - going out and fact-finding, holding workshops, visiting client sites or holding conference calls, corridor and coffee machine meetings - all these are out of scope of this briefing study. But fear not, there's still lots here to help.

However you've been doing it, you'll have a set of DFDs and an LDM. Depending on when you're looking, you'll have a developing or good understanding of the existing business system and a developing or good understanding of the required system.

You should also have some high level requirements referenced in the Project Initiation Document (PID), Terms of Reference (TOR), Project Brief, Feasibility Study or whatever it was that got the work started. These high level ones must beg a lot of questions and lead, via a ripple effect, to related requirements and, via a cascade effect, to more detailed requirements.

Each dataflow that crosses the boundary on an elementary process (on the DFD) has to have related requirements. Each occurrence of a datastore getting "poked" by a dataflow is the source of another potential requirement. Each elementary process will likely have reporting requirements. Find out who the owner of each requirement is and catch up with them - they'll be able to give you practical, business facts for the requirement and may be able to give or confirm others. Depending where you are in the project, they'll probably have helped you develop or confirm their bit of the DFM and LDM.

For each functional requirement, consider its non-functional aspects - any special security needs? Volumes: how many per period, any peaks / seasonal variations. Are there any special forms to be designed? Are there any special training needs other than the obvious? How quickly does the process need to recover after an interruption in service? Are there any existing technology constraints? How many users? Any special authorisation / audit needs? Any special data restriction or privacy needs?

Generic non-functional requirements need to be stated separately, in their own table. Legislative, performance, business interruption recovery, archiving and data retention are likely to fall into this category.