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 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 "racheted" by these changes, making errors in specifications and development and so it goes...

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

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

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

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

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

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 The Analysis Process the problem requirementselicitation build a prototype createanalysismodels develop Specification Review

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

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

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

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

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

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

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

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

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 Chapter 12 Analysis Modeling

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 Analysis Modeling: Where to Begin?  A statement of scope can be acquired from:  the FAST working document  A set of use-cases  the statement of scope must be “parsed” to extract data, function and behavioral domain information

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 Statement of Scope  a relatively brief description of the system to be built  indicates data that are input and output and basic functionality  indicates conditional processing (at a high level)  implies certain constraints and limitations

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 Identifying Objects and Operations  define “objects” by underlining all nouns in the written statement of scope  producers/consumers of data  places where data are stored  “composite” data items  define “operations” by double underlining all active verbs  processes relevant to the application  data transformations  consider other “services” that will be required by the objects

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 Data Modeling and Entity Relationship (E-R) Diagramming

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 Why Data Modeling?  examines data objects independently of processing  focuses attention on the data domain  creates a model at the customer’s level of abstraction  indicates how data objects relate to one another

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 What is a Data Object? Object —something that is described by a set of attributes (data items) and that will be manipulated within the software (system) eachinstance of an object (e.g., a book) of an object (e.g., a book) can be identified uniquely (e.g., ISBN #) each plays a necessary role in the system i.e., the system could not function without access to instances of the object each is described by attributes that are themselves data items

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 Typical Objects external entities (printer, user, sensor) things (e.g, reports, displays, signals) (e.g, reports, displays, signals) occurrences or events (e.g., interrupt, alarm) roles (e.g., manager, engineer, salesperson) organizational units (e.g., division, team) (e.g., division, team) places (e.g., manufacturing floor) (e.g., manufacturing floor) structures (e.g., employee record)

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 Data Objects and Attributes A data object contains a set of attributes that act as an aspect, quality, character- istic, or descriptor of the object object: automobile attributes: make make model model body type body type price price options code options code

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 What is a Relationship? relationship —indicates “connectedness”; a "fact" that must be "remembered" by the system and cannot or is not computed or derived mechanically  several instances of a relationship can exist  objects can be related in many different ways

28. 28 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 ERD Notation (0, m) (1, 1) object object relationship 1 2 One common form: (0, m) (1, 1) object 1 object 2 relationship Another common form: attribute

29. 29 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 Building an ERD  Level 1—model all data objects (entities) and their “connections” to one another  Level 2—model all entities and relationships  Level 3—model all entities, relationships, and the attributes that provide further depth

30. 30 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 ERD: An Example (1,1) (1,m) places Customer request for service generates (1,n) (1,1) workorder worktasks materials consistsof lists (1,1) (1,w) (1,1) (1,i) selectedfrom standard task table (1,w) (1,1)

31. 31 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 Creating a Flow Model

32. 32 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 Flow Model Every computer-based system is an information transform.... computerbasedsystem input output

33. 33 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 Flow Modeling Notation external entity process data flow data store

34. 34 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 External Entity A producer or consumer of data Examples: a person, a device, a sensor Another example: computer-based system Data must always originate somewhere and must always be sent to something

35. 35 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 Process A data transformer (changes input to output) Examples: compute taxes, determine area, format report, display graph Data must always be processed in some way to achieve system function

36. 36 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 Data Flow Data flows through a system, beginning as input and be transformed into output. computetrianglearea base height area

37. 37 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 Data Stores Data is often stored for later use. look-upsensordata sensor # report required sensor #, type, location, age sensor data sensor number type, location, age

38. 38 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 Data Flow Diagramming: Guidelines  all icons must be labeled with meaningful names  the DFD evolves through a number of levels of detail  always begin with a context level diagram (also called level 0)  always show external entities at level 0  always label data flow arrows  do not represent procedural logic

39. 39 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 Constructing a DFD—I  review ERD to isolate data objects and grammatical parse to determine “operations)  determine external entities (producers and consumers of data  create a level 0 DFD

40. 40 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 Level 0 DFD Example user processingrequest videosource NTSC video signal digitalvideoprocessor requestedvideosignal monitor

41. 41 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 Constructing a DFD—II  write a narrative describing the transform  parse to determine next level transforms  “balance” the flow to maintain data flow continuity  develop a level 1 DFD  use a 1:5 (approx.) expansion ratio

42. 42 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 Data Flow Hierarchy P a b xy p1 p2 p3 p4 5 a b c d e f g level 0 level 1

43. 43 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 Flow Modeling Notes  each bubble is refined until it does just one thing  the expansion ratio decreases as the number of levels increase  most systems require between 3 and 7 levels for an adequate flow model  a single data flow item (arrow) may be expanded as levels increase (data dictionary provides information)

44. 44 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 Maps into DFDs: A Look Ahead analysis model design model

45. 45 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 Behavioral Modeling and Process Specification

46. 46 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 Behavioral Modeling Outside world Application events behavior

47. 47 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 States of a System  state—a set of observable circum- stances that characterizes the behavior of a system at a given time  state transition—the movement from one state to another  event—an occurrence that causes the system to exhibit some predictable form of behavior  action—process that occurs as a consequence of making a transition

48. 48 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 Behavioral Modeling  make a list of the different states of a system (How does the system behave?)  indicate how the system makes a transition from one state to another (How does the system change state?)  indicate event  indicate action  draw a state transition diagram

49. 49 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 State Transition Diagram Notation state new state event causing transition action that occurs

50. 50 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 State Transition Diagram reading operator commands making copies reloading paper problem state full invoke read-op-input full and start invoke manage-copying copies done invoke read-op-input empty invoke reload paper jammed invoke problem-diagnosis not jammed invoke read-op-input

51. 51 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 Control Model the control flow diagram is "superimposed" on the DFD and shows events that control the processes noted in the DFD control flows—events and control items—are noted by dashed arrows a vertical bar implies an input to or output from a control spec (CSPEC) — a separate specification that describes how control is handled a dashed arrow entering a vertical bar is an input to the CSPEC a dashed arrow leaving a process implies a data condition a dashed arrow entering a process implies a control input read directly by the process control flows do not physically activate/deactivate the processes—this is done via the CSPEC

52. 52 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 Control Flow Diagram

53. 53 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 Control Specification (CSPEC) The CSPEC can be: state transition diagram (sequential spec) state transition table decision tables activation tables combinatorial spec

54. 54 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 Guidelines for Building a CSPEC list all sensors that are "read" by the software list all interrupt conditions list all "switches" that are actuated by the operator list all data conditions recalling the noun-verb parse that was applied to the software statement of scope, review all "control items" as possible CSPEC inputs/outputs describe the behavior of a system by identifying its states; identify how each state is reach and defines the transitions between states focus on possible omissions... a very common error in specifying control, e.g., ask: "Is there any other way I can get to this state or exit from it?"

55. 55 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 Process Specification (PSPEC) PSPEC narrative pseudocode (PDL) equations tables diagrams and/or charts bubble

56. 56 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 A Design Note one or more ”components" in the software design PSPEC

57. 57 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 Creating Mini-Specs Software Specification

58. 58 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 Real-Time Analysis Methods  each introduces its own notation, but all  propose an approach for representing control and separating it from data  provide a mechanism for specifying events, states, and distributed processing  begin at the analysis level and work to derive processor assignments, tasks and program architectures

59. 59 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 Real-Time Analysis & Design Methods  Gomaa, H., Software Design Methods for Concurrent and Real-Time Systems, Addison-Wesley, 1995.  Harel, D. et al, "STATEMATE: A Working Environment for the Development of Complex Reactive Systems, IEEE Trans. Software Engineering, vol. 16, no. 3, April, 1990, pp. 403-414.  Hatley, D.J. and I.A. Pirbhai, Strategies for Real-Time System Specification, Dorset House, 1987.  Selic, B., G. Gullekson, and P. Ward, Real-Time Object-Oriented Modeling, Wiley, 1994.  Shumate, K. and M. Keller,, Software Specification and Design—A Disciplined Approach For Real-Time Systems, Wiley 1992.  Ward, P.T. and S.J. Mellor, Structured Development for Real-Time Systems, 3 volumes, Yourdon Press, 1985, 1986.

60. 60 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 Data Dictionary

61. 61 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 Building a Data Dictionary

62. 62 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 Data Dictionary Notation

63. 63 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 Data Dictionary Example

64. 64 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 Writing the Software Specification Everyone knew exactly what had to be done until someone wrote it down!

65. 65 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 Guidelines

66. 66 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 Guidelines

67. 67 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 Guidelines