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.
 Read and understand a structure chart.
 Explain the roles of prototyping and CASE
tools in capturing design specifications.

Chapter 13
© 2008 by Prentice Hall
2
Finalizing Design Specifications
Chapter 13
© 2008 by Prentice Hall
3
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.
Can be paper-based or computer-based.
Can be written, graphical, or combination of the two.
Can be high-level broad-based or detailed as possible.
Format and amount of detail will be driven by intended
audience.
Good specifications should be stated simply, completely,
unambiguous, and have attributes that make requirements more
understandable.
Chapter 13
© 2008 by Prentice Hall
4
Design Specification Documents

Contains:
 Overall
system description.
 Interface requirements.
 System features.
 Nonfunctional requirements.
 Other requirements.
 Supporting diagrams and models (e.g.,
structure chart).
Chapter 13
© 2008 by Prentice Hall
5
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
6
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
7
Structure Chart (Cont.)


Pseudocode: a method for representing the instructions
in a module with language very similar to computer
programming code.
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
8
Roles of prototyping in capturing design
specifications
Evolutionary Prototyping





Begin by modeling parts of the target system.
If successful, evolve remaining system from prototype.
Prototype becomes actual production system.
Often, difficult parts of the system are prototyped first.
Exception handling must be added to prototype.
Chapter 13
© 2008 by Prentice Hall
10
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
11
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.
Read and understand a structure chart.
Explain the roles of prototyping in capturing design specifications.
Chapter 13
© 2008 by Prentice Hall
12
Descargar

Modern Systems Analysis and Design Ch1