© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 1 Chapter 13 Finalizing Design Specifications

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 2 Learning Objectives 14.Explain the roles of prototyping and CASE tools in capturing design specifications.  Describe how the need for system design specifications varies by system development methodology.  Define quality requirements and write quality requirements statements.  Explain and use a structure chart.

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 3  Explain the role of prototyping and CASE tools in capturing design specifications.  Describe the application of design specifications to Agile Methodologies.  Demonstrate how to declare design specifications for Web-based applications. Learning Objectives

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 4

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 5 The Process of Finalizing Design Specifications It is less costly to correct and detect errors during the design phase. Two sets of guidelines to be used:  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

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 6 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.

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 7 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.

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 8 Design Specification Document Contains:  Overall system description.  Interface requirements.  System features.  Nonfunctional requirements.  Other requirements.  Supporting diagrams and models.

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 9 Computer-based requirements management tools make it easier to keep documents up to date, add additional requirements and link related requirements

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 10 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.

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 11 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

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 12 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.

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 13 Structure Chart Symbols Conditional calls: only one of the subordinates is called. Conditional call is implemented by an IF statement in the computer program.

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 14 Structure Chart Symbols Repetitive calls: subordinates are called repeatedly until terminating condition is met.

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 15 Structure Chart Symbols Predefined module: function is dictated by a preexisting part of the system.

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 16 Structure Chart Symbols Embedded module: subordinate module is important logically but code is contained in superior module.

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 17 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.

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 18 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.

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 19 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.

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 20 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.

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 21 Throwaway Prototyping Prototype is not preserved. It is developed quickly to demonstrate unclear aspect of system design. CASE tools aid this approach,

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 22 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.

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 23 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 throughoutExperts only needed earlier Culture High degree of freedomWell-established procedures

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 24 Summary In this chapter you learned how to: 14.Explain the roles of prototyping and CASE tools in capturing design specifications.  Describe how the need for system design specifications varies by system development methodology.  Define quality requirements and write quality requirements statements.  Explain and use a structure chart.

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 25  Explain the role of prototyping and CASE tools in capturing design specifications.  Describe the application of design specifications to Agile Methodologies.  Demonstrate how to declare design specifications for Web-based applications