Fundamentals of Requirements Engineering
Fundamentals of Requirements Engineering
Chapter 2
Domain Understanding
& Requirements Elicitation
www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons 1
The scope of RE:
the WHY, WHAT, WHO dimensions
System-as-is System-to-be
problems, WHY
Objectives
opportunities, a new system?
system knowledge
satisfy
requirements,
constraints, WHAT
assumptions services?
assignment
WHO
will be
responsible
for what ?
? The WHY dimension
Difficulties
– Identify the right set of features
– Specify these precisely for understanding by all parties
– Ensure backward traceability to system objectives
? The WHO dimension
Assign responsibilities for the objectives, services, constraints
among system-to-be components
– based on their capabilities and on the system’s objectives
– yielding the software-environment boundary
Example: airport train control
– “Safe train acceleration” ... under direct responsibility of
software-to-be (driverless option) or of driver following
software indications ?
– “Accurate estimation of train speed/position” ... under responsibility
of tracking system or of preceding train ?
Difficulties
– Evaluate alternative options to decide on the right degree of
automation
Statements about the System
Descriptive statements state system properties holding
regardless of how the system should behave (indicative mood)
– natural law, physical constraint, etc
– e.g. “If train doors are closed, they are not open”
“If the train’s acceleration is positive, its speed is non-null”
trainSpeed measuredSpeed
M: monitored variables I: input data
Environment SoftwareToBe
DoorsClosed doorsState
C: controlled variables O: output results
alternative proposals
domain understanding
& elicitation
start
Domain understanding
alternative proposals
start agreed
requirements
The RE process (3)
alternative proposals
start
agreed
requirements
specification
& documentation
documented requirements
Specification & documentation
alternative proposals
start
consolidated agreed
requirements requirements
validation specification
documented requirements
Requirements consolidation
Products: Consolidated RD
Acceptance test data, prototype
Development plan
Project contract
Target qualities for RE process
Completeness of objectives, requirements, assumptions
Consistency of RD items
Adequacy of requirements, assumptions, domain props
Unambiguity of RD items
Measurability of requirements, assumptions
Pertinence of requirements, assumptions
Feasibility of requirements
Comprehensibility of RD items
Good structuring of the RD
Modifiability of RD items
Traceability of RD items
Types of RE errors & flaws: a wide palette
Chap. 2:
Elicitation
techniques
documented requirements
www.wileyeurope .com/college/van lamsweerde Chap.2: Domain Understanding & RE © 2009 John Wiley and Sons 25
RE has multiple connections with other disciplines
J Concrete examples/counter-examples
J Narrative style (appealing to stakeholders)
J Yield animation sequences, acceptance test cases
L Inherently partial (cf. test coverage problem)
L Combinatorial explosion (cf. program traces)
L Potential overspecification: unnecessary sequencing,
premature software-environment boundary
L May contain irrelevant details,
incompatible granularities from different stakeholders
L Keep requirements implicit
cf. confidentiality req in negative scenario example
Concrete scenarios naturally jump in anyway...
invaluable as initial elicitation vehicles
Prototypes & mock-ups
Elaborate Prototype
requirements requirements
Demonstrate proto
& get feedback
[ not Proto_OK ]
[ Proto_OK ]
…
Mock-up: proto is thrown away (product = adequate reqs)
Evolutionary proto: transformed towards efficient code
Prototypes & mock-ups: pros & cons
Limited
Resource User GetUnit
Use Abstract domain
Specialization Concrete domain
Limited Patron BorrowCopy
Book
Loans
Spec inheritance
“A user may not use more than X resource units at a time”