User-centered design and

the requirement process

The slides are based on slides by Tuva

Solstad and Anne-Stine Ruud Husevåg

22 JANUARY, 2016

Outline

• A general introduction to iterative methodology and user-centered

design

• The requirement process

• Identify users and other stakeholders

• Collecting requirements (requirement trawling)

• How to write requirements

• Requirement analysis and evaluation

• Prototyping

22 JANUARY, 2016

The Problem

The goal: "designing the right thing“ and "designing the thing right"

(Boehm, 1981)22 JANUARY, 2016

Bildet hentet fra knowyourmeme.com, original weblog.cemper.com – Typical Project Life

What is user-centered design?

22 JANUARY, 2016

Iterative methodology that puts the user and the users

needs at the center of all design decisions. The design is

driven and refined by user-centred evaluation.

More likely to give a good user experience, better

usability and better acceptance.

Traditional waterfall life cycle

22 JANUARY, 2016

Planning

Implemenation

Testing

Maintenance

Iterative life cycle

Implemenation

(prototype)

Planning

Testing

Evaluation

22 JANUARY, 2016

The figure is based on the basic elements of User-Centered Design (Wodtke, 2002, p. 70)

The basic steps of user-centered design

Gather, analyse, evaluate and (re-)formalize requirements

What is a requirement?

A requirement is something the product must door a quality it must have.

In practice: A formalized, detailed and unambiguous description on how a system is to be build; a “recipe” for the system builders.

Development projects without a requirements specification risk:

• To lose focus

• Not meet their users' needs

• To go over budget and beyond deadlines

22 JANUARY, 2016

Functional requirements – The whatSpecifies something the system should do

Non-functional requirements – The howSpecifies how the system should behave

Types of requirements

22 JANUARY, 2016

Example: Login shall be available 24/7.

Example: The system shall include a user

authorization procedure where users must

identify themselves using a login name and

password.

The requirements process

• Identify the stakeholders (Find out who the users are)

• Gather requirements (Talk to those people)

• Requirements analysis - structure and prioritize the requirements,

resolve stakeholder conflicts

• Document the requirements in a requirements

document/specification

• Evaluate the requirements

22 JANUARY, 2016

Find out who the users are

Stakeholders (“anyone with requirements for the product”):

• Interest in the product

• Knowledge relevant to the product

How to identify:

• Brainstorming

• Ask already identified stakeholders

• Consult organizations

• Follow the money and resources

• Review organizational charts

Problem: possibly very large group, with a lot of variation. Who

should we choose?22 JANUARY, 2016

Requirement trawling:

“Running a net” through the organization to “trap” as many requirements as possible.

(Robertson and Robertson, )

22 JANUARY, 2016

Foto: Peter Church [CC BY-SA 2.0],via Wikimedia Commons

Talk to those people (Requirement trawling)

You could use one or more of these methods:

22 JANUARY, 2016

• brain storming

• use cases

• prototyping

• Interviews

• questionnaires

• user observation

• workshops

“If I had asked people what they wanted,

they would have said faster horses.”

Henry Ford (undocumented quote)

• apprenticing

• focus groups

• role playing

Interview

Interviews are good for getting an overall understanding of what stakeholders

do and how they might interact with the system.

Interviews can be structured, semi-structured or unstructures. Conducted in a

group or one-on-one.

Important:

Take note of the interviewee’s terminology and keep track of synonyms!

Some pitfalls:

• Difficult to understand specialized domain terminology.

• Some domain knowledge is so familiar to the stakeholder that people find it

hard to articulate or think that it isn’t worth articulating.

22 JANUARY, 2016

Interview, some practical advisesTry to ask questions that allows the collection of user “stories”. This will help you gain insight to the required capabilities of the project. When you come across possible features and needs ask follow-up questions.

Possible starter questions:

• What are the biggest challenges in your role? (may trigger stories)

• What does a dream solution look like? (ensures focus on future solution and not current state)

• What problems is the website trying to address?

Follow-up in regards to a need or feature (e.g. navigate to news section or register patients):

• How might we meet this need?

• Who will use this feature?

• Where would the user access this feature?

• When will this feature be used?

• Where would the results be visible?

• What is the end result of doing this?

• What needs to happen next?

22 JANUARY, 2016

Try it out:

Pretend that your goal is to make or remake a website for an artist or music group.

Pair up in groups of two (or three), take turns interviewing each other.

The person being interviewed should pretend to be one of the following stakeholders:

• A devoted fan

• Music journalist

