SAD Chapter 11 Finalizing Design Specification PDF

Modern Systems Analysis and Design Finalizing Design Specifications 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 ©...

Modern Systems Analysis and Design Finalizing Design Specifications 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 2 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 3 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 4 Finalizing Design Specifications Chapter 13 © 2008 by Prentice Hall 5 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 6 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 7 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 8 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 9 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 10 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 11 Specification Documents Contains:  Overall system description.  Interface requirements.  System features.  Nonfunctional requirements.  Other requirements.  Supporting diagrams and models. Chapter 13 © 2008 by Prentice Hall 12 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 13 Specification Documents (Cont.) Figure 13-3 A screen from DOORS© Enterprise Requirements Suite (a product of Telelogic AB) Chapter 13 © 2008 by Prentice Hall 14 Specification Documents (Cont.) Figure 13-4 A screen from Compuware Optimal Trace requirements management and definition solution Chapter 13 © 2008 by Prentice Hall 15 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 16 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 17 Structure Chart (Cont.) Figure 13-5 An illustration of the hierarchy of a structure chart Chapter 13 © 2008 by Prentice Hall 18 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 19  Structure Chart (Cont.) Figure 13-6 Special symbols used in structure charts – Data couples and control flag Chapter 13 © 2008 by Prentice Hall 20 Structure Chart (Cont.) Figure 13-7 How to read a structure chart – (a) Nonoverlapping arrows Chapter 13 © 2008 by Prentice Hall 21 Structure Chart (Cont.) Figure 13-7 How to read a structure chart – (b) Overlapping arrows Chapter 13 © 2008 by Prentice Hall 22 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:  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 13-11 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 without 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 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 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. 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 13-13 – (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 44