The document discusses various requirements modeling approaches used in software engineering. It describes goals of analysis modeling such as providing the first technical representation of a system, partitioning the system, and differentiating essential from implementation information. It then summarizes four main types of modeling: flow-oriented modeling depicts how data is transformed; scenario-based modeling represents the system from the user's perspective; class-based modeling defines objects and relationships; and behavioral modeling depicts how events impact class states. Finally, it provides examples of using data flow diagrams to model a lemonade stand system.

1. Chapter 6
• Requirements Modeling Approaches
1
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman
Software Engineering 9/e
By Ian Sommerville
IT/CS:321
Introduction to Software Engineering

2. Goals of Analysis Modeling
2
• Provides the first technical representation of a system
• Is easy to understand and maintain
• Deals with the problem of size by partitioning the system
• Uses graphics whenever possible
• Differentiates between essential information versus
implementation information
• Helps in the tracking and evaluation of interfaces
• Provides tools other than narrative text to describe software
logic and policy

3. A Set of Models
3
• Flow-oriented modeling – provides an indication of
how data objects are transformed by a set of
processing functions
• Scenario-based modeling – represents the system
from the user's point of view
• Class-based modeling – defines objects, attributes,
and relationships
• Behavioral modeling – depicts the states of the
classes and the impact of events on these states

4. Requirements Analysis

5. Purpose
5
• Specifies the software's operational characteristics
• Indicates the software's interfaces with other system
elements
• Establishes constraints that the software must meet
• Provides the software designer with a representation
of information, function, and behavior
• This is later translated into architectural, interface,
class/data and component-level designs
• Provides the developer and customer with the means
to assess quality once the software is built

6. Overall Objectives
6
• Three primary objectives
• To describe what the customer requires
• To establish a basis for the creation of a software
design
• To define a set of requirements that can be
validated once the software is built
• All elements of an analysis model are directly
traceable to parts of the design model, and some
parts overlap

7. Domain Analysis
7
• Definition
• The identification, analysis, and specification of common,
reusable capabilities within a specific application domain
• Do this in terms of common objects, classes, and frameworks

8. Analysis Modeling Approaches
8
Structured analysis
• Considers data and the processes that transform the data as
separate entities
• Data is modeled in terms of only attributes and relationships
(but no operations)
• Processes are modeled to show the 1) input data, 2) the
transformation that occurs on that data, and 3) the resulting
output data
Object-oriented analysis
• Focuses on the definition of classes and the manner in
which they collaborate with one another to fulfill customer
requirements

9. Elements of the Analysis Model
9
Use case text
Use case diagrams
Activity diagram
Swimlane diagram
Scenario-based
modeling
Class diagrams
Analysis packages
CRC models
Collaboration diagrams
Class-based
modeling
Data flow diagrams
Control-flow diagrams
Processing narratives
Flow-oriented
modeling
State diagrams
Sequence diagrams
Behavioral
modeling
Structured Analysis
Object-oriented Analysis

10. Elements of the Analysis
Model
10
• Scenario based elements depict how the user interacts with
the system and the specific sequence of activities that occur as
the software is used
• Class based elements model the objects that the system will
manipulate, the operations that will be applied to the objects to
effect the manipulation, relationship (some hierarchical)
between the objects, and the collaborations that occur between
the classes that are defined.

11. Cont...
11
• Behavioural elements depict how external events change the
state of the system or the classes that reside within it
• Flow-oriented elements represent the system as an
information transform, depicting how data objects are
transformed as they flow through various system functions.

12. Flow-oriented Modeling

13. Data Modeling
13
Identify the following items
• Data objects (Entities)
• Data attributes
• Relationships
• Cardinality (number of occurrences)

14. Cont...
• Data Objects: A data object is a representation of composite
information that must be understood by software.
• A data object encapsulates data only—there is no reference
within a data object to operations that act on the data.
• Data attributes: Attributes name a data object, describe its
characteristics, and in some cases, make reference to another
object.
• Relationship: Data objects are connected to one another in
different ways
14

15. Data flow diagram
• The DFD takes an input-process-output view of a system.
• data objects flow into the software
• transformed by processing elements
• resultant data objects flow out of the software.
• transformations are represented by circles (also called
bubbles).
15

16. Cont....
• External entities: These are the entities interacting with the
system in any of two different ways.
• An external entity can represent a human, system or
subsystem
• either receiving the data from the system
• producing the data for the system to consume.
16

17. Process
• A process is a business activity or function where the
manipulation and transformation of data takes place
17

