Briefing Study: Requirements Analysis and Specification (slide 12)
Requirement Definition technique
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.
Requirements that are too "solutiony"
- A guestbook is needed so visitors can leave comments about photos
- A copy of each received order should be placed in an archive folder in Outlook
- Orders for photo prints placed via the web site should be sent automatically to Photobox's website for fulfilment.
Compare each of the above to the same numbered requirement below:
Business requirement stated so that they avoid mentioning solutions
- 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.
- Each order received should be retrievable in its original received
(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).
- Orders for photo-based products that can be taken via our web-site are to be passed automatically for fulfillment to the currently set supplier for that product.
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.
Two types of requirement...
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 dataflow diagrams (DFDs) and a logical data model (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.
Always start a major piece of work by writing a terms of reference document. The reason is that it makes clear exactly what the scope of work is, who it's for, who the key players are and includes an initial outline plan.
Project managers love it, the business loves it, you love it - because you're setting yourself up for success, whatever the outcome of the piece of work.
With the terms of reference in first draft, everyone's on board (or submitting amendments). Anyway, the outcome is that everyone knows what you're up to, how you're going to approach the business and a list of the stakeholders you'll need time from.
That's what project managers like and projects need: certainty.
Terms of Reference template
We have a template you can buy for a ToR document. It's got all the sections and headings you'll need, with notes under each one to tell you what to put there.
It's one of two templates included, the other being a template for a Statement of Requirements. Find out more and buy the templates here