• Producer

• The artist/band

• Someone not familiar with the artist but interested in this type of music

Your goal as an interviewer is to get insight into the stakeholder needs and wishes for the website. Remember to take notes. You will need them in the next exercise.

22 JANUARY, 2016

Requirements analysis

• Identify the goals

• Structure the requirements in sections under each goal

• Each requirement shall only explain one functionality or property

• Resolve stakeholder conflicts

• Prioritize

• Make sure that nothing major is forgotten

The set of requirements should be realistic, consistent and complete.

22 JANUARY, 2016

Requirement trawling

Requirement analysis Requirement specification

Document the requirements

What to write about (requirements specification):

Feel free to use the relevant elements from Robertson & Robertsons

requirements specification template.

How to document a single requirement:

A requirement template should document where it comes from, what

it means, who cares about it, why it matters and how to test it

Snow card

22 JANUARY, 2016

Why it matters

What it means

How to test it

Example 1

22 JANUARY, 2016

From: Robertson & Robertson

Example 2

1.2 Scope

The “Amazing Lunch Indicator” is a GPS-based mobile application which helps people to find the closest restaurants based on the user’s current position and other specification like price, restaurant type, dish and more.

3.2.1.12 Functional requirement 1.12

ID: FR12

TITLE: Mobile application - Search by priceDESC: A user should be able to input a maximum and a minimum price range. The result is displayed in a list view by default.RAT: In order for a user to search by price.DEP: FR8

3.2.1.15 Functional requirement 1.15

ID: FR15

TITLE: Mobile application - Search by restaurant type 12

DESC: A user should be able to select a restaurant type in a given list as input. The result is displayed in a map view by default.RAT: In order for a user to search by restaurant type.DEP: FR7

22 JANUARY, 2016

From: http://www.cse.chalmers.se/~feldt/courses/reqeng/examples/srs_example_2010_group2.pdf

Pitfalls

22 JANUARY, 2016

The website shall have a calender and an archive that is

quickly accessible.

2 requirements

What does quickly mean? Need a measureable fit criteria.

and

quickly

More pitfalls

22 JANUARY, 2016

1. The website shall provide 2 post formats

Use the same terms throughout and be concise.

The website shall support the photographer in describing

photos.

Vague

2. The website shall require that users log in before they

can write articles

The system shall provide an input screen for describing

photos when photos are uploaded.

Solution:

post

articles

support

Try it out.

Use the notes from the previous exercise to write some requirements on a

snowcard. Fill out description, rationale and fit-criterion.

22 JANUARY, 2016

Iteration: Evaluate the requirements

Evaluate the requirements together with the stakeholders. Important things to

look for:

• Does the requirements have a clear ownership?

• Are the requirements ambiguous?

• Lack of structure, repetitions, omissions?

22 JANUARY, 2016

Test a prototype of the site

A prototype is an early model built to test the website.

Start with testing:

• Content

• Labels

• Navigation

Information architecture before look and feel.

Decide what you want to find out with the test. Don't try to cover every inch of

the design. Concentrate on uncertainties, conflict areas and areas of high

priority or value

22 JANUARY, 2016

Foto: Simon Collison [CC BY-NC-ND 2.0] via Flickr

To sum it up

• User-centered design and working through the requirement process gives a

better likelihood of designing a product that satisfies the users goals and

needs as well as a product that functions well.

• We need to first identify the stakeholders then talk to them to get

requirements. You could use brainstorming, observations, interviews etc.

• Special care should be taken when writing requirements to make them clear,

testable, atomic and realistic

• Use prototypes to test the design early and often, start with testing the

information architecture.

22 JANUARY, 2016

References

– Alexander, I. F. (2002). Writing better requirements. London: Addison-Wesley.

– Boehm, B. W. (1981). Software engineering economics.

– International Organization for Standardization. (2010). Ergonomics of human-

system interaction Part 210: Human-centered design for interactive systems..

Genève: ISO. (International standard ; ISO 9241-210:2010).

– Macaulay, L. A. (1996). Requirements engineering. Springer-Verlag. Chicago

– Methods. (n.d.). Retrieved January 12, 2015, from

http://www.usability.gov/how-to-and-tools/methods/index.html

– Robertson, S., & Robertson, J. (2012). Mastering the requirements

process (3rd ed.). Upper Saddle River, N.J.: Addison-Wesley.

– Wodtke, C. (2002). Information architecture: Blueprints for the

Web. Indiananpolis, IN: New Riders.

22 JANUARY, 2016