1. Chapter 13 Finalizing Design Specifications
Modern Systems Analysis and Design Fourth Edition
Chapter 13
Finalizing Design Specifications

2. Learning Objectives
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.

4. The Process of Finalizing Design Specifications
Less costly to correct and detect errors during the design phase
Two 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

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

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

7. Design Specification Document
Contains:
Overall system description
Interface requirements
System features
Nonfunctional requirements
Other requirements
Supporting diagrams and models

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

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

10. Structure Chart Symbols
A structure chart is hierarchical diagram that shows how an information system is organized:
composed of modules, self-contained system components defined by their function.

11. Structure Chart Symbols
Data couple: diagrammatic representation of data exchanged between two modules
Flag: diagrammatic representation of a message passed between two modules
Flags and data couples are parameters and return values in the resulting computer program.

12. Structure Chart Symbols
Conditional calls: only one of the subordinates is called.
Conditional call is implemented by an IF statement in the computer program.

13. Structure Chart Symbols
Repetitive calls: subordinates are called repeatedly until terminating condition is met.

14. Structure Chart Symbols
Predefined module: function is dictated by a preexisting part of the system.

15. Structure Chart Symbols
Embedded module:
subordinate module is important logically but code is contained in superior module.

16. Order of execution is basically left-to-right, depth first
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.

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.

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

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.

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

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

22. Factors Distinguishing Agile and Traditional System Development
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

23. Summary In 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.