Chapter15 finalizing design specifications
Download as PPT, PDF2 likes2,579 views
This document discusses finalizing design specifications for systems analysis. It describes writing quality requirement statements and using structure charts to represent hierarchical relationships between system modules. Traditional and radical design methods are presented, including evolutionary and throwaway prototyping. CASE tools can capture specifications, and extreme programming iteratively plans requirements through user story cards. The document provides an example of prototyping an electronic commerce application in Microsoft FrontPage.
Chapter15 finalizing design specifications
- 1. Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 15 Finalizing Design Specifications 15.1
- 2. Learning Objectives Discuss the need for system design specifications Define quality requirements and write quality requirements statements Read and understand a structure chart Distinguish between evolutionary and throwaway prototyping Explain the role of CASE tools in capturing design specifications Demonstrate how design specifications can be declared for Web-based applications 15.2
- 3. Introduction Need for systems to be developed more quickly today The lines between analysis and design and design and implementation are blurring Traditional approaches allowed for a break between design and implementation Other approaches, such as CASE and prototyping, have caused overlap between the two phases 15.3
- 4. The Process of Finalizing Design Specifications Less costly to correct and detect errors during the design phase Two sets of guidelines Writing quality specification statements The quality of the specifications themselves Quality requirement statements Correct Feasible Necessary Prioritized Unambiguous Verifiable15.4
- 5. The Process of Finalizing Design Specifications Quality requirements Completely described Do not conflict with other requirements Easily changed without adversely affecting other requirements Traceable back to origin 15.5
- 6. The Process of Finalizing Design Specifications Deliverables and Outcome Set of physical design specifications Contains detailed specifications for each part of the system 15.6
- 7. Representing Design Specifications Traditional Methods Pre-CASE Documents written natural language and augmented with graphical models Specification documents Figure 15-2 shows an example Several methods for streamlining Computer-based requirements tools Prototyping Visual development environments 15.7
- 8. Representing Design Specifications Structure Charts 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 15.8
- 9. Representing Design Specifications Structure Charts Module A self-contained component of a system, defined by a function One single coordinating module at the root of structure chart Single point of entry and exit Communicate with each other by passing parameters Data couple A diagrammatic representation of the data exchanged between two modules in a structure chart Flag A diagrammatic representation of a message passed between two modules 15.9
- 10. Representing Design Specifications Structure Charts Module Special Symbols Diamond Only one subordinate will be called Curved Line Subordinates are called repeatedly until terminating condition is met Predefined modules Hat Subordinate module is important logically but code is contained in superior module 15.10
- 11. Representing Design Specifications Structure Charts 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 15.11
- 12. Representing Design Specifications Prototyping Construction of the model of a system Allows developers and users to Test aspects of the overall design Check for functionality and usability Iterative process Two types Evolutionary Prototyping Throwaway Prototyping 15.12
- 13. Representing Design Specifications Prototyping Evolutionary Prototyping Begin by modeling parts of the target system If successful, evolve rest of the system from the prototype Prototype becomes actual production system Often, difficult parts of the system are prototyped first Exception handling must be added to prototype 15.13
- 14. Representing Design Specifications Prototyping Throwaway Prototyping Prototype is not preserved Developed quickly to demonstrate unclear aspect of system design Fast, easy to use development environment aids this approach 15.14
- 15. Representing Design Specifications Prototyping Oracle Designer: An Example Transforming and Generating the Database Entity-Relationship Diagramming Tool Database Design Transformer Tool Server Model Diagram End Result Generation of Data Definition Language (DDL) scripts Create database by running scripts 15.15
- 16. Representing Design Specifications Prototyping Oracle Designer: An Example Transforming and Generating Software Modules Data Flow Diagram Functional Hierarchy Diagram Application Design Transformer Transforms diagrams into software modules which can be used to generate forms or reports Generate form or report in Design Editor 15.16
- 17. Radical Methods: eXtreme Programming Short cycles Incremental planning approach Automated tests Utilizes two-person programming team Planning, analysis, design and construction are fused together into one phase Requirements and specifications are uniquely captured 15.17
- 18. Radical Methods: eXtreme Programming Planning game Players Business Development Story cards Description of procedure or system feature 15.18
- 19. Radical Methods: eXtreme Programming Planning game Three phases Exploration Business creates a story card Development responds with time estimate Commitment Business sorts story cards into three stacks Development sorts story cards according to risk Business selects cards to include in next release of product Steering Business monitors development activity 15.19
- 20. Radical Methods: eXtreme Programming Iteration Planning Game Played by programmers Task Cards Several task cards generated for each story card Three phases Exploration Story cards converted to task cards Commitment Programmers accept responsibility for tasks Steering Programmers write code, test it and integrate it Game takes place during time between intervals of planning game steering phase meetings 15.20
- 21. Radical Methods: RAD Four life-cycle phases Planning Design Construction Cutover Iteration between design and construction 15.21
- 22. Electronic Commerce Application Microsoft FrontPage used to build throwaway prototype Template based HTML 15.22
- 23. Summary Types of Design Specifications Written document augmented by various diagrams Structure chart Computer-based requirements management tool Prototypes Throwaway versus Evolutionary 15.23
- 24. Summary Radical Methods eXtreme Programming RAD Electronic Commerce Application Throwaway prototyping 15.24