5 requirementselicitation
Post on 06-Apr-2018
224 Views
Preview:
TRANSCRIPT
-
8/2/2019 5 RequirementsElicitation
1/30
Page 1
ENGR2720U
ENGR2720
Software Design II
Notes taken from Requirements Engineering for SoftwareSystems, P.A. Laplante
Requirements Elicitation
Techniques
-
8/2/2019 5 RequirementsElicitation
2/30
Page 2
ENGR2720U
Background
In this lecture I will present several different techniques for solicitingrequirements. Which include:
BrainstormingCard SortingDesigner as Apprentice
Domain AnalysisEthnographic ObservationGoal-based ApproachesGroup WorkInterviewsIntrospection
Joint Application Development(JAD)
LadderingProtocol AnalysisPrototyping
Quality Function Deployment(QFD)QuestionnairesRepertory GridsScenariosTask Analysis
User StoriesViewpoints
-
8/2/2019 5 RequirementsElicitation
3/30
Page 3
ENGR2720U
Brainstorming
Informal sessions with Stakeholders togenerating overarching goals for the system.
Meetings can be formal but formality is inversely
related to creativity level exhibited at themeeting.
Prefer informal over formal but use a recorder.
The outcome may be some preliminaryrequirements but it is primarily a way to get newideas into the process.
Good for general objectives such as mission or vision
statements.
-
8/2/2019 5 RequirementsElicitation
4/30
Page 4
ENGR2720U
Card Sorting
Stakeholders complete a set of cards that includes keyinformation about functionality for the system/softwareproduct.
Include ranking and rationale for each of the functionalities.
It is recommended that a minimum of 1 week and nomore that 2 be given to complete the cards.
Requirements engineer sorts the cards based on groupsof requirements types.
These cards can also be used to as an input to the process CRC(capability, responsibility, class) that is used to develop classesfrom the requirements.
Customer can be shown the sorted cards forcorrection or missing features.
-
8/2/2019 5 RequirementsElicitation
5/30
Page 5
ENGR2720U
Designer as Apprentice
Designer Engineer looks over the shoulder of thecustomer to basically learn what the software might do.
Customers do not have to have any form of teachingability since many persons can easily talk about what
they are doing as it unfolds.Seeing the work reveals what matters.
Some actions occur because of years of experience and thecustomer cannot recollect easily when interviewed.
In order for this to work the SE must understand thestructure and implication of the work.
The designer must demonstrate an understanding of thework to the customers so that any misunderstandingscan be corrected.
-
8/2/2019 5 RequirementsElicitation
6/30
Page 6
ENGR2720U
Domain Analysis
Basically this point emphasizes that domainanalysis is key for the developer.
-
8/2/2019 5 RequirementsElicitation
7/30Page 7
ENGR2720U
Ethnographic Observation
Any technique in which observation of indirect and directfactors inform the work of the requirements engineer.
Comes from the Social Science domain in whichobservations of human activity and the environment inwhich the occurs are used to inform the scientist in thestudy of some phenomenon.
This can be done in an active way like Designer asApprentice or passive where the SE simply observes.
It is time-consuming and takes some training to do.
It is subject to the Heisenberg uncertainty principle. When you observe something you cause a change in the environment.
-
8/2/2019 5 RequirementsElicitation
8/30Page 8
ENGR2720U
Goal-Based Approaches
Requirements are recognized to emanate from themission statement, through a set of goals that lead torequirements.
Look at the mission statement and extract goals, and
finally lower-level goals that lead to specific high-levelrequirements.
Take a goal and
Derive from it what questions must be answered to determine if
they are being met. Decide what must be measured in order to be able to answer the
question.
Sometimes it is not easy to determine the appropriatequestion for some goal.
-
8/2/2019 5 RequirementsElicitation
9/30Page 9
ENGR2720U
Group Work
The most celebrated group-oriented work for requirements discoveryis Joint Application Design (JAD).
Important group meeting guidelines:
Research all aspects of the organization, problems, politics,environment, and so on.
Publish an agenda.
Stay on the agenda.
Have a dedicated note taker.
Do not allow personal issues to creep in.
Allow all to have their voices heard.
Look for a consensus at the earliest opportunity
Do not leave until all items on the agenda have received sufficientdiscussion.
Publish the minutes of the meeting within a couple of days and allow forchanges.
-
8/2/2019 5 RequirementsElicitation
10/30Page 10
ENGR2720U
Interviews
Opposite of group activities, a one to oneinterview.
There are 3 kinds of interviews:
Unstructured Conversational in nature, but can be hit or miss.
Structured
More formal, pre-defined questions and templates used.
Problems are that some customers might withholdinformation because format is too stodgy
Semi-structured
Preferred approach. Carefully thought out questions areprepared but the choice of which one to use is opportunistic.
-
8/2/2019 5 RequirementsElicitation
11/30Page 11
ENGR2720U
Interviews Examples of Questions
Name an essential feature of the system? Whyis this feature important?
On a scale of 1 to 5, how would you rate this
feature?How important is this feature with respect toother features?
What other features are dependant on thisfeature?
What other observations can you make aboutthis feature?
-
8/2/2019 5 RequirementsElicitation
12/30Page 12
ENGR2720U
Introspection
This is an important process that is even usedfor software development.
When a SE develops requirements based on he
thinks this is called introspection.Used when the SEs domain knowledge far
exceeds the customers.
Customer might ask the engineer If you were me
what would you want?
Dont tell a customer what they want!!
-
8/2/2019 5 RequirementsElicitation
13/30Page 13
ENGR2720U
Joint Application Design (JAD)
Involves highly structured group meetings with system users,system owners, and analysts at the same time for extended periodsof time.
4-8 hours a day over a couple of weeks.
Code for group consensus because all the stakeholders are at the
table.Steps:
Select participants
Preparing the agenda
Selecting the location
Stakeholder groups elect a leader to attend the meeting
Before planning a session the SE must determine the scope of theproject and set the high-level requirements.
Agenda code and documentation must be sent to participants in
plenty of time to review before the meeting.
-
8/2/2019 5 RequirementsElicitation
14/30Page 14
ENGR2720U
Joint Application Design (JAD) - Rules
Stick to the agenda
Stay on Schedule
Ensure the scribe can take notes
Avoid technical jargon
Resolve conflicts
Encourage group consensus
Encourage participation
Keep the meeting impersonal
Allow meetings to take as long as necessary.
-
8/2/2019 5 RequirementsElicitation
15/30Page 15
ENGR2720U
Laddering
The SE asks the customer short prompting questions(probes) to elicit requirements.
Follow questions are then used to dig deeper into therequirement.
Example: SE: Name a key feature of the system?
Customer: Customer identification.
SE: How do you identify a customer?
Customer: They can swipe their loyalty card
SE: What if a customer forgets their card?
Customer: They can be looked up by phone number
SE: When do you get the customers phone number?
Customer: ..
-
8/2/2019 5 RequirementsElicitation
16/30Page 16
ENGR2720U
Protocol Analysis
SE and customers walk through the proceduresthat they are going to automate.
Customer explicitly state the rationale for each
step that is being taken.Very similar to Design as Apprentice except thatSE is more passive.
-
8/2/2019 5 RequirementsElicitation
17/30Page 17
ENGR2720U
Prototyping
This involves constructing a model of the system that are eitherworking or non-working.
Working models have executable code while non-working models arelike story boards and mock-ups of user interfaces.
In general user interface prototypes can be re-used in the designand most agile developers use this technique.
This is also the technique used for the spiral development processwhere incremental parts of the system are designed, tested, anddelivered
Neil and Laplante 2003 Survey
60% of respondents used prototyping for requirements gathering. 40% Interfacing
27% Evolutionary
14% Throw away
-
8/2/2019 5 RequirementsElicitation
18/30Page 18
ENGR2720U
Quality Function Deployment
Technique that helps determine quality assurance pointsto be used throughout the production phase. Also knownas house of quality that is taught here to Mechanical
Engineers.
Construct relationship matrices between customerneeds, technical requirements, priorities, and competitorassessment.
Incorporates card sorting, laddering, and domain analysis.
Quality function deployment is a process of listening tothe voice of the customer, identifying the customers
needs, and incorporating those needs in the design andproduction of goods and services [Madu, 1999].
-
8/2/2019 5 RequirementsElicitation
19/30
Page 19
ENGR2720U
House of Quality (Akao 1990)
The HOQ is broken into 6steps shown at right.
Customer Requirements
Planning Rankingrequirements
Technical RequirementsQuantifying requirements
Interrelationships used togenerate consensus betweendevelopment team and
customers
Roof - Considers impact oftechnical requirements on eachother.
Targets Draw conclusions.
6. Targets6. Targets
4. Inter-
relationships
4. Inter-
relationships
2.
PlanningMatrix
1.
Customer
Requirements
3. Technical
Requirements
3. Technical
Requirements
5. Roof5. Roof
-
8/2/2019 5 RequirementsElicitation
20/30
Page 20
ENGR2720U
House of Quality Pros and Cons
Pros Involves the involvement of users and managers.
Shortens development lifecycle and improves overall projectdevelopment.
Supports team involvement.
Provides a preventative tool that avoids the loss of information.
Cons
Difficult to express temporal requirements.
Difficult to use with an entirely new project type.
Hard to find measurements for certain functions and keep thelevel of abstraction uniform.
The less we know the less we document
As the features grow the house of quality becomes a mansion.
-
8/2/2019 5 RequirementsElicitation
21/30
Page 21
ENGR2720U
Questionnaires
Good for large group of Stakeholders.
Used in the early stages of the elicitationprocess to quickly define the scope boundaries.
Questions can be closed (only certain choices)or open (text).
There is the danger of under or over scoping
based on the questions. Better when the domain is very well understood.
-
8/2/2019 5 RequirementsElicitation
22/30
Page 22
ENGR2720U
Repertory Grids
These are grids that incorporate a structured ranking system for variousfeatures of the different entities in the system.
Used when the customers are domain experts.
Rows System entities
Cols Rankings
Very much like a quality matrix that we will see later.
Baggage handling speed 1 1 5
Fault tolerance 4 5 5
Safety 5 4 4
Reliability 3 5 5
Ease of maintenance 3 5 5
Airline workers union repMaintenance engineer
Airport operations manager
-
8/2/2019 5 RequirementsElicitation
23/30
Page 23
ENGR2720U
Scenarios
Informal descriptions of the system that providea high-level description of system operations,classes of users, and exceptional situations.
We will see later that scenarios can be definedfrom Use Cases.
Useful when the domain is novel. User storiesare a form of scenario.
-
8/2/2019 5 RequirementsElicitation
24/30
Page 24
ENGR2720U
Task Analysis
A hierarchical oriented technique that involves afunctional decomposition of tasks to beperformed by the system.
This is very typical way of detailingrequirements.
The detailing continues until a single task is achieved.
-
8/2/2019 5 RequirementsElicitation
25/30
Page 25
ENGR2720U
User Stories
User stories are similar to scenarios except thatthey are written by the customers in terms ofwhat the system needs to do for them.
Consist of 2-4 sentences written on a 3x5 card.
About 80 user stories is said to be appropriatefor one system evolution.
They should only provide enough detail to make
a reasonably low-risk estimate of how long thestory will take to implement.
Later the developers will meet with the story tellers toflesh out the details.
ENGR U
-
8/2/2019 5 RequirementsElicitation
26/30
Page 26
ENGR2720U
Viewpoints
Used to organize information from the point of view of differentStakeholders.
Typically you will quickly see contradictions between theStakeholders.
Components in a viewpoint:
A representation style, which defines the notation used in thespecification.
A domain, which is defined as the area of concern addressed by the
viewpoint
A specification, which is a model of a system expressed in the define
style A work plan with a process model which defines how to build and check
the specification.
A work record, which is a trace of the actions taken in building,checking, and modifying the requirements.
ENGR2720U
-
8/2/2019 5 RequirementsElicitation
27/30
Page 27
ENGR2720U
Combining Elicitation TechniquesTechnique Type Techniques
Domain-oriented Card sortingDesigner in apprenticeDomain analysisLadderingProtocol AnalysisTask Analysis
Ethnography Ethnographic observation
Goals Goal-based approaches
Group work BrainstormingGroup WorkJAD
Interviews InterviewsIntrospectionQuestionnaires
Prototyping Prototyping
Scenarios ScenariosUser stories
Viewpoints ViewpointsRepertory grids
ENGR2720U
-
8/2/2019 5 RequirementsElicitation
28/30
Page 28
ENGR2720U
Techniques for Elicitation Activities
Interviews
D
omain
G
roupwork
E
thnography
P
rototyping
G
oals
S
cenarios
V
iewpoints
Understanding the domain
Identifying sources of requirements
Analyzing the stakeholders
Selecting techniques and approaches
Eliciting the requirements
ENGR2720U
-
8/2/2019 5 RequirementsElicitation
29/30
Page 29
ENGR2720U
Complementary and Alternative Techniques
Interviews
Domain
Groupwork
Ethnograp
hy
Prototypin
g
Goals
Scenarios
Viewpoints
Interviews C A A A C C C
Domain C C A A A A A
Groupwork A C C C C C
Ethnography A A A C C A A
Prototyping A A C C C C C
Goals C A C C C C C
Scenarios C A C A C C A
Viewpoints C A C A C C A
ENGR2720U
-
8/2/2019 5 RequirementsElicitation
30/30
ENGR2720U
Which Techniques are Used
Scenarios / User cases 51%
Focus Groups 38%
Informal modeling 33%
Semi-formal modeling 22%
JAD 20%
User centered diagrams 20%
Interviews 12%Designer as Apprentice 10%
QFD 5%
top related