1. 1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e copyright © 1996, 2001 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.

2. 2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 11 Analysis Concepts and Principles

3. 3 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Agenda  Requirements Analysis  Requirements Elicitation for Software  FAST  QFD  Analysis Principles  Software Prototyping  Specification  Review

4. 4 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 What Are the Real Problems? the customer has only a vague idea of what is required the developer is willing to proceed with the "vague idea" on the assumption that "we'll fill in the details as we go" the customer keeps changing requirements the developer is confused by these changes, making errors in specifications and development and so it goes...

5. 5 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Software Requirements Analysis  identify the “customer” and work together to negotiate “product-level” requirements  build an analysis model  focus on data  define function  represent behavior  prototype areas of uncertainty  develop a specification that will guide design  conduct formal technical reviews

6. 6 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Requirement Analysis Phases  Problem Recognition  Study the system specification (if exists)  Study the Project Plan (if exists)  Problem Evaluation and Solution Synthesis  Primary focus is on WHAT not on HOW  Modeling  Specification  Review

7. 7 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Requirement Elicitation for Software  Initiating the Process: use context-free questions  Facilitated Application Specification Techniques (FAST)  Quality Function Deployment (QFD)  Use Cases

8. 8 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Requirements Gathering Facilitated Application Specification Techniques Software Engineering Group Customer Group

9. 9 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 FAST Guidelines  participants must attend entire meeting  all participants are equal  preparation is as important as meeting  all pre-meeting documents are to be viewed as “proposed”  off-site meeting location is preferred  set an agenda and maintain it  don’t get mired in technical detail J. Wood & D. Silver

10. 10 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Quality Function Deployment  Translate customer needs into technical software requirements  Customer Voice Tables (contains summary of requirements)  Identify three types of requirements:  Normal Requirements – must be present in product for the customer to be satisfied  Expected Requirements – things like ease of use or reliability of operation, that customer assumes will be present in a professionally developed product without having to request them explicitly  Exciting Requirements – features that go beyond the customer’s expectations and prove to be very satisfying when they are present

11. 11 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Quality Function Deployment  Function deployment determines the “value” (as perceived by the customer) of each function required of the system  Information deployment identifies data objects and events  Task deployment examines the behavior of the system  Value analysis determines the relative priority of requirements

12. 12 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Use-Cases  A collection of scenarios that describe the thread of usage of a system  Each scenario is described from the point-of- view of an “actor”—a person or device that interacts with the software in some way  Each scenario answers the following questions:  What are the main tasks of functions performed by the actor?  What system information will the actor acquire, produce or change?  Will the actor inform the system about environmental changes?  What information does the actor require of the system?  Does the actor wish to be informed about unexpected changes

13. 13 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The Analysis Process the problem requirementselicitation build a prototype createanalysismodels develop Specification Review

14. 14 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Analysis Principle I Model the Data Domain  define data objects  describe data attributes  establish data relationships

15. 15 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Analysis Principle II Model Function  identify functions that transform data objects  indicate how data flow through the system  represent producers and consumers of data

16. 16 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Analysis Principle III Model Behavior  indicate different states of the system  specify events that cause the system to change state

17. 17 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Analysis Principle IV Partition the Models  Refine each model to represent lower levels of abstraction  refine data objects  create a functional hierarchy  represent behavior at different levels of detail  Horizontal Partitioning – Decomposition of the system Function, Behavior or Information one level at a time  Vertical Partitioning – Elaboration of the system function, behavior, or information, one subsystem at a time.

18. 18 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Analysis Principle V Essence  begin by focusing on the essence of the problem without regard to implementation details

19. 19 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Software Requirement Views  Essential View – presents the functions to be accomplished and the information to be processed without regard to implementation  Implementation View – presents the real world manifestation of processing functions and information structures  Avoid the temptation to move directly to the implementation view, assuming the essence of the problem is obvious

20. 20 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Davis’ Principles  Understand the problem before you begin to create the analysis model.  Develop prototypes that enable a user to understand how human-machine interaction will occur.  Record the origin of and the reason for every requirement.  Use multiple views of requirements.  Prioritize requirements.  Work to eliminate ambiguity.

21. 21 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The Analysis Model Data Model Behavioral Model Functional Model

22. 22 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Software Prototyping  Throwaway prototyping – prototype only used as a demonstration of product requirements, finished software is engineered using another system  Evolutionary prototyping – prototype is refined to build the finished system  Customer resources must be committed to evaluation and refinement of the prototype  Customer must be capable of making requirements decisions in a timely manner

23. 23 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Prototyping Methods and Tools  Fourth Generation Techniques – 4GL tools allow software engineer to generate executable code directly  Reusable Software Components – assembling prototype from a set of existing software components  Formal specification and prototyping environments – can interactively create executable programs from software specification models

24. 24 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Specification Principles  Separate functionality from implementation  Develop a behavioral model that describes functional responses to all system stimuli.  Establish the context in which software operates by specifying the manner in which other system components interact with software.  Define the environment in which the system operates and indicate how the collection of agents will interact with it.  Create a cognitive model rather than an implementation model.  Recognize that the specification must be extensible and tolerant of incompleteness.  Establish the content and structure of a specification so that it can be changed easily.

25. 25 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Specification Representation  Representation format and content should be relevant to the problem.  Information contained within the specification should be nested.  Diagrams and other notational forms should be restricted in number and consistent in use.  Representations should be revisable.

26. 26 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The Software Requirement Specification  Introduction  Information Description  Functional Description  Behavioral Description  Validation Criteria  Bibliography and Appendix  May accompany with executable prototypes, a paper prototype or a Preliminary User’s Manual

27. 27 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Specification Review  Constructed by customer and software developer  Once approved, the specification becomes a contract for software development  The specification is difficult to test in a meaningful way  Assessing the impact of specification changes is hard to do