Writing User-Driven Requirements

FROM CONCEPT TO CODING the art of writing user-driven requirements

The Beginning: Oh, the noise! Oh, the Noise! Noise! Noise! That's one thing he hated! The NOISE! NOISE! NOISE! ~ The Grinch

COHESION AND DIRECTION The beginning of a project generates a lot of great ideas; BUT, until a structure is applied to these ideas, they end up being a loose collection of separate thoughts with no direction. Requirements brings cohesion and direction to the noise.

PRODUCT REQUIREMENTS
define concept (what is it)
user base (who’s using it) and
product scope (what should it do)

FROM PROBLEM TO SOLUTION
For this presentation, our Client is a Sustainable Developer
Vertical is construction/development
Bring green ideas to traditional planning/building
Promotes emerging technology, e.g., wind farms, sustainable housing, etc.
Works with communities and planners

STEP 1 : STATE THE PROBLEM
If you can’t articulate the problem, how can you define a solution?
Our Client’s Problem: no one “gets” our ideas with just words. We need a quick way to sketch and share ideas.

STEP 2 : DEFINE THE CONCEPT
The product concept:
addresses the problem
is the overarching idea of your software
all features need to relate back to it.
Defining the concept is the first step in restraining scope creep.

Product Concept: An visually interactive, collaborative tool to explain our ideas in order to get users’ input and buy-in

STEP 3 : CONDUCT USER RESEARCH
User research tells you:
Who will be using the product
What they will be using it for
What they need to accomplish their goal(s)
Why do it?
Identifying users allows you to create a product that solves your business problem AND meets your users’ needs.
Addressing the actual needs of your users gives you a leg up on releasing a successful product.

Why spend the money on research? We already know who our users are.
User Research:
validates (or negates) assumptions
identifies new user groups
provides objective data

STEP 4 : IDENTIFY PERSONAS
Personas are derived from user research
Personas: Personas are fictitious characters created to represent the different user types for your site or product.

STEP 4 : IDENTIFY PERSONAS
Personas:
consolidate data from the user research
humanize the user data, e.g., Persona Sally rather than single women in the 20-35 age group
keep the team focused on the end users
address any issues from the POV of the persona
useful in identifying fringe cases
effective in keeping meetings/discussions focused on user’s interaction with product

OUR PROJECT PERSONAS city council fellow visionaries the community
The personas for our Sustainable Development client are
city council
the community
fellow visionaries

STEP 5 : USER MODELING
Activities are derived from needs and goals
what is it that personas need to do in order to get them to their stated goal
Activity diagrams begin to define the overall view of the software

STEP 6 : USER STORIES
User Stories describe who, what and why
User Stories provide further definition and details to an identified activity
User Stories: As a user , I need to do something in order to gain this benefit

As a member of the Community, I need to:
search for developments in my area so I know what’s going on
view solutions so I can learn what the latest proposals are and their impact to my community
add my comments so I can participate in the process
receive meeting alerts so I can be updated
COMMUNITY USER STORIES

Recap what we know so far:
business problem we’re solving
the product concept
our users
their needs and goals
their high-level activities
the user stories for these activities
This knowledge is fundamental to creating the feature list for our software

List the tasks that must be supported
e.g., signing up for alerts, deleting alerts
Consolidate the tasks into features
e.g., Signing up for and deleting alerts means we’ll need an Alert Management area in the application
therefore, new feature: My Alerts
Itemize the features into a list
STEP 7 : FEATURE LIST

STEP 7 : FEATURE LIST
Features and their tasks determine the entire scope of a product
Prioritizing the feature list determines the development and release plan
From here, we move onto defining the feature details

FEATURE REQUIREMENTS define the scope and functionality of the product’s features

ANATOMY OF A FEATURE REQUIREMENT
For each Feature:
Identify the user stories
Write the acceptance tests
Diagram the workflow
Create the wireframes
Write the functional specifications
This is where we delve into the details and uncover the unknowns

REQUIREMENTS : USER STORIES
For the feature, the user story will tell you:
who’s using the feature
the tasks the user needs to do, not how they’ll do it
the benefits of this feature to that user
User stories are used to generate acceptance tests

REQUIREMENTS : ACCEPTANCE TESTS
Acceptance tests are written in more detail than a user story but substantially less than functional specifications.
Acceptance Test: series of scenarios based on the User Story that defines the scope of the feature along with its acceptance criteria .

REQUIREMENTS : ACCEPTANCE TESTS
Acceptance Tests consist of two parts:
Title describing the activity
Scenario that is described in terms of Givens, Events and Outcomes
The givens define the preconditions, e.g., user is logged in
The event describes the action the user takes
The outcome describes the desired behavior

Search for Events Given that the user is a member of the community And that the user has successfully logged in When the user enters search criteria for an event And the user specifies a location Then the systems returns all events for that location that match the search criteria

REQUIREMENTS : FLOW DIAGRAMS
A workflow diagram begins to identify the screens needed for the feature and how the user enters and exits those screens
Workflow: diagrams a sequence of steps from start to finish that a user takes in order to complete a feature.

REQUIREMENTS : FLOW DIAGRAMS
The end-to-end flow:
Identifies the starting point(s)
Notes any decision point(s) and how they should be handled
Shows any subpaths a user can take
Declares the End Point

WORKFLOW LANGUAGE start decision? end action page process

WORKFLOW DIAGRAMS
Workflows help team members develop the optimal user experience, both at the presentation layer and in the backend

Because a picture is worth 1,000 words
REQUIREMENTS : WIREFRAMES Wireframes: a visual guide used to suggest the layout of the fundamental elements in the interface.

REQUIREMENTS : WIREFRAMES
Provides a visual reference for the structure of a scree and placement of elements
Establishes the language, content and structure of user interaction

What does a Wireframe look like?

ANNOTATED WIREFRAME Annotated Wireframe

REQUIREMENTS : FUNCTIONAL SPECS
Functional Specs are written in plain English, not developer or consultant speak
Functional Specifications: document the details and behavior of a feature, describing how it will work from the user’s perspective

REQUIREMENTS : FUNCTIONAL SPECS
Functional Specs describe:
Elements that should appear on a page
How the user interacts with a page
What happens when the user does something
Functional Specs do NOT describe:
how the feature will be built

4.1 Create Project Entry Report
see wireframe 5.1
The following data is required to create a report:
Project Name
Date Range
4.1.1 Project List
For Proletariats:
By default, displays a list of all active projects where user is an active resource
User can request inactive projects be displayed in project list
For all other Roles:
By default, displays a list of all active projects
User can request inactive projects be displayed in project list
Show Inactive Projects
Toggles displaying the inactive projects in the project list
When checked, project list will display both active and inactive projects
By default, checkbox is not selected
Available to all roles
When user selects the checkbox, project list displays both active and inactive projects
For Proletariats, show inactive projects where user is an active resource
For all other roles, show all inactive projects
o When user deselects the checkbox, project list displays active projects only
+ For Proletariats, show active projects where user is an active resource
+ For all other roles, show all active projects
SAMPLE FUNCTIONAL SPECIFICATION

ANATOMY OF A FEATURE REQUIREMENT
For each Feature:
Identify the user stories
Write the acceptance tests
Diagram the workflow
Create the wireframes
Write the functional specifications
Detailing the design of a feature before development saves time and money

ALICE TOTH senior consultant, uxd [email_address]

Writing User-Driven Requirements

by Pathfinder Software

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 250

Statistics

Writing User-Driven Requirements Presentation Transcript

http://www.pathf.com	241
http://www.slideshare.net	9