0% found this document useful (0 votes)
45 views

Lecture 07

The document discusses techniques for requirements elicitation in software engineering. It begins by outlining three common challenges in requirements elicitation: 1) The "Yes, But" syndrome where users provide additional requirements after seeing a prototype. 2) The "Undiscovered Ruins" syndrome where finding more requirements leads to discovering even more remaining unknown requirements. 3) The "User and Developer" syndrome which stems from communication gaps between users and developers. It then describes the requirements elicitation process and various techniques used, including interviews, questionnaires, background reading, introspection, and social analysis. For each technique, it provides details on how to conduct the technique and its advantages and disadvantages.
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
45 views

Lecture 07

The document discusses techniques for requirements elicitation in software engineering. It begins by outlining three common challenges in requirements elicitation: 1) The "Yes, But" syndrome where users provide additional requirements after seeing a prototype. 2) The "Undiscovered Ruins" syndrome where finding more requirements leads to discovering even more remaining unknown requirements. 3) The "User and Developer" syndrome which stems from communication gaps between users and developers. It then describes the requirements elicitation process and various techniques used, including interviews, questionnaires, background reading, introspection, and social analysis. For each technique, it provides details on how to conduct the technique and its advantages and disadvantages.
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 27

SOFTWARE REQUIREMENTS ENGINEERING

LECTURE # 7

TEAM SKILL 2: UNDERSTANDING USER AND


STAKEHOLDER NEEDS
REQUIREMENTS ELICITATION TECHNIQUES - I
3 Presentation Outline
 The Challenge of Requirement Elicitation
 Yes But Syndrome
 Undiscovered Ruins
 User and Developer Syndrome
 Requirement Elicitation
 The Requirement Elicitation Process
 Requirement Elicitation Techniques
 Interviews
 Questionnaires
 Background Reading
 Introspection
 Social Analysis
The Challenge of Requirements Elicitation
4

 Requirements elicitation is complicated by three endemic


syndromes.

 The "Yes, But" syndrome


 It has been observed that the users' reactions after checking software for the
first time are: "Wow, this is so cool; we can really use this, and so on …..
"Yes, but, hmmmm, now that I see it, what about this . . . ? Wouldn't it be
nice if . . . ? And so on . . . ”

 The "Undiscovered Ruins“ Syndrome


 In many ways, the search for requirements is like a search for undiscovered
ruins: the more you find, the more you know remain.

 The "User and the Developer" syndrome


 The third syndrome arises from the communication gap between the user
and the developer.
Requirements Elicitation Process
5

 Background Knowledge

 Requirements Gathering

 Requirements Classification

 Requirements Conflict

 Requirements Prioritization
Methods of Collecting Data
6

Qualitative Data and Quantitative Data

 Qualitative data is data that is mainly words, sounds or images.

 Quantitative data is data that is mainly numbers.


Methods of Collecting Data
7

Structured and Unstructured Data

 Structured data is organized, unstructured data is relatively disorganized.

 Structured data can be produced by closed questions, unstructured data can be produced by
open questions.
8 Requirements Elicitation Techniques
 Interviews
 Questionnaires
 Background Reading
 Introspection
 Social Analysis
 Requirements Workshops
 Brainstorming and Idea Reduction
 Story Boarding
 Role Playing
 Prototyping
 Requirements Reuse
Interviews [1]
9

 One of the most important, popular, and most commonly used requirements
gathering techniques is the user interview

 A simple, direct technique that can be used in nearly every situation.

 In this method the requirement engineering analyst’s discuss with different types of
the stakeholders to understand the requirements of the system

 There are two main types of interviews:

 Closed Interviews
 Open Interviews
Interviews
10

Closed Interviews
 In closed interviews the requirements engineer prepares some predefined questions and he
tries to get the answers for these questions from the stakeholder’s

Open Interviews
 In open interviews the requirements engineer does not prepares any predefined questions
and he tries to get the information from the stakeholder’s in open discussions

Closed ended Question


 A close-ended question is one that demands mostly a brief yes or no response. [3,4]

Open ended Question


 An open-ended question is one that demands far more than a brief yes or no response. [3,4]
Interviews [1]
11

 Generally the interviews start wit predefined questions

 However in the process of interview a lot of different considerable things may arise that leads
to open discussion

 Interviews are effective for understanding the problem in the existing system and to find the
requirements of the stakeholders

 To make the interview session effective the requirements engineer and the stakeholders has to
perform in the following ways::

 Interviewer should be patient enough to listen the stakeholder’s views and the requirements, he should
be open minded
 Stakeholders should be expressive in the interview session, they should express their views in definite
context
The Interview Context [1]
12

 Establishing the user profile


 Assessing the Problem
 Understanding the user environment
 Recap for understanding
 Analyst’s inputs on user’s problem
 Assessing your Solution
 Assessing the Opportunity
 Assessing Reliability, Performance and Support needs
 Any other requirements
 Wrap up
 Analyst’s Summary
