Requirements capture downloads
examples & illustrations

Requirements capture :: 1 of 3

< previous | next >

What is it?

Requirements capture is the collection (and structuring) of information via a number of different methods and means, and the detailed documentation of that structured information via one or more forms of specification document.

Characteristics

In a user-centred design-focused sense, requirements capture should be a highly generative process which uncovers and structures information on:

• The user and their usability requirements - including their characteristics, needs, skills and aptitudes
• The user interface - including its design, form and function
• Common tasks - and the environment in which the user will interact with the product or offering

What's it for?

To establish an agreed consensus on what the project is all about - with particular emphasis upon user-centred design (UCD) - and to document that understanding for the appropriate audience.

When to use it?

Given the nature of the activity, requirements capture is used exclusively at the beginning of a project or at the initiation of any distinct phase of a programme of effort. In terms of the Becta production methodology, requirements capture is central to Discovery.

Prolegomenon
At the start of a creative methodology I authored a while ago, I exapted a line from Frank Herbert's seminal novel Dune - "Beginnings are delicate times" - to illustrate the totally fundamental importance of accurately and transparently capturing a client's requirements before embarking on a commmunications project.

Equally important is clearly establishing a very public consensus on just what those requirements are before embarking on the project, thus avoiding all those unfortunate, "Oh, I thought that..." conversations weeks or months later.

It sounds like such a simple thing - confirm with a client what it is that they actually want before commiting to deliver it. But all to often it's not done (or not done properly). And of course, it's not a simple thing. Often a client doesn't know what it is that they want, and all they have (and rightly so) is an aspiration. More often than not, espcially amongst corporate organisations, there are political issues associated with the requirements of a project, and these undercurrents must be navigated too.

In my experience, establishing a working consensus (and I stress "working", because there must be flexibility) on the requirements of a project involves (as a minimum) a research effort to deliver a comprehensive project initiation or requirements specification document as the platform of a project, and then a stakeholder workshop to give this kind of necessarily dry document a damned good kicking before proceeding any further.

Just like any good UCD methodology, this bare-bones-mimimum would benefit from some iteration and elaboration of course :)

< previous | next >