1. Finalizing Design Specifications
Modern Systems Analysis and Design
Finalizing Design Specifications

2. Learning Objectives
Discuss how the need for system design specifications varies by system development methodology.
Define quality requirements and write quality requirement statements.
Chapter 13
© 2008 by Prentice Hall

3. Learning Objectives Read and understand a structure chart.
Explain the roles of prototyping and CASE tools in capturing design specifications.
Chapter 13
© 2008 by Prentice Hall

4. 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.
Chapter 13
© 2008 by Prentice Hall

5. Finalizing Design Specifications
Chapter 13
© 2008 by Prentice Hall

6. 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.
Chapter 13
© 2008 by Prentice Hall

7. The Process of Finalizing Design Specifications
Can be paper-based or computer-based.
Can be written, graphical, or combination of the two.
Chapter 13
© 2008 by Prentice Hall

8. 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.
Chapter 13
© 2008 by Prentice Hall

9. The Process of Finalizing Design Specifications (Cont.)
Good specifications should be stated simply, completely, unambiguous, and have attributes that make requirements more understandable.
Chapter 13
© 2008 by Prentice Hall

10. 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.
Chapter 13
© 2008 by Prentice Hall

11. Deliverables and Outcomes for Traditional Projects (Cont.)
Complete design specification is comprehensive.
Design specifications can be based on:
Traditional methods.
Agile methodologies (eXtreme programming).
Chapter 13
© 2008 by Prentice Hall

12. Specification Documents
Contains:
Overall system description.
Interface requirements.
System features.
Nonfunctional requirements.
Other requirements.
Supporting diagrams and models.
Chapter 13
© 2008 by Prentice Hall

13. Specification Documents (Cont.)
Computer-based requirements management tools make it easier to keep documents up to date, add additional requirements and link related requirements.
Chapter 13
© 2008 by Prentice Hall

14. Specification Documents (Cont.)
Figure 13-3 A screen from DOORS© Enterprise Requirements Suite
(a product of Telelogic AB)
Chapter 13
© 2008 by Prentice Hall

15. Specification Documents (Cont.)
Figure 13-4 A screen from Compuware Optimal Trace requirements management
and definition solution
Chapter 13
© 2008 by Prentice Hall

16. 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.
Chapter 13
© 2008 by Prentice Hall

17. 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.
Chapter 13
© 2008 by Prentice Hall

18. Structure Chart (Cont.)
Figure 13-5 An illustration of the hierarchy of a structure chart
Chapter 13
© 2008 by Prentice Hall

19. 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.
Chapter 13
© 2008 by Prentice Hall

20. Structure Chart (Cont.)
Figure 13-6 Special symbols used in structure charts – Data couples and control flag
Chapter 13
© 2008 by Prentice Hall

21. Structure Chart (Cont.)
Figure 13-7 How to read a structure chart – (a) Nonoverlapping arrows
Chapter 13
© 2008 by Prentice Hall

22. Structure Chart (Cont.)
Figure 13-7 How to read a structure chart – (b) Overlapping arrows
Chapter 13
© 2008 by Prentice Hall

23. Structure Chart (Cont.)
Pseudocode: a method for representing the instructions in a module with language very similar to computer programming code.
Chapter 13
© 2008 by Prentice Hall

24. 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.
Chapter 13
© 2008 by Prentice Hall

25. Evolutionary Prototyping
Begin by modeling parts of the target system.
If successful, evolve remaining system from prototype.
Prototype becomes actual production system.
Chapter 13
© 2008 by Prentice Hall

26. Evolutionary Prototyping (Cont.)
Often, difficult parts of the system are prototyped first.
Exception handling must be added to prototype.
Chapter 13
© 2008 by Prentice Hall

27. Evolutionary Prototyping (Cont.)
Figure 13-8 McConnell’s evolutionary prototyping model
Chapter 13
© 2008 by Prentice Hall

28. Throwaway Prototyping
Prototype is not preserved.
It is developed quickly to demonstrate unclear aspect of system design.
CASE tools aid this approach.
Chapter 13
© 2008 by Prentice Hall

29. Throwaway Prototyping (Cont.)
Figure 13-9 A prototype of Hoosier Burger’s inventory control system
generated with Oracle’s Designer CASE tools.
Chapter 13
© 2008 by Prentice Hall

30. Rapid Application Development
Rapid Application Development (RAD) has four life cycle phases:
Planning
Design
Construction
Cutover
Chapter 13
© 2008 by Prentice Hall

31. 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.
Chapter 13
© 2008 by Prentice Hall

32. Agile Methodologies Traditional approach: Agile 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.
Chapter 13
© 2008 by Prentice Hall

33. Agile Methodologies (Cont.)
Figure The analyze-design-code-test cycle
Chapter 13
© 2008 by Prentice Hall

34. 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.
Chapter 13
© 2008 by Prentice Hall

35. 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.
Chapter 13
© 2008 by Prentice Hall

36. 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.
Chapter 13
© 2008 by Prentice Hall

37. Agile Methodologies (Cont.)
The system should have the fewest possible classes.
The system should have the fewest possible methods.
Chapter 13
© 2008 by Prentice Hall

38. Finalizing design specifications.
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.
Chapter 13
© 2008 by Prentice Hall

39. The four key features of the human-computer interface PVF wanted:
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.
Chapter 13
© 2008 by Prentice Hall

40. Electronic Commerce Application: Finalizing Design Specifications for Pine Valley Furniture’s WebStore
Figure – (a) The Home page within the WebStore throwaway prototype
Chapter 13
© 2008 by Prentice Hall

41. 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.
Chapter 13
© 2008 by Prentice Hall

42. Summary (Cont.) Read and understand a structure chart.
Explain the roles of prototyping and CASE tools in capturing design specifications.
Chapter 13
© 2008 by Prentice Hall

43. Summary (Cont.)
Discuss how design specifications apply (or do not apply) to Agile Methodologies.
Demonstrate how to declare design specifications for electronic commerce applications.
Chapter 13
© 2008 by Prentice Hall