Writing Effective Requirement Documents – An Overview

In every UX Design project, the most important part is the requirements gathering process. This is an overview of some of the possible methods of requirements gathering.

Good design will take into consideration all business, user and functional requirements and even sometimes inform new functionality & generate new requirements, based on user comments and feedback. Without watertight requirements specification to work from, much of the design is left to assumptions and subjectivity. Requirements put a project on track & provide a basis for the design. A robust design always ties back to its requirements at every step of the design process.

Although there are many ways to translate project requirements, Use cases, User Stories and Scenarios are the most frequently used methods to capture them. Some elaborate projects may have a comprehensive Business Requirements Document (BRD), which forms the absolute basis for all deliverables for that project.

I will get a bit deeper into what each of this is and in which context each one is used…

 

What is a Use Case ?

Use Cases are a great way to elicit, analyze, and model interaction requirements. Also, they help generate related requirements for interfaces, data, process, and business rules. Use cases describe functionality that explains how users interact with a system. They are written as text and divided into sections. Use cases follow a format such as this one :

Name: Name of the Use Case

Description: Description of the Use Case

Primary Actor: The main user this is targeted at

Precondition: What must already exist for this use case to begin

Trigger: What starts this use case

Basic Flow: The ideal flow of events

Alternate Flow: Other possible flows that may occur

Post Condition: The result of the flow that was carried out.

There could be one or multiple use cases per system function and one use case may refer to another use case establishing a relationship. Analyzing them as a whole - for example, through a Use case diagram or flow chart that shows their relationships provides a solid foundation of valid requirements to start the design process with.

After: Matt Terski  Master the Use Case Include Relationship

 

What is a User Story ?

Many development teams who are making the shift from Waterfall to Agile, like to use User Stories. While a use case is highly structured and enumerates the steps, the User Story sets the stage by stating the need. User stories are typically worded in short sentences and in an informal language, such as this : “As a teacher, I would like to upload study materials to the school portal, so that my student can access and work off them”.

After: Derek Huether  What is a Qualified User Story?

User Stories are great as an activity in collecting and prioritizing the high level features. They are skeletal in nature and need more detail built in. Yet learning about this initial task from the user is a simple way of trying to get all of their needs identified and prioritized. These User Stories will then morph themselves into the business requirements and use cases.

 

What is a Scenario ?

A scenario is a narrative description of a person’s interaction with a system. These are typically linked to a User Persona that represents a group of users who exhibit similar behavioral patterns in their purchasing decisions, use of technology or products, lifestyle choices etc. When scenarios are built around a target group of users, it helps focus design efforts on the user’s needs, which are distinct from functional or business requirements. Scenarios are similar to user stories as they both are written in an informal, non-technical language. Scenarios are typically longer and provide additional contextual information. The level of detail featured by scenarios is comparable to use cases, yet scenarios lack the formal structure that use cases have. This can make it cumbersome to resolve a scenario into its relevant parts. Unlike use cases, however, scenarios can be both authored and understood by people who do not have any technical background.

After: Eric Schaffer  UI Design Newsletter , HFI

 

The following are examples of all three ways describing a sales manager’s day to day activities:

Scenario

John wants to manage his sales team better. For that, he needs to see a list of people on his team. He wants to search by sales person name or geo location or by customer.He finds Adam through his search. He wants to see Adam’s customers and his sales records.

User Story

As a Sales Manager, I would like to login and look up a list of my team members. I would like a search option to look up my team members and sales records associated with it.

Use Case

Name	Sales Person Lookup
Description	This is a use case describing the activity that a Sales Manager would perform in order to access information about a specific sales person of his/her team
Primary Actor	Sales Manager
Precondition	Must be logged in with Manager rights
Trigger	User has accessed on Dashboard
Basic Flow	User	System
	User accesses the NE region on US Map	System filters info on page for NE US
	User accesses a list of all sales persons	System displays full sales person list
	User selects Adam from the list of sales persons	System displays Adam’s info and sales record
Alternate Flow	User	System
	User utilizes a search engine using “Adam” as a search string.	System displays a search results list for all sales person whose first or last name contains “Adam”
	User selects ‘Adam’ from the search results	System displays Adam’s info and sales record
Post-Condition	When all conditions are met, user sees the details of the sales person he/she looked up

All these techniques for writing requirements are ways to consolidate and present them in an effective manner and do not dictate any specific way to include them in the design. For example, the look up list in this use case can be addressed in the UI as a drop-down menu or a list-box or a grid which is up to the designer to decide…that said, requirements only ask for a set of abilities that a user must have, to carry out a task.

Personally, I like to use a combination of use cases and scenarios for my designs. There are exceptions to this where I have had to work with verbal briefings from clients, who either don’t have the expertise or the time & interest to generate elaborate requirements for a project. And then there are situations when clients don’t always know their detailed requirements. Not a great project start for designers but …the best way to help such clients, is to guide them through the design process, use brainstorming to generate ideas, and then translate those ideas into concrete requirements, along the way !