Identifying Needs and Establishing Requirements Kelly Kim Haimin Lee

2 Content The importance of requirements Different types of requirements Data gathering Data interpretation and analysis Task descriptions Task analysis

3 The importance of requirements Different types of requirements Data gathering Data interpretation and analysis Task descriptions Task analysis

4 The importance of requirements User’s needs, requirements, aspirations, and expectations should be taken into consideration –Rewards if established correctly –Disadvantages if wrong or not done Getting requirements right is crucial!!

5 What are we trying to achieve? Two aims: 1. Understand as much as possible about users, task, context 2. Produce a stable set of requirements

6 How can we achieve? 1.Data gathering activities 2.Data analysis activities 3.Expression as ‘requirements’ 4.All of above are iterative

7 The importance of requirements Different types of requirements Data gathering Data interpretation and analysis Task descriptions Task analysis

8 Different types of requirements Definition –A requirement is a statement about an intended product that specifies what it should do or how it should perform Make it as clear, specific, and unambiguous as possible Example –Bad example “Web site should appeal to teenage girls” –Good example “Search time for a query should be less than 5 seconds” Example –Bad example “Web site should appeal to teenage girls” –Good example “Search time for a query should be less than 5 seconds” Further investigation would be necessary

9 Different types of requirements Functional Data Environment –Physical –Social –Organizational –Technical User Usability Functional requirements Non-Functional requirements

10 Functional requirements Functional —What the system should do Example –“A calculator should support different types of operations(+, -, /, …)” Example –“A calculator should support different types of operations(+, -, /, …)”

11 Non-functional 1. Data requirements Type, volatility, size/amount, persistence, accuracy, and value of amounts of the required data Example —“In the personal banking domain, data must be accurate, must persist over many months and years” Example —“In the personal banking domain, data must be accurate, must persist over many months and years”

12 Non-functional 2. Environmental requirements –Definition : Circumstances in which the interactive product will be expected to operate –Categories Physical Social Organizational Technical

13 Non-functional 2. Environmental requirements –physical: dusty? noisy? light? heat? …. (e.g. ATM) —social: sharing of files, across great distances, work individually, privacy for clients —organizational: Hierarchical management, communication structure and infrastructure, availability of training —Technical : compatibility, technological limitations

14 Non-functional 3. User requirements The characteristics of the intended user group –Ability and skills —Novice: step-by-step (prompted), clear information —Expert: flexibility of instructions —Frequency —Casual/infrequent: clear instructions, e.g. menu paths —Frequent: short cuts

15 Non-functional 4. Usability requirements To achieve Usability goals –effectiveness, efficiency, safety, utility, learnability, and memorability

16 Practical example A system to support distributed design teams, e.g., for car design –Functional : –Data : –Environmental : –Users : –Usability : “The system will be able to communicate information between remote sites” “The system must have access to design information that will be captured in a common file format(such as AutoCAD)” “Physically distributed over a wide area. Files and other electronic media need to be shared. The system must comply with available communication protocols and be compatible with network technologies” “Professional designers, who may be worried about technology but who are likely to be prepared to spend time learning a system that will help them perform their jobs better. The design team is likely to be multi-lingual” “Keeping transmission error rate low is likely to be of high priority”

17 The importance of requirements Different types of requirements Data gathering Data interpretation and analysis Task descriptions Task analysis

18 Data Gathering Purpose –Collect sufficient, relevant, and appropriate data –Produce a set of stable requirements

19 Questionnaires Questionnaires –Elicit specific information –Needs to be written well –Good for large groups of people –Administered at a distance –Often used in conjunction with other techniques

20 Interviews Interviews –In-person or phone –Structured or Unstructured –Good at getting people to explore issues –Time consuming –Not good for large groups of people

21 Workshops or Focus groups Focus Groups/Workshops –Consensus view –Highlights conflicts/disagreements –Structured or facilitator mediated –Strong personalities can dominate discussions

22 Naturalistic observation Naturalistic Observation –Shadow day to day tasks –More accurate, detailed descriptions –Vary from outside to participant observation –Time consuming –Generates large amounts of data

