Chapter 7 Identifying Needs and Establishing Requirements

1. Chapter 7Identifying Needs and Establishing Requirements By: Wang, Miao Fan, Xiaona

2. Before establishing requirements, we need to fully understand Users and user needs Users’ capability Current task and goals Condition under which the product will be used Product performance constrains Nature of problem space Introduction

3. Definition of Requirements • Requirement is: • “A statement about an intended product that specified what it should do or how it should perform.” • Requirements should be: • Specific • Unambiguous • Clear • Fit criterion: quantifiable and measurable

4. Intertwined Activities Requirements Activity Design Activity Evaluation Activity

5. Goals of Establishing Requirements • Identify/ invent needs: understand user, their work, context of that work • Produce a set of stable requirements to move forward to design

6. Sequential Activities of Establishing Requirements • Gather data • Interpreting data • Analyze data • End goal: Stable Requirements

7. Importance of Getting It Right • One major cause of IT project failure -unclear objective and requirements • Product should support stakeholders’ needs • Product be ignored, despised • Cause grief, anxiety, frustration • Lose revenue, customer confidence

8. Different Kinds of Requirements (1) • Functional requirements • what the product/system should do • Data requirements • the type, volatility, size/ amount …of the required data • Environmental requirements • Physical environment: noise, heating, lighting • Social environment: collaboration and coordination • Organizational environment: training, job design, politics, roles • Technical environment: software compatibility

9. Different Kinds of Requirements (2) • User requirements • characters of the intended users group: beginning vs. advanced user. • User profile affects the way interaction is designed. • Usability requirements • Capture the usability goals and associate measures • Specific measures of the usability goals are established and agreed early in the development process • then revisited and used to track progress

10. Data Gathering • Goals of data gathering: • Collect efficient relevant and appropriate data to produce stable requirements • Expand clarify and confirm the initial requirements • Data gathering techniques: • Questionnaires • Interviews • Focus groups/ workshops • Observation • Study documentation

11. Data Gathering Techniques (1)

12. Data Gathering Techniques (2) • Questionnaires: • Admin at a distance • Get answers for a specific question from a large group of people • No geographical location limitation • Design is crucial and low response rate • Interviews: • Exploring issues and encourage response • Time consuming, and not efficient to meet with all the people

13. Data Gathering Techniques (3) • Focus groups/ workshops • Good at gaining a consensus view point • Highlight areas of conflict • Helps users to meet designers and each other to express their view in public. • Observation: • Spending time with user in the natural context of activity. • Observe, take notes ask questions • Gain insights, and overcome the limitation of other techniques

14. Data Gathering Techniques (4) • Users can’t explain accurately • Fill in details not provided by other • Good at understand the nature of the task and the context • Time consuming and huge amount of data • Study documentation: • Study the written down procedures and rules in manuals • Study user dairies/ job logs • Good for understand legislation and background info; does not take time form users.

15. Issues Influence Choice of Techniques (1) • The nature of techniques Olson and Moran (1996): • The amount of time • The level of detail • The risk with the finding • The scales of the task Olson and Moran (1996): • Sequential steps vs. over-lapping steps • High information content vs. low information content

16. Issues Influence Choice of Techniques (2) • The knowledge required of the analyst: • Layman vs. practitioner • The knowledge about basic cognitive processes analyst must have • The point in development reached • The available resource (money, time, people) • Location and accessibility of stakeholders

17. Data Gathering Guidelines (1) • Focus on identifying users’ needs • Involve all the stakeholder groups • Involve only one representative from each stakeholder group is NOT enough • Combination of data gathering techniques

18. Data Gathering Guidelines (2) • Support the data gathering sessions with suitable props (task description to be reused.) • Run a pilot session • Make compromises because of pragmatic constraints (resource) • How to record the data during the face to face data gathering sessions

19. 7.5 Data Interpretation and Analysis • When? • As soon after the gathering session • Aim: • begin structuring and recording descriptions of the requirements • Approaches: • Initial interpretation template • More focused analysis of data

