Problem
I have an empty requirement document template (if I'm lucky!) but don't know how to start capturing requirement information in the document.
Solution
Adopt a 3 - phase iterative approach to writing down requirements, equivalent to the design - code - test & repeat approach of writing code:
- Note or jot down in the document any and all raw information as you capture it from meetings, emails, previous documents etc. These will be a mix of real requirements, design ideas, UI sketches etc. Initially don't worry about structuring the information or complying with your requirement rules. Do record the source of every entry for future reference.
- Begin structuring the requirements into a scope hierarchy, adopt simulataneous top-down and bottom-up techniques in the same document, whilst ruthlessly separating requirements (the "what" and "how well") from design (the "how"):
- Start re-writing the requirements by a simple top-down multi-level list of bulleted headlines. Focus on describing the scope at each level. Continuously refactor the list (changing headings, moving requirements to different positions in the list) as you add more scope items. Do not start labelling requirements at this stage.
- At the same time, where there is already sufficient detail, start writing formal requirements using definitions, testable statements etc. Paste these into / underneath the appropriate place in the top-down hierarchy, if this is obvious, else keep in separate section until scope hierarchy is sufficiently developed. Draw out common definitions into a Glossary.
- Share versions of the document early and often with the stakeholders as the analysis process continues, as the requirements structure becomes clearer. Get feedback and comments to feed into next iteration.
Discussion
Specifications are not written from page 1, fully-formed and complete. Like a novel, they have to be constructed by a deliberate process of iterative drafts, continuously building up detail. At the start of a new project, it is usually just not possible to launch into writing requirement statements at the level of detail and quality expected for the final version.
The ideas outlined above work as an initiator to begin the process of construction. The focus should be on quickly capturing the essential scope of the system, and defining key domain terminology and phrases. At this early stage, complying with the more formalised specification rules described elsewhere in this Cookbook may actually hinder progress.