Requirements Elicitation

Education & Research

1
De 201 / De Bridge - Framework

2
Requirements Elicitation Process
• “The process of identifying needs and bridging the gaps among the involved
communities for the purpose of defining and distilling the requirements to meet
the constraints of these communities”[SEI]

• “The process through which the customers, buyers or users of a software

system discover, reveal, articulate and understand their requirements”

3
Requirements Elicitation in RE

Requirements
Engineering

Requirements Requirements
Development Management

Elicitation Change Control

Analysis Version Control

Specification Requirements Tracking

Verification Status Tracking

4
Outcomes of a good RE
• Helps users explore and fully understand their requirements
• Separation of what they want and what they need
• Understand constraints
• Compare alternatives, technological or procedural in the proposed system
• Understand necessity for trade-offs
• Understand implications of the decisions
• Sense of ownership of products of elicitation process

5
Outcomes of a poor RE process
• More requirement changes, delays or wasted effort in design and
implementation
• Cost and schedule overrun
• Quality issues
• User dissatisfaction
• Loss of reputation or credibility for developers
• Increased maintenance cost

6
Difficulties in RE
• RE is an imprecise and difficult process
• Analyst needs to understand the underlying difficulties and adopt elicitation
techniques to overcome them
• RE issues can be classified into
– User organization issues
– Issues arise due to differing perspectives
– Knowledge and Cognitive limitations

7
Elicitation Issues
• People Related
• Lack of clarity
• Articulation issues
• Indecisiveness
• Personality type
• Apprehension about the change
• Prescriptive approach

• Organization Related
• Complete picture is not with a single person
• Conflicting view points
• Lack of awareness of importance of their involvement
• Internal politics

8
Personality type and communication

Source: Myers-Briggs Type Indicator (MBTI)

Be sensitive to people profile

9
Elicitation Issues
Differing Perspective
• Limited understanding of technology vs limited understanding of domain
• Users concerns being different from that of the developers
– usability and reliability versus resource utilization, algorithms, and
hardware/software constraints
• Cultural differences
• High expectations
– Assumption of user to be a domain expert
– Assumption that developer will ask relevant questions
• Level of detail

10

10
Elicitation Issues
Knowledge and Cognitive Limitations
• Difficulty with scale and complexity
• Possible bias by existing system capability
• Preconceived approach to the solution
• “Tunnel vision'' - focus attention on a few narrow aspects that are understood
best or that affect most directly

11

11
Elicitation – Choice of Techniques
• Study of existing system and documents
• Interviews
• Group meeting/Brainstorming
• JAD Sessions
• Prototyping
• Role playing
• Questionnaire
• Observation

Customize the elicitation technique to suit the context

12

12
Interviewing – Identify who to meet
• Start with person who has authorized or sponsored the project
• Identify everyone who is likely to be impacted by the new system
• Use Org chart to identify reporting structure
• Get concurrence from sponsor for the list of interviewees and subject of
interactions

13

13
Interviewing – Planning and scheduling
• Planning
– Prepare in advance list of questions
– Organize into a logical order
– Decide how much time to devote to each issue
• Scheduling
– Interviews must always be scheduled in advance
– Interviewees should be informed of the topics, goals, length of the interview
– Send relevant materials they may need in order to prepare

14

14
Interviewing – Conducting Interviews
• Types of questions
– Open-ended questions encourage unconstrained answers and can elicit a large
amount of information
– Close-ended questions are useful when you need to get a precise answer
– Avoid the tendency to anticipate an answer
– Put questions in context, avoid switching context too often

15

15
Interviewing – Closure
• Closing the interview involves
– Briefly summarizing the areas that have been discussed
– Highlighting the important facts and your understanding of them
– Highlighting the open issues and any action items from the interviewees

• Follow-up Activities
– Circulate a written summary/minutes including pending issues and further course of
action
– Follow-up on open issues and action items
– Provide clarifications as necessary

16

