 |
Benefits of requirements capture
The best, clearest and most obvious benefit from a thorough process of requirements capture is enhanced (deeper, better, more widely available) understanding. This understanding should reside within the project team - in people's heads rather than in neglected and unread documentation - so that all project stakeholders have a good mental model of the project, its users, goals, challenges etc.
In specific UCD terms, requirements capture:
- Highlights the importance of usability early in development
- Provides concrete objectives for usability
- Provides usability criteria that can be tested
Look out for
The structuring of information during the process is as important as the accumulation, so you need to be alive to the possibility of information overload.
- Getting ahead of yourself - don't try and solve problems, put right wrongs, create solutions or otherwise be too overtly creative during requirements capture. You'll have time for that later!
- Analysis paralysis - it's generally not wise to attempt too much analysis during requirements capture. By all means note issues and problems that require more thought, but don't try for solutions yet.
- Iterate your requirements specification - so that stakeholders have more than one opportunity to review and input
- Make it fun - people are generally much more forthcoming if they're feeling good about things. So do make a positive effort to make the session enjoyable
|
Useful resources |
Macaulay, L.A. (1996) Requirements Engineering. Berlin: Springer Verlag Series on Applied Computing.
Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, S. & Carey, T. (1994) Human-Computer Interaction. Reading MA: Addison-Wesley. |
Alternative methods
There are of course as many different approaches to requirements capture as you can shake a stick at. Many people distinguish, for example between kinds of requirements, so that business, user and functional requirements are treated as completely different things.
User-centred design is best done iteratively. Yet most requirements capture - because the production methodology requires it - is only done once, during an initial Discovery phase.
An alternative is incremental requirements capture. This is still very much a new idea, originating from the extreme programming and agile methodology schools. In this approach, a project team live and work with the realisation that they are working with partial information, and simply iterate back to a requirements capture mode when they need to take the project forward.
|
|
| |
