Supplementary Slides for Software Engineering A Practitioners Approach

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. 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 1

Chapter 11 Analysis Concepts and Principles 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 2

Agenda Requirements Analysis Requirements Elicitation for Software FAST QFD Analysis Principles Software Prototyping Specification Review 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 3

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. . . 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 4

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 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 5

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 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 6

Requirement Elicitation for Software Initiating the Process: use context-free questions Facilitated Application Specification Techniques (FAST) Quality Function Deployment (QFD) Use Cases 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 7

Requirements Gathering Facilitated Application Specification Techniques Software Engineering Group Customer Group 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 8

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 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 9

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 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 10

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 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 11

Use-Cases A collection of scenarios that describe 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 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 12

The Analysis Process build a prototype the problem requirements elicitation develop Specification Review create analysis models 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 13

Analysis Principle I Model the Data Domain define data objects describe data attributes establish data relationships 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 14

Analysis Principle II Model Function identify functions that transform data objects indicate how data flow through the system represent producers and consumers of data 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 15

Analysis Principle III Model Behavior indicate different states of the system specify events that cause the system to change state 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 16

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. 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 17

Analysis Principle V Essence begin by focusing on the essence of the problem without regard to implementation details 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 18

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 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 19

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. 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 20

The Analysis Model Data Model Functional Model Behavioral Model 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 21

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 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 22

Prototyping Methods and Tools Fourth Generation Techniques – 4 GL 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 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 23

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. 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 24

Specification 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. 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 25

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 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 26

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 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 27