fundamentals of re - zohoiau-tnb.zohosites.com/files/microsoft powerpoint - slides... ·...
TRANSCRIPT
1www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Fundamentals of REFundamentals of RE
Chapter 2Domain Understanding
& Requirements Elicitation
2www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
start
Chap. Chap. 22::ElicitationElicitationtechniquestechniques
alternative options
agreedrequirements
documented requirements
consolidatedrequirements
Chap.1: RE products and processes
3www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
A great deal of knowledge acquisitionknowledge acquisition is involved:as introduced in Chapter 1 ...
Studying the system-asas--isis– Business organization (knowledge about organization):
structure, dependencies, strategic objectives, policies,workflows, operational procedures, ...
– Application domain (kowledge about the domain in which theproblem world is rooted): concepts, objectives, tasks,constraints, regulations, ...
– Analysis of problems with system-as-is: the actors andresources involved, task and workflows, problem raised in thiscontext, symptoms, causes, consequences
4www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
A great deal of knowledge acquisitionknowledge acquisition is involved:as introduced in Chapter 1 ...
Analyzing technology opportunities, new market conditions Identifying the system stakeholdersstakeholders Identifying improvement objectivesobjectives; organizational &
technical constraintsconstraints on system-to-be; alternativealternative optionsoptionsfor satisfying objectives, for assigning responsibilities;scenariosscenarios of hypothetical software-environment interaction;requirementsrequirements on software, assumptionsassumptions on environment
5www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Domain analysis & requirements elicitation:outline
Identifying stakeholders & interacting with them Domain understanding and requirements elicitation combines differentdifferent
techniquestechniques:
ArtifactArtifact--drivendriven elicitation techniques: rely on specific types of
artifact to support the elicitation process– Background study– Data collection, questionnaires– Repertory grids, card sorts for concept acquisition– Scenarios, storyboards for problem world exploration– Prototypes, mock-ups for early feedback– Knowledge reuse: domain-independent, domain-specificStakeholderStakeholder--drivendriven elicitation techniques: rely on specific types ofinteraction with stakeholders– Interviews– Observation and ethnographic studies– Group sessions
6www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Domain analysis & requirements elicitation:outline
Identifying stakeholders & interacting with them
artifact-driven elicitation techniques– Background study– Data collection, questionnaires– Repertory grids, card sorts for concept acquisition– Scenarios, storyboards for problem world exploration– Prototypes, mock-ups for early feedback – Knowledge reuse: domain-independent, domain-specific
Stakeholder-driven elicitation techniques– Interviews– Observation and ethnographic studies– Group sessions
7www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Stakeholder analysis: prerequisite step Stakeholder cooperation is essential for successful RE
– Elicitation = cooperative learning
RepresentativeRepresentative samplesample ofof stakeholderstakeholder must be selected toensure adequate, comprehensive coverage of the problemworld– dynamic selection as new knowledge is acquired
Selection based on following criteria...– relevant position in the organization– role in making decisions, reaching agreement– type of contributed knowledge, level of domain expertise– exposure to perceived problems– personal interests, potential conflicts– influence in system acceptance
8www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Knowledge acquisition from stakeholders is difficult(1)
DistributedDistributed sources, conflicting conflicting viewpoints
-Many sources from multiple stakeholders should beconsidered-Such sources are often spread out-Conflicts may rises based on variety reason: competitionamong departments, outdated document, differentpriorities,…
Difficult access Difficult access to key people & data
- key people are generally very busy- They may not be convinced that it is worth spending time on the elicitation process
Different background, terminology, culturebackground, terminology, culture
9www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Knowledge acquisition from stakeholders is difficult(2)
TacitTacit knowledge, hidden needs
-Stakeholders assumeassume thatthat wewe knowknow the details orconnections among particular elements-People involved in routine tasks may havehave aa hardhard timetimeexplainingexplaining thingsthings from a distance-Often dodo notnot knowknow whatwhat theythey wantwant and hard to explain-…
Irrelevant details
Internal politics, competition, resistance to change, ...
Unstable conditions: Personnel turnover, changes inorganization, in priorities, …
10www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Knowledge acquisition from stakeholders is difficult(3)
NeededNeeded:–– CommunicationCommunication skillsskills: for talking to, listening from
diverse people– Trust relationship–– KnowledgeKnowledge reformulationreformulation && restructuringrestructuring (review
meetings at appropriate milestones during the elicitationprocess in order to redirect it if necessary)
11www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Domain analysis & requirements elicitation:outline
Identifying stakeholders & interacting with them
artifact-driven elicitation techniques– Background study– Data collection, questionnaires– Repertory grids, card sorts for concept acquisition– Scenarios, storyboards for problem world exploration– Prototypes, mock-ups for early feedback – Knowledge reuse: domain-independent, domain-specific
Stakeholder-driven elicitation techniques– Interviews– Observation and ethnographic studies– Group sessions
12www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Artifact-driven: Background study Collect, read, synthesize documents about...
– the organizationorganization: organizational charts, business plans,financial reports, meeting minutes, etc
– the domaindomain: books, surveys, articles, regulations, reportson similar systems in the same domain
– the systemsystem--asas--isis: documented workflows, procedures,business rules; exchanged documents; defect/complaintreports, change requests, etc.
Provides basics for getting prepared before meetingstakeholders =>=> prerequisite to other techniques
Data mining problem in this technique: huge documentation,irrelevant details, outdated info
Solution: use meta-knowledge to prune the doc space– know what you need to know & what you don’t need to know
13www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Artifact-driven: Data collection Gather undocumented facts & figures (e.g., relevant facts and
figures that are not explicitly available in documents)– marketing data, usage statistics, performance figures,
costs, ...– by designed experiments or selection of representative
data sets from available sources (use of statistical samplingtechniques)
May complement background study
Helpful for eliciting non-functional reqs on performance,usability, cost etc.
Difficulties:– Getting reliable data may take time– Data must be correctly interpreted
14www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Artifact-driven: Questionnaires
Submit a list of questions to selected stakeholders, each witha list of possible answers (+ brief context if needed)
–– MultipleMultiple choicechoice question: one answer to be selected fromanswer list
–– WeightingWeighting question: list of statements to be weighted...• qualitatively (‘high’, ‘low”, ...), or• quantitatively (percentages)to express perceived importance, preference, risk etc.
Effective for acquiring subjective info quickly, cheaply,remotely from many people
Helpful for preparing better focussed interviews (see next)
15www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Questionnaires should be carefully prepared
Subject to ...– multiple biasesbiases: recipients, respondents, questions, answers– unreliable info: misinterpretation of questions, of answers,
inconsistent answers, ....
16www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Artifact-driven: Card sorts & repertory grids(1)
GoalGoal: acquire further info about concepts already elicited tocharacterize these concepts for categorize them
CardCard sortsort: ask stakeholders to partition a set of cards ...–– EachEach cardcard capturescaptures aa conceptconcept textually or graphically– Cards groupedgrouped intointo subsetssubsets based on stakeholder’s criteria– For each subset, ask...
? implicit shared property used for grouping (reason ofgrouping the cards together ?
? descriptive, prescriptive ? (to be considered it as acandidate domain property or requirement)
– Iterate with same cards for new groupings/properties (tohave more reasons for grouping the same cards)
17www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Artifact-driven: Card sorts & repertory grids (2)
Example: meeting scheduling system– Iteration 1 (first reason): “Meeting”, “Participant” grouped
together
reason => “participants shall be invited to the meeting”-prescriptive
– Iteration 2 (another reason): “Meeting”, “Participant”grouped together
reason => “participant constraints for the meeting must beknown”- ”-prescriptive
18www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Artifact-driven: Card sorts & repertory grids
RepertoryRepertory gridgrid: ask stakeholders to characterizecharacterize targettargetconceptconcept throughthrough attributes and value ranges=> concept-attribute grid- have both (attribute ,value range)e.g. (Date, Mon-Fri), (Location, Europe)
for grid characterizing Meeting concept
ConceptualConceptual ladderingladdering: ask stakeholders to classifyclassify targettargetconceptsconcepts along class-subclass linkse.g. subclasses RegularMeeting, OccasionalMeeting of Meeting
Simple, cheap, easy-to-use techniques for prompt elicitation ofmissing info
Results may be subjective, irrelevant, inaccurate
19www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Artifact-driven: Scenarios & storyboards GoalGoal: acquire or validate info from concrete examples through
narratives ...– how things are running in the system-as-is– how things should be running in the system-to-be
StoryboardStoryboard: tells a story by a sequence of snapshots– Snapshot = sentence, sketch, slide, picture, etc.– Possibly more structured with annotations:
WHO are the players, WHAT happens to them, WHY thishappens, WHAT IF this does / does not happen, etc
–– PassivePassive mode (for validation): stakeholders are told the story
–– ActiveActive mode (for joint exploration): stakeholders contributeto the story
20www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Scenarios
Illustrate typical sequences of interaction among systemcomponents to meet an implicit objective
A structured form of storyboard covering who, what and howdimentions
Widely used for...–– explanationexplanation of system-as-is through concrete example of real-
life interaction sequence–– explorationexploration of system-to-be + elicitation of further info ...
e.g. WHY this interaction sequence ?WHY among these components ?
– specification of acceptance test cases
Represented by text or diagram
21www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Scenario example: meeting scheduling in the system-to-be involve following interactions between a meeting initiator, the
software scheduler and meeting participants1. The initiatorinitiator asks the schedulerscheduler for planning a meeting within some
date range. The request includes a list of desired participants.2. The schedulerscheduler checks that the initiator is entitled to do so and that
the request is valid. It confirms to the initiatorinitiator that the requestedmeeting is initiated.
3. The schedulerscheduler asks all participantparticipants in the submitted list to sendtheir date and location constraints back within the prescribed daterange.
4. When a participantparticipant returns her constraints, the schedulerscheduler validatesthem (e.g., with respect to the prescribed date range). ItIt confirmsto the participantparticipant that the constraints have been safely received.
5. Once all valid constraints are received, the schedulerscheduler determines ameeting date and location that fit them.
6. The schedulerscheduler notifies the scheduled meeting date and location tothe initiatorinitiator and to all invited participantparticipants
22www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Types of scenario PositivePositive scenario = one behavior the system should cover
(example) NegativeNegative scenario = one behavior the system should exclude
(counter-example), e.g.1. A participant returns a list of constraints covering all dates
within the given date range2. The scheduler forwards this message to all participants asking
them for alternative constraints within extended date rangeNot to be disclosed to others
NormalNormal scenario: everything proceeds as expected AbnormalAbnormal scenario = a desired interaction sequence in
exception situation (still positive)e.g. meeting initiator not authorized
participant constraints not valid
23www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Scenarios: pros & cons (1)
Concrete examples/counter-examples Narrative style (appealing to stakeholders)
Usage extends beyond the elicitation phase: As animationsequences when we validate requirements, As counterexamples when verify behavioral requirements, As test caseswhen we define acceptance test from the requirements
Inherently partial (cf. test coverage problem)- they do not coverall possible system behaviors under all possible circumstances
24www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Scenarios: pros & cons (2)
Combinatorial explosion (cf. program traces)- becausecomprehensive set of scenarios requires us to enumerate multiplecombinations of individual component behaviors
Potential overspecification: unnecessary sequencing ofsome interactions
premature software-environment boundary because ofthe allocation of responsibilities among interactingcomponents might be premature
May contain irrelevant details,incompatible granularities from different stakeholders
25www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Scenarios: pros & cons (3)
Keep requirements implicit: means capture interactionsequence, but not the reasons why such sequences shouldor should not take place[that is ; the requirementunderlying them]we need explicit requirements to support negotiation,analysis, implementation and evolution
cf. confidentiality req in negative scenario exampleConcrete scenarios naturally jump in anyway...invaluable as initial elicitation vehicles
26www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Artifact-driven: Prototypes & mock-ups
GoalGoal: check req adequacy from direct user feedback, by showingreduced sketch of software-to-be in action
PrototypePrototype = quick implementation of some aspects of the system-to-be..–– FunctionalFunctional prototype: focus on specific functional reqs
e.g. initiating meeting, gathering participant constraints–– UserUser interfaceinterface prototype: focus on usability by showing input-
output forms, dialog patterns between SW and userse.g. static/dynamic interaction to get participant constraints
The focus in general is on requirements that are unclear, hard toformulate or hard to understand
Quick implementation: by use of very high-level programminglanguage, executable spec language, generic services, ...
27www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Requirements prototyping
MockMock--upup: proto is thrown away (product = adequate reqs)
Evolutionary protoEvolutionary proto: transformed towards efficient code
Elaboraterequirements
Prototyperequirements
Demonstrate proto& get feedback
[ Proto_OK ][ Proto_OK ]
[[ notnot Proto_OK ]Proto_OK ]
…
28www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Prototypes & mock-ups: pros & cons
Concrete flavor of what the software will look like=> clarify reqs, elicit hidden ones, improve adequacy,
understand implications, ... Other uses: user training,...
Does not cover all aspects– missing functionalities– ignores important non-functional reqs (performance, cost, ...)
Can be misleading, set expectations too high
‘Quick-and-dirty’ code, hard to reuse for sw development
Potential inconsistencies between modified code anddocumented reqs which results to decrease the confidence inthe results
29www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Artifact-driven: Knowledge reuse GoalGoal: speed up elicitation by reuse of knowledge from
experience with related systems– knowledge about similar organization, domain, problem world:
requirements, assumptions, dom props, ...
Reuse-based parts of the process combine the following steps:1. RETRIEVERETRIEVE relevant knowledge from other systems2. TRANSPOSETRANSPOSE it to the target system3. VALIDATEVALIDATE the result, ADAPTADAPT it if necessary & INTEGRATEINTEGRATE it
with the system knowledge already acquired
Transposition mechanisms:–– instantiationinstantiation (memberOf)–– specializationspecialization (subClassOf) + feature inheritance–– reformulationreformulation in vocabulary of target system
30www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Artifact-driven: Knowledge reuse
Two different types of reuse can be introduced based onwhether
the reused knowledge is domain independent or
the reused knowledge is domain specific
31www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Reuse of domain-independent knowledge
Consider the requirement taxonomy
Reuse of a meta-model
32www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Reuse of domain-independent knowledge:requirements taxonomies
For each leaf node in available req taxonomies: “Is there any system-specific req instance from this class?”
More specific taxonomy => more focussed search
ThroughputResponseTimeSecondaryStorage
MainStorage
Performance Requirement
TimeSpace
PeakThroughputOffPeakThroughput
PeakMeanThroughput PeakUniformThroughput
Reusable catalogue in(Chung et al 2000)
mean number of meetings tobe scheduled at peak times ?
response time for ...participant constraints ?meeting scheduling ?meeting notification ?
33www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Reuse of domain-independent knowledge:RD meta-model
RDRD metameta--modelmodel = concepts & relationships in terms of whichRD items are captured
We acquiring knowledge about the organization or about thetarget system (e.g., RD items) as instantiation of elements ofthe meta-model according to which the organization or systemis modeled
It help to figure out what questions to ask and when
Elicitation by meta-model traversal
34www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Reuse of domain-independent knowledge:RD meta-model
If organization is modeled in terms of actors, resources anddependencies, the meta-model contain meta-classes: Actor,Task, Resource and Dependency
If organization is modeled in terms of goal, objects, agentsand operations, the meta-model contain meta-classes: Goal,Object, Agent and Operation
GoalReference Responsibility Performance
Instantiation
Agent OperationObject
BookCopy BorrowedCopiesReturnedOnTime
Patron CheckOut
Meta level
System level
35www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Reuse of domain-specific knowledge(1)
AbstractAbstract domaindomain = concepts, tasks, actors, objectives, reqs,dom props abstracting from a class of domains
RD items acquired as specializationsspecializations of abstract items totarget system (feature inheritance + system-specific renaming)
36www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Reuse of domain-specific knowledge(2)
E.x.. TargetTarget systemsystem: library management
DomainDomain: resource management
Abstract elements:
37www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Reuse of domain-specific knowledge(3)
E.x Specialize abstract elements such as:
into the notation of:
38www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Reuse of domain-specific knowledge(4)
LimitedUse
Specialization
User GetUnitResource
Book LimitedLoans
Patron BorrowCopy
Abstract domainConcrete domain
“A useruser may not useuse more than X resourceresource unitsunits at a time”
“A patronpatron may not loanloan more than X book copiesbook copies at a time”
Spec inheritance
39www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Reuse of domain-specific knowledge (5)
Same abstract domain may have multiple specializationse.g. resource management <-- library loan management,
videostore management, flight or concert seat allocation, ...
Same concrete domain may specialize multiple abstract domainse.g. library management (has three parts):
loan management --> resource managementbook acquisition --> e-shoppingpatron registration --> group membership management
40www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Reuse of domain-specific knowledge (6)
To increase the adequacy of reused knowledge, the abstractdomain should be made more structured and more accurate;
e.g. resource management is structured in terms of multiplespecializations of the resource concept:
returnable vs. consumable resource(distinguish between these two concept)
sharable vs. non-sharable resource(distinguish between these two concepts)
=> “A book copy can be borrowed by one patron at a time”(domain prop for non-sharable, returnable resource)
41www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Knowledge reuse: pros & cons
Expert analysts naturally reusereuse fromfrom pastpast experienceexperience
SignificantSignificant guidanceguidance and reductionreduction of elicitation effortsefforts
InheritanceInheritance ofof structurestructure && qualityquality ofof abstractabstract domaindomain spec
Effective for completingcompleting RD with overlooked aspects
Effective only ifif abstractabstract domaindomain sufficientlysufficiently “close“close”,
accurate
DefiningDefining abstractabstract domainsdomains for significant reusability is hardhard-specially whenwhen domaindomain isis complexcomplex
Validation & integration efforts
NearNear--matchesmatches may require trickytricky adaptationsadaptations
42www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Domain analysis & requirements elicitation:outline
Identifying stakeholders & interacting with them
artifact-driven elicitation techniques– Background study– Data collection, questionnaires– Repertory grids, card sorts for concept acquisition– Scenarios, storyboards for problem world exploration– Prototypes, mock-ups for early feedback – Knowledge reuse: domain-independent, domain-specific
Stakeholder-driven elicitation techniques– Interviews– Observation and ethnographic studies– Group sessions
43www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
stakeholders-driven: Interviews Primary technique for knowledge elicitation
1. SelectSelect stakeholderstakeholder specifically for info to be acquired(domain expert, manager, salesperson, end-user, consultant, ...)
2. OrganizeOrganize meeting with interviewee, askask questions, recordrecordanswers
3. WriteWrite reportreport from interview transcripts
4. SubmitSubmit reportreport to interviewee for validationvalidation && refinementrefinement
Single interview may involve multiple stakeholders saves times weaker contact; individuals less involved, speak less freely
Interview effectivenesseffectiveness:(utility x coverage of acquired info) / acquisition time
44www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Types of interview
StructuredStructured interview: predetermined set of questions– specific to purpose of interview– some open-ended, others with pre-determined answer set=> more focused discussion, no rambling among topics
UnstructuredUnstructured interview: no predetermined set of questions– free discussion about system-as-is, perceived problems,
proposed solutions=> exploration of possibly overlooked issues
=>=> Effective interviews should mix both modes ...– start with structured parts– shift to unstructured parts as felt necessary
45www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Interviews: strengths & difficulties
May revealreveal infoinfo notnot acquiredacquired throughthrough otherother techniquestechniques– how things are running really, personal complaints,
suggestions for improvement, ...
On-the-fly acquisition of informationinformation appearingappearing relevant– new questions triggered from previous answers
Acquired infoinfo might be subjectivesubjective (hard to assess)
Potential inconsistencies between different interviewees EffectivenessEffectiveness critically reliesrelies onon interviewer’sinterviewer’s attitudeattitude,
appropriatenessappropriateness ofof questionsquestions
46www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
stakeholders-driven: Observation & ethnographic studies
Focus on tasktask elicitation in the systemsystem--asas--isis
Understanding a task is often easier by observing people performing it(rather than verbal or textual explanation)– cf. tying shoelaces
PassivePassive observation: no interference with task performers– Watch from outside, record (notes, video), edit transcripts,
interpret–– ProtocolProtocol analysisanalysis: task performers concurrently explain it–– EthnographicEthnographic studiesstudies: over long periods of time, try to discover
emergent properties of social group involvedabout task performance + attitudes, reactions in specific
situation, gestures, ... ActiveActive observation: you get involved in the task, even become a team
member
47www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Observation & ethnographic studies: pros & cons (1)
May reveal ...–– tacittacit knowledgeknowledge that would not emerge otherwise
e.g. ethnographic study of air traffic control => to reveal animplicit model of air traffic that an automated version of thesystem needed to preserve. On the other word to analyze howcontrollers handle paper strips representing flight plans
– hidden problems through tricky ways of doing things– culture-specific aspects to be taken into account
Contextualization of acquired info
Slow & expensive: to be done over long periods of time, atdifferent times, under different workload conditions
48www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Observation & ethnographic studies: pros & cons (2)
Data mining problem, interpretationinterpretation problemproblem Potentially inaccurateinaccurate (people behave differently when
observed) FocusFocus on systemsystem--asas--isis
Some of the interviewing guidelines are relevant
49www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Group sessions More perception, judgment, invention from interactions within
group of diverse people
Elicitation takes place in series of group workshops (a fewdays each) + follow-up actionsaudiovisuals, wall charts to foster discussion, record outcome
StructuredStructured group sessions:– Each participant has a clearlyclearly defineddefined rolerole
(leader, moderator, manager, user, developer, ...)–– ContributesContributes toto reqreq elaborationelaboration according to his/her role,
towards reaching synergies– Generally focusedfocused onon highhigh--levellevel reqsreqs– Variants: focus groups, JAD,(Joint Application
Development), QFD (Quality Function Development), ...
50www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Group sessions (2)
UnstructuredUnstructured group sessions (brainstorming): – Participants have a less clearly defined roleless clearly defined role– Two separate stages ...
1. Idea generationIdea generation to address a problem: as many ideas as possiblefrom each participantwithout censorship/criticism
2. Idea evaluationIdea evaluation: by all participants togetheraccording to agreed criteria (e.g. value, cost, feasibility)to prioritize ideas
51www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Group sessions: pros & cons Less formal interactions Less formal interactions than interviews
=> may reveal hidden aspects of the system (as-is or to-be)
Potentially ...–– wider exploration wider exploration of issues & ideas–– more inventive more inventive ways of addressing problems
SynergiesSynergies => agreed conflict resolutions
Group composition is critical Group composition is critical ...– time consuming for key, busy people– heavily relying on leader expertise & skills– group dynamics, dominant persons => biases, inadequacies
Risk of Risk of ...– missing focus & structure => rambling discussions, little
concrete outcome, waste of time– superficial coverage of more technical issues
52www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Combining techniques
Elicitation techniques have complementary strengths &limitations
Strength-based combinations are more effective for full,adequate coverage– artifact-driven + stakeholder-driven
Examples–– ContextualContextual InquiryInquiry : workplace observation + open-ended
interviews + prototyping–– RADRAD: JAD group sessions + evolutionary prototyping (with
code generation tools)
Techniques from other RE phases support elicitation too– Resolution of conflicts, risks, omissions, etc.
53www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons
Domain analysis & requirements elicitation:summary
Identifying the right stakeholders, interacting the right way artifact-driven elicitation techniques
– Background study as a prerequisite– Data collection, questionnaires for preparing interviews– Repertory grids, card sorts for concept characterization– Scenarios, storyboards for concrete exploration– Prototypes, mock-ups for early feedback & adequacy check – Knowledge reuse brings a lot: domain-independent, domain-specific
Stakeholder-driven elicitation techniques– Interviews are essential - structured, unstructured, cf. guidelines– Observation, ethnographic studies for hidden knowledge– Group sessions for broader, more inventive acquisition & agreement
Model-driven elicitation provides focus & structure for what needs to be elicited