1 Chapter 4: Requirements Modeling

 Overview
 Scenario-based Modeling
 Class-based Modeling
 Flow-oriented Modeling
 Behavior Modeling

Software Engineering - Le Vu Hao 8/2/2023

Overview
2

Software Engineering - Le Vu Hao 8/2/2023

3 Requirements analysis

 Results in the specification of software’s operational characteristics,

indicates software’s interface with other system elements, and establishes
constraints that software must meet.
 Allows you (regardless of whether you’re called a software engineer, an
analyst, or a modeler) to elaborate on basic requirements established
during the inception, elicitation, and negotiation tasks
 Results in one or more of the following types of models:
 Scenario-based models
 Data models
 Class-oriented models
 Behavioral models

Software Engineering - Le Vu Hao 8/2/2023

4 Requirements analysis

 The requirements model as a bridge

between the system description and the
design model
 The requirements model must achieve
three primary objectives:
1. to describe what the customer requires,
2. to establish a basis for the creation of a
software design,
3. to define a set of requirements that can
be validated once the software is built.

Software Engineering - Le Vu Hao 8/2/2023

5 Analysis Rules of Thumb

 The model should focus on requirements that are visible

within the problem or business domain. The level of
abstraction should be relatively high.
 Each element of the requirements model should add to an
overall understanding of software requirements and
provide insight into the information domain
 Delay consideration of infrastructure and other
nonfunctional models until design.
 Minimize coupling throughout the system.
 Be certain that the requirements model provides value to
all stakeholders., function, and behavior of the system.
 Keep the model as simple as it can be.

Software Engineering - Le Vu Hao 8/2/2023

6 Domain Analysis

 Input and output for domain analysis

Software Engineering - Le Vu Hao 8/2/2023

7 Requirements Modeling Approaches

 Two views of requirements  Elements of the analysis model

modeling:
 structured analysis: considers data
and the processes that transform
the data as separate entities.
 object-oriented analysis: focuses
on the definition of classes and
the manner in which they
collaborate with one another to
effect customer requirements.
UML and the Unified Process are
predominantly object oriented.

Software Engineering - Le Vu Hao 8/2/2023

Scenario-based
Modeling
8

Software Engineering - Le Vu Hao 8/2/2023

9 Creating a Preliminary Use Case
What to write about?
 Inception and elicitation - provide you with the information you’ll need to begin
writing use cases.
 Requirements gathering meetings, QFD, and other requirements engineering
mechanisms are used to
 identify stakeholders
 define the scope of the problem
 specify overall operational goals
 establish priorities
 outline all known functional requirements, and
 describe the things (objects) that will be manipulated by the system.
 To begin developing a set of use cases, list the functions or activities performed
by a specific actor.

Software Engineering - Le Vu Hao 8/2/2023

10 Creating a Preliminary Use Case
What to write about?
 The following functions (an abbreviated list) that are performed by the
homeowner actor:
 Select camera to view.
 Request thumbnails from all cameras.
 Display camera views in a PC window.
 Control pan and zoom for a specific camera.
 Selectively record camera output.
 Replay camera output.
 Access camera surveillance via the Internet.

Software Engineering - Le Vu Hao 8/2/2023

11

Software Engineering - Le Vu Hao 8/2/2023

12

Software Engineering - Le Vu Hao 8/2/2023

13 Creating a Preliminary Use Case

 Primary scenarios: are use cases that don’t consider any alternative
interactions

Software Engineering - Le Vu Hao 8/2/2023

14 Preliminary use-case diagram
for the SafeHome system

Software Engineering - Le Vu Hao 8/2/2023

15 Refining a Preliminary Use Case

 A description of alternative interactions is essential for a complete

understanding of the function that is being described by a use case.
Therefore, each step in the primary scenario is evaluated by asking the
following questions:
 Can the actor take some other action at this point?
 Is it possible that the actor will encounter some error condition at this point?
 Is it possible that the actor will encounter some other behavior at this point (e.g.,
behavior that is invoked by some event outside the actor’s control)?

