Identifying Needs and Establishing Requirements

Identifying Needs and Establishing Requirements Kelly Kim Haimin Lee

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

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

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!!

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

How can we achieve? • Data gathering activities • Data analysis activities • Expression as ‘requirements’ • All of above are iterative

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

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

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

Non-functional1. 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”

Non-functional2. Environmental requirements • Definition : Circumstances in which the interactive product will be expected to operate • Categories • Physical • Social • Organizational • Technical

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

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

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

“The system will be able to communicate information between remote sites” “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” “The system must have access to design information that will be captured in a common file format(such as AutoCAD)” “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” Practical example • A system to support distributed design teams, e.g., for car design • Functional : • Data : • Environmental : • Users : • Usability :

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

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

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

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

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

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

Choosing between techniques Data gathering techniques differ in two ways: 1. Amount of time, level of detail andrisk 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?

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

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

Overview of techniques Technique Good For Advantages Disadvantages 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

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 Data Interpretation and Analysis

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

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. 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. Advantages of using scenarios • Capturing scenarios of existing behavior helps in determining new scenarios and hence gathering data for new requirements.

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. 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. Creating use cases

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

Example use case diagram for shared calendar

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

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

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

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 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 Sample task analysis

Sample task analysis 0.arrange a meeting Plan 0 : do 1, 2, 3 If potential dates are identified, do 4, 5 If no potential dates can be identified repeat 2-3 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 Plan 3 : do 3-1, 3-2, 3-3, 3-4 Or do 3.2, 3.1, 3.3, 3.4 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

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

Identifying Needs and Establishing Requirements