Design, Develop, Create

Thursday, 5 October 2017

Gathering and managing requirements

User requirements and analysis is often considered to be the starting point for the systems development process. There are many requirements management frameworks most of which are basically templates and checklists for gathering and recording a variety of user-oriented data.

  • Atlassian's Confluence/Jira offers a sophisticated holistic model for capturing, storing, presenting requirements for future development. See this example from the Confluence/Jira tutorial (link).
  • A typical/conventional/traditional requirements document; source - a student engineering project (link)
A selection of typical requirements documents.
Some musings on requirements:
Product requirements can be thought of as a rather unique kind of shopping list; a shopping list written by (more often on behalf of) the user, and written for (usually by) the developer to deliver. Taking the analogy further; the requirements shopping list is for a shop where the shelves are initially empty because the things the user wants haven’t been made yet. Alternatively there may be something on the shelf that approximates what the user wants but it’s not quite right and needs to be customized. To compound this seemingly odd situation we may also find that product requirements may be written (created) by someone who is neither the customer (user) nor the designer (developer). In this situation those charged with requirements capture have a lot of responsibility and power to influence the design process. Product requirements lie between the user and the designer and act as a communication device between the two. The requirements document is merely a representation of a potentially unbounded set of product requirements therefore the process used to create the representation is perhaps more significant that the document itself.

Links of interest?