Interviews [1]
13

Large amount of qualitative data can be hard to


 Rich collection of information analyze

Uncovers opinions, feelings, goals, as Not as many people from various parts of the
well as hard facts company are interviewed, because of cost so there
exists high possibility for bias
Can review in detail, and adapt
follow-up questions to what the person Usually many follow ups are required
tells you for clarification

 Interviewing is a difficult skill to master


The Interview
14

DEMO
Questionnaires [1]
15

 Questionnaires are one of the methods of gathering requirements in less cost and reach a large number of
people only in lesser time

 Can be manual (paper form) or electronic (soft form distributed throughe-mail)

 The results extracted from the Questionnaires must be clearly analyzed

 The results from the Questionnaires mainly depends on the two factors::

 Effectiveness and the design of Questionnaires


 Honesty of the respondents

 A well designed and effective questionnaire can be used to decide the actual user requirements, objectives
and the constraints
The Designing of Questionnaires
16

The steps involved in designing and conducting the Questionnaires are::

 The purpose of survey should be clearly defined


 The Sampling group (respondents of the survey) should be decided
 Clearly state Why the respondent was selected for questionnaire
 Provide clear instructions on how to complete the questionnaire
 Avoid asking two questions in one
 Do not ask questions that give clues to answers
 Keep the questionnaire brief and user friendly
 Preparing and developing the questionnaire
 Conducting the questionnaire process
 Gathering and analyzing the results
The Designing of Questionnaires
17

 The Designing of Questionnaire is a multi stage process and should be viewed accordingly

 Assume 30-50% return rate for paper and email questionnaires

 Assume a 5-30% return rate for web-based questionnaires


The Arrangement of Questionnaires
18

The steps in arranging a Questionnaire are::

 The questions should be arranged well, so that


general questions are followed by the particular
questions

 Arrange the questions such that easy questions come


first

 The questions relevant to the main subject should be


given high priority
Questionnaires
19

An economical way to get feedback It is hard to create questionnaires that will give all
from the users, because it can reach to a possible options customer wants to give
large number of users in a short period of
time  There is always a high risk of question ambiguity

They are easier to analyze than (not clear)

interviews, because they consist of  Usually many follow ups are required for regular
multiple choice True & False questions feedback, subsequently adding to the cost
Background Reading
20

 Background Reading is used to gather information about the organization, which is helpful to
gain an understanding of the organization’s structure, its working, and the existing system

 Background Reading technique is not solely used for eliciting requirements because you can
not get the real user needs by just studying the existing documents

 It is used as a complementary approach with other techniques

 Sources of information:
 company reports, organization charts, policy manuals,
job descriptions, reports, documentation of existing systems, etc.

 Appropriate for
 when you are not familiar with the organization being investigated.
Background Reading
21

Analyst gets an understanding of the  Written documents often do not match upto reality
organization before meeting the people who
work there.  Can include much irrelevant detail

 Helps analysts to prepare for other types of  This technique can not solely be used for gathering
fact finding e.g. Helps to prepare questions for requirements because of absence of user involvement
interviews and questionnaires

 May provide detailed requirements for the


current system.
Introspection
22

 In Introspection technique Requirements analyst “imagines” what kind of system is required


for doing the required job, or by using available equipment etc

 Introspection is the first and the most obvious method for trying to understand what properties
a system should have in order to succeed.
Introspection
23

Appropriate for

 when users are not available, don’t want to answer your questions or shows lack of feedback
or input then Requirement engineer’s can use this technique to imagine the things which he
assumes that the user would require
Introspection
24

Introspection can be very inaccurate at times


Introspection is an easier
because Requirement Analyst imagines what is
technique to apply
required rather than asking from the user what
he requires

This technique is unlikely to reflect the


stakeholder’s goals and actual user experiences
Social Analysis
25

 Social Analysis is also known as Observation

 Observation is a process of collecting requirements by observing the people doing


their normal work

 This method is used to find the additional requirements needed by the user, when
the user is unable to explain their expected requirements

 This Social Analysis can be of the following types::


 Passive Observation
 Active Observation
 Explanatory Observation
Social Analysis
26

Passive Observation

 This social analysis is carried out without the


direct involvement of the observer in the society

 The observation of the peoples work is carried


out by recording using videotapes, video cameras
and surveillance cameras

 The documentation of the problem and


requirements are prepared from the recorded
data
Social Analysis
27

Active Observation

 This social analysis is carried out with the direct involvement of the observer in the society

 The observers encourages people to work with the existing product to perform the operations
on the product

 The observer provides the domain knowledge to the user and makes the report of the
requirements of the people by observing their day to day work with the product
Social Analysis
28

Explanatory Observation

 In this type of observation the user talks loudly,


explaining what they are doing while using the
product

 The observer takes notes using the explanation given


by the user

You might also like