1. Identifying Needs and Establishing Requirements Presenters: Veronica Gasca Jennifer Rhough

2. Introduction: The whys User’s needs, requirements, aspirations, and expectations should be taken into consideration Rewards if established correctly Disadvantages if wrong or not done

3. Requirements Make it as clear, specific, and unambiguous as possible Abstract Web site should appeal to teenage girls Precise Search time for a query is less than 3 seconds Issue an auditory and visual alert when a download fails

4. Types of Requirements Functional Data (volatility, size, persistence, accuracy, value) User Usability Environment Physical Social Organizational Technical

5. Data Gathering Techniques Questionnaires Interviews Focus Groups/Workshops Naturalistic Observation Studying Documentation

6. Technique #1 Questionnaires Elicit specific information Needs to be written well Good for large groups of people, spread geographically Often used in conjunction with other techniques

7. Technique #2 Interviews In-person or phone Structured or Unstructured Good at getting people to explore issues More enjoyable Time consuming Not good for large groups of people

8. Technique #3 Focus Groups/Workshops Consensus view Highlights conflicts/disagreements Structured or facilitator mediated Strong personalities can dominate discussions

9. Technique #4 Naturalistic Observation Shadow day to day tasks More accurate, detailed descriptions Vary from outside to participant observation Time consuming Generates large amounts of data

10. Technique #5 Studying Documentation Background legislation Previous software

11. Which one? Time Experience of analyst Nature of task Other resource availability stakeholders

12. Some Tips Involve all stakeholders Use combo of techniques Obtain diversity Props/prototypes Run pilot data gathering sessions

13. Data Interpretation and Analysis Interpretation Goal: to structure and record descriptions of requirements. Start interpretation as soon after the gathering session as possible. Discuss the findings with others.

14. Requirements template (Volere, Atlantic Systems Guild): Requirement #: Unique IdRequirement 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? Fit Criterion: A quantification of the requirement used to determine whether the solution meets the requirement. …

15. Techniques to understand users’ goals and tasks Task Description Task Analysis Scenarios Use Cases Essential Use Cases

16. Scenarios Scenario: Informal narrative description of human activities or tasks in a story that allows exploration and discussion of contexts, needs, and requirements. Concentrate on the human activity rather than interaction with technology.

17. Sample scenario Mary needs to send some documents to her boss, who is currently in France. She scans the documents and places the electronic copies into her working directory and then opens her eMail application to send the information through electronic Mail. She creates a new memo and selects….

18. Advantages of using scenarios Scenarios help explain or discuss some aspect of the user’s goals. They can be used to imagine potential users of a device as well as to capture existing behavior. Capturing scenarios of existing behavior helps in determining new scenarios and hence gathering data for new requirements.

19. Use cases Also focus on user goals, but the emphasis here is on a user-system interaction rather than the user’s task itself. A use case is associated with an actor, and it is the actor’s goal in using the system that the use case wants to capture.

20. Creating use cases The main use case describes what is called the “normal course” through the use case To develop a use case: First, identify the actors (people or systems that will be interacting with the system under development). Examine these actors and identify their goals or goals in using the system. Each of these will be a use case.

21. Sample use case 1. The user chooses the option to arrange a meeting. 2. The system prompts user for the names of attendees. 3. The user types in a list of names. 4. The system checks that the list is valid. 5. The system prompts the user for meeting constraints. 6. The user types in meeting constraints. 7. … Alternative course: 5. If the list of people is invalid, display an error message and return to step 2.

22. Use case diagram Arrange a meeting

23. Essential use cases They represent abstractions from scenarios, and consist of: Name to express overall user intention Stepped description of user actions Stepped description of system responsibility Instead of actors, essential use cases are associated with user roles.

24. Sample essential use case User IntentionSystem responsibility Arrange a meeting request meeting attendees Identify meeting attendees Identify meeting constraints suggest potential dates …

25. Task analysis It’s used to analyze the underlying rationale and purpose of what people are doing. The most widely used version is known as HTA (Hierarchical Task Analysis) HTA involves breaking a task down into subtasks and then Into sub-subtasks And so on…. The starting point is a user goal

26. Sample task analysis 0. In order to arrange a meeting 1. compile a list of meeting attendees 2. compile a list of meeting constraints 3. f ind a suitable date 3.1 identify potential dates from departmental calendar 3.2 identify potential dates from each individual’s calendar 3.3 … 4. enter meeting into calendars …

27. For more information… Interaction Design (Preece, Rogers, Sharp) Chapter 7, Identifying needs and establishing requirements.