The Software Process

1
CHAPTER 11
SPECIFICATION PHASE
2
Overview

• The specification document
• Informal specifications
• Structured systems analysis
• Other semiformal techniques
• Entity-relationship modeling
• Finite state machines
• Other formal techniques

3
Overview (contd)

• Comparison of specification techniques
• Testing during the specification phase
• CASE tools for the specification phase
• Metrics for the specification phase
• Air Gourmet Case Study structured systems
  analysis
• Air Gourmet Case Study software project
  management plan
• Challenges of the specifications phase

4
Specification Phase

• Specification document must be
• Informal enough for client
• Formal enough for developers
• Free of omissions, contradictions, ambiguities

5
Specification Document

• Constraints
• Cost
• Time
• Parallel running
• Portability
• Reliability
• Rapid response time

6
Specification Document (contd)

• Acceptance criteria
• Vital to spell out series of tests
• Product passes tests, deemed to satisfy
  specifications
• Some are restatements of constraints

7
Solution Strategy

• General approach to building the product
• Find strategies without worrying about
  constraints
• Modify strategies in the light of constraints, if
  necessary
• Keep a written record of all discarded
  strategies, and why they were discarded
• To protect the specification team
• To prevent unwise new solutions during the
  maintenance phase

8
Informal Specifications

• Example
• If sales for current month are below target
  sales, then a report is to be printed, unless
  difference between target sales and actual sales
  is less than half of difference between target
  sales and actual sales in previous month, or if
  difference between target sales and actual sales
  for the current month is under 5

9
Meaning of Specification

• Sales target for January was 100,000, actual
  sales were only 64,000 (36 below target)
• Print report
• Sales target for February was 120,000, actual
  sales were only 100,000 (16.7 below target)
• Percentage difference for February (16.7) less
  than half of previous months percentage
  difference (36), do not print report
• Sales target for March was 100,000, actual sales
  were 98,000 (2 below target)
• Percentage difference lt 5, do not print

10
But Specifications Do Not Say This

• Difference between target sales and actual
  sales
• There is no mention of percentage difference
• Difference in January was 36,000, difference in
  February was 20,000
• Not less than half of 36,000, so report is
  printed
• Difference of 5
• Again, no mention of percentage
• Ambiguityshould the last clause read percentage
  difference of 5 or difference of
  5,000 or something else entirely?
• Style is poor

11
Informal Specifications (contd)

• Claim
• This cannot arise with professional
  specifications writers
• Refutation
• Text Processing case study (Section 11.2.1)

12
Informal Specifications

• Conclusion
• Natural language is not a good way to specify
  product
• Fact
• Many organizations still use natural language,
  especially for commercial products
• Reasons
• Uninformed management
• Undertrained computer professionals
• Management gives in to client pressure
• Management is unwilling to invest in training

13
Structured Systems Analysis

• Three popular graphical specification methods of
  70s
• DeMarco
• Gane and Sarsen
• Yourdon
• All equivalent
• All equally good
• Many U.S. corporations still use them for
  commercial products

14
Gane and Sarsens 9-step Specification Method

1. Draw the data flow diagram
2. Decide what sections to computerize and how
3. Determine the details of the data flows
4. Define the logic of the processes
5. Define the data stores
6. Determine the physical resources
7. Determine the input-output specifications
8. Perform the sizing
9. Determine the hardware requirements

15
Structured Systems Analysis Case Study

• Sallys Software Store buys software from
  various suppliers and sells it to the public.
  Popular software packages are kept in stock, but
  the rest must be ordered as required.
  Institutions and corporations are given credit
  facilities, as are some members of the public.
  Sallys Software Store is doing well, with a
  monthly turnover of 300 packages at an average
  retail cost of 250 each. Despite her business
  success, Sally has been advised to computerize.
  Should she?
• Better question
• What sections?
• Still better
• How? Batch, or online? In-house or out-service?

16
Case Study (contd)

• Fundamental issue
• What is Sallys objective in computerizing her
  business?
• Because she sells software?
• She needs an in-house system with sound and light
  effects
• Assume Computerization in order to make more
  money
• Cost/benefit analysis for each section of
  business

17
Data Flow Diagram (DFD)

• DFD shows logical data flow
• what happens, not how it happens

18
Step 1. Draw the DFD

• First refinement
• Infinite number of possible interpretations

19
Step 1 (contd)

• Second refinement
• pending orders scanned daily

20
Step 1 (contd)

• Portion of third refinement

21
Step 1 (contd)

• Final DFD
• Larger, but easily understood by client
• Larger DFDs
• Hierarchy
• Box becomes DFD at lower level
• Frequent problem
• Process P at level L, expanded at level L1
• Correct place for sources and destinations of
  data for process P is level L1
• Clients cannot understand DFDsources and
  destinations of data for P are missing
• Solution
• Draw correct DFD, modify by moving sources and
  destinations of data one or more levels up

22
Step 2. Decide What Parts to Computerize

