Chapter 3

Requirement Elicitation and Analysis

.
Page 1 of 53
Contents
 Requirements Elicitation
 Difficulties of Requirements Elicitation
 Components of Elicitation
 Elicitation , Analysis & Negotiation
 The requirements elicitation process
 The requirements Analysis & Negotiation Process
 Elicitation Techniques
 Traditional techniques
 Collaborative techniques
 Cognitive techniques
 Contextual approaches
Page 2 of 53
 Requirements Elicitation
 Encompass all activities involved in discovering the
requirements of a system
 System developers and engineers work in close relationship
with customer and end-users to
 Find out and understand the problems to be solved
 Find out and understand the functionalities of the system
 Find out the required “performance” of the solution
 Find out constraints, such as hardware and other, on the
solution
It is not as simple as “let’s ask the users what they want.”

Why ? Because -------?

Page 3 of 53
 Difficulties of Requirements Elicitation
 User/Customer:
1. Don’t always know all the requirements; may only know their own
respective areas
 May not know the grand, organizational needs and objectives
 May not know the “politics” at play
2. May give conflicting requirements
3. May prioritize differently among themselves
4. May intermix needs with wants
5. May not have time or forget to give the complete picture etc.
 Requirements Analyst:
1. May not be a good listener
2. May not understand the domain (the domain specific language) and
misinterpret the user/customer meaning
3. May not be trained, prepared or organized for elicitation
4. May not have enough time etc.
Page 4 of 53
 Difficulties of Requirements Elicitation…
 Requirements elicitation is further complicated by three endemic
syndromes.
 The "Yes, But" Syndrome
 Two immediate, distinct, and separate reactions when the users see the
system implementation for the first time are;
1. "Wow, this is so cool; we can really use this, what a neat job" and so on.
2. "Yes, but, hmmmmm, now that I see it, what about this ... ? Wouldn't it
be nice if . . . ? Whatever happened to . . . ?“
 The "Yes, But" syndrome is human nature and is an integral part of
application development. We should plan for it.
 We can significantly reduce this syndrome by applying techniques that get
the "Buts" out early.
 In so doing, we elicit the "Yes, But" response early, and we then can begin
to invest the majority of our development efforts in software that has
already passed the "Yes, But" test Page 5 of 53
 Difficulties of Requirements Elicitation…
 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.
 You never really feel as though you have found them all,
and perhaps you never will.
 Indeed, software development teams everywhere continually
struggle to determine when they are done with requirements
elicitation, that is,
 when have they found all the requirements that are material or
 when have they found at least enough?

Page 6 of 53
 Difficulties of Requirements Elicitation…
 The "User and the Developer“ Syndrome
 Communication gap between the user and the developer.
 Users and developers are typically from different worlds, may even speak different
languages, and have different backgrounds, motivations, and objectives.
 Reasons for this problem and some suggested solutions.

Page 7 of 53
 Components of Elicitation
 Application domain understanding
 Application domain knowledge is knowledge of
the general area where the system is applied.
 Problem understanding
 details of the specific customer problem where
the system will be applied must be understood.
 Business understanding
 understand how systems interact and contribute
to overall business goals.
Understanding the needs and constraints of system stakeholders
understand, in detail, the specific needs of people who require system
support in their work.
Page 8 of 53
Analysis & Negotiation

 The objectives of requirement analysis & negotiation is to

establish an agreed set of requirements which are complete and
consistent.
 During analysis process
 Missing requirements
 Requirements conflict
 Ambiguous requirements are discovered
 Overlapping requirements
 Unrealistic requirements
 For conflicting & ambiguous requirements stakeholders should
negotiate and agree on modifications and simplifications of the
requirements
Page 9 of 53
Elicitation, analysis and negotiation

Page 10 of 53
The requirements elicitation process

 Objective setting: establish the overall organizational objectives:

why is the system necessary?
 Background of knowledge acquisition: gather and understand
more background information about the system Page 11 of 53
 The requirements elicitation process…

 Knowledge organization: organize, prioritize and collate/compare

the large amount of data collected in the previous phases
 Stakeholder requirements collection: involve system stakeholders
