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

3. Introduction 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

4. 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

5. Intertwined Activities Design Activity Evaluation Activity Requirements Activity

6. 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

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

8. 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

9. 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

10. 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

11. 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

12. Data Gathering Techniques (1)

13. 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

14. 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

15. 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.

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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?

22. 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

23. 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

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

25. 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

26. 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.

27. 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”

28. Example of Use Case 1.The user go to the catalog website 2.The system prompts user for all kinds of catalogue 3.The user chooses the Author/Title catalog 4.The system prompts the user for Author/Title Catalog 5.The user types the author name and book title in the appropriate boxes 6.The system search the book

29. 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

30. 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

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

32. 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

33. Example of an essential use case User IntentionSystem Responsibility Request appropriate details Offer known details Offer search results Note search results Quit system close Note that it does not specify search options or details of how to initiate the search

34. 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

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

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

37. 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