finalizing design specifications modern systems analysis and design

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.


Learning Objectives

Read and understand a structure chart.

Explain the roles of prototyping and CASE tools in capturing design specifications.


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



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.


The Process of Finalizing Design Specifications

Can be paper-based or computer-based.

Can be written, graphical, or combination of the two.


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.


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.


Deliverables and Outcomes for Traditional Projects (Cont.) Complete design specification is

comprehensive. Design specifications can be based on:

Traditional methods.Agile methodologies (eXtreme programming).



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.




Figure 13-3 A screen from DOORS© Enterprise Requirements Suite(a product of Telelogic AB)



Figure 13-4 A screen from Compuware Optimal Trace requirements management and definition solution


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.




Figure 13-5 An illustration of the hierarchy of a structure chart


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.




Figure 13-6 Special symbols used in structure charts – Data couples and control flag



Figure 13-7 How to read a structure chart – (a) Nonoverlapping arrows



Figure 13-7 How to read a structure chart – (b) Overlapping arrows


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.


Evolutionary Prototyping Begin by modeling parts of the target

system. If successful, evolve remaining system

from prototype. Prototype becomes actual production

system.


Evolutionary Prototyping (Cont.) Often, difficult parts of the system are

prototyped first. Exception handling must be added to

prototype.



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.



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


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.



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.


Agile Methodologies (Cont.)

Figure 13-11 The analyze-design-code-test cycle


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.



Simple design reflects one of the key values of eXtreme Programming – simplicity.

Refactoring: making a program simpler after adding a new feature.


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.



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.


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.


Electronic Commerce Application: Finalizing Design Specifications for Pine Valley Furniture’s WebStore


Figure 13-13 – (a) The Home page within the WebStore throwaway prototype


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.


Summary (Cont.)Read and understand a structure

chart.Explain the roles of prototyping and

CASE tools in capturing design specifications.


Summary (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 modern systems analysis and design

Documents

prentice halldeliverables

system design specifications

physical design specifications

design phase

detailed specifications

complete design specification

logical design information

quality requirements