to discover their requirements. Page 12 of 53
 Problem Statement
 The problem statement is developed by the client as a condensed
description of the requirements that should be addressed by the
system
 Describes the problem that should be solved
 It describes “what” is needed, not “how” it should be reached
 The problem statement contains
 Current situation: The Problem to be solved (a few pages)
 Description of one or more scenarios
 Some initial requirements ( Functional and Non-functional requirements. No
complete description)
 Project Schedule ( Major milestones that involve interaction with the client
including deadline for delivery of the system)
 Target environment (The environment in which the delivered system has to
perform a specified set of system tests
Page 13 of 53
 Client Acceptance Criteria ( Criteria for the system tests)
Elicitation techniques - Introduction
 Specific techniques which may be used to collect knowledge
about system requirements
 This knowledge must be structured
 Partitioning - aggregating related knowledge
 Abstraction - recognizing generalities
 Projection – organizing knowledge from several perspectives
 Requirements elicitation is cooperative process involving
requirements engineers and system stakeholders.
 Problems:
 Not enough time for elicitation
 Inadequate preparation by engineers
 Stakeholders are unconvinced of the need for a new system
Page 14 of 53
 Elicitation techniques
 Traditional techniques
 Introspection
 Reading existing documents
 Analyzing hard data
 Interviews
 Open-ended
 Structured
 Surveys / Questionnaires
 Meetings
 Collaborative techniques
 Group techniques
 Focus Groups
 Brainstorming
 JAD/RAD workshops
 Prototyping
 Participatory Design
 Cognitive techniques
 Task analysis
 Protocol analysis
 Knowledge Acquisition Techniques
 Card Sorting
 Laddering
 Repertory Grids
 Proximity Scaling Techniques
 Contextual approaches
 Ethnographic techniques
 Participant Observation
 Enthnomethodology
 Discourse Analysis
 Conversation Analysis
 Speech Act Analysis
 Sociotechnical Methods
Page 15 of 53
 Soft Systems Analysis
 Introspection
 Is the mental thoughts of the requirements engineering about the
wants and needs of the stakeholders about the systems.
 It amounts to imagining what kind of system I would want if I were doing this
job, using this equipment, etc.
 The introspection technique is the starting point for other
requirement elicitation techniques.
 Advantages
 It helps the other elicitation techniques. So it is a good starting activity
for requirement elicitation.
 There are almost no costs of this technique.
 Disadvantages
 In case of using the introspection the analyst should not only be familiar
with the domain and goals of the system, but also should be expert in the
business processes of the users.
 In other words this technique requires a huge experience of the
requirement analyst.
Page 16 of 53
 Background Reading
 Sources of information:
 Company reports, organization charts, policy manuals, job descriptions,
reports, documentation of existing systems, etc.
 Advantages:
 Helps the analyst to get an understanding of the organization before
meeting the people who work there.
 May tell you the detailed requirements for the current system.
 Disadvantages:
 Written documents often do not match up to reality.
 Can be long-winded with much irrelevant detail.
 Appropriate for - Whenever you are unfamiliar with the organization
being investigated.

Page 17 of 53
“Hard Data” Collection
 Identify Collections of Hard Data
 Facts and figures, financial information, invoices…
 Reports used for decision making,…
 Survey results, marketing data,…
 Sampling
 Sampling used to select representative set from a population
 Purposive Sampling - choose the parts you think are relevant without
worrying about statistical issues
 Simple Random Sampling - choose every kth element
 Stratified Random Sampling - identify strata/class and sample each
 Clustered Random Sampling - choose a representative subpopulation
and sample it
 Sample Size is important - balance between cost of data
collection/analysis and required significance Page 18 of 53
 Interview

 Probably the most common technique of requirements

elicitation.

 Interviewers must be open-minded and should not approach the

interview with pre-conceived notions about what is required

 Interviewers must be aware of organizational politics

 Some requirements may not be discussed because of their political
implications
 Interviews with different stakeholders Different perspectives
Page 19 of 53
Interviews Different Techniques
 Structured (closed) interviews
 Stakeholders answer a predefined set of questions
 Easy to analyze (+)
 Well-formed questions generate well-formed answers (you have
to know your goals) (+)
 Knowledge about what and how to ask (-)
 Non-structured (open) interviews
 No predefined agenda
 Generating new ideas (experimental, brain storming) (+)
 sometimes hard to handle (dynamics of discussion) (-)
 In practice: mixed interview types are normal
Page 20 of 53
 Interviews: Written vs. oral interviews, group vs. single
 Oral interviews:
 possibility to discussion (+)
 interviewer may influence interviewee (-)
 Written interviews
 problems in understanding (-)
 already transcribed, thus easy to analyze (+)
 Interviewing a single person:
 individual opinions (+)

 Interviewing a group of people: -

 Involvement of many perspectives
 Developer need experience to moderate (-)
 Sometimes single or silent opinions are not noticed (-)
 Independent Moderator can mediate between group. Page 21 of 53
Interviewing Tips
 Prepare some initial questions  good entry point
 Do not press the interviewee through the questioning
 Restrict the time frame for the questioning (approx. 1 hour)
 Announce the estimated time for the interview
 Short introduction for the purpose of the interview
 Ensure anonymity (if necessary)
 Make notes to the answers
 Explain the purpose of the records (reduces potential fear!)
 Do not interrupt the interviewee’s flow of words
 Allow people to refuse a question (don’t insist on answers!)
 Announce feedback (evaluation) at the end
Page 22 of 53
Interviewing …
 Advantages
 Rich collection of information
 Good for uncovering opinions, feelings, goals, as well as hard facts
 Can probe in depth, & adapt follow up questions to what the person
tells you
 Disadvantages
 Large amount of qualitative data can be hard to analyze.
 Hard to compare different respondents.
 Interviewing is a difficult skill to master.

Page 23 of 53
Surveys and Questionnaires
 Advantages
 Can quickly collect info from large numbers of people
 Can be administered remotely
 Can collect attitudes, beliefs, characteristics
 Disadvantages
 Simplistic (presupposed) categories provide very little context
 No room for users to convey their real needs
 Watch for:
 Bias in sample selection & in self-selecting respondents
 Small sample size (lack of statistical significance).
 Open ended questions (very hard to analyze!).
 Ambiguous questions.

Page 24 of 53
 Meetings
 Used for summarization and feedback
 E.g. meet with stakeholders towards the end of each stage
 to discuss the results of the information gathering stage
 to conclude on a set of requirements
 to agree on a design etc.
 Use the meeting to confirm what has been learned, talk about findings
 Meetings are an important managerial tool
 Used to move a system development project forward.
 Need to determine objectives for the meeting:
 E.g. presentation, problem solving, conflict resolution, progress
analysis, gathering and merging of facts, training, planning,...
 Plan the meeting carefully: time, agenda, place, rules, …
 Special rules apply for formal presentations, walkthroughs,
brainstorming, etc. Page 25 of 53
 Collaborative techniques: Group techniques
 In the group work, different stakeholders are invited to conduct the
group meeting in a collaboration to elicit the requirements of the
system to be developed.
 Two types:
 Focus Groups
 Brainstorming
 Focus Groups
 A kind of group interview
 Groups are brought together to discuss some topic of interest
 produces data and insights that would be less accessible without
interaction found in a group setting—listening to others’ verbalized
experiences stimulates memories, ideas, and experiences in
participants
Page 26 of 53
 Brainstorming
 Brainstorming refers to the process of systematic and liberal
generation of a large volume of ideas from a number of participants.
 So much severe criticism is not allowed in this type of technique
because due to this the biasness can be generated.
 The ideas are freely explained and everyone has to interpret it in a
very pleasant environment with some informal discussion.
 Brainstorming can be structured or unstructured
 Unstructured brainstorming
 Participants can give ideas as they come to mind
 Quite often not very efficient
 Structured brainstorming
 Participants must follow structure in order to make the gathering of
inputs more orderly and more efficiently. Page 27 of 53
 Process of Structured Brainstorming
 State the central brainstorming theme in question form and write it
down where every participant can see (white board or flipchart)
 Ensure that all the members have a full understanding the question
 Let each team member have a turn to give his or her input as answer
to the question.
 If a team member can't think of any input when his or her turn comes, he simply
needs to say 'Pass,' and the next member gets the turn.
 Write each input on the board or flipchart as it is given.
 Nobody is allowed to criticize an input, no matter what.
 Moderator writes down the input on the board or flipchart using exactly the
same words used by the input giver.
 Repeat the brainstorming rounds until everybody says 'Pass' in the
same round ( ideas are exhausted).
 Review each of the listed inputs for further improvement and
maximize its clarity.
 Other team members can ask the input giver what he or she actually means by
his or her input. Page 28 of 53
 Group techniques: Pros & Cons
 Advantages
 More natural interaction between people than questioner &
formal interview
 It promotes free thinking and expression of ideas.
 Brainstorming provides the innovative ideas about the project to
be developed.
 Disadvantages
 May create unnatural groups (uncomfortable for participants)
 Brain storming is seriously affected by exploring the critique
ideas.
 May only provide superficial responses

Page 29 of 53
 Joint Application Development
 Joint Application Development (JAD) is a requirements
elicitation method that brings together stakeholders, end-users,
and development teams in a collaborative workshop setting..

 The primary goal of JAD is to gather requirements and create a

shared understanding of the desired system or software
application.

 Have Workshop Format: JAD sessions are typically conducted in

a facilitated workshop format, bringing together all relevant
stakeholders, including business users, subject matter experts,
analysts, developers, and other project team members.. Page 30 of 53
 JAD: pros & Cons
 Advantages
 decreases time and costs associated with requirements elicitation process.
 During 2-4 weeks information not only is collected, but requirements, agreed upon
by various system users, are identified.
 JAD sessions help bring experts together giving them a chance to share
their views, understand views of others, and develop the sense of project
ownership.
 Well known and can easily be applied
 Easy integration of CASE tools into JAD workshops improves session
productivity and provides systems analysts with discussed and ready to use
models.
 Disadvantages
 valuable time of professionals can be wasted easily.
 The wrong problem can be addressed, the wrong people can be invited to
participate. Page 31 of 53
 Prototyping
 A prototype is an initial version of a system which is available
early in the development phase
 Prototypes are valuable for requirements elicitation because
users can experiment with the system and point out its strengths
and weaknesses of the implemented requirements
 Rapid development of prototypes is essential so that they are
available early in the elicitation process
 In prototypes
 Some functionality may be left out
 Non-functional requirements (e.g. performance) are less stringent
 No secondary functions (e.g. maintenance)
 No complete documentation
Page 32 of 53
 Prototyping: Types
 Throw-away prototyping
 Intended to help elicit and develop the system requirements.
 The requirements which should be prototyped are those which cause
most difficulties to customers and which are the hardest to understand.
 Requirements which are well-understood need not be implemented by
the prototype.
 Evolutionary prototyping (Increment)
 Intended to deliver a workable system quickly to the customer.
 Therefore, the requirements which should be supported by the initial
versions of this prototype are those which are well-understood and
which can deliver useful end-user functionality.
 It is only after extensive use that poorly understood requirements should
be implemented.
Page 33 of 53
 Prototyping: Approaches
 Paper prototyping
 a paper mock-up of the system is developed and used for system
experiments
 ‘Wizard of Oz’ (WOZ) prototyping
 a person simulates the responses of the system in response to some
user inputs
 Executable prototyping
 a programming language or other rapid development environment
is used to develop an executable prototype
 Executable Prototype Development
 Visual programming languages such as Visual Basic
 Internet-based prototyping solutions [ HTML browsers, Java)
 Visualization Tools like Microsoft Visio
 Powerful CASE tools ( Eclipse, NetBeans ) Page 34 of 53
 Prototyping: benefits
 The prototype allows users to experiment and discover what
they really need to support their work
 Establishes feasibility and usefulness before high development
costs are incurred
 Can even reduce the development costs
 Essential for developing the ‘look and feel’ of a user interface
 Probably the only technique to validate interface requirements
 Can be used for system testing and for further development of
documentation
 Back-to-Back testing: same tests are applied to both prototype and final
system
 Forces a detailed study of the requirements which reveals
inconsistencies and omissions
Page 35 of 53
 Prototyping: Disadvantages
 Insufficient analysis- The focus on a limited prototype can distract
developers from properly analyzing the complete project.
 User confusion of prototype and finished system - Users can begin to think
that a prototype, intended to be thrown away, is actually a final
system that merely needs to be finished or polished.
 Expense of implementing prototyping - the start up costs for building a
development team focused on prototyping may be high
 Excessive development time of the prototype- A key property to
prototyping is the fact that it is supposed to be done quickly.
 Possibility of implementing systems before they are ready.
 Not suitable for large applications

Page 36 of 53
 Knowledge Elicitation Techniques in RE
 Background
 Knowledge elicitation is concerned with discovering ‘expert’ knowledge
 Originally focused on deriving expert’s “rules” for Rule-based Systems
 More recently, focused on understanding “problem solving methods”
 Task analysis
 Task analysis provides the tasks in a hierarchical fashion with a top-down
manner.
 In this approach main task and the sub-tasks are described by different
levels in the tree format and hence this detail continues until the root
tasks are encountered.
 The primary objectives of this technique is to construct a hierarchy of
the tasks performed by the users and the system, and determine the
knowledge used or required to carry them out.
 is also useful for representing design analysis, integration with business
models and model of requirements change. Page 37 of 53
 Task analysis…
 Advantages
 provides the interaction of both user and the system with
respect to some task that takes place.
 used by the project manager to manage the user and system
tasks.
 Disadvantages
 requires a lot of effort as compared to interview.
 The detail of level is mandatory in task analysis
 and hence it needs a lot of detail for the low level tasks.

Page 38 of 53
 Protocol analysis
 Is a sort of meeting where participants discuss the requirements of the
customer while talking loudly. (psychological research method )
 Protocol Analysis also provides the required actions to be taken for
fulfilling the user requirements by using rationale.
 Advantages
 This technique can provide the analyst with specific information and
rationale for the processes the target system must support.
 This technique enables all the stakeholders to provide active
participation.
 Disadvantages
 Sometime this technique does not provide the true picture of the
requirements as talking through operations.
 Conflicts can occur among the participants while talking loudly.
Page 39 of 53
 Card Sorting
 In card sorting technique the customer is provides with a set of cards
to sort it according to the names of domain entities.
 Also the costumer has to provide the criteria according to which the
cards are sorted.
 Advantages
 It provides the requirements prioritization by sorting and placing the
most important requirements at the top of the cards.
 It provides how much the customer has the knowledge about the problem
domain.
 elicits classification knowledge
 Disadvantages
 It requires deep knowledge about the domain and also all the entities
should be included in the process otherwise this technique gives wrong
results.
 Complex cards can confuse the novice stakeholder. Page 40 of 53
 Laddering
 A series of simple questions are asked from the stakeholders which are
answered in a clear way by the stakeholders.
 These questions are arranged into a hierarchical format which is useful
to show the order of the questions that has been asked and priority.
 The stakeholder domain information is vital for the success of this
technique.
 Advantages
 provides the close contact with the stakeholders by asking them about
their prioritized needs.
 arranges the customer requirements in proper hierarchical format that is
easy to be understood.
 Disadvantages
 becomes more complex for a large numbers of requirements
 The maintenance of this technique becomes very hard when adding and
deleting the requirements anywhere in the laddering. Page 41 of 53
 Delphi Technique
 Is an iterative technique in which information is exchanged in a
written form until a consensus is reached.
 For example participants may write down their requirements,
sorted in order of importance.
 The sets of requirements obtained are distributed to all
participants, who reflect on them to obtain a revised set of
requirements.
 The procedure will be repeated several times until sufficient
consensus is reached.
 Used where contact between experts is difficult

Page 42 of 53
 Delphi Technique: pros & cons
 Advantage
 Anonymous
 Freedom from individual influence or dominance
 Can reach consensus in hostile groups
 Insulates from lobbying
 Disadvantages
 Time consuming
 Information only as good as participants
 Needs good written communication skills
 Possible manipulation
 Best method for complex problems
Page 43 of 53
 Repertory Grids
 develop a grid in the form of a matrix used to store the
requirements involve asking stakeholders to develop attributes
and assign values to a set of domain entities.

 Used to detect terminological differences

 Get the experts to agree a set of entities
 Each expert provides attributes and values
 For each attribute in expert A's grid, find the closest match in expert B's
grid. (i.e. are there attributes which have the same discriminatory
function?)
 Experts then rate the entities using each other's attributes

Page 44 of 53
 Contextual approaches: Participant Observation
 People often find it hard to describe what they do because it is so
natural to them.
 Actual work processes often differ from formal, prescribed processes
 Sometimes the best way to understand it is to observe them at work
 This technique is often used with the conjunction of other
requirements engineering techniques like interview and task analysis.
 Advantages
 highly authentic requirements engineering tool
 mostly used in order to validate and verify the requirements.
 Disadvantages
 very much expensive to be performed because of the travelling costs.
 Mostly the results of observations are wrong as the customer problems
cannot be understand as they are being watched during observations and
adjust themselves. Page 45 of 53
 Ethnography
 Ethnography means how the people understand the problem.
 From the software requirements engineering context, the
ethnography defines how people perceive their needs to be fulfilled by
the software.
 An ethnographer spends some time observing people at work and
building up a picture of how work is done
 Fundamental Theory:
 The full understanding of a culture emerges only when an observer becomes
part of it, relates to the people involved and knows the importance of the
detailed practices to go on
 Rationale for incorporating ethnography in the software development
process
 Realization of developers: understanding the domain in which a system is operating
is of tremendous importance
 Software is produced for human beings that have social characters Page 46 of 53
 Ethnography Guidelines
 Assume that people are good at doing their job and look for
nonstandard ways of working (resist on individual
experience)
 Spend time getting to know the people and establish a trust
relationship
 Keep detailed notes of all work practices. Analyze them and
draw conclusions from them
 Combine observation with open-ended interviewing
 Organize regular de-briefing session where the ethnographer
talks with people outside the process
 Integrate other methods to elicit requirements (prototyping)
Page 47 of 53
 Ethnography Guidelines…

 Two phases:
 Analysis: Initial understanding of the system and application
domain
 Focused Ethnography: discover answers from questions which are
raies during prototyping Page 48 of 53
 Ethnography: Pros & Cons
 Advantages
 useful to collects the quality attribute requirements such as
usability and efficiency etc… which are necessary for the success
of the project.
 much effective when to determine the social factors
 Disadvantages
 fails in many cases because there are so much diverse
communities of people belonging to different social and ethical
sects.
 It is difficult to analyze the social requirements of the people and
hence the psychologists are required to provide their

Page 49 of 53
 Domain Analysis
 Domain analysis provides domain knowledge, and
identification of reusable concepts and components.
 It is an earlier eliciting technique which investigates the
thorough domain area by the domain expert.
 These types of investigations are particularly important when
the project involves the replacement or enhancement of an
existing legacy system.
 Domain requirements are fundamental for software reuse and
are the product of domain analysis.
 The domain analysis is so much important and it is usually
found inside the requirement analysis.
Page 50 of 53
Domain Analysis…

The Domain Analysis of SADT diagram

Page 51 of 53
 Domain Analysis: pros & cons
 Advantages
 is useful for eliciting requirements from documents, instruction
manuals of existing systems and other files and forms used in the
current business process.
 used in the conjunction of other elicitation techniques as an input.
 provides the opportunity to reuse specifications and validate new
requirements against other domain instances
 Disadvantages
 quite complex task because it needs to focus on different type of
domains and hence is very much complex technique.
 requires a lot of expertise and skills from diverse fields of software
engineering.
Page 52 of 53
 Selection Criteria
 There numerous elicitation techniques. The choice depends on
 System to be created
 Greenfield Engineering
 Reengineering
 Interface Engineering
 Highly interactive (Cooperation Support System)
 Specific applications like Games
 Budget/Time
 Degree of User Participation
 Time
 Experience of users
 …. (many more)
Page 53 of 53