Software Engineering - Le Vu Hao 8/2/2023

16 Refining a Preliminary Use Case

 An exception describes a situation (either a failure condition or an

alternative chosen by the actor) that causes the system to exhibit
somewhat different behavior.
 Using a “brainstorming” session to derive a reasonably complete set of
exceptions for each use case with the following questions:
 Are there cases in which some “validation function” occurs during this use case?
 Are there cases in which a supporting function (or actor) will fail to respond
appropriately?
 Can poor system performance result in unexpected or improper user actions?

Software Engineering - Le Vu Hao 8/2/2023

17 Writing a Formal Use Case

 When a use case involves a critical activity or describes a complex set of

steps with a significant number of exceptions, a more formal approach
may be desirable.
 Good Use case template
 UML Use case diagram:

Software Engineering - Le Vu Hao 8/2/2023

18

Software Engineering - Le Vu Hao 8/2/2023

19

Software Engineering - Le Vu Hao 8/2/2023

20

Software Engineering - Le Vu Hao 8/2/2023

21

Software Engineering - Le Vu Hao 8/2/2023

22
An example of Use Case

Software Engineering - Le Vu Hao 8/2/2023

UML Models That
Supplement The Use There are many requirements modeling

Case situations in which a text-based model -

even one as simple as a use case - may
not impart information in a clear and
concise manner. In such cases, you can
23 choose from a broad array of UML
graphical models.

Software Engineering - Le Vu Hao 8/2/2023

24 UML

 UML, short for Unified Modeling Language, is a standardized modeling language consisting
of an integrated set of diagrams, developed to help system and software developers for
specifying, visualizing, constructing, and documenting the artifacts of software systems, as
well as for business modeling and other non-software systems.
 The primary goals in the design of the UML summarize by Page-Jones in Fundamental
Object-Oriented Design in UML as follows:
 Provide users with a ready-to-use, expressive visual modeling language so they can develop
and exchange meaningful models.
 Provide extensibility and specialization mechanisms to extend the core concepts.
 Be independent of particular programming languages and development processes.
 Provide a formal basis for understanding the modeling language.
 Encourage the growth of the OO tools market.
 Support higher-level development concepts such as collaborations, frameworks, patterns
and components.
 Integrate best practices.

Software Engineering - Le Vu Hao 8/2/2023

25 Developing an Activity Diagram

 A UML activity diagram represents the actions and decisions that occur as
some function is performed.

Software Engineering - Le Vu Hao 8/2/2023

26

Activity diagram for

Access camera
surveillance via the
Internet - display
camera view
function.

Software Engineering - Le Vu Hao 8/2/2023

27 Swimlane Diagrams

 A UML swimlane diagram represents the flow of actions and decisions and
indicates which actors perform each.
 The UML swimlane diagram is a useful variation of the activity diagram and
allows you to represent the flow of activities described by the use case and
at the same time indicate which actor (if there are multiple actors involved
in a specific use case) or analysis class (discussed later in this chapter) has
responsibility for the action described by an activity rectangle.

Software Engineering - Le Vu Hao 8/2/2023

28

Software Engineering - Le Vu Hao 8/2/2023

Data Modeling
Concepts
29

Software Engineering - Le Vu Hao 8/2/2023

30 Data Modeling Concepts

 Data model is used when:

 Software requirements include the need to create, extend, or interface with a
database or
 Complex data structures must be constructed and manipulated
 entity-relationship diagram (ERD): a data model representing all data
objects that are entered, stored, transformed, and produced within an
application as well as the relationships between the data objects.

Software Engineering - Le Vu Hao 8/2/2023

31 What is a Data Object?

 a representation of almost any composite information that must be understood

by software.
 composite information - something that has a number of different properties or
attributes
 can be an external entity (e.g., anything that produces or consumes
information), a thing (e.g., a report or a display), an occurrence (e.g., a
telephone call) or event (e.g., an alarm), a role (e.g., salesperson), an
organizational unit (e.g., accounting department), a place (e.g., a warehouse),
or a structure (e.g., a file).
 The description of the data object incorporates the data object and all of its
