1. Requirements Specification & Documentation:
Fundamentals of RE
Chapter 4
Requirements Specification & Documentation:
Formal Specification

2. alternative options Where are we? Chap.1: RE products and processes
Elicitation
techniques
Chap. 3:
Evaluation
techniques
consolidated
requirements
start
agreed
requirements
Chap. 4:
Specification &
documentation
techniques
documented requirements

3. Requirements specification & documentation: what we’ve seen so far...
Free documentation in unrestricted natural language
Disciplined documentation in structured natural language
Local rules on writing statements
Global rules on organizing the Requirements Document
Use of diagrammatic notations
System scope: context, problem, frame diagrams
Conceptual structures: entity-relationship diagrams
Activities and data: SADT diagrams
Information flows: dataflow diagrams
System operations: use case diagrams
Interaction scenarios: event trace diagrams
System behaviors: state machine diagrams
Stimuli and responses: R-net diagrams
Integrating multiple system views, multi-view spec in UML

4. Requirements specification & documentation: formal specification techniques
Formal specification: what, why?
Logic as a basis for formalizing statements
Propositional logic
First-order predicate logic
First-order specification languages
History-based specification
Linear temporal logic
Branching temporal logic
State-based specification
Z schemas
Event-based specification
SCR tables
Algebraic specification
Formal spec: strengths & limitations

5. Formal specification: what, why?
To complement NL & diagrammatic specs, especially for mission-critical aspects
Full formalization of RD items ...
declaration part: item structure (like diagrams)
assertion part: item properties --prescriptive, descriptive
mechanisms for structuring large specs into small units
Formal = in machine-processable language
often based on mathematical logic
syntax, semantics, rules for inference of new information
Benefits ...
higher precision in statement formulation
more precise rules of interpretation
automation of more sophisticated checks & derivations

6. Propositional logic: syntax
Ù Ú Ø
Propositional logic: syntax
Recursive composition of non-decomposable statements through logical connectives and, or, not, if ... then, iff
limited expressiveness: no variables, no quantification
Syntax rules for grammatically well-formed statements:
<atomicProposition> ::= true | false | <propositionSymbol>
<statement> ::= <atomicProposition> | (¬ <statement>)
| (<statement> Ù <statement>) | (<statement> Ú <statement>)
| (<statement> ® <statement>) | (<statement> « <statement>)
Example
trainStopped Ù Emergency ® doorsOpen

7. Propositional logic: semantics
Ù Ú Ø
Propositional logic: semantics
Definition of meaning of statements in some interpretation
interpretation I for statement S: specific assignment valI of
truth values to each atomic proposition in S
meaning VALI of S in I: truth value T, F of S under valI
Semantic rules:
VALI (true) = T ; VALI (false) = F ;
VALI (atomProp) = valI (atomProp)
VALI (¬ S) = T if VALI (S) = F; F otherwise
VALI (S1 Ù S2) = T if VALI (S1) = T and VALI (S2) = T; F otherwise
VALI (S1 Ú S2) = T if VALI (S1) = T or VALI (S2) = T; F otherwise
VALI (S1 ® S2) = T if VALI (S1) = F or VALI (S2) = T; F otherwise
VALI (S1 « S2) = T if VALI (S1) = VALI (S2); F otherwise

8. Semantics of propositional logic (2)
Ù Ú Ø
Semantics of propositional logic (2)
Example of semantic evaluation:
under interpretation
valI (trainMoving) = F, valI (doorsClosed) = F
the semantics of trainMoving ® doorsClosed is:
VALI (trainMoving ® doorsClosed) = T
(using implication rule)

9. Propositional logic: proof theory
Ù Ú Ø
Propositional logic: proof theory
Rules for infering new statements from available ones
sound rule if conclusion is true under any interpretation that
makes premise true
enables automatic derivations without semantic evaluation
Sample of inference rules:
P ® Q , P P ® Q , Q ® R P Ú Q , Ø P Ú R
¾¾¾¾¾ ¾¾¾¾¾¾¾ ¾¾¾¾¾¾¾¾
Q P ® R Q Ú R
Example of derivation using 3rd rule (resolution):
from Ø trainMoving Ú doorsClosed, trainStopped Ú trainMoving
we get doorsClosed Ú trainStopped
premise
conclusion

