user-centered design and the requirement process.pdf
TRANSCRIPT
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