Identifying Needs and Establishing Requirements

John Thiesfeld

Jeff Morton

Josh Edwards

Chapter Goals

• Describe different kinds of requirements. • Enable you to identify examples of different

kinds of requirements from a simple description. • Explain how different data gathering techniques

may be used, and enable you to choose among them for a simple description.

• Enable you to develop a "scenario,'' a "use case,'' and an "essential use case'' from a simple description.

• Enable you to perform hierarchical task analysis on a simple description

Two Aims

• Identifying Needs

• Produce a set of stable requirements

How to get requirements

• Gather Data

• Interpret and Analyze

• Capture Findings

Why Bother?

• Requirements issues lead to project failures– Requirements definition– Unclear objectives and requirements

• Project needs to support stakeholders

• Stakeholders don’t know exactly what they want

Requirements?

• A requirements is a statement about an intended product that specifies what it should do or how it should perform.

• Specific

• Unambiguous

• Clear as possible

Different Kinds of Requirements

Traditional types of Requirements

• Functional – what the system should do

• Non-Functional – what constraints there are on the system and its development

Different Kinds of Requirements

• Functional Requirements• Data Requirements• Environmental Requirements

– Physical environment – Social environment– Organizational environment– Technical environment

• User requirements• Usability requirements

Data Gathering

Purpose – collect sufficient, relevant and appropriate data so that a set of stable requirements can be produced

Data Gathering Techniques

• Questionnaires

• Interviews

• Focus groups

• Workshops

• Naturalistic Observation

• Studying Documentation

Questionnaires

• Series of questions designed to elicit specific information

• Usually not interactive

• Yes/No or short answer

• Good for large geographically diverse group

Interviews

• Interviews involve asking someone a set of questions, usually face to face

• Interviewees like to use artifacts to help explain to interviewer

• Structured/Unstructured/Semi-Structured

• Time consuming

• Hard to reach a broad group

Focus Groups and Workshops

• A group of stakeholders discuss issues and requirements together. Facilitator guides group.

• Easier to find areas of conflict and disagreement

• A small group can dominate discussion

Naturalistic Observation

• Observing a person do the task you are trying to build your product around.

• Humans might have difficulty explaining what they do

• Good for understanding the nature of the tasks and the context in which they are performed

Studying Documentation

• Looking through procedures and rules written down in manuals

• Shouldn’t be used by itself

Choosing between techniques

• Initially interviews are usually best

• Resources available

• Location and accessibility of stakeholders

Guidelines

• Focus on identifying the stakeholders’ needs• Involve all the stakeholders• Involve multiple representatives from each group• Use a combination of data gathering techniques• Use props to support data-gathering sessions• Run a pilot session• Know what kind of information you want to

gather• How data is recorded is important (written

reports/video recording)

Data interpretation and analysis

• Start immediately after gathering session

• Begin structuring and recording descriptions of requirements

• Maintain traceability

• Analysis is iterative

Task Description

• Scenarios

• Use Cases

• Essential Use Cases

Scenarios

• Describes human activities or tasks in a story that allows exploration and discussion of contexts, needs and requirements

• Does not describe the use of software or other technological support

Use Cases

• Focus on user-system interaction

• Capture actor’s goal in using system

Calendar Program1. The user chooses the option to arrange a meeting2. The system prompts user for the names of attendees3. The user types in a list of names4. The system checks that the list is valid5. The system prompts the user for meeting constraints

If List is invalida. The system displays an error messageb. The system returns to step 2

6. The user types in meeting constraints7. The system searches the calendars for a date that satisfies the constraints8. The system displays a list of potential dates

If no potential dates are founda. The system displays a suitable messageb. The system returns to step 5

9. The user chooses one of the dates10. The system writes the meeting into the calendar11. The system emails all the meeting participants informing them of the appointment

Essential Use Cases

• Represent abstraction from scenarios, and try to avoid the assumptions of a traditional use case.

• Associated with user roles

Users Intention System ResponsibilityArrange a meeting Request meeting attendees and

constraints

Identify meeting attendees and constrains Suggest potential Dates

Choose preferred date Book meeting

Task Analysis

Used mainly to investigate an existing situation, not to envision new systems or devices.

• What people are trying to achieve?

• Why are they trying to achieve it?

• How are they going about it?

Hierarchical Task Analysis

• Break down tasks

• Group together as plans that specify how a task could be performed

• Focus on the physical and observable actions

• Start at the user goal