10. First-order predicate logic: syntax
"x$y
First-order predicate logic: syntax
Extends expressiveness of propositional logic through variables, constants, quantifications, relations & functions
Syntax rules:
<term> ::= <constant> | <variable> | <functionSymbol> (<term>*)
<atomicPredicate> ::= true | false | <predicateSymbol> (<term>*)
<statement> ::= <atomicPredicate> | (¬ <statement>)
| (<statement> Ù <statement>) | (<statement> Ú <statement>)
| (<statement> ® <statement>) | (<statement> « <statement>)
| (" <variable>)(< statement >) | ($ <variable>) (< statement >)
Example:
" tr1, tr2
Following (tr2, tr1) ® Dist (tr2, tr1) > WCS-Dist (tr2)
atomic predicates
terms

11. First-order predicate logic: semantics
"x$y
First-order predicate logic: semantics
Interpretation: definition of what unquantified variables, constants, functions, predicates designate in domain of interest
predicate specs have meaning only within specific interpretation
Documenting interpretations is essential for communication, non-ambiguity, adequacy checking ...
Domain of interest e.g. trains connecting airport terminals
For constants a, unquantified variables x:
valI (a), valI (x) = specific domain elements
e.g. valI (MTP) = main terminal platform
For function symbol f: valI (f) = specific function over domain
e.g. valI (WCS-Dist) = function returning the worst-case distance
for the given train to stop in emergency
For n-ary predicate symbol P: valI (P) = n-ary relation over domain
e.g. valI (Following) = set of train pairs with 1st directly behind 2nd

12. First-order predicate logic: semantic rules
"x$y
First-order predicate logic: semantic rules
Within specific interpretation I, semantic value VALI is ...
VALI (a) = valI (a) for constants
VALI (x) = valI (x) for unquantified variable occurrences
VALI ( f (t1, ..., tn) ) = (valI (f )) (VALI (t1), ..., VALI (tn)) for terms
VALI (true) = T , VALI (false) = F
VALI ( P (t1, ..., tn)) = (valI (P )) (VALI (t1), ..., VALI (tn)) for atomic predic
VALI (¬ S), VALI (S1 Ù S2), VALI (S1 Ú S2), VALI (S1 ® S2),
VALI (S1 « S2): cf. propositional logic
VALI (("x) S ) = T if VAL{x ¬ d}oI (S ) = T for each domain element d
F if VAL{x ¬ d}oI (S ) = F for some domain element d
VALI (($x) S ) = T if VAL{x ¬ d}oI (S ) = T for some domain element d
F if VAL{x ¬ d}oI (S ) = F for each domain element d

13. First-order predicate logic: proof theory
"x$y
First-order predicate logic: proof theory
Inference rules from propositional logic + specific ones, e.g.
("x) S u1 = v1, ..., un = vn u1 = v1, ..., un = vn
¾¾¾ ¾¾¾¾¾¾¾¾¾¾ ¾¾¾¾¾¾¾¾¾¾¾
S [x / t] f (u1, ..., un ) = f (v1, ..., vn ) P (u1, ..., un ) « P (v1, ..., vn )
=> automated derivation/checking of more expressive statements
instantiation
term/predicate rewriting under equality of args

14. First-order specification languages
"x$y
First-order specification languages
Variables designate objects involved in reqs, dom props, assumptions (e.g. entity instances in ER diagram)
with value generally changing over time
State of variable x: pair (x, v) v: value
System state: pair (X, V)
X: set of system variables, V: set of corresponding values
e.g. train tr2 following tr1 at distance of 100m , WCS-Dist = 50m
In many spec languages, specs are interpreted over states
spec satisfied by some states, falsified by others
Many first-order spec languages are sorted
typed variable designates some instance in a set
e.g. " tr1, tr2: Train
Following (tr2, tr1) ® Dist (tr2, tr1) > WCS-Dist (tr2)
sort
instance variables (e.g. entity instances)

15. First-order specification languages (2)
"x$y
First-order specification languages (2)
Formal specification = logical “theory”
= set of formal statements (“axioms”) from which new statements can be derived (“theorems”) by inference rules
More precise characterization of specification errors/flaws ...
Contradiction: no interpretation of interest that can make all statements true together
Ambiguity: multiple interpretations of interest that can make all statements true together
Redundancy: some statements can be inferred from others
Automated derivation of theorems is useful for ...
adequacy ckecking (“do you want this consequence?”)
consistency checking (false as derivable theorem)

16. Requirements specification & documentation: formal specification techniques
Formal specification: what, why?
Logic as a basis for formalizing statements
Propositional logic
First-order predicate logic
First-order specification languages
History-based specification
Linear temporal logic
Branching temporal logic
State-based specification
Z schemas
Event-based specification
SCR tables
Algebraic specification
Formal spec: strengths & limitations

17. History-based specification
□ ◊ ●
History-based specification
Specs capture maximal sets of admissible system histories
history = infinite temporal sequence of object states
declaratively, implicitly: time & histories are kept implicit
Statements are written in a temporal logic (TL)
logical connectives for reference to past, future states
TL statements are interpreted over histories
satisfied by some histories, falsified by others
Different time/history structures => different TLs
discrete, dense, continuous time
linear histories, branching histories

18. Linear Temporal Logic (LTL)
□ ◊ ●
Linear Temporal Logic (LTL)
Discrete time points (isomorphic to naturals)
Linear histories
H: Nat ® State (X) X: set of system variables
Propositional connectives, first-order constructs
+ temporal connectives:
◊ (some time in the future) ¨ (some time in the past)
 (always in the future)  (always in the past)
W (always in the future unless) B (always in the past back to)
U (always in the future until) S (always in the past since)
o (in the next state) · (in the previous state)
P  Q :  (P ® Q) P  Q :  (P « Q)

19. Linear Temporal Logic (2)
□ ◊ ●
Linear Temporal Logic (2)
Real-time extensions:
◊d (some time in the future within deadline d)
d (always in the future up to deadline d)
Spec examples:
“Train doors shall always remain closed between platforms unless
the train is stopped in emergency”
" tr: Train, pl: Platform
· At (tr, pl) Ù ¬ At (tr, pl) Þ
tr.Doors = “closed’’ W [At (tr, next (pl)) Ú Alarm (tr) Ù ¬ Moving (tr) ]
“Trains shall reach their next platform within at most 5 minutes”
At (tr, pl) Þ  5m At (tr, next(pl))

20. Linear Temporal Logic: semantics
□ ◊ ●
Linear Temporal Logic: semantics
Interpretation over linear histories
(H, i) |= P “P is satisfied by history H at time position i”
History H satisfies statement P iff (H, 0) |= P
Semantic rules
(H, i) |=  P iff for some j ³ i: (H, j) |= P
(H, i) |=  P iff for all j ³ i: (H, j) |= P
(H, i) |= P U Q iff exists j ³ i: (H, j) |= Q and for every k, i  k < j:
(H, k) |= P
(H, i) |= P W Q iff (H, i) |= P U Q or (H, i) |=  P
(H, i) |= o P iff (H, i+1) |= P
(H, i) |= d P iff for some j ≥ i with dist (i, j)  d: (H, j) |= P
(H, i) |= d P iff for all j ≥ i such that dist (i, j)  d: (H, j) |= P

21. Linear Temporal Logic: proof theory
□ ◊ ●
Linear Temporal Logic: proof theory
Sample of inference rules
 P P1 Ù P2  Q,  P1,  P P  Q
¾¾ ¾¾¾¾¾¾¾¾¾¾¾ ¾¾¾¾¾¾
P  Q  P   Q
=> automated derivation/checking of LTL specs
Some model-checking tools verify whether state machine diagrams meet desired properties specified in LTL (cf. Chap. 5)

22. Branching Temporal Logics
AG EF
Branching Temporal Logics
Discrete time points
Interpretation over tree-structured histories
branching to alternative successor states
Computation Tree Logic (CTL): properties can be quantified over paths and over states along a path ...
AG P (for all paths, P holds globally for all states along the path)
AF P (for all paths, P holds finally in some state along the path)
EG P (there exists a path where P holds globally for all path states)
EF P (there exists a path where P holds finally in some path state)
Reachability formalizable through EF quantifiers

23. History-based specification: strengths & limitations for RE
□ ◊ ●
History-based specification: strengths & limitations for RE
J Declarative, abstract formulation of reqs, assumptions,
domain properties
no extra variables needed for encoding time, past events
no explicit operation for capturing state transitions
often “close” to NL formulation
=> good for formal RE
L May be complex, hard to write, unintelligible for specs
requiring excessive nesting of temporal connectives
e.g. “Q should hold after P holds and before R holds”:
 ¬ P Ú  ( P Ù ¬ R U ( Q Ú  ¬ R ) ) !!!
=> specification patterns needed to hide such intricacies
L Lack of structuring mechanisms (on variables, groups of statements)

24. Requirements specification & documentation: formal specification techniques
Formal specification: what, why?
Logic as a basis for formalizing statements
Propositional logic
First-order predicate logic
First-order specification languages
History-based specification
Linear temporal logic
Branching temporal logic
State-based specification
Z schemas
Event-based specification
SCR tables
Algebraic specification
Formal spec: strengths & limitations

25. State-based specification
"x$y
State-based specification
Specs capture maximal sets of admissible states at system snapshot
Statements are written in a sorted logic (± first-order)
invariants on state space,
pre- & postconditions on operations
Interpreted over states
satisfied by some states, falsified by others
Variety of state-based spec languages
different constructs for structuring states, for organizing specs
e.g. Z, B, VDM, Alloy, OCL, ...

26. State-based specification: invariants, pre- and postconditions
Invariant = condition constraining state space at snapshot
must hold for any state
e.g. " tr: Train, bl: Block · tr.Speed £ bl.SpeedLimit
Precondition = necessary condition for operation to be applied
applicability condition, on operation's input state
F weakest precondition = least restrictive condition
e.g. for operation OpenDoors (tr):
tr.DoorsState = 'closed' Ù tr.Speed = 0
Postcondition = condition if operation is applied
effect condition, on operation's output state
F strongest postcondition = most complete effect
tr.DoorsState = 'open' [ Ù tr.Speed = 0 ]

27. State-based specification with Z
Î Í Ç ®
State-based specification with Z
Simple basis: sets, tuples
Standard math notations for manipulating sets, relations, functions, sequences, ...
non-primitives defined in reusable spec toolkit from a few primitives on sets & tuples
Structuring mechanisms for assembling spec units piecewise
Z specification = collection of schemas + textual definitions
Data schemas, operation schemas
SchemaName ¾¾
Declaration part
¾¾¾¾¾¾¾¾¾
Assertion part

28. Z data schemas Î Í Ç ® Specify state space fragments by ...
Î Í Ç ®
Z data schemas
Specify state space fragments by ...
declaring aggregations of coupled state variables
stating invariants on these
LibraryAgents ¾¾¾¾
OrdinaryPatron: P Person
Staff: P Person
¾¾¾¾¾¾¾¾¾¾¾
OrdinaryPatron Ç Staff = Æ
Declarations of form stateVar : Type
meaning "the values of stateVar are members of set Type "
Variables may be...
simple e.g. bc: BookCopy, switch: {off, on}
structured e.g. date: Day ´ Month value is a tuple
Available: P BookCopy value is a set of bookcopies
whichBook: BookCopy « Book value is a relation

29. Z operation schemas Î Í Ç ® Specify operations by ...
Î Í Ç ®
Z operation schemas
Specify operations by ...
declaring input, output variables
importing variables from other data schemas
stating pre- and postconditions on those (implicitly)
CheckOut ¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
D Library, X LibraryAgents
p?: Person, bc?: BookCopy
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
bc? Î Available Ù p? Î OrdinaryPatron È Staff
OnLoan’ = OnLoan È {bc?} Ù Available’ = Available \ {bc?} Ù ...
Variables get decorated ...
stateVar? : Type input variable
stateVar' : Type output variable (yielding states)
stateVar! : Type output variable (external, not yielding states)
D Schema variables imported from Schema are changed
X Schema variables imported from Schema are not changed

30. A sample of non-primitive notations predefined in the Z toolkit
Î Í Ç ®
A sample of non-primitive notations predefined in the Z toolkit
È , Ç , \ set union, intersection, difference
Æ, # empty set, set cardinality Í set inclusion
S1« S2 set of relations on S1,S2 e1 |® e2 ordered pair in relation
dom R domain of relation R ran R range of relation R
S <| R domain restriction to set S S <-| R domain restriction to complement of S
R-1 inverse of relation R R (| S |) relational image of set S by R
S1 ® S2 set of total functions from S1 to S2
S1 -|-> S2 set of partial functions from S1 to S2
S1 >® S2 , S1 ->> S2 , S1 >->> S2 set of injections, surjections, bijections
f Å g functional overriding of f by g

31. Functions provide simplest way of specifying query operations
Î Í Ç ®
Functions provide simplest way of specifying query operations
BiblioSearch ¾¾¾¾¾¾¾¾¾¾
X Directory
tp?: Topic
booklist!: P Book
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
booklist! = {x: Book | tp? Î Covers (x) }
hence the need for this variable
in a corresponding data schema
Directory ¾¾¾¾¾¾¾¾¾¾
WhichBook: BookCopy -|-> Book
...
Covers: Book -|-> P Topic
¾¾¾¾¾¾¾¾¾¾¾¾¾¾
dom Covers Í ran WhichBook

32. Initial state schemas and textual specifications
Î Í Ç ®
Initial state schemas and textual specifications
Initial state schemas can be associated with data schemas
used for inductive reasoning about spec (cf. Chap.5)
InitLibraryShelves ¾¾¾¾¾
LibraryShelves
¾¾¾¾¾¾¾¾¾¾¾¾¾
Available = Æ Ù OnLoan = Æ
Spec of given types: primitives sets on which the spec relies
to be defined informally (but precisely!)
e.g. [Book, BookCopy, Author, Topic, Person]
BookCopy: set of all possible books that could ever be considered; ...
Spec of free types
e.g. ErrorMessage ::= {unRegisteredPatron, bookUnavailable, ...}

33. Structuring large specs: schema inclusion
Declarations and assertions of included schema are imported in including schema
LibrarySystem ¾¾¾¾¾¾¾¾¾
Directory
LibraryShelves
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
dom WhichBook = Available È OnLoan
LibraryShelves ¾¾¾¾¾¾¾¾¾¾
LibraryAgents
Available, OnLoan: P BookCopy
BorrowedBy: BookCopy -|-> Person
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Available Ç OnLoan = Æ
OnLoan = dom BorrowedBy
ran BorrowedBy Í OrdinaryPatron È Staff
" p: OrdinaryPatron ·
# BorrowedBy-1 (| {p} |) ≤ LoanLimit
Directory ¾¾¾¾¾¾¾¾¾¾
WhichBook: BookCopy -|-> Book
WrittenBy: Book -|-> P Author
Covers: Book -|-> P Topic
¾¾¾¾¾¾¾¾¾¾¾¾¾¾
dom WrittenBy Í ran WhichBook
dom Covers Í ran WhichBook

34. Structuring large specs: logical combination of schemas
Ù Ú Ø
Declarations of combining schema are imported from combined schemas
Assertions of combining schema are composed from combined schemas using the specified logical connectives
e.g. the textual spec
NewSchema = Schema1 Ù Schema2 Ú Schema3
amounts to:
NewSchema ¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
All declarations from Schema1, Schema2, Schema3
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
ConjoinedAssertionsFromSchema1 Ù ConjoinedAssertionsFromSchema2
Ú ConjoinedAssertionsFromSchema3
F Most helpful for incremental spec elaboration & schema reuse
e.g. reuse of common exceptions for different operations

35. Incremental elaboration and schema reuse: example
Î Í Ç ®
Incremental elaboration and schema reuse: example
RobustCheckout = Checkout Ù AuthorizedAgent Ú UnauthorizedAgent Ú UnregisteredUser Ú UnknownCopy Ú UnavailableBook Ú LoanLimitReached
RobustReturn = Return Ù AuthorizedAgent Ú UnauthorizedAgent Ú UnregisteredUser Ú UnknownCopy Ú BookAvailable
Return ¾¾¾¾¾¾¾¾¾¾¾
D LibrarySystem
X Directory, X LibraryAgents
bc?: BookCopy
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
bc? Î OnLoan
Available’ = Available È {bc?}
OnLoan’ = OnLoan \ {bc?}
BorrowedBy’ = {bc?} <-| BorrowedBy
UnRegisteredUser ¾¾¾
p?: Person, mes !: Message
¾¾¾¾¾¾¾¾¾¾¾¾
p? Ï OrdinaryPatron È Staff
mes ! = ‘unRegisteredPatron’

36. State-based specification: strengths & limitations for RE
Î Í Ç ®
State-based specification: strengths & limitations for RE
J Simple machinery
invariants, pre- and postconditions
standard notations from elementary discrete maths & logics
J Powerful structuring mechanisms
for composing spec units
for structuring states => especially appropriate for systems with
complex object structures
J Amenable to automated analysis
type checking, consistency checking, invariance proofs, claim verification, spec animation (for equational postconditions)
L Limited expressive power
functional aspects mainly
obligations cannot be specified (e.g. trigger conditions)
no historical referencing
programming tricks required to encode past states
cf. library example in Sect

37. Requirements specification & documentation: formal specification techniques
Formal specification: what, why?
Logic as a basis for formalizing statements
Propositional logic
First-order predicate logic
First-order specification languages
History-based specification
Linear temporal logic
Branching temporal logic
State-based specification
Z schemas
Event-based specification
SCR tables
Algebraic specification
Formal spec: strengths & limitations

38. Event-based specification
Specs capture sets of state transitions required by events along admissible system histories
obligations
They formalize transition functions
conditions on input/output states, triggering events, guards
cf. state machine diagrams
states here are SM states (cf. Sect )
Variety of state-based spec languages
different constructs for defining & structuring SM states, for organizing specs, for handling concurrency & interaction
different built-in semantic assumptions
e.g. SCR, RSML, STATEMATE, LTS

39. Event-based specification with SCR
Based on 4-variable model (cf. Chap. 1)
prescriptive statements (REQ) + descriptive ones (NAT)
reqs = relations between monitored & controlled variables
deterministic machine, non-deterministic environment
synchrony hypothesis: machine handles one input event completely before next event is processed (infinitely fast reaction)
Specs in tabular format for better readability
cf. decision tables (Sect )
Output-driven
spec unit = table
= function yielding single output from input combinations
Mode transition tables, event tables, condition tables
+ variable declarations, type definitions, initial state def, assumptions, dom props

40. SCR modes and events Mode = condition on monitored variable
often abstraction for continuous variable
e.g. mode TooFast for monitored variable MeasuredSpeed
Mode class = auxiliary variable behaviorally defined by
state machine on monitored variables
modes = SM states
e.g. mode class MovementState
with modes Stopped, MovingOK, TooFast
Event = variable changing value
form: @T (v) meaning "v becomes true"
Input event: refers to monitored variable
Conditioned event: additional guard condition must hold
(v) WHEN C meaning "v becomes true when C was true"
e.g. @T(Reset= On) WHEN Alarm = On

41. SCR mode transition tables
Specify the state machine associated with a mode class
mode transitions triggered by events
newMode = function (previous mode, events)
E.g. mode transition table for mode class MovementState associated with monitored variable measuredSpeed
Old Mode
New Mode
Event
MovingOK @T (measuredSpeed = 0) Stopped
Stopped @T (measuredSpeed > 0) MovingOK
MovingOK @T (measuredSpeed ³ blockLimit) TooFast
TooFast @T (measuredSpeed < blockLimit) MovingOK
entries must be disjoint

42. SCR event tables Specify the values of a controlled variable or term:
Var = Function (AMC mode, events)
AMC: associated mode class
term: auxiliary variable --function on monitored variables,
mode classes or terms (for more concise spec)
E.g. event table for term Emergency with AMC MovementState and monitored variables Alarm and Reset
Mode
Events
Stopped, @T (Alarm = On) @T (Reset = On)
MovingOK, WHEN Alarm = On
TooFast
Emergency True False

43. SCR condition tables
Specify the values of a controlled variable or term:
Var = totalFunction (AMC mode, conditions)
condition: predicate on monitored, controlled or internal variables
E.g. condition table for controlled variable DoorsState as a function of AMC MovementState and term Emergency
Mode
Conditions
Stopped AtPlatform OR Emergency NOT AtPlatform AND NOT Emergency
MovingOK, False True
TooFast
DoorsState Open Closed
conditions in a row must be disjoint (for a function)
and cover all cases (for a total function)

44. Event-based specification with SCR: strengths & limitations for RE
J Based on RE reference model
requirements vs. specifications, prescriptive vs. descriptive
J Event-based => especially appropriate for reactive systems
J Local specs, output-driven, tabular functions
=> easier understanding & completeness checking
J Rich toolset for automated analysis
consistency checking, model checking, simulation, invariance generation, test data generation
L Lack of structuring mechanisms
for structuring variables, for composing/decomposing specs
L Limited expressive power
functional aspects mainly
no historical referencing
rationale for complex specs?

45. Requirements specification & documentation: formal specification techniques
Formal specification: what, why?
Logic as a basis for formalizing statements
Propositional logic
First-order predicate logic
First-order specification languages
History-based specification
Linear temporal logic
Branching temporal logic
State-based specification
Z schemas
Event-based specification
SCR tables
Algebraic specification
Formal spec: strengths & limitations

46. Algebraic specification
op(gen) = a
Algebraic specification
Specs = equations formalizing laws for composing operations
+ operation signatures
operations seen as mathematical functions
no explicit notion of state
system history = trace of operation applications
Grouping by referred concept
cf. abstract data types, universal algebras
E.g. WhichTrain?: Block  Train
EnterBlock: Train  Block  Block
" tr: Train, bl: Block
WhichTrain? (EnterBlock (tr, bl)) = tr
Variety of algebraic spec languages
different constructs for spec organization, parameterization, ...
e.g. OBJ, LARCH, ASL, PLUSS, ...

47. Algebraic specification: beyond the basic idea
op(gen) = a
Algebraic specification: beyond the basic idea
Types are definable through parameterized type constructors
e.g. Type Directory is SetOf [Tuple [Book, BookCopy, Topic]]
with imported operations on sets, tuples, ...
Equations can be conditional
e.g. LeaveBlock (tr, EnterBlock (tr’, bl)) = bl if tr == tr’
Operations can be partial functions
use of preconditions or 'Undef' sort in codomain
e.g. Pre_LeaveBlock (tr, bl): On (tr, bl)
with On: Train  Block  Boolean
On (tr, EnterBlock (tr’, bl)) = true if tr == tr’
false otherwise or
LeaveBlock: Train  Block  Block È UndefinedLeave
LeaveBlock (tr, EnterBlock (tr’, bl)) = bl if tr == tr’
= undef_leav if not tr == tr’

48. Building algebraic specs systematically
op(gen) = a
Building algebraic specs systematically
For target concept, classify associated operations...
modifiers: produce any concept instance by composition with other modifiers --e.g. create empty sequence, add, remove element
generators: minimal subset of modifiers to generate any concept instance by minimal number of compositions --e.g. create empty, add
observers: to get relevant info about any concept instance
To get minimal set of composition laws ...
Identify generator set GS;
For each generator Gen in GS:
For each observer Obs [and condition <case>], write equation
Obs (…, Gen (…, …, …), …) = <effectTerm> [ if <case>]
For each modifier Mod not in GS [and condition <case>], write equation
Mod (…, Gen (…, …, …), …) = <effectTerm> [ if <case>]
often recursive equation

49. Building algebraic specs systematically: library example
" lib: Library, bc, bc’: BookCopy
CopyBorrowed (EmptyLib (), bc) = false
CopyBorrowed (AddCopy (lib, bc’), bc) = CopyBorrowed (lib, bc)
CopyBorrowed (CheckOut (lib, bc’), bc) = true if bc = bc’
= CopyBorrowed (lib, bc) if bc ¹ bc’
RemoveCopy (AddCopy (lib, bc’), bc) = lib if bc = bc’
= AddCopy (RemoveCopy (lib, bc), bc’) if bc ¹ bc’
RemoveCopy (CheckOut (lib, bc’), bc) = RemoveCopy (lib, bc) if bc = bc’
= CheckOut (RemoveCopy (lib, bc), bc’) if bc ¹ bc’
Return (CheckOut (lib, bc’), bc) = lib if bc = bc’
= CheckOut (Return (lib, bc), bc’) if bc ¹ bc’
Return (AddCopy (lib, bc’), bc) = AddCopy (Return (lib, bc), bc’) if bc ¹ bc’
generators for book copies in library
generator for borrowed book copies
recursive

50. Algebraic specs may reuse operations imported from other spec units
op(gen) = a
Algebraic specs may reuse operations imported from other spec units
Type Directory is SetOf [Tuple [Book, BookCopy, Topic]
Imports List [T]
SIGNATURES
EmptyDir: Æ  Directory
AddEntry: Directory  Book  BookCopy  Topic  Directory
BiblioSearch: Directory  Topic  List [Book]
EQUATIONS
" dir: Directory, b: Book, bc: BookCopy, tp, tp’: Topic
BiblioSearch (EmptyDir (), tp) = nil
BiblioSearch (AddEntry (dir, b, bc, tp’), tp) = AddList (b, BiblioSearch (dir, tp) if tp = tp’
= BiblioSearch (dir, tp) if tp ¹ tp’
imported operation

51. Algebraic specification: strengths & limitations for RE
op(gen) = a
Algebraic specification: strengths & limitations for RE
J Efficient automated analysis
powerful term rewriting engines
J Executable specs
good for rapid prototyping (cf. Section 2.2.6)
J Rich structuring mechanisms
parameterization, import, inheritance, ...
L Limited expressive power
just equations
no historical referencing
L Closer to programming
correctness of recursive equations ?

52. Formal specification: summary
Formalization of declaration and assertion parts
Logic-based -> formal syntax, semantics, proof rules
Differences in ...
focus: histories vs. states vs. events vs. operation compositions
style: declarative vs. operational
structuring mechanisms for large specs, complex objects
More effective for dedicated types of application domains
state-based, algebraic: sequential behaviors, complex objects
history-based, event-based: concurrent behaviors, simpler objects

53. Formal specification techniques: common strengths & challenges
J Higher precision, less inclination to spec defects
ambiguity, noise, unmeasurability, forward ref, ... (cf. Sect.1.1.7)
often defect fixes from formalization activity
J More sophisticated analysis
automated by tools
spec animation, property verification, completeness checks
J Generation of other artefacts
counterexamples, test cases, spec refinements, code
J Many success stories
especially in mission-critical domains
L Limitations in expressive power
unlike natural language
L Hard to write, hard to read

54. Specification techniques: common limitations for the RE process => Part 2 of the book
Confusing descriptions and prescriptions (cf. Chap.1)
OpenDoors ¾¾¾¾¾¾¾¾¾¾¾
D Train
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
Doors = 'closed' Ù MoveState = 'stopped'
Doors’ = ‘’open‘’
¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾¾
prescriptive
descriptive
No coverage of the WHY, WHO dimensions of RE (cf. Chap.1)
Lack of coverage of non-functional concerns
Lack of capture of alternative options to be explored
Little guidance in building complex specs