attributes.
 A data object encapsulates data only - there is no reference within a data
object to operations that act on the data.

Software Engineering - Le Vu Hao 8/2/2023

32 Data Objects and Attributes

 A data object contains a set of attributes that act as an aspect, quality,

characteristic, or descriptor of the object

Software Engineering - Le Vu Hao 8/2/2023

33 Relationships

 Data objects are connected to one another in different ways.

Software Engineering - Le Vu Hao 8/2/2023

34 ERD Notation

Software Engineering - Le Vu Hao 8/2/2023

35 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

Software Engineering - Le Vu Hao 8/2/2023

36 The ERD: An Example

Software Engineering - Le Vu Hao 8/2/2023

Class-based
Modeling
37

Software Engineering - Le Vu Hao 8/2/2023

38 Class-based Modeling

 Represents:
 The objects of the system
 The operations (also called methods or services) applied to the objects
 Relationships (some hierarchical) between the objects
 The collaborations occurring between the classes
 The elements of a class-based model include:
 Classes and objects
 Attributes
 Operations
 Class responsibility-collaborator (CRC) models
 Collaboration diagrams
 Packages.

Software Engineering - Le Vu Hao 8/2/2023

39 Identifying Analysis Classes

 Examining the usage scenarios developed as part of the requirements

model and perform a "grammatical parse"
 Classes are determined by underlining each noun or noun phrase and entering it
into a simple table.
 Synonyms should be noted.
 If the class (noun) is required to implement a solution, then it is part of the solution
space; otherwise, if a class is necessary only to describe a solution, it is part of the
problem space.
 But what should we look for once all of the nouns have been isolated?

Software Engineering - Le Vu Hao 8/2/2023

40 Manifestations of Analysis Classes

 Analysis classes manifest themselves in one of the following ways:

 External entities (e.g., other systems, devices, people) that produce or consume
information
 Things (e.g, reports, displays, letters, signals) that are part of the information domain for
the problem
 Occurrences or events (e.g., a property transfer or the completion of a series of robot
movements) that occur within the context of system operation
 Roles (e.g., manager, engineer, salesperson) played by people who interact with the
system
 Organizational units (e.g., division, group, team) that are relevant to an application
 Places (e.g., manufacturing floor or loading dock) that establish the context of the
problem and the overall function
 Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of
objects or related classes of objects

Software Engineering - Le Vu Hao 8/2/2023

41

Software Engineering - Le Vu Hao 8/2/2023

42 Potential Classes

1. Retained information. The potential class will be useful during analysis only if information
about it must be remembered so that the system can function.
2. Needed services. The potential class must have a set of identifiable operations that can
change the value of its attributes in some way.
3. Multiple attributes. During requirement analysis, the focus should be on "major" information;
a class with a single attribute may, in fact, be useful during design, but is probably better
represented as an attribute of another class during the analysis activity.
4. Common attributes. A set of attributes can be defined for the potential class and these
attributes apply to all instances of the class.
5. Common operations. A set of operations can be defined for the potential class and these
operations apply to all instances of the class.
6. Essential requirements. External entities that appear in the problem space and produce or
consume information essential to the operation of any solution for the system will almost
always be defined as classes in the requirements model.

Software Engineering - Le Vu Hao 8/2/2023

43

Software Engineering - Le Vu Hao 8/2/2023

44 Specifying Attributes

 Attributes describe a class that has been selected for inclusion in the
analysis model.
 build two different classes for professional baseball players
 For Playing Statistics software: name, position, batting average, fielding percentage,
years played, and games played might be relevant
 For Pension Fund software: average salary, credit toward full vesting, pension plan
options chosen, mailing address, and the like.

 Attributes are the set of data objects that fully define the class within the
context of the problem.

Software Engineering - Le Vu Hao 8/2/2023

