Post on 03-Jan-2016
Finalizing Design Specifications
Modern Systems Analysisand Design
© 2008 by Prentice Hall 2Chapter 13
Learning Objectives
Discuss how the need for system design specifications varies by system development methodology.
Define quality requirements and write quality requirement statements.
© 2008 by Prentice Hall 3Chapter 13
Learning Objectives
Read and understand a structure chart.
Explain the roles of prototyping and CASE tools in capturing design specifications.
© 2008 by Prentice Hall 4Chapter 13
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.
Finalizing Design Specifications
© 2008 by Prentice Hall 5Chapter 13
© 2008 by Prentice Hall 6Chapter 13
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.
© 2008 by Prentice Hall 7Chapter 13
The Process of Finalizing Design Specifications
Can be paper-based or computer-based.
Can be written, graphical, or combination of the two.
© 2008 by Prentice Hall 8Chapter 13
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.
© 2008 by Prentice Hall 9Chapter 13
The Process of Finalizing Design Specifications (Cont.)
Good specifications should be stated simply, completely, unambiguous, and have attributes that make requirements more understandable.
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.
© 2008 by Prentice Hall 10Chapter 13
Deliverables and Outcomes for Traditional Projects (Cont.) Complete design specification is
comprehensive. Design specifications can be based on:
Traditional methods.Agile methodologies (eXtreme programming).
© 2008 by Prentice Hall 11Chapter 13
© 2008 by Prentice Hall 12Chapter 13
Specification Documents
Contains:Overall system description. Interface requirements.System features.Nonfunctional requirements.Other requirements.Supporting diagrams and models.
Specification Documents (Cont.)
Computer-based requirements management tools make it easier to keep documents up to date, add additional requirements and link related requirements.
© 2008 by Prentice Hall 13Chapter 13
Specification Documents (Cont.)
© 2008 by Prentice Hall 14Chapter 13
Figure 13-3 A screen from DOORS© Enterprise Requirements Suite(a product of Telelogic AB)
Specification Documents (Cont.)
© 2008 by Prentice Hall 15Chapter 13
Figure 13-4 A screen from Compuware Optimal Trace requirements management and definition solution
© 2008 by Prentice Hall 16Chapter 13
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.
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.
© 2008 by Prentice Hall 17Chapter 13
Structure Chart (Cont.)
© 2008 by Prentice Hall 18Chapter 13
Figure 13-5 An illustration of the hierarchy of a structure chart
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.
© 2008 by Prentice Hall 19Chapter 13
Structure Chart (Cont.)
© 2008 by Prentice Hall 20Chapter 13
Figure 13-6 Special symbols used in structure charts – Data couples and control flag
Structure Chart (Cont.)
© 2008 by Prentice Hall 21Chapter 13
Figure 13-7 How to read a structure chart – (a) Nonoverlapping arrows
Structure Chart (Cont.)
© 2008 by Prentice Hall 22Chapter 13
Figure 13-7 How to read a structure chart – (b) Overlapping arrows
Structure Chart (Cont.)
Pseudocode: a method for representing the instructions in a module with language very similar to computer programming code.
© 2008 by Prentice Hall 23Chapter 13
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.
© 2008 by Prentice Hall 24Chapter 13
Evolutionary Prototyping Begin by modeling parts of the target
system. If successful, evolve remaining system
from prototype. Prototype becomes actual production
system.
© 2008 by Prentice Hall 25Chapter 13
Evolutionary Prototyping (Cont.) Often, difficult parts of the system are
prototyped first. Exception handling must be added to
prototype.
© 2008 by Prentice Hall 26Chapter 13
© 2008 by Prentice Hall 27Chapter 13
Evolutionary Prototyping (Cont.)
Figure 13-8 McConnell’s evolutionary prototyping model
Throwaway Prototyping
Prototype is not preserved. It is developed quickly to demonstrate
unclear aspect of system design. CASE tools aid this approach.
© 2008 by Prentice Hall 28Chapter 13
© 2008 by Prentice Hall 29Chapter 13
Throwaway Prototyping (Cont.)Figure 13-9 A prototype of Hoosier Burger’s inventory control systemgenerated with Oracle’s Designer CASE tools.
Rapid Application Development
Rapid Application Development (RAD) has four life cycle phases:PlanningDesignConstructionCutover
© 2008 by Prentice Hall 30Chapter 13
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.
© 2008 by Prentice Hall 31Chapter 13
© 2008 by Prentice Hall 32Chapter 13
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.
© 2008 by Prentice Hall 33Chapter 13
Agile Methodologies (Cont.)
Figure 13-11 The analyze-design-code-test cycle
© 2008 by Prentice Hall 34Chapter 13
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.
© 2008 by Prentice Hall 35Chapter 13
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.
© 2008 by Prentice Hall 36Chapter 13
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.
© 2008 by Prentice Hall 37Chapter 13
Agile Methodologies (Cont.)
The system should have the fewest possible classes.
The system should have the fewest possible methods.
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.
© 2008 by Prentice Hall 38Chapter 13
Electronic Commerce Application: Finalizing Design Specifications for Pine Valley Furniture’s WebStore The four key features of the human-
computer interface PVF wanted:Menu-driven navigation with cookie
crumbs.Lightweight graphics.Form and data integrity rules.Template-based HTML.
© 2008 by Prentice Hall 39Chapter 13
Electronic Commerce Application: Finalizing Design Specifications for Pine Valley Furniture’s WebStore
© 2008 by Prentice Hall 40Chapter 13
Figure 13-13 – (a) The Home page within the WebStore throwaway prototype
© 2008 by Prentice Hall 41Chapter 13
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.
© 2008 by Prentice Hall 42Chapter 13
Summary (Cont.)Read and understand a structure
chart.Explain the roles of prototyping and
CASE tools in capturing design specifications.
© 2008 by Prentice Hall 43Chapter 13
Summary (Cont.)Discuss how design specifications
apply (or do not apply) to Agile Methodologies.
Demonstrate how to declare design specifications for electronic commerce applications.