31269: Business Requirements Modelling

Requirements Elicitation

Week 3 Lecture

UTS CRICOS 00099F

 Objectives

• Plan for and carry out elicitation of requirements from stakeholders

and other sources
• Understand the benefits and drawbacks of different elicitation
techniques
• Identify appropriate technique for eliciting requirements for a given
situation
• Understand the differences between requirements elicitation for
existing systems vs the new system

31269 Business Requirements Modelling

Slide 2
Topics
• Requirements Elicitation Process
• Techniques for eliciting requirements
• Interview
• Questionnaires/Survey
• Observation
• Prototyping with ‘Wireframes’
• Requirements Workshop

31269 Business Requirements Modelling Slide 3

 Requirements Process

31269 Business Requirements Modelling Slide 4

Requirements Elicitation Process
• The following activities could be included in any requirements
elicitation process:
• Understanding the application domain & the properties of the existing
system
• Identifying the sources of requirements
• Identifying and analyzing all the relevant stakeholders
• Selecting the approaches, techniques and tools for elicitation
• Eliciting the requirements from the stakeholders and other sources using
the selected techniques, approaches and tools

31269 Business Requirements Modelling Slide 5

 Present versus Future system
• Get a clear understanding of
• The overall objectives of the enterprise
• What do individual users of the system want to achieve in their job
• Understand
• How the business is operating at present
• How people are working right now and what they cannot do with the
existing system
• The problems with and inadequacies of the current system

• Hence, discover the “new requirements”

31269 Business Requirements Modelling Slide 6

 Requirements Elicitation Techniques - Interview

• An interview is a systematic approach designed to elicit information from a person

or group of people.
• One-on-one interviews are typically most common.
• In a group interview (with more than one interviewee in attendance) the
interviewer must be careful to elicit responses from all attendees.
• Interviewer formally or informally directs questions to a stakeholder.
• Used to explore issues and can collect some quantitative, but mostly qualitative
data.
• Widely used elicitation and fact finding technique and requires the most skill and
sensitivity.
31269 Business Requirements Modelling Slide 7
 Requirements Elicitation Techniques - Interview

• Requires good planning and preparation, good interpersonal skills and an alert and
responsive frame of mind during the interview, and good analysis skills post interview.
• Ensure that the biases and predispositions of the interviewer do not interfere with
a free exchange of information.
• Structured Interview: where the interviewer has a pre-defined set of questions and is
looking for answers.
• Unstructured Interview: where, without any pre-defined questions, the interviewer and
the interviewee discuss topics of interest in an open-ended way.

31269 Business Requirements Modelling Slide 8

Preparing for interviews
• Establish the objective for the interview
• Determine relevant stakeholders to be involved
• Determine project team members to participate
• Build a list of questions and issues to be discussed
• Review related documents and materials
• Set the time and location
• Inform all participants of objective, time and location

31269 Business Requirements Modelling Slide 9

Conducting interviews

• Arrive on time and take responsibility for the agenda

• Stick to the planned timetable, do not over-run
• If you plan to tape the interview, ask the interviewees permission
but take notes as well.
• Probe for details by using different types of questions
• Take thorough notes
• Identify and document unanswered items or open questions

31269 Business Requirements Modelling Slide 10

 Interview Guidelines
• Plan and organize
• Start with high level general questions
• Ask specific questions
• Seek lead for more information from stakeholders
• Keep it to 1-2 hours
• Take and share meeting notes and minutes
• Record following up and action items
• Focus on “Project” and not the people
• Ask, listen, probe, understand and record (ALPUR)
• Avoid blaming, jargons, forcing your opinion

31269 Business Requirements Modelling Slide 11

 Interview Approach – the Don’ts

• Never show aggression nor create an impression of apportioning

blame.
• Do not force solutions on users- play role of an advisor and facilitator
• Explain limitations of the system in user terms
• Describe how system will help users in their work
• Do not ask leading questions, ask for suggestions for improvement and
follow them up.

31269 Business Requirements Modelling Slide 12

 Open Questions
