Requirements Engineering in User-Centered Product Development T-121.100 Sari Kujala sari.kujala@hut.fi
Contents The principles of user-centered design Requirements engineering User requirements From user needs to user requirements
The principles of user-centred design Early focus on users, (+ direct contacts) Empirical measurement with real users early in the development process Iterative design, prototyping
What is Requirements Engineering (RE)? The earliest activity of the software development life cycle The goal is assure that a correct and good product is defined and developed from the stakeholders point of view Possible stakeholders are customers, users, engineers responsible for system development and maintenance etc.
RE process (Kotonya & Sommerville, 1998)
User Requirements (1/3) User needs (user study results) need to be analysed, prioritized and documented as user requirements. User requirements are written from user point of view (vs. technical requirements). User requirements describe any function, constraint, or other property that must be provided to satisfy the user needs.
User Requirements (2/3) user group A user group B User requirements tell WHAT the system shall do from user s point of view. Users are not interested in technical details. The system is seen as a black box.
User requirements (3/3) USER NEEDS USER REQUIREMENTS SYSTEM REQUIREMENTS Who uses and why? Possibilities and constraints What system should do to satisfy user needs? User and customer point of view How the system is implemented? Technical point of view
User requirements document example 1.Introduction Describes business goals, the need for the system, basic functions 2.Context of use User groups and characteristics, Environment and equipment Tasks 3.User requirements
User requirements documentation Short and clear sentences Unambigious Verifiable (measurable) Understandable No design characteristics Diagrams Use cases Holistic, dynamic view to requirements
User requirement example The user shall be able to store documents The user shall be able to search document by its name Rationale Source Priority
From user needs to user requirements 1. Visit users and explore their needs 2. Describe the existing context of view, task sequence 3. Analyse and prioritize the breakdown points, problems and possibilities 4. Redesign users taskflow (keep the existing, correct problems) 5. Define user requirements
Describing the context of use User descriptions and profiles Videoshots and photographs Physical, artifact, work, cultural models Task scenarios Task sequences and hierarchies
Analysing problems and possibilities Affinity diagrams User need tables
Redesigning users task flow Use scenarios Storyboards Use workflows and hierarchies Use flow diagrams Use cases
Describing users: User/task table User group Admission clerk Task Collect patient data Number 25 Nurses Administrators View medical data Install and maintain software 490 12
Describing users: User group figure User groups in hospital Admission clerks -Collect patient data -Want effectiveness Nurses -View medical data -Want to heal patients -Need easy access and accurate data Administrators -Install and maintain software -Love technology -Want security
Task scenario (current context of use) Matti on opettajana yläasteella. Hänellä on raskas päivä takana ja hän päättää rentoutua television ääressä. Hän laittaa television päälle painamalla nappia laitteen ylänurkasta. Tämän jälkeen hän lösähtää sohvalle. Ikävä kyllä ohjelma ei kiinnostakaan häntä ja hän nousee sohvalta, kävelee television luo vaihtamaan kanavaa.
Use scenario (redesigning) Matti on opettaja yläasteella. Hänellä on raskas päivä takana ja hän päättää rentoutua television ääressä. Hän lösähtää sohvalle ja nappaa kaukosäätimen käteensä. Tämän jälkeen hän laittaa television päälle. Katsottuaan aikansa tylsää saippuaoopperaa, hän ojentaa kätensä ja alkaa vaihdella kanavia kaukosäätimellä.
Use hierarchy (redesigning)
Use flow diagram (redesigning)
User need table (analysing problems) Tehtäväsekvenssi 1. Käyttäjä käynnistää tv:n rentoutuakseen töiden jälkeen 2. Käyttäjä lösähtää sohvalle, mutta haluaakin vaihtaa kanavaa 3. Käyttäjä nousee sohvasta ja menee tv:n luo vaihtamaan kanavaa Ongelmat ja mahdollisuudet Käyttäjälle mieluinen kanava voi vaihtua kesken katselun. Käyttäjä haluaa säätää äänenvoimakkuutta nopeasti esim. vastatakseen puhelimeen. Käyttäjä joutuu nousemaan sohvalta, vaikka hän haluaa rentoutua. Korkea prioriteetti X
User requirements: use case USE CASE Summary Television kaukokäyttö Käyttäjä haluaa rentoutua televisiota katsoessaan ja kauko-ohjaa televisiota sohvalta käsin. Basic sequence 1. Käyttäjä käynnistää television kaukosäätimestä 2. Käyttäjä vaihtaa kanavaa kaukosäätimestä 3. Käyttäjä sammuttaa television kaukosäätimestä
User need table (analysing problems) Task sequence: Step 1: When trapped in an elevator, passenger makes an emergency alarm. Step 2: Unoccupied service centre operator receives the emergency alarm call and asks for information (description of the failure). Step 3: Etc. Problems and possibilities: - Passengers want to get out of the elevator as soon as possible - All kinds of passengers must be able to make an alarm call (blind, foreigners etc.) - Sometimes passengers may make false alarms unintentionally. - Passengers may be in panic. - Different versions and types of remote monitoring systems. - Passenger is the only information source. - Service centre operator does not notice the emergency alarm call. Etc.
User requirements: Use Case Use Case: Summary: Actors: Preconditions: Basic sequence: Exceptions: Post conditions: Making An Emergency Alarm Call An entrapped passenger pushes the emergency alarm button in order to get help. Passenger and service centre operator An elevator has stopped between floors and there is a passenger in the elevator. The goal of the passenger is to get out of the elevator safely and as quickly as possible. Step 1: The passenger presses the emergency alarm button. Step 2: The service centre operator gets a visible notification about the emergency alarm call on the screen with an optional audio signal. Step 3: The service centre operator accepts the emergency alarm call. Step 1: If an entrapped passenger does not push the alarm button long enough (less than 3 seconds), the system alerts. The entrapped passenger knows that the service centre operator will contact a serviceman who will help the passenger out of the elevator safely as soon as possible.
Conclusions Usability is more than the sum of the userinterface details Early focus on users is most cost-effective Don t invent requirements, but have real data from users Some data is better than no data
Literature Hackos, J. T. ja Redish, J. C. (1998). User ja Task Analysis for Interface Design. New York: Wiley. Redish, J. C. ja Wixon, D. (2003). Task Analysis. In Jacko, J. A. ja Sears, A. (Eds.) The Human- Computer Interaction Handbook: Fundamentals, Evolving Technologies ja Emerging Applications. New Jersey: Lawrence Erlbaum Associates, pp. 922-940.