All about requirements

February 5, 2008

Requirements tackle the what, without touching the how: what needs to be accomplished by the design or development. Sometimes, the line between what and how is vague, such as in functional specifications documentation. Requirements can also be refered to as: product backlog

What requirements document should adhere to:
Use simple language and simple sentences. If you have to use jargon or technical terms, they should be understood without explanation by every member of the team.
– Contain vision (goals) by the client, product owner and/or interaction designer
– Short (generally no more than 5 pages) to read and write
– Understandable (easy and pleasurable read, not too technical, not too many cross-references)
– Usable (practical to apply)
– Maintainable (extensible without loss of cross-references)
– High-level (not too detailed, and not dictating solutions – only the how)
– Be sticky by connecting each functional requirement to a specific business requirement. (see example below)
– Facilitate product evolution (not just incremental change).

Out-of-the box creative specs:
-Camtasia recordings
-If prototyped screens are representative to the pixel, say so.
– Include Flow (map out real screenshots on a large paper)
– The specs could serve as a manual and be finished the same time as the product

Requirements sources of inspiration:
Requirements originate from research:
– Competitive audits (what are main competitors or similar sites doing?)
– Contextual scenario’s (of primary persona)
– Interviews (with SME. and users??)
– User needs and goals, business goals and technical constraints

Requirements deliverable formats:
Requirements fit user tasks
– SCRUM (stories)
– Action (or function), object (or data), context: e.g. Call contact person using Address Book
– Feature list (Excel sheet can be used for documenting and tracking progress and client decisions)
– Matrix of development cost versus business value. Or from a questionnaire, get users to evaluate existing features on a scale important weakness/strength: this gives insight into which features may need redesign.

Requirements could/should contain:
– Structured hierarchically
– Priority (with MOSCOW, the must-haves being essentially the show-stoppers: can’t/won’t launch without it; or with +/++/+++ )

Requirements destinations:
Requirements are fed to the Interaction Framework phase [Face3.0] to inform designers (but where do functional requirements come in??). They can be used by IA’s/ID’s to form deep (rather than shallow) arguments.
Reqs. are used by developers as a basis for programming various functionalities/components. They might feedback the requirements by assessing feasbility or performing an impact analysis or impact assessment. In such an analyis, developers might express each requirements in terms of effort or time (NUT) : e.g. Things we can do now, things we can do by the end of the year, and things that will take a long time.

During design an interaction designer comes up with micro-requirements, features that need to be implemented as part of a design. The ID might present alternatives designs in his/her documentation if need may be. An important principle of ID is to avoid overdoing it, or ‘overpampering’ the user with bells and whistles which may be perceived as overkill – although these may be great features that add some value to usability or UX, every (micro-)requirement must be outweighed against an estimated development cost/effort. The interaction designer needs the skills to assess micro-requirements, during design or as part of alternatives analysis, with a good feel for trading off business value against performance, development cost.

Requirement template docs:
Feature, priorty, actor, remarks

Other thoughts:

  • Requirements can be further divided into business, functional and technical specifications. Within these categories, further split can be made by identifying (abstract) components and elements.
  • Sometimes, the requirements document is used for project management (assigning, tracking progress).
  • In a team it is key to use the same language (terminology) to talk about the same thing.
  • There is no ‘ one fits all’ solution. As the size, time and budget for projects differ, so does the breadth and detail (or existence!) of the requirements document, or even the functional specs. Sometimes it is more desirable to do something fast and on (developer’s) intuition, than it is to get a quality product. In such cases, and in general, frequent involvement from product owners and interaction designers (during dev they are only asked when the need is felt) is usually a good idea.
  • Requirements are often inter-related. The importance/priority/need of a need depends if another is implemented or not.

About the process: Revisions (feedback and interviews) are used to get the requirement down to the right level of detail.
When with clients discussing the business requirements, it is inevitable they come with “the how”. Don’t fight it (because you’ll lose); just add their comments to a running list of functional requirements that you can integrate after the meeting.

Example 1)
“The user needs to approve an order before it is assigned to vendors.”
Functional: “Ability to display only those orders pending approval that are relevant to the user role.”
Functional: “Ability to cancel orders that have been rejected.”
Functional: “Ability to record person granting approval.”

Articles:  –  a lot about agile requirements, design and non-functional requirements