CPRE-FL Module 3: Eliciting Requirements

Few questions
What are the
sources of
requirements?
What is the
relevance of
requirements
sources?
What is the
consequence of
unconsidered
sources?
What is
requirement?
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/cpre-fl-module-3-eliciting-requirements-2558

Details to document Requirement sources
Requirements engineers should document
requirements sources with following details:
Name
Function/Role
Personal and contact data
Temporal (time) availability
Spatial (location) availability
Relevance of the stakeholder
Area of expertise
Extent of expertise
Goals regarding the project
Interests regarding the project

Stakeholders list
A very useful technique for
stakeholder identification is checklist
Many stakeholders are involved in
complex and “difficult” projects
Due to limited resources,
requirements engineers MUST
carefully select stakeholders most
suitable for requirements elicitation

Obligations and privileges of the
stakeholders
A number of obligations and
privileges result from agreement
with stakeholders
It enables requirements engineer
to:
Speak the language of the
stakeholders
Be able to get work results
across
Become thoroughly familiar with
the application domains
Create requirements
documents
Ensure that the system satisfies the
functional and qualitative demands of
the stakeholders
Maintain respectful
relationships with stakeholders
Present their ideas and alternatives
as well as their realizations
Allow stakeholders to demand
properties that make the system
user-friendly and simple

Few questions
What is a
stakeholder
charter?
Discuss few
stakeholder
rights and duties

Elicitation techniques

Survey Techniques
Survey techniques expect
Stakeholders can express their
requirements
They are ready to invest their time
and effort towards the elicitation

Questionnaires
Can elicit information from many
people in a short period of time
Survey questions are of two types:
Closed ended
Open-ended

Brainstorming
Technique where one or group of
stakeholders deliberate on an idea
The aim is to produce numerous new
ideas in a non-judgmental environment
Moderator documents without discussing,
judging, or commenting on them at first

Change of perspectives/ Six Thinking Hats
(De Bono)
Change of perspective involves participants
adopt different extreme viewpoints
The technique is succeeded because most
people tend to have a dominant trait
This technique allows other perspectives to
emerge

Advantages and disadvantages of Analogy
Technique
Advantages
Complex problems may become
manageable through analogies
Changing the context helps tear
down inhibitions
Experiences and solutions from
other contexts can be used,
Very successful to find creative
solutions
Disadvantages
Participants should be capable of
analogous thinking
Need a lot of time
Should have an in-depth domain
with which an analogy will be drawn
Results produced can lead to
unsuitable solutions

Document-centric techniques Advantages
and Disadvantages
Advantages
Extremely suitable for re-engineering
projects
Can be a good technique to follow
before using other techniques
Can validate requirements elicited
through other techniques
Can identify new requirements
Disadvantages
Documented requirements may be
obsolete

Perspective-based reading
During this, requirements engineers
read documents with a particular
perspective in mind
One can ignore aspects that are
contained in the document but do
not pertain to the current
perspective

Requirements Reuse Advantages and
Disadvantages
Advantages
Reduce requirements work
Re-use saves labor and reduces time
to market
Requirements need not be re-
validated repeatedly
Re-use avoids rework
Disadvantages
Organizations are reluctant to expend
resources to develop reusable
components

Advantages and Disadvantages of
Observation Techniques
Advantages
Can be used when SMEs are not
available to discuss or unable to
express
Observe real processes
Provides an outsider view to identify
process improvements
Helps requirements engineer learn the
domain
Good for identifying dis-satisfiers
Disadvantages
Cant’ be used for future processes
Time consuming
Can be applied for physically visible
processes only

Requirements workshops
Workshops are joint meetings between stakeholders and
requirements engineers to discover requirements
CRC cards
CRC stands for Class Responsibility Collaboration
These are helpful to develop new requirements
Audio and video recordings
Can help to re-wind and observe fast work
processes

Question 1
1. The Kano model describes that dis-satisfiers (basic factors) are
hard to find. What is the best elicitation technique for dis-
satisfiers?
a. Interview
b. Questionnaire
c. Field observation
d. Low-fidelity prototyping

Correct Option for Question 2
B. Wikis are helpful for collaboratively developing
documentation

Question 4
4. What do the following techniques have in common?
1. Perspective-based reading
2. Apprenticing
3. Contextual inquiry
4. System archaeology
a. They are all moderated techniques
b. They are all group-orientated techniques
c. The techniques are applicable when stakeholders show little motivation
d. The techniques are suitable for the identification of stakeholders

D. All other options are correct.

Question 7
7. What are the two basic types of interviewing when eliciting
requirements?
a. Structured and unstructured
b. Top-down and bottom-up
c. Open-ended and closed-ended
d. End user and technical

D. Onion diagram is a useful technique to indicate sphere
of influence for requirements

Question 10
10. What is the primary responsibility of a scribe of
requirements work-shop?
a. Enforcing discipline, structure and ground rules for the
meeting
b. Documenting business requirements in the format
determined prior to the meeting
c. Introducing the goals and agenda for the meeting
d. Ensuring that all stakeholders participate and have their input
heard

1
Flevy (www.flevy.com) is the marketplace
for premium documents. These
documents can range from Business
Frameworks to Financial Models to
PowerPoint Templates.
Flevy was founded under the principle that
companies waste a lot of time and money
recreating the same foundational business
documents. Our vision is for Flevy to
become a comprehensive knowledge base
of business documents. All organizations,
from startups to large enterprises, can use
Flevy— whether it's to jumpstart projects, to
find reference or comparison materials, or
just to learn.
Contact Us
Please contact us with any questions you may have
about our company.
• General Inquiries
support@flevy.com
• Media/PR
press@flevy.com
• Billing
billing@flevy.com

CPRE-FL Module 3: Eliciting Requirements

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Mehr von Flevy.com Best Practices

Mehr von Flevy.com Best Practices (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

CPRE-FL Module 3: Eliciting Requirements