18. Data store
• A data store represents the storage of persistent data required
and/or produced by the process.
18

19. Types of DFD
• Context level DFD
• Level 1 DFD
• Level 2 DFD
19

20. 20
Creating Data Flow Diagrams
Lemonade Stand Example

21. 21
Creating Data Flow Diagrams
Steps:
1. Create a list of activities
• Old way: no Use-Case Diagram
• New way: use Use-Case Diagram
2. Construct Context Level DFD
(identifies sources and sink)
3. Construct Level 1 DFD
(identifies manageable sub processes )
4. Construct Level 2- n DFD
(identifies actual data flows and data stores )
Example
The operations of a
simple lemonade stand
will be used to
demonstrate the creation
of dataflow diagrams.

22. 22
Creating Data Flow Diagrams
1. Create a list of activities
Example
Think through the
activities that take place
at a lemonade stand.
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product

23. 23
Creating Data Flow Diagrams
Example
Also think of the
additional activities
needed to support the
basic activities.
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
1. Create a list of activities

24. 24
Creating Data Flow Diagrams
Example
Group these activities in
some logical fashion,
possibly functional areas.
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
1. Create a list of activities

25. 25
Creating Data Flow Diagrams
0.0
Lemonade
System
EMPLOYEE
CUSTOMER
Pay
Payment
Order
Context Level DFD
Example
Create a context level
diagram identifying the
sources and sinks
(users).
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
VENDOR
Payment
Purchase Order
Production Schedule
Received Goods
Time Worked
Sales Forecast
2. Construct Context Level DFD
(identifies sources and sink)
Product Served

26. 26
Creating Data Flow Diagrams
Level 1 DFD
Example
Create a level 0 diagram
identifying the logical
subsystems that may
exist.
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
3. Construct Level 1 DFD
(identifies manageable sub processes )
2.0
Production
EMPLOYEE
Production
Schedule
1.0
Sale
3.0
Procure-
ment
Sales Forecast
Product Ordered
CUSTOMER
Pay
Payment
Customer Order
VENDOR
Payment
Purchase Order
Order
Decisions
Received Goods
Time Worked
Product Served
4.0
Payroll

27. 27
Creating Data Flow Diagrams
Level 2 DFD
Example
Create a level 1
decomposing the
processes in level 0 and
identifying data stores.
4. Construct Level 2- n DFD
(identifies actual data flows and data stores )
1.3
Produce
Sales
Forecast
Sales Forecast
Payment
Customer Order
Serve Product
Collect Payment
Produce Product
Store Product
Order Raw Materials
Pay for Raw Materials
Pay for Labor
1.1
Record
Order
Customer Order
ORDER
1.2
Receive
Payment
PAYMENT
Severed Order
Request for Forecast
CUSTOMER

28. Example of DFD
28
 Order processing system
 System
 Order processing system
 External entities
 Kitchen
 Restaurant
 Customer
 Processes
 Customer order
 Receipt
 Food order
 Management report

29. Context Diagram
• Context diagram : This is the level of DFD which provides the
least amount of details about the working of the system
29

30. 30

31. Level 1 diagram
• Steps in creating the level 1 DFD
• Identify distinct modules of the system
• Create DFDs for all the modules one by one
• establish link between different DFDs by either connecting the
entities of the system or processes of the system
31

32. 32

33. Detailed data flow diagram
• Is used when we have to further explain the functionality of
the processes that we showed briefly in the Level 1 Diagram
• It means that generally detailed DFDS are expressed as the
successive details of those processes for which we do not or
could not provide enough details.
33

34. 34

35. Scenario-based Modeling

36. Writing Use Cases
36
 To begin developing a set of use cases, list the
functions or activities performed by a specific
actor
 It is effective to use the first person “I” to describe
how the actor interacts with the software
 Format of the text part of a use case
Use-case title:
Actor:
Description: I …

37. Use case diagram Objects
• Use case diagrams consist of 4 objects.
• Actor
• Use case
• System
• Package
37

38. Actor
• Actor in a use case diagram is any entity that performs a
role in one given system. This could be a person,
organization or an external system and usually drawn like
skeleton shown below.
38

39. UseCase
• A use case represents a function or an action within the
system. Its drawn as an oval and named with the function.
39

40. System
• System is used to define the scope of the use case and drawn
as a rectangle. This an optional element but useful when you
visualizing large systems
40

41. Extends relationship b/w two use
cases
• Extends the base use case and adds more functionality to the
system
• The extending use case is usually optional
41

