Software Quality Assurance From requirements to specification

1
Software Quality AssuranceFrom requirements to
specification

• Charles Wallace
• Michigan Technological University
• wallace_at_mtu.edu

2
Deriving specifications from requirements
(Jackson and Zave, 1995)
Example control of a turnstile at the entry to a
zoo The turnstile consists of a rotating barrier
and a coin slot, and is fitted with an electrical
interface. This mechanical apparatus has
already been chosen, and the development job is
to write the controlling software. To enter the
zoo, a visitor must first push on the
turnstile barrier, moving it to an intermediate
position from which it will continue rotating of
its own accord, returning to its initial
position and gently pushing the visitor into the
zoo. The turnstile is equipped with a locking
device when locked it prevents the barrier from
being pushed to the intermediate position.
3
Environmental phenomena of interest
Push(e) Visitor pushes barrier to intermediate
position (environment-controlled,
shared) Enter(e) Visitor pushes barrier fully
home and so gains entry to the zoo
(environment-controlled, not shared) Coin(e) Vali
d coin inserted into coin slot (environment-cont
rolled, shared) Lock(e) Turnstile receives
locking signal (machine-controlled,
shared) Unlock(e) Turnstile receives unlocking
signal (machine-controlled, shared) An event e
is atomic and instantaneous (abstraction)
4
Indicative environment properties
the state of the world, whether we like it or not
Push and Enter events alternate, starting with
Push.
(IND1)
Push
Pushable
Enterable
Enter
5
Indicative environment properties
If Locks and Unlocks alternate, starting with
Unlock, then a Push can occur only after an
Unlock and before the next Lock. (Note If Locks
and Unlocks dont alternate, all bets are off.)
Lock, Unlock
(DEF1)
Lock
Locked
Lock- Unknown
(IND2) ?e Locked(pre(e)) ? ?Push(e)
Lock
Unlock
Unlocked
Unlock
6
Optative properties (requirements)
No one should enter without paying.
(OPT1) ?s Enter(s) Coin(s)
Visitors who pay should not be prevented from
entering the zoo. (i.e. the machine will not
prevent their entry)
(OPT2) ?s (Enter(s) lt Coin(s)) ? The
machine will not prevent another Enter
(more work needed to make this precise)
7
(OPT1) ?s Enter(s) Coin(s)
How can our machine ensure this? By compelling
Coin events or preventing Enter events - both
event types are environment-controlled
Need a form of OPT1 that doesnt involve
(non-shared) Enter events
(IND3) ?s Push(s)-1 Enter(s) Push(s)
(from IND1)
(OPT1a) ?s Push(s) Coin(s)
(from OPT1, IND3)
OPT1a is a stronger form of OPT1, specifying
that ?s Enter(s) Push(s) Coin(s)
8

• Necessary and sufficient condition
• If the number of pushes equals the number of
  coins,
• prevent a further push until after another coin
  is inserted
• How to prevent pushes?
• Being in the Locked state prevents pushes
• How to ensure that the Locked state is reachable?
• Ensure the alternation of locks and unlocks
• (thereby avoiding Lock-Unknown)

(OPT3)
Unlock
Lock
9
Refinement of OPT1
(OPT4a) ?e (Locked(pre(e)) ? Push(pre(e))
Coin(pre(e))) ? ?Unlock(e)
Safety property Bad things dont happen Here,
the bad thing is unlocking in a dangerous state
(OPT4b) ?e (Unlocked(pre(e)) ? Push(pre(e))
Coin(pre(e))) ? Lock(e)
Liveness property Good things (eventually)
happen Here, the good thing is locking when a
dangerous state arises Assumption machine is
able to detect the dangerous state and react with
a Lock before any other events occur Q How
quickly must the machine react?
10
Refinement of OPT2
(OPT5a) ?e (Unlocked(pre(e)) ? Push(pre(e)) lt
Coin(pre(e))) ? ?Lock(e)
Safety property The machine must not lock the
turnstile when there is credit
(OPT5b) ?e (Locked(pre(e)) ? Push(pre(e)) lt
Coin(pre(e))) ? Unlock(e)
Liveness property The machine must eventually
unlock the turnstile when there is credit
11
Reference

• M.A. Jackson and P. Zave. Deriving
  specifications and requirements An example.
  Proc. ICSE, April 1995.