• Encourage spontaneous and unstructured responses.
• General questions establishing a viewpoint
• Question that requires a full answer
• Open-ended questions begin with the following words: why, how, what, describe,
tell me about..., or what do you think about...
• Examples of open-ended questions are:
• "What happened after I left?“
• "Why did Jim leave before Susan?"
• "Tell me about your day at work."
• "What do you think about the new season of this TV show?“
• “Is there anything else I should be asking you?” (Your last question of the interview)
For more examples see http://examples.yourdictionary.com/examples-of-open-ended-and-closed-ended-questions.html

31269 Business Requirements Modelling Slide 13

Closed Questions
• Question that can be answered by single word (yes or no) or a short phrase.
• They are used to obtain facts and specific pieces of information.
• Restrict the response requiring specific answer such as a number, explanation of a report,
reason for an action”
• Examples of closed-ended questions are:
• "Who will you choose?"
• "What brand of car do you own?"
• "Did you speak to Bob?"
• "Did Susan leave with Jim?"
For more examples see http://examples.yourdictionary.com/examples-of-open-ended-and-closed-ended-questions.html

31269 Business Requirements Modelling Slide 14

 Probes

• Probes are a
• Follow up from a previous answer
• “Why do you…”
• “Where do you…”
• “How often do you…”

Most interviews use a combination of all three question types. The

approach you take will depend on the type/role of interviewee

31269 Business Requirements Modelling Slide 15

 Concluding and evaluating interviews
• Thank interviewees for their time. Offer to provide them with a copy of your
notes for them to validate. Make an appointment for further interviews if
needed.
• Review and transcribe your tapes or notes ASAP after the interview while the
content is still fresh in your mind.
• Review your notes for accuracy, completeness, consistency and
understanding.
• Transfer information to appropriate models and documents.
• Identify areas needing further clarification.
• Send interviewees your notes and update your notes to reflect their
comments.

31269 Business Requirements Modelling Slide 16

Advantages and disadvantages of Interviews
+ Allows the interviewer and participant to have full discussions and explanations of the questions and answers.
+ Personal contact allows responsiveness and adapting to what the user says.
+ Analyst can probe in greater depth than any other methods of elicitation
+ Allows interviewees to express opinions in private that they may be reluctant to express in public.
- Can be time consuming and costly. Requires considerable commitment and involvement of the participants.
- Interview results have to be transcribed and written and transcription and analysis of interview data can be
complex and expensive.
- Can be subject to bias
- If conflicting information is given, it can be difficult to resolve and interviews are not an ideal means of reaching
consensus across a group of stakeholders.
- There is a risk of unintentionally leading the interviewee.

31269 Business Requirements Modelling Slide 17

Requirements Elicitation Techniques – Surveys/Questionnaires
• A Questionnaire or “Survey” is a document containing a number of standard questions
that can be sent to individuals to obtain information from a large number of people or
when the people are geographically dispersed.

• So, you could send these list of questions to your stakeholders asking them about the
new system or the changes to the existing system

• Can collect both quantitative and qualitative data.

• They are also appropriate for systems that will be used by the general public and where
the analyst has to investigate all the types of users of the system.

31269 Business Requirements Modelling Slide 18

 Types of Questions
• Yes/No questions:
e.g. “Do you print reports from existing system?” Yes No (please circle one)
• Multiple Choice questions:
e.g. How many clients do you obtain in a year?
a) 1-10
b) 11-20
c) 21-30
d) 31 +
• Scaled Questions: e.g. How satisfied are you with the response time of the stock update?
(please circle one option) 1. Very satisfied 2. Satisfied 3. Dissatisfied
• Open-ended questions e.g. What additional reports would you require from the system?
31269 Business Requirements Modelling Slide 19
 Advantages and disadvantages of Surveys
+ An economical and quick method of gathering data from a large sample.
+ Can reach many people with low resource.
+ Used for answering specific questions.
+ Can be administered remotely.
+ Depending on how well it is designed, the results can be analysed easily by software
applications.
+ Effective and efficient when stakeholders are not located in one location.

