Ch 7 Identifying needs and establishing requirements Group

Ch 7 Identifying needs and establishing requirements Group 3: Lauren Sullivan Chris Moore Steven Pautz Jessica Herron

Overview • The importance of requirements • Different types of requirements • Data gathering • Task descriptions: Scenarios Use Cases Essential use cases • Task analysis: HTA

What, how and why? • What Two aims: 1. Understand as much as possible about users, task, context 2. Produce a stable set of requirements • How: Data gathering activities Data analysis activities All of this is iterative

What, how and why? • Why: Getting requirements right is crucial. It must support stakeholders needs. Requirements definition: is the stage where failure occurs most commonly. Think of a CS project where the objectives were unclear and possibly led to misunderstandings and even failure. Requirements Engineering: evolution iterative process of

Establishing requirements • What do users want? What do users ‘need’? Requirements need clarification, refinement, completion, rescoping Input: requirements document (maybe) Output: stable requirements • Why? Requirements arise from understanding users’ needs Requirements can be justified & related to data Process Impact

Different kinds of requirements • Functional: —What the system should do —Historically the main focus of requirements activities • Non-Functional: —Memory size —Response time and downtime • Data: —What kinds of data need to be stored? —How will they be stored (e. g. database)?

Different kinds of requirements Environment or context of use: —physical: dusty? noisy? vibration? light? heat? humidity? …. (e. g. OMS insects, ATM) —social: sharing of files, of displays, in paper, across great distances, work individually, privacy for clients —organisational: hierarchy, IT department’s attitude and remit, user support, communications structure and infrastructure, availability of training

Different kinds of requirements • Users: Characteristics: you need to understand their ability and background. 4 main categories: Novice Need instruction, step by step prompting Expert Flexibility and access/power Casual Clear instructions and be able to do what they need to do immediately Frequent Short cuts and an overall memorable design Ex: MS Word

Different kinds of requirements • Usability: learn-ability, throughput, flexibility, attitude, memorability Note that user requirements and usability requirements refer to different things -Wet. PC usability example

Current Issues with Requirements • Lack of standards & ITU • URN and Mitel Corp. • Military Example of IT requirements

Data Gathering • Purpose: – To collect sufficient, relevant, and appropriate data so that a set of stable requirements can be produced. • Techniques: – Questionnaires – Interviews – Focus groups and workshops – Naturalistic observation – Studying documentation

Data Gathering Techniques • Questionnaires: Example Links: Yahoo Customer Poll MYCLE survey Good for Answeri ng specific question s Kind of data Advantag Disadvanta es ges Quantitative Can reach Low and many response qualitative people rate. data

Data Gathering Techniques • Interviews: Good for Exploring issues Kind of data Some quantitative, mostly qualitative Advantages Disadvantages Encourages contact between developers and users Time consuming

Data Gathering Techniques • Focus groups and workshops: Good for Kind of data Collecting Some multiple quantitative, view points mostly qualitative Advantage s Disadvantag es Encourages contact between developers and users Possibility of dominant characters

Data Gathering Techniques • Naturalistic Observation: Good for Understandin g context of user activity Kind of Data Advantages Qualitative Observing actual work gives insight Disadvantages Very time consuming, huge amounts of data

Data Gathering Techniques • Studying Documentation: Good for Kind of data Learning Quantitative about procedures, regulations, and standards Advantages Disadvantages Not time commitment from users Day-to-day working will differ from documented procedures

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 layman or skill practitioner?

Data-Gathering Guidelines • Focus on identifying the stakeholders’ needs. • Involve all the stakeholder groups. • Involve more than one representative from each stakeholder group. • Use a combination of data gathering techniques.

Some basic guidelines • Support the process with props, such as prototypes and task descriptions. • Run a pilot session. • You will need to compromise on the data you collect and the analysis to be done, but before you can make sensible compromises, you need to know what you’d really like. • Consider carefully how to record the data.

Data interpretation and analysis • Start soon after data gathering session - Data stays fresh in the mind Avoids caused bias Use templates such as suggested in Volere Class and sequence diagrams…remember Cp. Sc 372?

Task descriptions • Scenarios - “an informal narrative description” - e. g. users of a library catalog service or a shared calendar system • Use cases - assume interaction with a system - assume detailed understanding of the interaction • Essential use cases - abstract away from the details - does not have the same assumptions as use cases

Scenario for shared calendar “The user types in all the names of the meeting participants together with some constraints such as the length of the meeting, roughly when the meeting needs to take place, and possibly where it needs to take place. The system then checks against the individuals’ calendars and the central departmental calendar and presents the user with a series of dates on which everyone is free all at the same time. Then the meeting could be confirmed and written into people’s calendars. Some people, though, will want to be asked before the calendar entry is made. Perhaps the system could email them automatically and ask that it be confirmed before it is written in. ”

Scenarios (continued) • The level of detail present in a scenario varies • Generated during workshop or interview sessions • Used to imagine potential uses of a device • Not intended to capture a full set of requirements

Use Cases • Shows the relationship between the user and the system • Interactions take place between actors • More formal than a Scenario • First, the actors are identified. • Next, the goals of the actors are determined • Each goal becomes a Use Case

Use Cases: Example Arrange a Meeting 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. The user chooses the option to arrange a meeting. The system prompts user for the names of attendees. The user types in a list of names. The system checks that the list is valid. The system prompts the user for meeting constraints. The user types in meeting constraints. The system searches the calendars for a date that satisfies the constraints. The system displays a list of potential dates. The user chooses one of the dates. The system writes the meeting into the calendar. The system emails all the meeting participants informing them of them appointment

Use Cases: Example

Essential Use Cases • A structured narrative • Consists of a title and descriptions of user actions and system responsibilities • More broad than normal Use Cases • Utilizes user roles instead of actors • May represent a single person or system, or a group of people or systems with similar goals

Essential Use Cases: Example User Intention System Responsibility Arrange a meeting Request Meeting Identify meeting Suggest potential attendees and dates constraints Choose preferred Book Meeting date

Task Analysis • Used to investigate an existing situation • Descriptions of existing tasks may be used to envision new systems or devices • Combines many different techniques, at a high level of abstraction and in detail • Most popular form is Hierarchical Task Analysis

Hierarchical Task Analysis • A task is divided into subtasks, then subtasks are divided as necessary • Results in a tree-like explanation of a task • Starts with a user goal. Main tasks are identified from this goal, and are subdivided as appropriate.

HTA: Example 0. In order to borrow a book from the library 1. go to the library 2. find the required book 2. 1 access library catalogue 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 4. take book to checkout counter

HTA: Example Borrow a book from the library 0 plan 0: do 1 -3 -4. If book isn’t on the shelf expected, do 2 -3 -4. go to the library 1 find required book 2 retrieve book from shelf 3 take book to counter 4 plan 2: do 2. 1 -2. 4 -2. 5. If book not identified from information available, do 2. 2 -2. 3 -2. 4 -2. 5 access catalog 2. 1 access search screen 2. 2 enter search criteria 2. 3 identify required 2. 4 book note location 2. 5

Summary • Getting the requirements correct is crucial to product’s success • Different types of requirements: • functional, data, environmental, user, and usability • Common data-gathering techniques: • questionnaires, interviews, focus groups and workshops, naturalistic observation, and studying documentation • Scenarios, use cases, and essential use cases can be used to explain existing and envisioned work practices, as well as plan future practices • Task analysis techniques, including HTA, help to investigate existing systems and current practices