16
Group meeting/Brainstorming
• Brainstorming is a simple group technique for generating ideas
• Creates atmosphere for informal sharing of ideas
• It avoids the tendency to focus too narrowly too soon
• It stimulates imaginative thinking to help users become aware of their needs
• It helps understand requirements as seen by multiple people
• It helps in prioritization and in building consensus
• Helps people think out-of-the-box

17

17
Brainstorming
• Generation phase
– Participants are encouraged to offer as many ideas as possible, without discussion
of the merits of the ideas
• Consolidation phase
– Ideas are discussed, revised, and organized

18

18
Questionnaires
• State objective in the pre-amble
• Ensure questions are context-free and un-ambiguous
• Have clear purpose when you seek information
• Expect delays in response and plan accordingly

19

19
RE – Improving effectiveness
• Listen actively
• Be objective
• Explain implications of alternatives
• Use concerns raised by users effectively to arrive at scenarios
• Summarize, rephrase to confirm your understanding
• Facilitate, try to get everyone participate in the discussion
• Choose right elicitation technique based on user response
• Be prepared to reschedule if interviewees are unprepared

20

20
Preparation for RE

21
Preparation for RE
• Understanding commitments
– Appreciation of customer business
– Proposal walk-through with DM/CFG
– Fine tune and create execution plan for Requirements phase
• Infrastructure requirements
– Inform customer of office space and workstation needs
– Other hardware/software needs both onsite and offshore
– Choice of tools and templates for RE
– Initiate approval process for offshore procurements
• Team composition
– Phased ramping of RE team
– Balanced team
– Identify need for language experts

22

22
Preparation
• Team orientation
– Project overview
– Project commitments
– Domain appreciation
– Project technology training
– Cross-cultural orientation
– Expectations, Roles and responsibilities
– Orientation on specific process & templates used for RE
• Kick-off meeting with customer
– Prepare presentation
• Project objectives & overview
• Highlight elicitation process
• Introduction of RE team
– Include all customer stakeholders

23

23
Discussion #1
(Identify the issue with these requirement statements)
• “All employees who are 65 or older at the end of year get CPI of $1000”
• “All employees with 10 years or more service at the end of the year receive
CPI of $500”

• Consistency
What about employees who satisfy both the conditions?

24

24
Discussion #2
• “The XYZ System shall provide special medical life-support accommodations for one ill or
injured crew member consisting of medical life-support and monitoring equipment and the
capability of limiting impact accelerations on that crew member to be not greater than… for a
total impulse not to exceed … ”

• Clarity
– The XYZ system shall be used as an ambulance for an ill or injured
crewmember. Only one crewmember shall be accommodated at a time. The
following define the unique requirements for this capability.
– …provide medical life-support accommodations for one crew member
– …provide monitoring equipment for one crew member
– …limit impact accelerations to the ill or injured crew member to no greater
than…
– …limit total impulse to the ill or injured crew member to…

25

25
Discussion #3
• “Automobile should provide for rapid acceleration”

• Ambiguity
– Each requirement should be verifiable
– Avoid ambiguous words
• Minimize / Maximize
• Rapid
• User-friendly
• Easy
• Sufficient
• Adequate
• Quick

26

26
Discussion #4
• “The system shall be accepted if it passes 25 test cases”

• Clarity
– "Test cases" has no standard meaning, so the requirement is meaningless, unless
the term is defined elsewhere. This requirement attempts to set a contractual
standard for the client. It has no place in the requirements for the system.

27

27
Discussion #5
• “For up to 10 aircrafts, a small display format shall be used. Otherwise, a large
display format shall be used.”

• Ambiguity
– For up to 10 … does this mean “for up to including 10th aircraft or excluding it?”
– The results can be potentially disastrous if interpretation is different

28

28
References
• Sridhar Raghavan, Gregory Zelesnik, Gary Ford, 1994: Lecture Notes on
Requirements Elicitation
• Karl E. Wiegers. 1999 Software Requirements
• Alan M. Davis, Software Requirements

29

29
Thank You

30