45 Defining Operations

 Do a grammatical parse of a processing narrative and look at the verbs

 Operations can be divided into four broad categories:
 (1) operations that manipulate data in some way (e.g., adding, deleting,
reformatting, selecting)
 (2) operations that perform a computation
 (3) operations that inquire about the state of an object, and
 (4) operations that monitor an object for the occurrence of a controlling event.
 When you define operations for an analysis class, focus on problem-
oriented behavior rather than behaviors required for implementation.

Software Engineering - Le Vu Hao 8/2/2023

46 Class diagram for the system class

Software Engineering - Le Vu Hao 8/2/2023

47

Software Engineering - Le Vu Hao 8/2/2023

48 Class-Responsibility-Collaborator (CRC)
Modeling
 Class-responsibility-collaborator (CRC) modeling [Wir90] provides a simple
means for identifying and organizing the classes that are relevant to system
or product requirements. Ambler [Amb95] describes CRC modeling in the
following way:
 A CRC model is really a collection of standard index cards that represent classes.
The cards are divided into three sections. Along the top of the card you write the
name of the class. In the body of the card you list the class responsibilities on the
left and the collaborators on the right.

Software Engineering - Le Vu Hao 8/2/2023

49 A CRC model index card

Software Engineering - Le Vu Hao 8/2/2023

50 Class Types

 Entity classes, also called model or business classes, are extracted directly from
the statement of the problem (e.g., FloorPlan and Sensor).
 Boundary classes are used to create the interface (e.g., interactive screen or
printed reports) that the user sees and interacts with as the software is used.
 Controller classes manage a “unit of work” [UML03] from start to finish. That is,
controller classes can be designed to manage
 the creation or update of entity objects;
 the instantiation of boundary objects as they obtain information from entity objects;
 complex communication between sets of objects;
 validation of data communicated between objects or between the user and the
application.

Software Engineering - Le Vu Hao 8/2/2023

51 Responsibilities

 System intelligence should be distributed across classes to best address the

needs of the problem
 Each responsibility should be stated as generally as possible
 Information and the behavior related to it should reside within the same
class
 Information about one thing should be localized with a single class, not
distributed across multiple classes.
 Responsibilities should be shared among related classes, when appropriate.

Software Engineering - Le Vu Hao 8/2/2023

52 Collaborations

 Classes fulfill their responsibilities in one of two ways:

 A class can use its own operations to manipulate its own attributes, thereby
fulfilling a particular responsibility, or
 a class can collaborate with other classes.
 Collaborations identify relationships between classes
 Collaborations are identified by determining whether a class can fulfill each
responsibility itself
 Three different generic relationships between classes [WIR90]:
 the is-part-of relationship
 the has-knowledge-of relationship
 the depends-upon relationship

Software Engineering - Le Vu Hao 8/2/2023

53

Software Engineering - Le Vu Hao 8/2/2023

54 Reviewing CRC Model
by stakeholders
1. All participants in the review (of the CRC model) are given a subset of the CRC model index
cards.
 Cards that collaborate should be separated (i.e., no reviewer should have two cards that collaborate).
2. All use-case scenarios (and corresponding use-case diagrams) should be organized into
categories.
3. The review leader reads the use-case deliberately.
 As the review leader comes to a named object, she passes a token to the person holding the
corresponding class index card.
4. When the token is passed, the holder of the class card is asked to describe the responsibilities
noted on the card.
 The group determines whether one (or more) of the responsibilities satisfies the use-case requirement.
5. If the responsibilities and collaborations noted on the index cards cannot accommodate the use-
case, modifications are made to the cards.
 This may include the definition of new classes (and corresponding CRC index cards) or the specification of
new or revised responsibilities or collaborations on existing cards.

Software Engineering - Le Vu Hao 8/2/2023