• Depends on how much client is prepared to spend
• Large volumes, tight controls
• Batch
• Small volumes, in-house microcomputer
• Online
• Cost/benefit analysis

23
Step 3. Refine Data Flows

• Determine data items for each data flow
• Refine each flow stepwise
• Refine further each of the preceding components
  is refined further
• Need a data dictionary

24
Sample data dictionary entries (Fig. 11.5)
25
Step 4. Refine Logic of Processes

• Have process give educational discount
• Sally must explain discount for educational
  institutions
• 10 on up to 4 packages, 15 on 5 or more
• Translate into decision tree

26
Step 4 (contd)

• Advantage of decision tree
• Missing items are quickly apparent
• Can also use decision tables
• CASE tools for automatic translation

27
Step 5. Refine Data Stores

• Define exact contents and representation (format)
  
• COBOL specify to pic level
• Ada specify digits or delta
• Specify where immediate access is required
• Data immediate access diagram (DIAD)

28
Step 6. Define Physical Resources

• For each file, specify
• File name
• Organization (sequential, indexed, etc.)
• Storage medium
• Blocking factor
• Records (to field level)
• If DBMS is to be used, then specify
• The relevant information for each table

29
Step 7. Determine Input/Output Specs

• Specify input forms, input screens, printed output

30
Step 8. Perform Sizing

• Numerical data for Step 9 to determine hardware
  requirements
• Volume of input (daily or hourly)
• Size, frequency, deadline of each printed report
• Size, number of records passing between CPU and
  mass storage
• Size of each file

31
Step 9. Hardware Requirements

• DASD (Direct Access Storage Disk) requirements
• Mass storage for back-up
• Input needs
• Output devices
• Is existing hardware adequate?
• If not, recommend buy or lease

32
However

• Response times cannot be determined
• Number of I/O channels can only be guessed
• CPU size and timing can only be guessed
• Nevertheless, no other method provides these data
  for arbitrary products
• The method of Gane and Sarsen, DeMarco, Yourdon
  has resulted in major improvements in the
  software industry

33
Entity-Relationship (Modeling) Diagrams

• A semi-formal data-oriented (as opposed to
  structured systems analysis action-oriented)
  technique for specifying a product
• Widely used for specifying databases
• One element of object-oriented analysis
• One-to-Many relationship

34
Entity-Relationship Diagrams (contd)

• Many-to-many relationship
• Many-to-many-to-many relationship

35
Formality versus Informality

• Informal method
• English (or other natural language such as ??)
• Semiformal methods
• Structured Systems Analysis (Gane
  Sarsen/DeMarco/Yourdon)
• Entity-Relationship Diagrams
• Jackson/Orr/Warnier,
• SADT, PSL/PSA, SREM, etc.
• Formal methods
• Finite State Machines (section 11.6)
• Petri Nets (section 11.7)
• Z (section 11.8)
• ANNA, VDM, CSP, etc. (section 11.9)

36
Finite State Machines

• Case study
• A safe has a combination lock that can be in one
  of three positions, labeled 1, 2, and 3. The
  dial can be turned left or right (L or R). Thus,
  there are six possible dial movements, namely 1L,
  1R, 2L, 2R, 3L, and 3R. The combination to the
  safe is 1L, 3R, 2L any other dial movement will
  cause the alarm to go off

State Transition Diagram (STD)
37
Finite State Machines (contd)

• Transition table

38
Extended Finite State Machines

• Extend FSM with global predicates (condition or
  state)
• EFSM transition rules have form
• current state and event and predicate Þ new
  state

39
Elevator Problem

• A product is to be installed to control n
  elevators in a building with m floors. The
  problem concerns the logic required to move
  elevators between floors according to the
  following constraints
• Each elevator has a set of m buttons, one for
  each floor. These illuminate when pressed and
  cause elevator to visit corresponding floor.
  Illumination is canceled when corresponding floor
  is visited by elevator.
• Each floor, except the first and the top floor,
  has 2 buttons, one to request an up-elevator, one
  to request a down-elevator. These buttons
  illuminate when pressed. The illumination is
  canceled when an elevator visits the floor, then
  moves in the desired direction.
• If an elevator has no requests, it remains at its
  current floor with its doors closed.

40
Elevator Problem FSM

• Two sets of buttons
• Elevator buttonsin each elevator, one for each
  floor
• Floor buttonstwo on each floor, one for
  up-elevator, one for down-elevator
• EB(e, f) Elevator Button in elevator e
  pressed to request floor f

41
Elevator Buttons (contd)

• Two states
• EBON(e, f) Elevator Button (e, f) ON
• EBOFF(e, f) Elevator Button (e, f) OFF
• If button is on and elevator arrives at floor f,
  then light is turned off
• If light is off and button is pressed, then light
  comes on

42
Elevator Buttons (contd)

• Two events
• EBP(e,f) Elevator Button (e,f) Pressed
• EAF(e,f) Elevator e Arrives at Floor f
• Global predicate
• V(e,f) Elevator e is Visiting (stopped at)
  floor f