- Effective questionnaires are hard to design (e.g. leading questions,

misinterpretation of questions).
- Questions are usually not answered completely.
- The response rates for surveys can be too low for statistical significance.
- There is no automatic way of follow up unless you do interviews later.

31269 Business Requirements Modelling Slide 20

Requirements Elicitation Techniques - Observation
• Analyst observes the actual execution of existing processes by the users (study
a stakeholder’s work environment), usually without direct interference.
• Seeing the environment and domain where the system will be situated in action
gives additional perspectives and a better understanding of system
functionalities.
• Observe system as it actually behaves.
• Observation also allows us to verify statements made in interviews and surveys
to determine whether the procedures within the domain really operate as they
were described.
• you might discover that neither the system documentation nor the interview
statements are accurate.
31269 Business Requirements Modelling Slide 21
Requirements Elicitation Techniques - Observation
• Direct gathering of information rather than through description.
• Individual behaviour maybe altered because they know they are being studied.
• Avoid disturbing users from their normal activities.
• Two types of Observations:
• Passive: You don’t ask questions, simply observe and make notes.
• Active: You observe and have a dialog with the users/stakeholders while they are performing
their work.

• IIt is useful in situations where different interviewees have provided conflicting

information about the way existing system works.
• Observation is essential for gathering some quantitative and mostly qualitative
data about people’s jobs.

31269 Business Requirements Modelling Slide 22

 Guidelines for observation
• Ask enough questions to ensure that you have a complete
understanding of the present system.
• Document any procedures for handling exceptions
• Consider each user who works with the system
• What information does that person receive from other people?
• What information does this person generate?
• How is this information communicated?
• How often do interruptions occur?
• How much down time occurs?
• How much support does the user require and who provides it?

31269 Business Requirements Modelling Slide 23

 Advantages and disadvantages of Observation
+ Provides first hand experience of the way the current system works
+ Data is collected in real time and can have a high level of validity
+ Can be used to verify information from other sources or to look for exceptions
+ Baseline data about the performance of the existing system and of users can be collected

- Could be very time consuming

- Need to analyse huge amounts of data
- Most people do not like to be observed and may be disruptive to the person being observed.
- Requires trained and skilled observer to be most effective.
- There may be ethical problems if the person being observed deals with sensitive private or personal data or
directly with members of public.
- There may be logistical problems if the staff being observed work shifts.
- Unusual exceptions and critical situations that happen infrequently may not occur during the observation.

31269 Business Requirements Modelling Slide 24

 Requirements Elicitation Techniques - Prototype

• A prototype is an initial working model of a larger, more complex

entity, usually a program with limited functionality that is built to test
out some aspect of how the final system will work (and look like)
and then present it to the stakeholders.
• Prototypes may be constructed with various objectives in mind:
• To investigate user requirements
• To test specific concept or verify an approach
• To focus on human-computer interface
• Investigate input and output and its form
• Investigate most suitable interface

31269 Business Requirements Modelling Slide 25

Example UI flow: Online banking system
Storyboard/Wireframes (UI flows) – part of
assessment 4
• UI flows or storyboarding (wireframes): A storyboard is a series of drawings used
mostly for identifying user interfaces; screens that the software will display are
drawn.
• User interface-flow diagrams (Storyboards/Wireframes) offer a high-level view of
the interface of a system, you can quickly gain an understanding of how the
system is expected to work. You can then validate the overall flow of your
application's user interface. For example, does the flow make sense?
• User interface-flow diagrams are used to model the interactions that users
have with your software, as defined in a single use case.
• They also enable you to gain a high-level overview of the user interface for
your application.
Source: http://www.agilemodeling.com/artifacts/uiFlowDiagram.htm

31269 Business Requirements Modelling Slide 27

 Advantages & Disadvantages
+ Allows for early user interaction and feedback.
+ Inexpensive means to quickly uncover and confirm a variety of requirements.
+ Supports users who are more comfortable and effective at articulating their needs by
using pictures, as prototyping lets them “see” the future system’s interface.
+ A vehicle for designers and developers to learn about the users’ interface needs and
to evolve system requirements.

