Functional Specification

1
Functional Specification Reviews

• CS 3302

2
Specification

• In contrast to customer-oriented requirements, a
  specification is directed toward the implementors
  and testers of a system
• The audience is primarily system literate, not
  application literate
• Language is semi-formal
• Style is technical
• Used as reference source, not guide for the big
  picture

3
Exercise Writing functional specs.

• You have to specify a function that correctly
  categorizes triangles
• Function accepts triple of integers
• Write a specification of the function
• Is it clear and unambiguous
• Is it complete (in the technical sense)?
• Is it correct?

Equilateral
Isosceles
Scalene
4
Suggested spec.
Classify Triangle The function accepts three
signed integers representing the lengths of the
sides of a triangle and classifies the triangle
as equilateral, isosceles, scalene, or
unfeasible. - If there are less than or more
than three input values or any input value is
other than an integer, the function returns the
value unfeasible. - If any input value is
zero or negative, the function returns the value
unfeasible. - If the three positive input
values are equal, the function returns the
value equilateral - If exactly two of the
positive input values are equal, the function
returns the value isosceles. - For any
combination of input values not covered in the
preceding definitions, the function returns the
value scalene. (see how long-winded and
legalistic this can become if done right?)
5
How to write a requirement

• Completeness
• Systematically invent all the feasible cases. Are
  they accounted for?
• For more complex inputs (e.g. interaction over
  time), use concrete scenarios
• Clarity / unambiguity
• Read it over your own shoulder or get a
  colleague to criticize wording
• Consistency
• Do any of the parts of the spec. conflict?
• Check them systematically if you can
• e.g. all three inputs equal - equilateral
  conflicts with the no zeros or negatives
• What about 0,0,0?

6
Structured Analysis philosophy

• Describing a system is describing the functions
  it performs
• Systems do things
• Functions are essential actions or computational
  operations
• Functional architecture is hierarchical
• System is a collection of interacting functions
  which may be decomposed further
• Net inputs and outputs should be consistent
  across levels
• Function interactions are data flows
• Data flow arc states that data can flow, not when
  it flows or that it must

7
Context diagram (Burglar alarm system)
Alarm notificn
Security company
Sensor
Time
Status signal
Clock

• Burglar alarm
• system

