Requirements Elicitation

1
Requirements Elicitation

• CSCI 5801 Software Engineering

2
Requirement Elicitation
3
Requirement Elicitation

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

4
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

???
5
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

6
Customer Interviews

• Asking clients/users what system must do
• Most imprecise method
• Wrong approachDescribe 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

7
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

8
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

9
Often Cyclical Process
Kickoff meeting
Analysis and Validation
Further questions
Structured interview
10
Scenario Refinement

• Asking what if type questions about scenario
  Fred wants to register for the MW 1000 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 200. 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?

11
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 open sections
Find courses offered this semester
Choose section based on time
12
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?
13
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. Lets use their student ID instead.
What if they forget their password?
Im not sure. Let me think about that...
Who else should I talk to?
14
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

15
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.
16
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?

17
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 infrequentlyExample
  transfer students
• Not all parts of process may be observableCan
  only observe how courses entered, not how chosen

18
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

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

20
Form Analysis
What could you learn from this form?
21
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!