User-centered design and the requirement process The slides are based on slides by Tuva Solstad and Anne-Stine Ruud Husevåg
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
The Problem Bildet hentet fra knowyourmeme.com, original weblog.cemper.com Typical Project Life The goal: "designing the right thing and "designing the thing right" (Boehm, 1981)
What is user-centered design? 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 Planning Implemenation Testing Maintenance Evaluation Planning Testing Implemenation (prototype) Iterative life cycle
The basic steps of user-centered design Gather, analyse, evaluate and (re-)formalize requirements The figure is based on the basic elements of User-Centered Design (Wodtke, 2002, p. 70)
What is a requirement? A requirement is something the product must do or 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
Types of requirements Functional requirements The what Specifies something the system should do Example: The system shall include a user authorization procedure where users must identify themselves using a login name and password. Non-functional requirements The how Specifies how the system should behave Example: Login shall be available 24/7.
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
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?
Requirement trawling: Running a net through the organization to trap as many requirements as possible. (Robertson and Robertson, ) Foto: Peter Church [CC BY-SA 2.0],via Wikimedia Commons
Talk to those people (Requirement trawling) If I had asked people what they wanted, they would have said faster horses. Henry Ford (undocumented quote) You could use one or more of these methods: Interviews questionnaires user observation workshops brain storming use cases prototyping 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.
Interview, some practical advises Try 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?
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.
Requirements analysis Requirement trawling Requirement analysis Requirement specification 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.
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 What it means Why it matters How to test it
Example 1 From: Robertson & Robertson
Example 2 From: http://www.cse.chalmers.se/~feldt/courses/reqeng/examples/srs_example_2010_group2.pdf 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 price DESC: 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
Pitfalls 2 requirements The website shall have a calender and an archive that is quickly accessible. What does quickly mean? Need a measureable fit criteria.
More pitfalls 1. The website shall provide 2 post formats 2. The website shall require that users log in before they can write articles Use the same terms throughout and be concise. Vague The website shall support the photographer in describing photos. Solution: The system shall provide an input screen for describing photos when photos are uploaded.
Try it out. Use the notes from the previous exercise to write some requirements on a snowcard. Fill out description, rationale and fit-criterion.
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?
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 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.
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 humansystem 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.