-----
- Depending on the complexity of the target system, using prototyping to elicit
requirements can take considerable time.
- A prototype may lead users to develop unrealistic expectations regarding the
delivered system’s performance, completion date, reliability and usability
characteristics. This is because an elaborated, detailed prototype can look a lot
like a functional system.
31269 Business Requirements Modelling Slide 28
 Requirements Elicitation Techniques –
Requirements Workshop (Focus Groups)
• A technique used to expedite requirements elicitation, also referred to as “Joint
Application Development” or “focused groups”.

• The objective is to compress all of the activities involved in other fact finding
techniques into a shorter series of workshop sessions with users and project team
members.

• These sessions are usually conducted in special rooms with supporting facilities:
overhead projector, a white board, flip charts, adequate workspace for the
participants.

31269 Business Requirements Modelling Slide 29

 Requirements Workshop Fundamentals
• A workshop may be used to scope, discover, define, refine, update,
prioritize and reach closure on requirements for the target system.
• A workshop may be used to generate ideas for new features or
products, to reach consensus on a topic or conflicting views, or to
review requirements.
• Organised process: uses techniques such as brain storming, top
down analysis, etc.
• Documented approach: output of each session is documented in
such a way to make it easy to read and understand and agree upon.

31269 Business Requirements Modelling Slide 30

 Requirements Workshop Guidelines

• Participants must be selected carefully representing different classes

of stakeholders.
• Ensure that all stakeholders participate and have their input heard.
• Must have a skilled facilitator (you as a BA).
• You should remain neutral and promote discussion.
• Meeting room should have all the necessary facilities and the
environment be conducive to hold effective meetings
• Need visual aids (e.g. flip charts, whiteboard, large screens, GUI)

31269 Business Requirements Modelling Slide 31

 Requirements Workshop

• Goal and Agenda

• Elicitation, Review, Sign Off workshops
• Who…10-15 people max.
• Location and time
• Facilitator
• Subscriber
• Tools
• Food
• Ice breaker
• Follow-up

31269 Business Requirements Modelling Slide 32

 Advantages & Disadvantages
+ Workshop sessions are very successful in reducing project development
efforts and shortening the schedule.
+ Used to generate ideas for new features or products.
+ To reach consensus on a topic or conflicting views.
+ Is able to gauge reaction to stimulus material (e.g. storyboards, screenshots).
+ A requirements workshop provides a means for stakeholders to collaborate,
make decisions and gain a mutual understanding of requirements.
---------------------------------------------------------------------------------
- Risk involved in speeding up the decisions. Sometimes the decisions made
about the requirements are not optimal.
- May suffer from dominance and submission.
- At times, details are inappropriately defined or missed altogether.

31269 Business Requirements Modelling Slide 33

 Summary of elicitation techniques
• Techniques for eliciting requirements
• Interviews
• Questionnaires/Survey
• Observation
• Prototypes with Wireframes
• Requirements Workshops

31269 Business Requirements Modelling Slide 34

Using interview technique to elicit requirements
(will discuss further in the lecture)

Examples Questions/answers to elicit FR and NFR

• Functional requirements
Does the ATM need to have a proof of transaction system?
ATM should print receipts as a record of transactions

• Non functional requirements

How fast will the processing speed be?
We want to keep all interactions with the ATM under 2-3 minutes, no
noticeable slow down even with large transactions/withdrawals

31269 Business Requirements Modelling 35

 Example requirements statements (will discuss further in the lecture)

1. The ATM must allow users to withdraw, deposit, view their

account balance and transfer money. Functional requirement
statement

2. The ATM should have a touchscreen and pin pad interface

and all actions should be processed and performed in under 2
minutes Non functional requirement statement

31269 Business Requirements Modelling 36

Using prototype technique to elicit requirements
Example ATM System
Login screen

31269 Business Requirements Modelling Slide 37

Tips for Tutorial activities (will discuss in the lecture)
• Case Study BB (‘Bookish Bliss’ Case study)

31269 Business Requirements Modelling Slide 39

 Q&A

31269 Business Requirements Modelling Slide 40

NEXT WEEK

Process Modelling

Slide 41
Thank you

UTS CRICOS 00099F