Modern Systems Analysis
and Design
Fifth Edition
Jeffrey A. Hoffer
Joey F. George
Joseph S. Valacich
Chapter 13
Finalizing Design
Specifications
Learning Objectives
 Discuss
how the need for system
design specifications varies by
system development methodology.
 Define quality requirements and write
quality requirement statements.
Chapter 13
© 2008 by Prentice Hall
2
Learning Objectives
 Read
and understand a structure
chart.
 Explain the roles of prototyping and
CASE tools in capturing design
specifications.
Chapter 13
© 2008 by Prentice Hall
3
Learning Objectives (Cont.)
 Discuss
how design specifications
apply (or do not apply) to Agile
Methodologies.
 Demonstrate how to declare design
specifications for electronic
commerce applications.
Chapter 13
© 2008 by Prentice Hall
4
Finalizing Design Specifications
Chapter 13
© 2008 by Prentice Hall
5
The Process of Finalizing
Design Specifications
 Less
costly to correct and
detect errors during the design
phase.
 Take logical design information
and turn it into a blueprint for
the physical information system.
Chapter 13
© 2008 by Prentice Hall
6
The Process of Finalizing
Design Specifications
 Can
be paper-based or
computer-based.
 Can be written, graphical, or
combination of the two.
Chapter 13
© 2008 by Prentice Hall
7
The Process of Finalizing
Design Specifications (Cont.)
 Can
be high-level broad-based
or detailed as possible.
 Format and amount of detail will
be driven by intended audience.
Chapter 13
© 2008 by Prentice Hall
8
The Process of Finalizing
Design Specifications (Cont.)
 Good
specifications should be
stated simply, completely,
unambiguous, and have
attributes that make
requirements more
understandable.
Chapter 13
© 2008 by Prentice Hall
9
Deliverables and Outcomes for
Traditional Projects

A set of physical design specifications for
the entire system, including detailed
specifications for each separate part of the
system.
 Include
functional descriptions for each part of
the system.
 input received and output generated for each
program and its component parts.
Chapter 13
© 2008 by Prentice Hall
10
Deliverables and Outcomes for
Traditional Projects (Cont.)
Complete design specification is
comprehensive.
 Design specifications can be based on:

 Traditional
methods.
 Agile methodologies (eXtreme programming).
Chapter 13
© 2008 by Prentice Hall
11
Specification Documents

Contains:
 Overall
system description.
 Interface requirements.
 System features.
 Nonfunctional requirements.
 Other requirements.
 Supporting diagrams and models.
Chapter 13
© 2008 by Prentice Hall
12
Specification Documents (Cont.)

Computer-based requirements
management tools make it easier to keep
documents up to date, add additional
requirements and link related
requirements.
Chapter 13
© 2008 by Prentice Hall
13
Specification Documents (Cont.)
Figure 13-3 A screen from DOORS© Enterprise Requirements Suite
(a product of Telelogic AB)
Chapter 13
© 2008 by Prentice Hall
14
Specification Documents (Cont.)
Figure 13-4 A screen from Compuware Optimal Trace requirements management
and definition solution
Chapter 13
© 2008 by Prentice Hall
15
Structure Chart

Structure Chart: a hierarchical diagram
that shows how an information system is
organized.
 Shows
how an information system is
organized in hierarchical models.
 Shows how parts of a system are related to
one another.
 Shows breakdown of a system into programs
and internal structures of programs written in
third- and fourth-generation languages.
Chapter 13
© 2008 by Prentice Hall
16
Structure Chart (Cont.)
Structure chart is composed of modules.
 Modules: a self-contained component of a
system that is defined by its function.

 Functions
or subroutines in the resulting
computer program (COBOL, BASIC,
FORTRAN).
 Method in object-oriented language.
Chapter 13
© 2008 by Prentice Hall
17
Structure Chart (Cont.)
Figure 13-5 An illustration of the hierarchy of a structure chart
Chapter 13
© 2008 by Prentice Hall
18
Structure Chart (Cont.)
Data couple: a diagrammatic
representation of the data exchanges
between two modules in a structure chart.
 Flag: a diagrammatic representation of a
message passed between two modules.

Chapter 13
© 2008 by Prentice Hall
19
Structure Chart (Cont.)
Figure 13-6 Special symbols used in structure charts – Data couples and control flag
Chapter 13
© 2008 by Prentice Hall
20
Structure Chart (Cont.)
Figure 13-7 How to read a structure chart – (a) Nonoverlapping arrows
Chapter 13
© 2008 by Prentice Hall
21
Structure Chart (Cont.)
Figure 13-7 How to read a structure chart – (b) Overlapping arrows
Chapter 13
© 2008 by Prentice Hall
22
Structure Chart (Cont.)
 Pseudocode:
a method for
representing the instructions in a
module with language very similar
to computer programming code.
Chapter 13
© 2008 by Prentice Hall
23
Structure Chart (Cont.)
 Serves
two functions:
Helps
analyst think in a structured
way about the task a module is
designed to perform.
Acts as a communication tool
between analyst and programmer.
Chapter 13
© 2008 by Prentice Hall
24
Evolutionary Prototyping
Begin by modeling parts of the target
system.
 If successful, evolve remaining system
from prototype.
 Prototype becomes actual production
system.

Chapter 13
© 2008 by Prentice Hall
25
Evolutionary Prototyping (Cont.)
Often, difficult parts of the system are
prototyped first.
 Exception handling must be added to
prototype.

Chapter 13
© 2008 by Prentice Hall
26
Evolutionary Prototyping (Cont.)
Figure 13-8 McConnell’s evolutionary prototyping model
Chapter 13
© 2008 by Prentice Hall
27
Throwaway Prototyping
Prototype is not preserved.
 It is developed quickly to demonstrate
unclear aspect of system design.
 CASE tools aid this approach.

Chapter 13
© 2008 by Prentice Hall
28
Throwaway Prototyping (Cont.)
Figure 13-9 A prototype of Hoosier Burger’s inventory control system
generated with Oracle’s Designer CASE tools.
Chapter 13
© 2008 by Prentice Hall
29
Rapid Application Development

Rapid Application Development (RAD) has
four life cycle phases:
 Planning
 Design
 Construction
 Cutover
Chapter 13
© 2008 by Prentice Hall
30
Rapid Application Development
(Cont.)

RAD Trends:
 Heavy
iteration between the design phase
where requirements are captured;
 And heavy iteration in the construction phase
where the system is designed and built.
Chapter 13
© 2008 by Prentice Hall
31
Agile Methodologies

Traditional approach:
 Analysis

 design  code  test loop
Agile approach:
 Design
specifications come from code instead of
verbal text descriptions.
 Requirements  design  code

Best known method: eXtreme programming
or XP.
Chapter 13
© 2008 by Prentice Hall
32
Agile Methodologies (Cont.)
Figure 13-11 The analyze-design-code-test cycle
Chapter 13
© 2008 by Prentice Hall
33
Agile Methodologies (Cont.)
 Simple
design: the creation of
uncomplicated software and
software components that work to
solve current the current problem
rather than the creation of
complicated software designed for
a future that may not come.
Chapter 13
© 2008 by Prentice Hall
34
Agile Methodologies (Cont.)
 Simple
design reflects one of the
key values of eXtreme
Programming – simplicity.
 Refactoring: making a program
simpler after adding a new feature.
Chapter 13
© 2008 by Prentice Hall
35
Agile Methodologies (Cont.)
 XP
has four constraints that
facilitate simple design:
The
system must communicate
everything you want it to
communicate.
The system must contain no duplicate
code.
Chapter 13
© 2008 by Prentice Hall
36
Agile Methodologies (Cont.)
The
system should have the fewest
possible classes.
The system should have the fewest
possible methods.
Chapter 13
© 2008 by Prentice Hall
37
Electronic Commerce Application:
Finalizing Design Specifications for
Pine Valley Furniture’s WebStore
 Finalizing
design specifications.
 Defined required fields for each of the
pages identified in the design phase.
Chapter 13
© 2008 by Prentice Hall
38
Electronic Commerce Application:
Finalizing Design Specifications for
Pine Valley Furniture’s WebStore
 The
four key features of the humancomputer interface PVF wanted:
 Menu-driven
navigation with cookie
crumbs.
 Lightweight graphics.
 Form and data integrity rules.
 Template-based HTML.
Chapter 13
© 2008 by Prentice Hall
39
Electronic Commerce Application:
Finalizing Design Specifications for
Pine Valley Furniture’s WebStore
Figure 13-13 – (a) The Home page within the WebStore throwaway prototype
Chapter 13
© 2008 by Prentice Hall
40
Summary
 In
this chapter you learned how
to:
 Discuss
how the need for system
design specifications varies by
system development methodology.
 Define quality requirements and write
quality requirement statements.
Chapter 13
© 2008 by Prentice Hall
41
Summary (Cont.)
 Read
and understand a structure
chart.
 Explain the roles of prototyping and
CASE tools in capturing design
specifications.
Chapter 13
© 2008 by Prentice Hall
42
Summary (Cont.)
 Discuss
how design specifications
apply (or do not apply) to Agile
Methodologies.
 Demonstrate how to declare design
specifications for electronic
commerce applications.
Chapter 13
© 2008 by Prentice Hall
43