20. Example of Interpretation Template(The Volere Shell for Requirements) Requirement #: Unique ID Requirement Type: Template section Event/use case#: Origin of the requirement Description: A one-sentence statement of the intention of the requirement Rationale: Why is the requirement considered important or necessary? Source: Who raised this requirement?

21. Example of Interpretation Template(The Volere Shell for Requirements) Continued Fit Criterion: A quantification of the requirement used to determine whether the solution meets the requirement. Customer Satisfaction: Measures the desire to have the requirement implemented Customer Dissatisfaction: Unhappiness if it is not implemented Dependencies: Other requirements with a change effect

22. Kinds of More Focused Analysis of Data • Data-flow diagrams • State charts • Work-flow chart • Class diagrams • Scenarios • Use cases • Essential use cases • Task analysis

23. 7.6 Task Description • Techniques of Task description • Scenarios • Use cases • Essential use cases • Relationships between different Techniques

24. 7.6.1 Scenarios • Definition • Advantages • Easy to understand by the stakeholders • Concentrate on the human activity • Good start point • Characteristics • Personalized account, offering only one perspective • The level of detail present in a scenario varies • Human activity may not be preserved in the future

25. Example of Scenarios(using library catalogs) I want to find a book by Charles Dickens. He was a British Writer. I remember the title is something like “Christmas Carol”, but not very sure if the author name and title are accurate. So I go to the website of library catalog. There are different kinds of Catalogs: Author, Title/Journal Title, Keyword, Author/Title, Subject Heading, etc. Since I have unclear ideas of author and title, so I click author/title catalog. On the webpage of “Author/Title Search”, I type “Dickens” into the Author box, and “Christmas Carol” into Title box. Then the search result comes out. There are several editions of “A Christmas Carol” written by Charles Dickens. I choose my favorite edition, and get the call No. and location of the book.

26. 7.6.2 Use Cases • Characteristics: • emphasize on user-system interaction, stress is still very much on the user’s perspective, not the system’s • Associate with an actor (user) • “Normal course” & “alternative course”

27. Example of Use Case • The user go to the catalog website • The system prompts user for all kinds of catalogue • The user chooses the Author/Title catalog • The system prompts the user for Author/Title Catalog • The user types the author name and book title in the appropriate boxes • The system search the book

28. Example of Use Case (continued) 7. The system displays a list of potential books. 8.The user chooses one of the book 9.The system displays the detail information of the book 10.The user get the call No. and location of the book

29. Example of Use Case (continued) 7. If no book is matched the search criterion, 7.1 The system provide “no match book” information 7.2 The system returns to step2

30. Graphical Representation of Use Case Locate book Collect books Update catalog Use case diagram for the library automatic system

31. 7.6.3 Essential Use Cases • Characteristics: • abstract from scenarios, and try to avoid the assumptions of a traditional use case • More general • are associated with user roles • Difference between actor and user roles • Compositions: • A name which expresses the overall user intention • A stepped description of user actions • A stepped description of system responsibility

32. Example of an essential use case

33. 7.7 Task Analysis • Purpose: Analyze the underlying rationale and purpose of what people are doing • Definition: An umbrella term that covers techniques for investigating cognitive processes and physical actions, at a high level of abstraction and in minute detail • Widely used version • HTA: Hierarchical Task Analysis • GOMS: goals, operations, methods, and selection rules

34. 7.7.1 Hierarchical Task Analysis • How? • Top-down approach • Characteristics • Focus on physical and observable actions • Examples

35. A Graphical Representation of the Task Analysis for Borrowing a Book

36. An HTA for borrowing a book from the library 0. In order to borrow a book from the library 1. Go to the library 2. Find the required book 2.1 access library catalog 2.2 access the search screen 2.3 enter search criteria 2.4 identify required book 2.5 note location 3. Go to correct shelf and retrieve book