RE I Slides Part II
RE I Slides Part II
RE I Slides Part II
Conclusions!
References!
!
Photo © Lise Aserud / DPA
The need:!
● Communicating requirements !
● Having a basis for contracts and acceptance decisions!
The means: A requirements specification document!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 60!
5.1 Document types!
❍ Performance!
● Data volume!
● Reaction time!
● Processing speed!
● Specify measurable values if possible!
● Specify more than just average values!
!
❍ Specific qualities!
● “-ilities” such as!
• Usability!
• Reliability!
• etc.!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 66!
Aspects to be documented – 3!
❍ Constraints!
Restrictions that must be obeyed / satisfied!
● Technical: given interfaces or protocols, etc.!
● Cultural!
● Environmental!
● Physical!
!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 69!
VOLERE! [Robertson and Robertson 2006]
[www.volere.co.uk]!
Informally!
Semi-formally!
❍ Structural models !!
Typically as diagrams which are!
❍ Interaction models! enriched with natural langue texts!
Formally!
© UFS, Inc.!
Three dimensions:!
How precise?!
What’s better?!
“The participant entry form has fields for name, first name, sex, ...”
“The participant entry form has the following fields (in this order):
Name (40 characters, required), First Name (40 characters,
required), Sex (two radio buttons labeled male and female,
selections exclude each other, no default, required),...”
It depends.!
● Degree of implicit shared understanding of problem!
● Degree of freedom left to designers and programmers!
● Cost vs. value of detailed specification!
● The risk you are willing to take!
!“...!
!4.3!Administration of participants!
! !4.3.1 !Entering a new participant!
! ! ! !4.3.1.1 !New participant entry form!
! ! ! !4.3.1.2 !New participant confirmation!
! !4.3.2 !Updating a participant record!
!...”!
❍ No general consensus !
❍ Different, overlapping sets of quality criteria used in!
● this course!
● RE textbooks!
● RE standards!
● Quasi-standards such as the IREB Certified Professional for
Requirements Engineering (see http://www.ireb.org) !
Requirements Specification!
● Elicitation!
● Analysis!
● Documentation!
● Validation!
Requirements Management!
● Identification and metadata!
● Requirements prioritization!
● Change and release management!
● Traceability!
Specify Develop
Design Update re-
requirements! system vision!
increment! quirements
specification:
Design system! Create initial Add new and
Implement
requirements changed
and integrate
Implement specification! requirements!
increment!
system!
Design prelim- Deploy results!
Deploy results! inary system
architecture!
[Not done]! [Done]!
Decision criteria!
❍ Linear!
● Clear, stable, a priori known requirements!
● Low risk (of developing the wrong system)!
● Relatively short duration of project!
● Complex requirements change process is acceptable!
❍ Incremental!
● Evolving requirements!
● High risk (of developing the wrong system)!
● Long duration of project!
● Ability to change requirements easily is important!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 85!
Prescriptive – Explorative – COTS-driven!
❍ Strongly interactive!
❍ Close and intensive collaboration between!
● Stakeholders (know the domain and the problem)!
● Requirements engineers (know how to specify)!
❍ Very short feedback cycles!
❍ Risk-aware and feasibility-aware!
● Technical risks/feasibility!
● Deadline risks/feasibility!
❍ Careful negotiation / resolution of conflicting requirements!
❍ Focus on establishing shared understanding!
❍ Strives for innovation!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 92!
!
7 Requirements elicitation!
❍ Stakeholders!
❍ Context!
❍ Observation!
❍ Documents!
❍ Existing systems!
Ask!
❍ Interview stakeholders!
❍ Use questionnaires and polls!
[Zowghi and Coulin 2005]!
Collaborate! [Dieste, Juristo, Shull 2008]!
[Gottesdiener 2002]!
❍ Hold requirements workshops! [Hickey and Davis 2003]!
[Goguen and Linde 1993]!
Build and play!
❍ Build, explore and discuss prototypes and mock-ups!
❍ Perform role playing!
Observe!
❍ Observe stakeholders in their work context!
Analyze!
❍ Analyze work artifacts!
❍ Analyze problem/bug reports!
❍ Conduct market studies!
❍ Perform benchmarking!
!
Things to elicit!
❍ Time for performing a task or producing a reaction!
❍ Volume of data!
❍ Throughput (data transmission rates, transaction rates)!
❍ Frequency of usage of a function!
❍ Resource consumption (CPU, storage, bandwidth, battery)!
❍ Accuracy (of computation)!
Analyze processes /!
Analyze terminology /!
workflows!
domain properties!
Build activity /
Build glossary!
process models!
Analyze business! Analyze dynamic!
and data objects! Problem! system behavior!
Build object and ! Build behavior
class models! model!
Note: requirements are about a future state of affairs; analyze the current
state only when necessary!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 115!
Documenting elicited requirements!
The oldest...!
...and most widely used way!
● taught at school!
● extremely expressive!
“In the sales transaction, the system shall record the buyer’s data and
timestamp the sold access card.”
Typical template:!
Example:!
When a valid card is sensed, the system shall send
the command ‘unlock_for_a_single_turn’ to the turnstile
within 100 ms.!
Standard template:!
As a <role> I want to <my requirement> [ so that <benefit> ]!
!
! !
As a skier, I want to pass the chairlift gate so that I get
access without presenting, scanning or inserting a
ticket at the gate.!
!
!
!
!
!
!
!
Author: Dan Downhill ! Date: 2013-09-20! ID: S-18!
Acceptance criteria: !
● Recognizes cards worn anywhere in a pocket on the left
side of the body in the range of 50 cm to 150 cm above
ground!
● If card is valid: unlocks turnstile and flashes a green light
for five seconds or until the turnstile is moved!
● If card is invalid: doesn’t unlock gate and flashes a red
light for five seconds!
● Time from card entering the sensor range until unlock and
flash red or green is less than 1.5 s (avg) & 3 s (max) !
● The same card is not accepted twice within an interval of
200 s!
!
➪ Scrutinize all-quantifications (“every”, “all”, “always”...) and
exclusions (“never”, “nobody”, “either – or”,...) for potential
exceptions!
➪ Specify found exceptions as requirements!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 126!
Dealing with redundancy!
❍ Entity-relationship models!
❍ Class and object models!
❍ Component models!
has!
!
Class models are inadequate here!
Closed!
Incident
Command&Control System...!
normal mode!
❍ Models the dynamic behavior:!
count = 0!
● How the system reacts to external
events in a given state! closed!
● Reaction depends on actual state!
card sensed! card invalid!
● States may be hierarchically validate card! flash red light!
nested and/or orthogonal (parallel)!
validating!
❍ In UML: state machine diagrams! card valid!
allow one turn;!
+ !Global view of system behavior! count’ = count +1;!
flash green light!
+ !Precise, but still readable!
open!
– !Weak for modeling functionality
and data! one turn done!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 147!
Sequence diagrams / MSCs!
Object Management Group (2011b)!
❍ Models ...!
● ... lifelines of system components or objects!
● ... messages that the components exchange!
sd NormalMode!
:RFID :Scanner! :Access :Turnstile! :Turnstile!
card! controller! device!
Scan()!
CardInfo! Validate(CardInfo)!
alt! ValidCard! AllowOneTurn()!
[Valid]! Count()! OneTurnDone!
InvalidCard!
[else]! FlashRedLight()!
❍ Activity models!
❍ Data flow / information flow models!
❍ Process and work flow models!
[valid]!
[invalid]! Flash red light!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 151!
Data and information flow!
[DeMarco 1978]!
Chairlift schema
Alarm boundary images!
parameters! Problem log!
+!Easy to understand!
+!Supports system decomposition!
– !Treatment of data outdated: no types, no encapsulation!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 152!
Process and workflow modeling!
❍ Elements!
● Process steps / work steps!
● Events influencing the flow!
● Control flow!
● Maybe data / information access and responsibilities!
❍ Typical languages!
● UML activity diagrams!
● BPMN!
● Event-driven process chains!
[Object Management
Group 2011]!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 154!
Process modeling: EPC!
Information
Function! Org unit!
object!
Information Connector
object! (AND, OR, XOR)!
Event! Event!
[Carroll 1995!
Sutcliffe 1998
Glinz 1995]!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 158!
Use case / scenario descriptions!
Authenticate
Act!
user!
Perform a
Treat invalid
library
card!
function!
Reserve on-
Borrow books! Return books!
loan books!
Normal path!
Alternative path!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 166!
Mini-Exercise: Writing a use case!
For the Chairlift access control system, write the use case
“Get Access”, describing how a skier gets access to a chairlift
using his or her RFID ticket.!
Structure Behavior!
Diagram! Diagram!
Profile!
Sequence Interaction Over-
Diagram!
Diagram! view Diagram!
Normal font: UML 2 Diagram type! Communication Timing
Italic font: Abstract concepts! Diagram! Diagram!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 173!
10 Formal specification languages!
Typical languages!
● “Pure” Automata / Petri nets!
● Algebraic specification!
● Temporal logic: LTL, CTL!
● Set&predicate-based models: Z, OCL, B!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 174!
What does “formal” mean?!
Potential forms!
● Purely descriptive, e.g., algebraic specification!
● Purely constructive, e.g., Petri nets!
● Model-based hybrid forms, e.g. Alloy, B, OCL, VDM, Z!
TYPE Stack!
FUNCTIONS!
new: !() !→
Stack; !-- Create new (empty) stack!
push: !(Stack, elem) !→
Stack; !-- add an element!
pop: !Stack !→
Stack; !-- remove most recent element from stack!
top: !Stack !→
elem; !-- returns most recent element!
empty: !Stack !→
bool; !-- true if stack is empty!
full: !Stack !→
bool; !-- true if stack is full!
AXIOMS!
∀ s ∈ Stack, e ∈ elem!
(1) !¬ full(s) → pop(push(s,e)) = s !-- !pop reverses the effect of push!
(2) !¬ full(s) → top(push(s,e)) = e !-- !top retrieves the most recently
! ! !stored element!
(3) !empty(new) = true !-- !a new stack is always empty!
(4) !¬ full(s) → empty(push(s,e)) = false !-- !after push, a stack is not
! ! !empty!
(5) !full(new) = false !-- !a new stack is not full!
(6) !¬ emtpy(s) → full(pop(s)) = false !-- !after pop, a stack is not full!
❍ Z is set-based!
❍ Specification consists of sets, types, axioms and schemata!
❍ Types are elementary sets: [Name] [Date] IN!
❍ Sets have a type: Person: Name Counter: IN !
❍ Axioms define global variables and their (invariant) properties!
Declaration!
string: seq CHAR!
#string ≤ 64! Invariant!
❍ Schemata!
● organize a Z-specification!
● constitute a name space!
Name!
Counter!
Value, Limit: IN! Declaration part:!
Declaration of state variables!
Value ≤ Limit ≤ 65535!
Predicate part:!
• !Restrictions!
• !Invariants!
• !Relationships!
• !State change!
The library has a stock of books and a set of persons who are
library users.!
Books in stock may be borrowed.!
Library!
Stock: Book!
User: Person!
lent: Book → Person!
dom lent ⊆ Stock!
ran lent ⊆ User! → Partial function!
dom !Domain ...!
ran !Range...!
!...of a relation!
❍ What is OCL?!
● A textual formal language!
● Served for making UML models more precise!
● Every OCL expression is attached to an UML model
element, giving the context for that expression!
● Originally developed by IBM as a formal language for
expressing integrity constraints (called ICL)!
● In 1997 integrated into UML 1.1!
● Current standardized version is Version 2.3.1!
● Also published as an ISO standard: ISO/IEC 19507:2012!
!
Employee! Document!
...!
has! Authorization! concerns! docID: Integer!
clearanceLevel:
0..*! 1! securityLevel:
!Integer!
noOfDocs: grantedOn: Date! !Integer!
...!
!Integer!
...!
authorize (doc: !
!Document)!
More examples:!
❍ The number of documents listed for an employee must be
equal to the number of associated authorizations:!
context Employee inv: self.has->size() = self.noOfDocs!
❍ The documents authorized for an employee are different
from each other!
context Employee inv: self.has->forAll (a1, a2: Authorization |
a1 <> a2 implies a1.concerns.docID <> a2.concerns.docID)!
❍ There are no more than 1000 documents:!
context Document inv: Document.allInstances()->size() ≤ 1000!
Benefits!
● Unambiguous by definition!
● Fully verifiable!
● Important properties can be!
• proven!
• or tested automatically (model checking)!
Limitations / problems!
● Cost vs. value!
● Stakeholders can’t read the specification: how to validate?!
● Primarily for functional requirements!
General principles!
● Work with the right people (i.e., stakeholders for requirements)!
● Separate the processes of problem finding and correction!
● Validate from different views and perspectives!
● Validate repeatedly / continuously!
Additional principles for requirements [Pohl and Rupp 2011]!
● Validate by change of documentation type
e.g., identify problems in a natural language specification by
constructing a model!
● Validate by construction of artifacts
e.g., identify problems in requirements by writing the user
manual, test cases or other development artifacts!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 207!
Requirements validation techniques!
Review!
● Main means for requirements validation!
● Walkthrough: author guides experts through the specification!
● Inspection: Experts check the specification!
● Author-reviewer-cycle: Requirements engineer continuously
feeds back requirements to stakeholder(s) for review and
receives feedback!
Requirements Engineering tools!
● Help find gaps and contradictions!
Acceptance test cases!
● Help disambiguate / clarify requirements!
Simulation/Animation!
● Means for investigating dynamic system behavior!
● Simulator executes specification and may visualize it by
animated models!
Prototyping!
● Lets stakeholders judge the practical usefulness of the
specified system in its real application context!
● Prototype constitutes a sample model for the system-to-be!
● Most powerful, but also most expensive means of
requirements validation!
Formal Verification / Model Checking!
● ! Formal proof of critical properties!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 209!
Reviewing practices!
❍ Paraphrasing!
● Explaining the requirements in the reviewer’s own words!
❍ Perspective-based reading!
● Analyzing requirements from different perspectives,
e.g., end-user, tester, architect, maintainer,...!
❍ Playing and executing!
● Playing scenarios!
● Mentally executing acceptance test cases!
❍ Checklists!
● Using checklists for guiding and structuring the review
process!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 210!
Requirements negotiation!
❍ Organize!
● Store and retrieve!
● Record metadata (author, status,...)!
❍ Prioritize!
❍ Keep track: dependencies, traceability!
❍ Manage change!
Storage!
● Paper and folders!
● Files and electronic folders!
● A requirements management tool!
Retrieving support!
● Keywords!
● Cross referencing!
● Search machine technology!
Querying!
● Selective views (all requirements matching the query)!
● Condensed views (for example, statistics)!
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 222!
13.2 Prioritizing requirements!
Pre-! Post-!
Solution!
traceability! Requirements! traceability!
Sources! specification! Modules!
Stakeholders! ...!
Requirements! Test cases!
Documents! ...!
Rationale!
❍ Manually!
● Requirements engineers explicitly create traces when
creating artifacts to be traced!
● Tool support required for maintaining and exploring traces!
● Every requirements change requires updating the traces!
● High manual effort; cost and benefit need to be balanced!
❍ Automatic!
● Automatically create candidate trace links between two
artifacts (for example, a requirements specification and a set
of acceptance test cases)!
● Uses information retrieval technology!
● Requires manual post processing of candidate links !
Requirements Engineering I – Part II: RE Practices !© 2013 Martin Glinz! 228!
13.4 Requirements evolution!