Modern Systems Analysis
and Design
Hoffer, George & Valacich
Chapter 13
Finalizing Design Specifications
1
Course: Physical System Design and Implementation ITBIS395
Learning Objectives
 Discuss the need for system design
specifications
 Define quality requirements and write quality
requirements statements
 Read and understand a structure chart
 Distinguish between evolutionary and
throwaway prototyping
 Explain the role of CASE tools in capturing
design specifications
2
Where do we stand ?
3
Introduction
• Need for systems to be developed more quickly
today
• The lines between analysis and design and
design and implementation are blurring
 Traditional approaches allowed for a break
between design and implementation
 Recent approaches, such as CASE and
prototyping, in addition to new system
development methodologies have caused overlap
between the two phases
4
Finalizing Design Specifications
• Is the process of transforming all
information reached to at this stage (input,
output, interface, dialog and database) into
a set of final and complete design
specifications document, also known as
software requirement specification.
5
The Process of Finalizing design
specification
• It is much easier and much cheaper, to
detect and correct errors at this point than
it is to detect and correct errors during
implementation.
• There are several guidelines you can
follow to help you in your conversion from
logical to physical design.
6
The Process of Finalizing Design
Specifications
• Two sets of guidelines in conversion from
logical to physical:
 Writing quality specification statements (six
characteristics)
 The quality of the specifications themselves
(four characteristics)
7
Characteristics of Quality
specification Statements
1- Correct: should accurately describe the functionality
to be developed
2- Feasible: must be possible based on the
environment and the system
3- Necessary: must be something the users really need
4- Prioritized: should be assigned a priority rating,
which reflects its importance
5- Unambiguous: should be clear with only one way to
interpret each statement
6- Verifiable: should be possible to determine if it has
been successfully implemented
8
Characteristics of Quality Requirements
1- Complete: should not miss any key description
information.
2- Consistent: Do not conflict with other
requirements specified for the system.
3- Modifiable: A quality requirement can be altered, with
a history kept of the changes that are made. Each quality
requirement, then must be unambiguously labeled and
kept separate from other requirement.
4- Traceable: Can be traced back to origin
source
9
• Example of a poorly written requirements statement for a
low quality requirement. “ the product shall provide
status message at regular intervals not less than
every 60 seconds”
• The statement is ambiguous.
• We cant tell what “the product” is,
• The information about timing of message is not at all
clear., and
• The requirement itself is incomplete.
10
• Here is a suggested solution:
• 1. Status Messages.
• 1.1: The Background Task Manager shall display
status message in a designated area of the user
interface at interval of 60 plus or minus 10
seconds.
1.2: If background processing is progressing normally, the
percentage of the background task processing that
has been completed shall be displayed.
11
• 1.3: A message shall be displayed when the background
•
task is completed.
• 1.4: An error message, shall be displayed if the
•
background task has stalled.
12
Deliverables and Outcome for
Traditional Projects
• The Design specification include functional
descriptions for each part of the system,
as well as information about input received
and output generated for each program
and its component parts.
• Table 13-3 provides more detailed
information on the contents of a design
specification.
13
14
• Specification Documents
• Information systems are extremely complicated
things, especially in today’s and Internet oriented
environment. Fig (13-2) give an example of just
how much information needs to be provided in a
specification documentation, examine the partial
list of information required for such document for
the government of the state Maryland.
15
16
17
Traditional Methods For Representing Design
Specification
Several methods for streamlining(‫)التبسيط‬
1.Computer-based requirements tools (Fig 13-3).
-Make it easier for analysts to keep requirements
documents up-to date.
-Add additional information about specification.
-Define links between different parts of the overall
specification package.
2. Prototyping
3. Visual development environment
18
19
Structure Charts For Representing Design
Specification
1. Hierarchical diagram shows how an information
system is organized in hierarchical models.
2. Shows how parts of a system are related to
one another.
3. Shows breakdown of a system written in third
and fourth generation languages.
4. Refines the data and processing of DFDs into a
“good programming” design structure
20
Structure Charts Notations
Main menu
• Module (method)
 Small unit of a system that
is defined by its function.
 One single coordinating
module at the root of
Main menu opts
structure chart
 Modules in the middle may
call additional modules
below
 Mostly, a module has a
single point of entry and
exit.
 Modules at the lowest
levels do not call any other
modules, they only perform
specific task.
Additional modules
21
Structure Charts Notations
• Communicate with each other
by passing parameters
• Data couple: A diagrammatic
representation of the data
exchanged between two
modules in a structure chart
• Flag: A diagrammatic
representation of a control or
message passed between two
modules
Data
Couple
Flag
22
Structure Charts Notations
Special Module Symbols:
• Diamond: Only one
subordinate will be called
(conditional/selection)
• Curved Line: Subordinates
are called repeatedly until
terminating condition is met
(looping)
23
Structure Charts Notations
• Predefined modules:
its function is dictated
by a preexisting part of
the system (e.g. OS
functionality)
• Hat: Subordinate
module is important
logically but code is
contained in superior
module (code block)
24
1. The system module first calls the Get Valid A module.
2. Get valid A first calls the module Read A, which executes its function and
returns the data couple A to its coordinating module (boss module).
3. A is then passed to validate A, which returns the data couple Valid A.
4. Control is returned to get valid A, which then returns the data couple Valid A
and control to the boss module.
5. A similar set of steps occurs in connection with the data couple Valid B.
6. Next valid A and valid B are passed to make C, which returns the data
couple C and control to the system module.
7. Finally, the system module calls put C and pass C to the module.
25
Structure Charts and Pseudocode
Pseudocode: Method used for representing the
instructions inside a module (description), very
similar to computer programming code.
Has 2 functions:
1. Helps analyst think in a structured way about
the task a module is designed to perform
2. Acts as a communication tool between analyst
and programmer
26
Example of Pseudocode
while not at end of list
compare adjacent elements
if second is greater than first
switch them
get next two elements
if elements were switched
repeat for entire list
27
Prototyping
• Construction of the model of a system
• Allows developers and users to
 Test aspects of the overall design
 Check for functionality and usability
• Iterative process
• Two types
 Evolutionary Prototyping
 Throwaway Prototyping
28
Evolutionary Prototyping
•
•
•
•
•
Begin by modeling parts of the target system
If successful, evolve rest of the system from the prototype
Prototype becomes actual production system
Often, difficult parts of the system are prototyped first
Prototyping usually lacks support for security, networking and
scalability
• Exception handling must be added to prototype, exceptions are 90%
of system function
29
Throwaway Prototyping
•
•
•
•
Prototype is not preserved
Developed quickly to demonstrate unclear aspect of system design
Fast, easy to use development environment aids this approach
Best developed with the aid of CASE tools or Automated
Development
30
Rapid Appln Development (RAD)
•
Has Four life cycle phases:
1.
2.
3.
4.
Planning
Design
Construction
Cutover
31
Agile Methodologies
• Requirements  functional design  code
Test
• Design specifications come from code
instead of verbal text descriptions
• Example: eXtreme Programming’s Planning
Game
 Two techniques:
 Simple design: uncomplicated program component to
solve current (not anticipated) problem
 Refactoring: make a program simpler after adding a new
feature
32