© 2005 by Prentice Hall Chapter 13 Finalizing Design Specifications Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.

© 2005 by Prentice Hall© 2005 by Prentice Hall

Chapter 13 Finalizing Design

Specifications

Modern Systems Analysisand Design

Fourth Edition

Jeffrey A. Hoffer Joey F. George

Joseph S. Valacich

© 2005 by Prentice Hall© 2005 by Prentice Hall13-2

Learning ObjectivesDiscuss how design specifications vary based

on 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 design specifications.Discuss the application of design

specifications to Agile Methodologies.



The Process of Finalizing Design Specifications

Less costly to correct and detect errors during the design phaseTwo sets of guidelines: 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


Characteristics of Quality Requirement Statements

Correct: accurately describe functionality to developFeasible:possible within time and resource constraintsNecessary: something the users really needPrioritized: ranked based on level of importanceUnambiguous: clear to anyone who reads the descriptionVerifiable: possible to determine if requirement has been met


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


Design Specification Document

Contains: Overall system description Interface requirements System features Nonfunctional requirements Other requirements Supporting diagrams and models


Computer-based requirements management tools make it easier to keep documents up to date, add additional requirements and link related requirements


Structure ChartA 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 is composed of modules, self-contained system components defined by their function.

Modules are functions or subroutines in the resulting computer program.

Structure Chart Symbols


Structure Chart SymbolsData couple: diagrammatic representation of data exchanged between two modules

Flags and data couples are parameters and return values in the resulting computer program.

Flag: diagrammatic representation of a message passed between two modules



Conditional calls: only one of the subordinates is called.

Conditional call is implemented by an IF statement in the computer program.



Repetitive calls: subordinates are called repeatedly until terminating condition is met.



Predefined module: function is dictated by a preexisting part of the system.



Embedded module:

subordinate module is important logically but code is contained in superior module.


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.


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.


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


Evolutionary PrototypingBegin 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.


Throwaway Prototyping

Prototype is not preserved.It is developed quickly to demonstrate unclear aspect of system design.CASE tools aid this approach,


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


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


SummaryIn this chapter you learned how to: Discuss how design specifications vary

based on 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 design specifications. Discuss the application of design

specifications to Agile Methodologies.

© 2005 by Prentice Hall Chapter 13 Finalizing Design Specifications Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.

Documents

prentice hall chapter

system component slide

valacich slide

information system

nonfunctional requirements

additional requirements

requirements modifiable

entire system