55 Associations and Dependencies

 Two analysis classes are often related to one another in some fashion
 In UML these relationships are called associations
 Associations can be refined by indicating multiplicity (the term cardinality is used
in data modeling
 In many instances, a client-server relationship exists between two analysis
classes.
 In such cases, a client-class depends on the server-class in some way and a
dependency relationship is established

Software Engineering - Le Vu Hao 8/2/2023

56

Software Engineering - Le Vu Hao 8/2/2023

57

Software Engineering - Le Vu Hao 8/2/2023

58 Analysis Packages

 A package is used to assemble a collection of related classes.

 Various elements of the analysis model (e.g., use-cases, analysis classes) are
categorized in a manner that packages them as a grouping
 The plus sign preceding the analysis class name in each package indicates that
the classes have public visibility and are therefore accessible from other
packages.
 Other symbols can precede an element within a package. A minus sign
indicates that an element is hidden from all other packages and a # symbol
indicates that an element is accessible only to packages contained within a
given package.

Software Engineering - Le Vu Hao 8/2/2023

59

Software Engineering - Le Vu Hao 8/2/2023

60 Requirements Modeling Strategies

 One view of requirements modeling, called structured analysis, considers

data and the processes that transform the data as separate entities.
 Data objects are modeled in a way that defines their attributes and relationships.
 Processes that manipulate data objects are modeled in a manner that shows
how they transform data as data objects flow through the system.
 A second approach to analysis modeled, called objectoriented analysis,
focuses on
 the definition of classes and
 the manner in which they collaborate with one another to effect customer
requirements.

Software Engineering - Le Vu Hao 8/2/2023

Flow-Oriented
Modeling
61

Software Engineering - Le Vu Hao 8/2/2023

62 Flow-Oriented Modeling

 data flow diagram (DFD):

 outdated technique, related diagrams and information are not a formal part of
UML
 used to complement UML diagrams and provide additional insight into system
requirements and flow
 takes an input-process-output view of a system: data objects flow into the
software, are transformed by processing elements, and resultant data objects
flow out of the software.

Software Engineering - Le Vu Hao 8/2/2023

63 The Flow Model

Software Engineering - Le Vu Hao 8/2/2023

64 Flow Modeling Notation

Software Engineering - Le Vu Hao 8/2/2023

65 Flow Modeling Notation

Software Engineering - Le Vu Hao 8/2/2023

66 External Entity

Software Engineering - Le Vu Hao 8/2/2023

67 Process

Software Engineering - Le Vu Hao 8/2/2023

68 Data Flow

Software Engineering - Le Vu Hao 8/2/2023

69 Data Stores

Software Engineering - Le Vu Hao 8/2/2023

70 Creating a Data Flow Model

 The data flow diagram enables you to develop models of the information
domain and functional domain.
 As the DFD is refined into greater levels of detail, you perform an implicit
functional decomposition of the system.
 Guidelines:
1. the level 0 data flow diagram should depict the software/system as a single bubble.
2. primary input and output should be carefully noted.
3. refinement should begin by isolating candidate processes, data objects, and data
stores to be represented at the next level.
4. all arrows and bubbles should be labeled with meaningful names.
5. information flow continuity must be maintained from level to level..
6. one bubble at a time should be refined.

Software Engineering - Le Vu Hao 8/2/2023

71 Constructing a DFD - 1

 review user scenarios and/or the data model to isolate data objects and
use a grammatical parse to determine “operations”
 determine external entities (producers and consumers of data)
 create a level 0 DFD

Software Engineering - Le Vu Hao 8/2/2023

72

Software Engineering - Le Vu Hao 8/2/2023

73 Constructing a DFD - 2

 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

Software Engineering - Le Vu Hao 8/2/2023

74

Software Engineering - Le Vu Hao 8/2/2023

75

Software Engineering - Le Vu Hao 8/2/2023

76

Software Engineering - Le Vu Hao 8/2/2023

77

Software Engineering - Le Vu Hao 8/2/2023

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

Software Engineering - Le Vu Hao 8/2/2023

79 Control Flow Model

 A large class of applications are “driven” by events rather than data,

produce control information rather than reports or displays, and process
information with heavy concern for time and performance.
 control flow modeling: represents “events” and the processes that manage
events
 An event or control item is implemented as a Boolean value (e.g., true or
false, on or off, 1 or 0) or a discrete list of conditions (e.g., empty, jammed,
full).

Software Engineering - Le Vu Hao 8/2/2023

80 Guidelines to select potential
candidate events
 List all sensors that are “read” by the software.
 List all interrupt conditions.
 List all “switches” that are actuated by an operator.
 List all data conditions.
 Recalling the noun/verb parse that was applied to the processing
narrative, review all “control items” as possible control specification
inputs/outputs.
 Describe the behavior of a system by identifying its states, identify how
each state is reached, and define the transitions between states.
 Focus on possible omissions—a very common error in specifying control; for
example, ask: “Is there any other way I can get to this state or exit from it?”

Software Engineering - Le Vu Hao 8/2/2023

81 The Control Specification

 A control specification (CSPEC) represents the behavior of the system (at

the level from which it has been referenced) in two different ways:
 a state diagram: a sequential specification of behavior.
 a program activation table (PAT): the PAT represents information contained in
the state diagram in the context of processes, not states. That is, the table
indicates which processes (bubbles) in the flow model will be invoked when an
event occurs.
 The CSPEC describes the behavior of the system, but it gives us no
information about the inner working of the processes that are activated as
a result of this behavior. The modeling notation that provides this
information is in the process specification (PSPEC)

Software Engineering - Le Vu Hao 8/2/2023

82

Software Engineering - Le Vu Hao 8/2/2023

83 Process activation table
for the level 1 flow model (Figure 7.5)

Software Engineering - Le Vu Hao 8/2/2023

84
The Process Specification

• The process specification

(PSPEC) is used to describe
all flow model processes
that appear at the final level
of refinement.

Software Engineering - Le Vu Hao 8/2/2023

Behavioral Modeling
85

Software Engineering - Le Vu Hao 8/2/2023

86 Behavioral Modeling

 The behavioral model indicates how software will respond to external

events or stimuli. To create the model, the analyst must perform the
following steps:
1. Evaluate all use-cases to fully understand the sequence of interaction within the
system.
2. Identify events that drive the interaction sequence and understand how these
events relate to specific objects.
3. Create a sequence for each use-case.
4. Build a state diagram for the system.
5. Review the behavioral model to verify accuracy and consistency.

Software Engineering - Le Vu Hao 8/2/2023

87 Identifying Events with the Use Case

 An event occurs whenever the system and an actor exchange information.

 Example:
 The homeowner uses the keypad to key in a four-digit password. The password is
compared with the valid password stored in the system. If the password is
incorrect, the control panel will beep once and reset itself for additional input. If
the password is correct, the control panel awaits further action.
 An actor should be identified for each event; the information that is exchanged
should be noted, and any conditions or constraints should be listed.
 In the context of the requirements model, the object, Homeowner,7 transmits an event
to the object ControlPanel. The event might be called password entered.

Software Engineering - Le Vu Hao 8/2/2023

88 State Representations

 In the context of behavioral modeling, two different characterizations of

states must be considered:
 the state of each class as the system performs its function and
 the state of the system as observed from the outside as the system performs its
function
 The state of a class takes on both passive and active characteristics
[CHA93].
 A passive state is simply the current status of all of an objectʼs attributes.
 The active state of an object indicates the current status of the object as it
undergoes a continuing transformation or processing

Software Engineering - Le Vu Hao 8/2/2023

89 State diagrams for analysis
classes
represents active states for
each class and the events
(triggers) that cause changes
between these active states.

State Diagram for the ControlPanel Class

Software Engineering - Le Vu Hao 8/2/2023

90 The States of a System

 state - a set of observable circumstances 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

State Diagram for the ControlPanel Class

Software Engineering - Le Vu Hao 8/2/2023

91
Sequence diagrams
indicates how events cause
transitions from object to
object.

Sequence diagram (partial) for the SafeHome

security function

Software Engineering - Le Vu Hao 8/2/2023

 92 Writing the Software Specification
 i

Software Engineering - Le Vu Hao 8/2/2023

93

Software Engineering - Le Vu Hao 8/2/2023