23 Studying documentation Studying Documentation –Ex. Manuals –Good for understanding legislation & getting some background information –No need of stakeholder time

24 Choosing between techniques Data gathering techniques differ in two ways: 1. Amount of time, level of detail and risk associated with the findings 2. Knowledge the analyst requires The choice of technique is also affected by the kind of task to be studied: —Sequential steps or overlapping series of subtasks? —High or low, complex or simple information? —Task for a layman or a skilled practitioner?

25 Some basic guidelines Focus on identifying the users’ needs Involve all the stakeholder groups Involve more than one representative from each stakeholder group Use a combination techniques Run a pilot session

26 Practical example You are developing a website for a young person’s fashion e-commerce site –Which technique?

27 Overview of techniques TechniqueGood ForAdvantagesDisadvantages Questionnaires Answering specific questions Many people Low resources Design is crucial Response rate may be low Interviews Exploring issues Encourages contact Time consuming Artificial environment Focus groups and Workshops Collecting Multiple viewpoints Consensus and Conflict Encourages contact Possibility of dominant characters Naturalistic Observation Understanding context of user activity Insights with actual work Very time consuming Huge amounts of data Studying documentation Learning about procedures, regulations and standards No time Commitment From users required Day-to-day working will differ from documents

28 The importance of requirements Different types of requirements Data gathering Data interpretation and analysis Task descriptions Task analysis

29 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. Different approaches emphasize different elements e.g. class diagrams for object-oriented systems, entity-relationship diagrams for data intensive systems

30 The importance of requirements Different types of requirements Data gathering Data interpretation and analysis Task descriptions Task analysis

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

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

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

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

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

36 Sample use case 1.The system prompts for user name and password 2.The user enters name and password into the catalog system. 3.The system verifies the user’s password. 4.The system displays a menu of choices. 5.The user chooses the search option. 6.The system displays the search menu. 7.… Alternative course: 4. If user password is not valid 4.1 The system displays error message. 4.2 The system returns to step 1.

37 Example use case diagram for shared calendar

38 Essential use cases Developed by Constantine and Lockwood(1999) Scenario Concrete stories Scenario Concrete stories Use cases Certain assumptions Use cases Certain assumptions Essential use cases Avoid assumptions Use Abstractions

39 Essential use cases They represent abstractions from scenarios, and consist of: 1.Name to express overall user intention 2.Stepped description of user actions 3.Stepped description of system responsibility What the user is responsible for What the system is to do

40 Sample essential use case User IntentionSystem responsibility Arrange a meeting request meeting attendees Identify meeting attendees and constraints suggest potential dates Choose preferred date book meeting Arranging meeting in the shared calendar application

41 The importance of requirements Different types of requirements Data gathering Data interpretation and analysis Task descriptions Task analysis

42 Task analysis It’s used to analyze the underlying rationale and purpose of what people are doing. –What are they trying to achieve? –Why are they trying to achieve it –How are they going about it? 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

43 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. find 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 5. Inform meeting participants of calendar entry Plan 0 : do 1, 2, 3 If potential dates are identified, do 4, 5 If no potential dates can be identified repeat 2-3

44 Sample task analysis 0.arrange a meeting 1. compile a list of meeting attendees 2. compile a list of meeting constraints 3. find a suitable date 4. enter meeting into calendars 5. Inform meeting participants of calendar entry 3.1 identify potential dates from departmental calendar 3.2 identify potential dates from each individual’s calendar 3.3 Compare potential dates 3.4 Choose a preferred date Plan 0 : do 1, 2, 3 If potential dates are identified, do 4, 5 If no potential dates can be identified repeat 2-3 Plan 3 : do 3-1, 3-2, 3-3, 3-4 Or do 3.2, 3.1, 3.3, 3.4

45 Summary Getting requirements right is crucial There are different kinds of requirement, each is significant for interaction design The most commonly-used techniques for data gathering are: questionnaires, interviews, focus groups and workshops, naturalistic observation, studying documentation Scenarios, use cases and essential use cases can be used to articulate existing and envisioned work practices. Task analysis techniques such as HTA help to investigate existing systems and practices