Chapter 13
Finalizing Design Specifications
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 1
Learning Objectives
14. Explain the roles of prototyping and CASE
tools in capturing design specifications.



Describe how the need for system design
specifications varies by system development
methodology.
Define quality requirements and write quality
requirements statements.
Explain and use a structure chart.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 2
Learning Objectives
 Explain the role of prototyping and CASE tools in
capturing design specifications.
 Describe the application of design specifications to
Agile Methodologies.
 Demonstrate how to declare design specifications
for Web-based applications.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 3
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 4
The Process of Finalizing Design
Specifications
• It is less costly to correct and detect errors
during the design phase.
• Two sets of guidelines to be used:


The quality requirements statements.
The quality requirements themselves.
• Deliverable: a set of design specifications for
the entire system, with detailed functional
descriptions of each system component
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 5
Characteristics of Quality Requirement
Statements
• Correct: accurately describe functionality to develop.
• Feasible: possible within time and resource
constraints.
• Necessary: something the users really need.
• Prioritized: ranked based on level of importance.
• Unambiguous: clear to anyone who reads the
description.
• Verifiable: possible to determine if requirement has
been met.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 6
Characteristics of Quality Requirements
• Complete: not missing any key description
information.
• Consistent: does not conflict with other
requirements.
• Modifiable: easily changed, with a history
kept of changes.
• Traceable: to its original source.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 7
Design Specification Document
• Contains:






Overall system description.
Interface requirements.
System features.
Nonfunctional requirements.
Other requirements.
Supporting diagrams and models.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 8
Computer-based
requirements
management tools
make it easier to
keep documents up
to date, add
additional
requirements and
link related
requirements
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 9
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.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 10
Structure Chart Symbols
Structure chart is
composed of
modules, selfcontained system
components
defined by their
function.
Modules are functions or subroutines in
the resulting computer program.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 11
Structure Chart Symbols
Data couple:
diagrammatic
representation of
data exchanged
between two
modules.
Flags and data couples are parameters and
return values in the resulting computer
program.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 12
Flag:
diagrammatic
representation of
a message
passed between
two modules.
Structure Chart Symbols
Conditional calls:
only one of the
subordinates is
called.
Conditional call is implemented by an IF
statement in the computer program.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 13
Structure Chart Symbols
Repetitive calls:
subordinates are
called repeatedly
until terminating
condition is met.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 14
Structure Chart Symbols
Predefined
module:
function is
dictated by a
preexisting part
of the system.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 15
Structure Chart Symbols
Embedded
module:
subordinate
module is
important
logically but
code is
contained in
superior
module.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 16
Order of execution is basically left-to-right, depth first. You
use the returned data couple from the left module as you go
to the right module.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 17
Because of redundancy of Validate Data module, the order of
sub-module calls for Get Valid B is right to left. Again, the
received data couple B from Read B is subsequently sent to
Validate Data.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 18
Pseudocode
• Method used for representing the instructions inside
a module.
• Language similar to computer programming code.
• 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.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 19
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.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 20
Throwaway Prototyping
• Prototype is not
preserved.
• It is developed
quickly to
demonstrate unclear
aspect of system
design.
• CASE tools aid this
approach,
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 21
Agile Methodologies
• Requirements  functional design  code
• 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.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 22
Factors Distinguishing Agile and Traditional
System Development
Agile
Traditional
Size
Smaller
Larger
Criticality
Better for low critical
Better for highly critical
Dynamism
High dynamism
High stability
Personnel
Experts needed throughout
Experts only needed earlier
Culture
High degree of freedom
Well-established
procedures
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 23
Summary
In this chapter you learned how to:
14. Explain the roles of prototyping and CASE
tools in capturing design specifications.



Describe how the need for system design
specifications varies by system development
methodology.
Define quality requirements and write quality
requirements statements.
Explain and use a structure chart.
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 24
 Explain the role of prototyping and CASE tools in
capturing design specifications.
 Describe the application of design specifications to
Agile Methodologies.
 Demonstrate how to declare design specifications
for Web-based applications
© 2006 ITT Educational Services Inc.
SE350 System Analysis for Software Engineers: Unit 10 Slide 25
Descargar

Modern Systems Analysis and Design Ch13