42. Include Relationship Between Two
Use Cases
• Include relationship show that the behavior of the
included use case is part of the including (base) use
case
• The main reason for this is to reuse the common
actions across multiple use cases.
• In some situations this is done to simplify complex
behaviours
42

43. cont...
43

44. Example Use Case Diagram
Make automated menu
selections
Order food and drink
Pay for food and drink
Notify customer that
food and drink are ready
Customer
Cook
Payment
System
Expert Menu
System

45. Class-based Modeling

46. Class based modelling
46
• Class-based modeling represents the objects that the system
will manipulate
• The operations (also called methods or services) that will be
applied to the objects to effect the manipulation,
• Relationships (some hierarchical) between the objects
• The collaborations that occur between the classes that are
defined

47. Identifying Analysis Classes
47
• General classifications for a potential class
• External entity (e.g., another system, a device, a
person)
• Thing (e.g., report, screen display)
• Occurrence or event (e.g., movement, completion)
• Role (e.g., manager, engineer, salesperson)
• Organizational unit (e.g., division, group, team)
• Place (e.g., manufacturing floor)
• Structure (e.g., sensor, vehicle, computer)

48. Example Class Box
48
Component
+ componentID
- telephoneNumber
- componentStatus
- delayTime
- masterPassword
- numberOfTries
+ program()
+ display()
+ reset()
+ query()
- modify()
+ call()
Class Name
Attributes
Operations

49. Association
Represented by a solid line between two classes
directed from the source class to the target class
Used for representing (i.e., pointing to) object
types for attributes
49
person Car
Owns

50. Dependency
• A dependency exists between two elements if
changes to the definition of one element (i.e., the
source or supplier) may cause changes to the other
element (i.e., the client)
• Examples
• One class calls a method of another class
• One class utilizes another class as a parameter of
a method
50

51. 51

52. Aggregation
• Aggregation illustrates “is part of” relationships.
•
52

53. Composition
• Composition relates to instance creational responsibility.
When class B is composed by class A, class A instance owns
the creation or controls lifetime of instance of class B
53

54. 54

55. Inheritance/generalization
• Inheritance models “is a” and “is like” relationships, enabling
you to rather conveniently reuse data and code that already
exist.
• “A” inherits from “B”
• “A” is the subclass of “B”
• “B” is the superclass of “A.”
55

56. 56

57. 57

58. Behavioral Modeling

59. Identifying Events in Use Cases
59
• An event occurs whenever an actor and the system
exchange information
• An event is NOT the information that is exchanged,
but rather the fact that information has been
exchanged
• Some events have an explicit impact on the flow of
control, while others do not
• An example is the reading of a data item from the
user versus comparing the data item to some
possible value

60. Building a sequence Diagram
• Describe the flow of messages, events, actions between
objects.
• Show concurrent processes and activations
• Show time sequences that are not easily depicted in other
diagrams.
• used during analysis and design to document and understand
the logical flow of your system
60

61. Sequence Diagram key parts
• Participant: Object or entity that acts in diagram
• Message: Communication between participant objects.
• Axes:
• – horizontal: which object/participant is acting.
• – vertical: time (down -> forward in time)
61

62. Sequence Diagram(make a phone call)
62

63. Representing Objects
• Squares with object type, optionally preceded by "name :"
• write object's name if it clarifies the diagram
• object's "life line" represented by dashed vert. line
63

64. Messages Between Objects
• messages (method calls) indicated by arrow to other object
64

65. Indicating method calls
• activation: thick box over object's life line; drawn when
object's method is on the stack
• Either that object is running its code, or it is on the stack
waiting for another object's method to finish
65

66. Sequence diagram from use case
scenario
• Customer specifies the author on the search page and then
presses the search button.
• System validates customer search criteria
• System search the catalogue for books associated with
specified author.
• When search is complete system displays the search results on
search results page.
66

67. Summary:
Elements of the Analysis Model
67
Use case text
Use case diagrams
Activity diagrams
Swim lane diagrams
Scenario-based
modeling
Class diagrams
Analysis packages
CRC models
Collaboration diagrams
Class-based
modeling
Data flow diagrams
Control-flow diagrams
Processing narratives
Flow-oriented
modeling
State diagrams
Sequence diagrams
Behavioral
modeling
Structured Analysis
Object-oriented Analysis


68. 68
Draw use case
Diagram and DFD
diagram (level 0
and level 1)

69. These slides are designed to accompany Software Engineering:
A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides
copyright 2009 by Roger Pressman.
69
Draw Use-case Diagram and DFD(0 level and 1 level)to
understand the system