![Page 1: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/1.jpg)
Slide 1
A Reference Model for Requirements and Specifications
NOTES
![Page 2: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/2.jpg)
Slide 2
Software Artifacts in the Real World
Example from the ESA software engineering standard:• User Requirements Specification.
• Software Requirements Specification.
Example from Lucent:• Customer Specification Document.
• Feature Specification Document.
Common scenario: just the code.
![Page 3: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/3.jpg)
Slide 3
Reference Models
Provide an idealized model of the architecture for common concepts, standards, reference implementation.
Accommodate both variation and precision.
Successful example: ISO 7-layer model for networks. Benefits include:• Improved communication.
• Guide for good designs.
• Vehicle for analysis of tradeoffs.
![Page 4: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/4.jpg)
Slide 4
Key Concepts for a Reference Model for Software Artifacts
Kinds of artifacts.• Informal vs. Rigorous vs. Formal.
• Verbal vs. Document vs. Code.
Environment and System.
Visibility and Control.
Refinement Obligations.
![Page 5: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/5.jpg)
Slide 5
Reference Model Artifacts
W R S P M
Domain (“World”) knowledge provides presumed facts about the environment.
Environment System
![Page 6: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/6.jpg)
Slide 6
Reference Model Artifacts
W R S P M
Requirements that indicate what the customer needs
from the system, described in terms of its effect on the
environment.
Environment System
![Page 7: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/7.jpg)
Slide 7
Reference Model Artifacts
W R S P M
Specification providing enough information for a
programmer to build a system that satisfies the
requirements.
Environment System
![Page 8: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/8.jpg)
Slide 8
Reference Model Artifacts
W R S P M
Program implementing the specification on the given
program platform.
Environment System
![Page 9: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/9.jpg)
Slide 9
Reference Model Artifacts
W R S P M
Programming platform (“Machine”) provides a basis for
programming a machine to satisfy the specification.
Environment System
![Page 10: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/10.jpg)
Slide 10
Reference Model Artifacts
W R S P M
Given(Indicative)
Environment System
Given(Indicative)
Given(Indicative)
![Page 11: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/11.jpg)
Slide 11
Reference Model Artifacts
W R S P M
Environment System
“Wished For”(Optative)
![Page 12: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/12.jpg)
Slide 12
Reference Model Artifacts
W R S P M
Common Language Refinement
Environment System
![Page 13: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/13.jpg)
Slide 13
Designations
Environment System
eh ev sv sh
Visibility Control
![Page 14: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/14.jpg)
Slide 14
Example: Patient Monitoring System
Requirement: a system to warn a nurse ifa patient’s heart stops beating.
![Page 15: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/15.jpg)
Slide 15
Artifacts
Domain knowledge W.• A nurse is always at the nurse’s station and can hear a bell.
• If the patient’s heart has stopped, then a sensor on the patient’s chest ceases detecting the sound of a heartbeat.
Programming platform M.• Sound sensor.
• Bell.
• Computer that can activate the bell based on information from the sensor.
![Page 16: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/16.jpg)
Slide 16
Designations
eh – The nurse and the heart of the patient.
ev – The sound of the heartbeat.
sv – The ringing bell.
sh – Internal variables used in calculations.
All sets distinct.
Let e = eh ev and s = sh sv.
![Page 17: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/17.jpg)
Slide 17
Anecdote
Safety requirement in an aircraft: reverse thrusters should not activate while the plane is in the air or stopped on the ground.
Domain knowledge assumption: wheels are turning iff the plane is rolling on the ground.
Hidden from the system (eh): whether the plane is on the ground.
Visible to the system (ev): whether the wheels are turning.
Fallacy in 2.
![Page 18: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/18.jpg)
Slide 18
Fundamental Refinement Obligations
FO1 Adequacy: e s. W M P RImplementing the program P on the machine M implies that t
he requirements R are met so long as the domain W behaves as expected.
FO2 Consistency: e s. WThe domain assumptions W are consistent.FO3 Relative Consistency:
ev. (eh s. W) (eh s. W M P) Allowed actions of the environment must be consistent with t
he system behavior.
![Page 19: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/19.jpg)
Slide 19
Relative ConsistencyHow to Get it Wrong!
FO3 ev. (eh s. W) (eh s. W M’)
where M’ = M PSome choice of environment events makes the syste
m consistent: e s. W M’.
Too weak: the system doesn’t get to pick what the environment will do.
![Page 20: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/20.jpg)
Slide 20
Second Way to Get it Wrong
FO3 ev. (eh s. W) (eh s. W M’)
Every set of events consistent with the domain assumptions is allowed by the system. e s. W M’.
Too strong: this defeats the point of the requirements, which say how the system should constrain possibilities.
![Page 21: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/21.jpg)
Slide 21
Third Way to Get it Wrong
FO3 ev. (eh s. W) (eh s. W M’)
If there is a system behavior consistent with the domain assumptions then the system must allow it. e s. W M’.
Too weak: given e, if there is an s that is inconsistent with domain knowledge, then the system can implement anything.
![Page 22: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/22.jpg)
Slide 22
Fourth Way to Get it Wrong
FO3 ev. (eh s. W) (eh s. W M’)
If there is a system behavior consistent with the domain assumptions then the system must allow it. e. (s. W) (s. W M’)
Too strong: consider patient monitoring system. It is consistent with W for the patient’s heart (ev) to stop beating without the nurse being warned (eh)!
![Page 23: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/23.jpg)
Slide 23
Role of the Specification
The specification provides communication between the user and the developer expressed in the common vocabulary of the environment and system.
It enables a factorization of responsibilities between user and developer.• Users work with designations visible in the environment (viz. W
and R).
• Developers work with designations visible in the system (viz. P and M).
![Page 24: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/24.jpg)
Slide 24
Environment-Side Obligations
EO1 e s. W S R
EO2 e s. W
EO3 ev. (eh s. W)
(s. S) ( s. S eh. W)
![Page 25: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/25.jpg)
Slide 25
System-Side Obligations
SO1 e. ( s. S)
(s. M P) ( s. M P S)
![Page 26: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/26.jpg)
Slide 26
How to Get it Wrong
EO3 ev. (eh s. W)
(s. S) ( s. S eh. W)
FO3 ev. (eh s. W) (eh s. W M’)
Replace EO3 with a weaker obligation formed by close analogy with FO3: ev. ( eh s. W) ( eh s. W S)
Fails to imply that the fundamental obligations are met.
![Page 27: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/27.jpg)
Slide 27
The Key Objective
Theorem:
EO1 EO2 EO3 SO1
FO1 FO2 FO3
![Page 28: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/28.jpg)
Slide 28
Related Work
Functional documentation model (Parnas and Madey).• Feasibility similar to relative consistency.
• Obligations weaker than WRSPM.
• FD model allows implementations with unpredictable behavior.
Domain descriptions (Jackson and Zave).
Reactive Modules (Alur and Henzinger).
Village Telephone System (Karthik, Obradovic, and authors).
![Page 29: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/29.jpg)
Slide 29
Conclusions
Reference model based on 5 artifacts: WRSPM.
Four variables reflect visibility and control between environment and system.
Proof obligations can be factored between environment and system by the use of a specification in the common language.
![Page 30: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/30.jpg)
Slide 30
Functional Documentation Model
REQ(m,c)
Nat(m,c)
m c
IN(m,i) OUT(o,c)SOF(i,o)
i o
Environment
System
![Page 31: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/31.jpg)
Slide 31
FD Proof Obligations
FD1 Acceptability m i o c. NAT(m,c) IN(m,i) SOF(i,o) OUT(o,c) REQ(m,c)
FD2 Feasibility m. (c. NAT(m,c)) (c. NAT(m,c) REQ(m,c))
FD3 m. (c. NAT(m,c)) (i. IN(m,i))
![Page 32: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/32.jpg)
Slide 32
FD Counterexample
The following definitions satisfy all FD conditions, but cannot be realized.
NAT: (t. c(t) > 0) (t. m(t) < 0)
REQ: t. c(t + 3) = -m(t)
IN: t. i(t+1) = m(t)
SOF: t. o(t+1) = i(t)
OUT: t. o(t+1) = i(t)
![Page 33: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/33.jpg)
Slide 33
FD to WRSPM
m ev
c sv
i,o sh
W = NAT(m,c)
R = REQ(m,c)
M’ = IN(m,i) SOF(i,o) OUT(o,c)
![Page 34: Slide 1 A Reference Model for Requirements and Specifications NOTES](https://reader036.vdocuments.net/reader036/viewer/2022062313/56649f445503460f94c65246/html5/thumbnails/34.jpg)
Slide 34
WRSPM Conditions for FD Artifacts
T1 Admissibility m i o c. NAT(m,c) IN(m,i) SOF(i,o) OUT(o,c) REQ(m,c)
T2 Consistency m c. NAT(m,c)T3 Relative Consistency m. (c. NAT(m,c)) (
m i o c. NAT(m,c) IN(m,i) SOF(i,o) OUT(o,c))
TheoremT1 T2 FD1 FD2 FD3