Requirements Elicitation

CSCI 5801: Software Engineering

Requirement Elicitation

Requirement Elicitation

• Working with customers/users to determine requirements– Interviews– Observation– Other methods

Why Is This Difficult?

• Developers must create system in unfamiliar domain

Clients• Understand domain (or at least their own part)

• Not experts in software development ideas or terminology

Developers • Understand programming and software development

• Not experts in domain or in its users

???

Why Is This Difficult?

• Users not good at specifying processes– Assume implicit knowledge– Skip steps in process

“Fred registers for 31302, which is Dr. Sullins’ graduate project course”

– 31320 is the CRN, but have not told developer about difference between CRNs and course numbers

– Fred must also specify number of hours for project courses, but client has forgotten to mention this

Customer Interviews

• Asking clients/users what system must do– Most imprecise method

• Wrong approach:“Describe in detail what system should do”

• Better approach: General to specific– Get general list of desired features– Get more detail about each– Ask questions to clarify as needed

Kickoff Meeting

• Initial meeting between customers/developers– Free-form discussion

• Main goals:– User gives basic features required for system– User can give background about problems/needs

• Developers can also make suggestions about features

– User describes context in which system will operate• Creating new system? Updating existing system?

– Identify main stakeholders

Followup Meetings

Much more structured meeting• Developers look at previous interviews,

determine unanswered questions• Prepare specific questions for meeting

– Can involve simple prototypes

• Customers provide specific answers which developers record– Can be done via email if questions simple/clear

enough

Often Cyclical Process

Kickoff meeting

Analysis and Validation

Further questions

Structured interview

Scenario Refinement

• Asking “what if” type questions about scenario “Fred wants to register for the MW 10:00 section of CSIS 2610. He logs onto BANNER and tries to add it, but is told that it is closed. BANNER provides a list of open sections, which include one at MW 2:00. Fred is ok with that time, so he registers for that section.”

– What if no other sections open?– What if Fred does not like any other times?– What if time conflicts with other classes?– What if section closes before Fred finishes?– …

Task Analysis

• Decomposition of tasks into subtasks, gathering more detail about each

Register for course

Choose course Select section Add section

Find required courses

Find courses offered this semester

Choose section based on time

Find open sections

Understanding Requirements

• Find out why customer gives requirements– Better understanding of system– Help customer find better alternatives possible

“The system will need to be able to show a list of all courses for students to use.”

“Why do they need it? What are they looking for in particular?”

“They look for courses that meet requirements, at times that work for them.”

“Could we provide a search mechanism also? One that lets them narrow this big list by requirements met or times offered?”

Understanding Requirements

• Customers may also only have vague understanding of requirements

• Elicitation can help them develop understanding!

“Students have to log in with their name and password before adding classes”

“What if two students have the same name?”

“Good point. Let’s use their student ID instead.”

“What if they forget their password?”

“I’m not sure. Let me think about that...”

“Who else should I talk to?”

Customer Interviews

Basic guidelines:

• Allow plenty of time

• Prepare before you meet with the client

• Understand their viewpoint (type of stakeholder)

• Keep full notes for future reference

• If you do not understand, ask for clarification

• Small group meetings are often most effective

Ethnography

Major problems with interviews:• Interviewee may not explicitly state all steps in

process to be incorporated in software• What people say is not always what they do

“Prerequisites must always be followed.”

Prerequisites are overridden when appropriate.

Ethnography

• Alternative: observe users perform tasks– Will observe all steps– Will observe what actually happens

• Passive: Observe (and possibly record) task• Active: Ask questions at each stage

– Why did you do that?– What else could you have done?

Problems with Ethnography

• Only works when creating system to duplicate existing processes– Online registration process may not duplicate paper process

• May not observe all important parts of process– Some exceptions may occur infrequently

Example: transfer students

– Not all parts of process may be observableCan only observe how courses entered, not how chosen

Problems with Ethnography

• May not be convenient to observe process– Registration only happens 3 times a year

• Users may not like being observed• Users may act differently when observed

– More likely to “follow book”

Form Analysis

• Much redesign involves converting paper forms to computer/on line forms

• Use to understand crucial parts of process– What input are needed?– What reports are produced?

• Good basis for user interface design– Common usability requirement: keep system as

familiar as possible to users.

Form Analysis

What could you learn from this form?

Written Sources

• Instruction manuals, employee handbooks, etc.– Required sequence of steps– What must be done before each step– What to do if problems

– Must make sure they are up to date and actually followed!