Requirements Elicitation Education & Research
1
De 201 / De Bridge - Framework
2
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
3
Requirements Elicitation in RE Requirements Engineering Requirements
Requirements
Development
Management
Elicitation
Change Control
Analysis
Version Control
Specification
Requirements Tracking
Verification
Status Tracking
4
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
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
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
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
8
Personality type and communication
Source: Myers-Briggs Type Indicator (MBTI)
Be sensitive to people profile
9
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 – – –
•
Infrastructure requirements – – – –
•
Appreciation of customer business Proposal walk-through with DM/CFG Fine tune and create execution plan for Requirements phase 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