We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byIrea Bowman
Modified over 2 years ago
© 2005 by Prentice Hall Chapter 13 Finalizing Design Specifications Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich
© 2005 by Prentice Hall 13-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.
© 2005 by Prentice Hall 13-3
© 2005 by Prentice Hall 13-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
© 2005 by Prentice Hall 13-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
© 2005 by Prentice Hall 13-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
© 2005 by Prentice Hall 13-7 Design Specification Document Contains: Overall system description Interface requirements System features Nonfunctional requirements Other requirements Supporting diagrams and models
© 2005 by Prentice Hall 13-8 Computer-based requirements management tools make it easier to keep documents up to date, add additional requirements and link related requirements
© 2005 by Prentice Hall 13-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
© 2005 by Prentice Hall 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
© 2005 by Prentice Hall Structure Chart Symbols Data 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
© 2005 by Prentice Hall Structure Chart Symbols Conditional calls: only one of the subordinates is called. Conditional call is implemented by an IF statement in the computer program.
© 2005 by Prentice Hall Structure Chart Symbols Repetitive calls: subordinates are called repeatedly until terminating condition is met.
© 2005 by Prentice Hall Structure Chart Symbols Predefined module: function is dictated by a preexisting part of the system.
© 2005 by Prentice Hall Structure Chart Symbols Embedded module: subordinate module is important logically but code is contained in superior module.
© 2005 by Prentice Hall 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.
© 2005 by Prentice Hall 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.
© 2005 by Prentice Hall 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
© 2005 by Prentice Hall 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.
© 2005 by Prentice Hall Throwaway Prototyping Prototype is not preserved. It is developed quickly to demonstrate unclear aspect of system design. CASE tools aid this approach,
© 2005 by Prentice Hall Agile Methodologies Requirements functional design code Design specifications come from code instead of verbal text descriptions Example: eXtreme Programmings 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
© 2005 by Prentice Hall Factors Distinguishing Agile and Traditional System Development AgileTraditional Size SmallerLarger Criticality Better for low criticalBetter for highly critical Dynamism High dynamismHigh stability Personnel Experts needed throughout Experts only needed earlier Culture High degree of freedomWell-established procedures
© 2005 by Prentice Hall 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.
© 2005 by Prentice Hall Chapter 6 Determining System Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph.
Chapter 20 Quality Assurance Through Software Engineering Systems Analysis and Design Kendall and Kendall Fifth Edition.
Chapter 16 Quality Assurance Through Software Engineering Systems Analysis and Design Kendall & Kendall Sixth Edition.
© 2005 by Prentice Hall Appendix 3 Object-Oriented Analysis and Design Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
Computing Higher - SD Process – Topic 2 St Andrew’s High School Unit 2 Software Development Process.
Systems Analysis and Design 8 th Edition Chapter 7 Development Strategies.
CHAPTER 6: SOLVING AND PREVENTING INCIDENTS AND PROBLEMS A Guide to Customer Service Skills for the Service Desk Professional Third Edition.
1 Week 2 The Object-Oriented Approach to Requirements.
Chapter 3 Managing the Information Systems Project Modern Systems Analysis and Design Seventh Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich.
Construction process lasts until coding and testing is completed consists of design and implementation reasons for this phase –analysis model is not sufficiently.
© 2005 by Prentice Hall Chapter 9 Structuring System Data Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
10-1. Systems Analysis & Programming 10.1 Systems Development 10.2 Programming: A Five-Step Procedure Generations of Programming Languages 10.4.
Lecture 5: Requirements Engineering Dr Valentina Plekhanova University of Sunderland, UK
October DMV Team members: Lin Fry, Heather Goulet, Nancy Trefzger.
Chapter 4 Requirements Engineering Slide 1 Chapter 4 Requirements Engineering.
Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1.
CS101: INTRODUCTION TO COMPUTER PROGRAMMING LECTURE-1: INTRODUCTION TO PROBLEM SOLVING - CS002: REVIEW -
Lecture 6: Software Design (Part I) Dr Valentina Plekhanova University of Sunderland, UK
ISBN Prentice-Hall, 2006 Chapter 5 Designing the System Copyright 2006 Pearson/Prentice Hall. All rights reserved.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Topics covered l Functional and non-functional requirements l User requirements.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
© 2014 by McGraw-Hill Education. This is proprietary material solely for authorized instructor use. Not authorized for sale or distribution in any manner.
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 4 Slide 1 Requirements Engineering u Establishing what the customer requires from a software.
1 Approaches to System Development Lecture 2. 2 Aids to Assist in Analysis and Design u Methodologies l Comprehensive guidelines to follow for completing.
Acceptance and Unit Testing (introduction) Alessandro Marchetto Fondazione Bruno Kessler - IRST.
Software Process Modeling with UML and SPEM Chris Armstrong Armstrong Process Group
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 10 Architectural Design.
1 GREY BOX TESTING Web Apps & Networking Session 10 Boris Grinberg
Chapter - 5 Understanding Requirements Unit II. Introduction Definition : “The broad spectrum of tasks and techniques that lead to an understanding of.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
© 2016 SlidePlayer.com Inc. All rights reserved.