• Transition Rules
• EBOFF(e,f) and EBP(e,f) and not V(e,f) Þ
  EBON(e,f)
• EBON(e,f) and EAF(e,f) Þ EBOFF(e,f)

43
Floor Buttons

• Floor buttons
• FB(d, f) Floor Button on floor f that requests
  elevator traveling in direction d
• States
• FBON(d, f) Floor Button (d, f) ON
• FBOFF(d, f) Floor Button (d, f) OFF
• If floor button is on and an elevator arrives at
  floor f, traveling in correct direction d, then
  light is turned off
• If light is off and a button is pressed, then
  light comes on

44
Floor Buttons (contd)

• Events
• FBP(d, f) Floor Button (d, f) Pressed
• EAF(1..n, f) Elevator 1 or or n Arrives at
  Floor f
• Predicate
• S(d, e, f) elevator e is visiting floor f and
  the direction of motion is up (d U), down (d
  D), or no requests are pending (d N)
• Transition rules
• FBOFF(d, f) and FBP(d, f) and not S(d, 1..n, f)
  Þ FBON(d, f)
• FBON(d, f) and EAF(1..n, f) and S(d, 1..n, f) Þ
  FBOFF(d, f),
• d U or D

45
Elevator Problem FSM (contd)

• State of elevator consists of component
  substates, including
• Elevator slowing
• Elevator stopping
• Door opening
• Door open with timer running
• Door closing after a timeout

46
Elevator Problem FSM (contd)

• Assume elevator controller moves elevator through
  substates
• Three elevator states
• M(d, e, f) Moving in direction d (floor f is
  next)
• S(d, e, f) Stopped (d-bound) at floor f
• W(e, f) Waiting at floor f (door closed)
• For simplicity, three stopped states S(U, e, f),
  S(N, e, f), and S(D, e, f) are grouped into one
  larger state

47
Elevator Problem FSM (contd)

• Events
• DC(e,f) Door Closed for elevator e, floor f
• ST(e,f) Sensor Triggered as elevator e nears
  floor f
• RL Request Logged (button pressed)
• Transition Rules
• If elevator e is in state S(d, e, f) (stopped,
  d-bound, at floor f), and doors close, then
  elevator e will move up, down, or go into wait
  state
• DC(e,f) and S(U, e, f) Þ M(U, e, f1)
• DC(e,f) and S(D, e, f) Þ M(D, e, f-1)
• DC(e,f) and S(N, e, f) Þ W(e,f)

48
Elevator Problem FSM (contd)
49
Power of FSM to Specify Complex Systems

• No need for complex preconditions and
  postconditions
• Specifications take the simple form
• current state and event and predicate Þ next
  state

50
Power of FSM to Specify Complex Systems

• Using an FSM, a specification is
• Easy to write down
• Easy to validate
• Easy to convert into design
• Easy to generate code automatically
• More precise than graphical methods
• Almost as easy to understand
• Easy to maintain
• However
• Timing considerations are not handled

51
Who Is Using FSMs?

• Commercial products
• Menu driven
• Various states/screens
• Automatic code generation a major plus
• System software
• Operating system
• Word processors
• Spreadsheets
• Real-time systems
• Statecharts are a real-time extension of FSMs
• CASE tool Rhapsody

52
Comparison of Specification Techniques

• We must always choose the appropriate
  specification method
• Formal methods
• Powerful
• Difficult to learn and use
• Informal methods
• Little power
• Easy to learn and use
• Trade-off
• Ease of use versus power

53
Comparison of Specification Techniques (contd)
54
Which Specification Method to Use?

• Depends on the
• Project
• Development team
• Management team
• Myriad other factors

55
Testing during the Specification Phase

• Specification inspection
• A team of inspectors reviews the specifications
  against a checklist
• Have all the required functions been specified?
• Have the required hardware resources been
  specified?
• Have the acceptance criteria been specified?

56
CASE Tools for the Specification Phase

• Graphical tool
• DFD tool
• ER Diagram tool
• STD tool
• Data dictionary
• Usually provided in a case tool
• Specification method without CASE tools can
  easily fail

57
CASE Tools for the Specification Phase

• Typical tools
• Analyst/Designer
• Software through Pictures
• System Architect

58
Metrics for the Specification Phase

• Size
• Number of pages in the specification document
• Quality
• Fault statistics
• Number, type of each fault
• Rate of detection
• Metrics for predicting size of target product
• Total number of items in data dictionary
• Number of items of each type
• Number of files, processes

59
Air Gourmet Case Study Structured Sys. Anal.

• Data flow diagram reflects centrality of SPECIAL
  MEAL DATA
• See Appendix E for remainder of structured
  systems analysis

60
Air Gourmet Case Study SPMP

• The Software Project Management Plan is given in
  Appendix F

61
Challenges of the Specification Phase

• A specification document must be
• Informal enough for the client and
• Formal enough for the development team
• The specification phase (what) should not cross
  the boundary into the design phase (how)
• Read Chapter 11