Alarm cmd
Settings
Tone generator
Security code
Warning tone cmd
Householder
8
Data flow diagram (Burglar alarm system
Alarm cmd
Security code
Alarm notificn
Settings
Active sensors
Non- inhibited alarm
Alarm signal
Monitor sensors
Warning tone cmd
Intruder signal
Time
9
Structured analysis

• Principle
• Specify essential architecture of system
• Methods
• Top-down decomposition
• Outside-in handling of events
• Components
• Process hierarchy
• Data and process defs.
• Maturity
• 1980s state of practice

B
D
A
P
Q
C
E
R
Data element
Definition
A
Integer
B
Integer, Float
Process P Find sum of elements Find mean of
elements
10
Defining Data flows

• Data dictionary
• Collection of definitions of data elements that
  flow along data flows
• Backus-Naur Form
• Settings Out In Off
• Security_Code Digit Digit Digit Digit
• Security_Code Digit
• Alarm_Notificn Time House_Id Sensor_Id

11
Defining processes
Raise_Alarm

• Data flow diagram decomposition
• Sub-diagram with consistent I/O
• Pseudo-code defs

Non-inhibited alarm
Alarm Cmd
set_alarm is begin read Security_Code if
valid(Security_Code) then read(Settings) Active_Se
nsors Sensors_in(Settings) write(Active_Se
nsors) end if end
Alarm notificn
12
Structured analysis exercise

• Draw a context diagram for the meeting scheduler
• Decompose the context diagram into a set of
  interacting functions
• Only one data flow diagram
• Describe the functions and data flows in English
• Questions
• What types of decision do you have to make?
• Do you have all the information you need to make
  them? If not, how would you get it?

13
LimitationsTop-down decomposition is better for
explaining than for derivingEssential
architecture and implementation architecture
often differentDocument maintenanceSignificant
ambiguitiesSerious for RT systems

• Structured analysis evaluation

• Advantages
• Basic ideas and notations are simple
• Many organizations have major investment in SA
• Widespread tool support for notations and analyses

14
State transition diagrams

• Explicit modeling of system states and
  transitions among them
• Triggers associated with transitions
• Behavior (operations) may be associated with
• states (cf. flow charts)
• or transitions
• Standard notation is not used in some methods

T1
S2
T2
T3
or...
T1
S1
T2
S2
T3
15
Example
announce standing for reelection
good primary
debate
nomi- nated
Nominee
President
elected
announce candi- dacy
not nomi- nated at convention
out of office
not elected
poor primaries
16
Evaluation of transition diagrams

• Complexity of real systems is too great for STDs
• (1) Astronomically large state space
• Aggregation of states through use of programming
  language-like variables
• E.g. Add 'reelection count' to prevent more than
  two terms
• State-changing actions added to states or
  transitions
• (2) Orthogonal transitions
• Some error conditions must be trapped for every
  state
• Messy diagrams because of large number of arcs

17
Statecharts (Harel, 1988)

• living

politics
maintenance activities
born
die
18
Information-based models

• Model the subject matter first, then behavior
• Subject matter is more stable than desired
  behaviors
• So information-based design is more robust when
  requirements change
• Subject matter is modeled as entities,
  relationships and attributes
• Emphasize what properties characterize the states
  the system can be in
• Main tool is the entity-relationship diagram
• Many notations

19
Entity-relationship diagrams

• Purpose
• Show the subject matter of the system as
  principal objects and their relationships
• Basis
• Can be reduced to set theory
• Intuitive way to think about conceptual structure
  of problem domain
• Used to model different things
• Information in proposed system
• Problem domains (for future system development)
• Applicability
• Can easily transform ER model to
  relational/network DB schema

20
ER Diagrams

• Entities
• Boxes for classes of entities
• Relationships
• Arrows for binary relations
• Complex relations are modeled as entities
• Cardinality constraints for min/max association
• Attributes
• Properties that characterize entities

Library
author
Copy
acqn
(0,n)
borrows
Patron
(0,1)
name
21
Information modeling Exercise

• Sketch an information model for the meeting
  scheduler application
• Major entity classes
• Relationships
• Attributes
• Cardinality constraints
• What types of issues does the ERA diagram raise?

22
Model-based formal specifications

• Principle
• A mathematically formal description of system
  properties aids understanding and analysis
• Model-based style
• Extension of ER modeling
• ER diagrams are like type and function
  declarations
• Cardinality constraints are logical rules
• Other rules that cannot be shown in an ER diagram
  can be specified
• Behavior is specified in operations
• Preconditions and postconditions for each
  operation
• Languages
• Z, VDM, Fusion (OOA) method

23
Admissible states

• System states are legal configurations of
  attribute/relationship values
• What are the rules that specify these legal
  states?
• And only these states
• Need to specify these succinctly
• Not as a transition diagram

Admissible states
Conceivable states
24
Model-based specification of behavior

• System behavior is modeled as a collection of
  state-changing operations
• The preconditions of an operation state when it
  can occur
• Not when it is triggered
• Postconditions define the effects

illegal operation
Permitted operation
25
Simple Z example
schema

• Container
• contents Nat
• capacity Nat
• contents lt capacity

declarations
predicate/ invariant
26
Z operation schema
precondition

• Fill

changes Container
amount? Nat contents amount? lt
capacity contents' contents amount?
postcondition
27
Z exercise

• Specify a new operation
• Write the operation schema for dispense, an
  operation that dispenses fluid from the container
• Add a new rule
• Let the container have a warning light that goes
  on when the container becomes more than 80 full
• Questions
• What kinds of proof obligations arise in the two
  cases
• How does using model-based specification clarify
  your understanding of the (very trivial) problem
  domain?

28
Model-based formal specification Evaluation

• Maturity
• Encouraging experiences in industrial projects,
  incl.
• IBM (CICS)
• Tektronix (oscilloscope embedded software)
• Inmos (transputer FP microcode)
• Advantages
• Precision helps understand requirements and
  design implications
• Limitations
• Requires retraining (but not advanced math)
• Trend
• Increasing investment with need for dependable
  software accountability for effects