Deepanjal Shrestha

(PhD)
Software Modeling PU, SOE
Requirement Analysis

• 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.
• Scenario-based models of requirements from the point of view of various system
“actors”
• Data models that depict the information domain for the problem
• Class-oriented models that represent object-oriented classes (attributes and
operations) and the manner in which classes collaborate to achieve system
requirements
• Flow-oriented models that represent the functional elements of the system and how
they transform data as it moves through the system
• Behavioral models that depict how the software behaves as a consequence of
external “events”
Analysis Model
The Main Focus: Requirement Model

• Throughout requirements modeling, the primary focus is on what, not how.

• What user interaction occurs in a particular circumstance?
• What objects does the system manipulate?
• What functions must the system perform?
• What behaviors does the system exhibit?
• What interfaces are defined, and what constraints apply?
The Requirement Model Relationship
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. “Don’t get bogged down in
details”
• Each element of the requirements model should add to an overall
understanding of software requirements and provide insight into the
information domain, function, and behavior of the system.
• Delay consideration of infrastructure and other nonfunctional models until
design.
• That is, a database may be required, but the classes necessary to implement it, the
functions required to access it, and the behavior that will be exhibited as it is used should
be considered only after problem domain analysis has been completed.
Analysis Rules of Thumb

• Minimize coupling throughout the system.

• It is important to represent relationships between classes and functions.
However, if the level of “interconnectedness” is extremely high, effort should
be made to reduce it.
• Be certain that the requirements model provides value to all stakeholders.
Each constituency has its own use for the model.
• For example, business stakeholders should use the model to validate requirements;
designers should use the model as a basis for design; QA people should use the model to
help plan acceptance tests.
• Keep the model as simple as it can be.
• Don’t create additional diagrams when they add no new information.
• Don’t use complex notational forms, when a simple list will do.
Domain Analysis
Domain Analysis

• Software domain analysis is the identification, analysis, and

specification of common requirements from a specific
application domain, typically for reuse on multiple projects within
that application domain
• Object-oriented domain analysis is the identification, analysis, and
specification of common, reusable capabilities within a specific
application domain, in terms of common objects, classes,
subassemblies, and frameworks.
Requirements Modeling Approaches

• 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 modeling, called object-oriented
analysis, focuses on the definition of classes and the manner in
which they collaborate with one another to effect customer
requirements.
SCENARIO-BASED MODELING: Use Cases

• Creating a Preliminary Use Case

• To begin developing a set of use cases, list the functions or
activities performed by a specific actor.
• We can obtain these from a list of required system functions,
through conversations with stakeholders, or by an evaluation of
activity diagrams developed as part of requirements modeling.
Developing Use cases
Use Case
Developing Use cases

• The SafeHome home surveillance function (subsystem) discussed identifies the

following functions (an abbreviated list) that are performed by the
homeowner actor:
• Select camera to view.
• Request thumbnails from all cameras. In general, use cases
• Display camera views in a PC window. are written first in an
• Control pan and zoom for a specific camera. informal narrative
• Selectively record camera output. fashion
• Replay camera output.
• Access camera surveillance via the Internet.
Developing Use cases

• Use case: Access camera surveillance via the Internet—display camera views (ACS-DCV)
• Actor: homeowner
• 1. The homeowner logs onto the SafeHome Products website.
• 2. The homeowner enters his or her user ID.
• 3. The homeowner enters two passwords (each at least eight characters in length).
• 4. The system displays all major function buttons.
• 5. The homeowner selects the “surveillance” from the major function buttons.
• 6. The homeowner selects “pick a camera.”
• 7. The system displays the floor plan of the house.
• 8. The homeowner selects a camera icon from the floor plan.
• 9. The homeowner selects the “view” button.
• 10. The system displays a viewing window that is identified by the camera ID.
• 11. The system displays video output within the viewing window at one frame per second.
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?
If so, what might it be?
• 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)?
• If so, what might it be?
Refining a Preliminary Use Case

• Answers to these questions result in the creation of a set of secondary

scenarios that are part of the original use case but represent alternative be
• 6. The homeowner selects “pick a camera.”
• 7. The system displays the floor plan of the house.
• Can the actor take some other action at this point? The answer is “yes.”
• Referring to the free-flowing narrative, the actor may choose to view
thumbnail snapshots of all cameras simultaneously.
• Hence, one secondary scenario might be “View thumbnail snapshots for all
cameras.”
Writing a Formal Use Case
Preliminary use-case diagram
 UML MODELS THAT
SUPPLEMENT THE USE CASE
• Developing an Activity Diagram
• The UML activity diagram
supplements the use case by
providing a graphical
representation of the flow of
interaction within a specific
scenario.
Data Modeling and Entity Relationship (E-R)
Diagramming
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
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)

each instance 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
Typical Objects

external entities (printer, user, sensor)

things (e.g, reports, displays, signals)
occurrences or events (e.g., interrupt, alarm)
roles (e.g., manager, engineer, salesperson)
organizational units (e.g., division, team)
places (e.g., manufacturing floor)
structures (e.g., employee record)
 Data Objects and Attributes

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

characteristic, or descriptor of the object

object: automobile
attributes:
make
model
body type
price
options code
 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
ERD Notation

One common form:

(0, m)
object 1
relationship object 2
(1, 1)

attribute
Another common form:

object relationship
1 object 2
(0, m) (1, 1)
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
 The ERD: An Example

request
Customer places for service
(1,1) (1,m)
(1,1)
standard
generates (1,n) work
task table order
(1,1) (1,1) (1,1)
selected work (1,w)
consists
from (1,w) tasks of

(1,i)
materials lists
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, and
the collaborations that occur between the classes that are
defined
Identifying Analysis Classes

• 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, or it is part of the solution space.
Identifying Analysis Classes

• External entities (e.g., other systems, devices, people) that produce or consume
information to be used by a computer-based system.
• 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 of the system.
• Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of
objects or related classes of objects.
Representing Class
Specifying Attributes

• Attributes define the class—that clarify what is meant by the class in the
context of the problem space
• In Safehome, we consider the System class.
• A homeowner can configure the security function to reflect sensor information,
alarm response information, activation/deactivation information,
identification information, and so forth.
• We can represent these composite data items in the following manner:
Defining Operations

• Operations define the behavior of an object.

• Although many different types of operations exist, they can
generally 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.
Class Representation
Class-Responsibility-Collaborator (CRC)
Modeling

• 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.
Class-Responsibility-Collaborator (CRC)
Modeling

• Responsibilities are the attributes and operations that are

relevant for the class. Stated simply, a responsibility is
“anything the class knows or does”.
• Collaborators are those classes that are required to
provide a class with the information needed to complete a
responsibility.
• In general, a collaboration implies either a request for
information or a request for some action.
CRC: Example
Classes: 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” from start to finish. That is,
controller classes can be designed to manage
(1) the creation or update of entity objects,
(2) the instantiation of boundary objects as they obtain information
from entity objects,
(3) complex communication between sets of objects,
(4) validation of data communicated between objects or between the
user and the application.
Class Diagram
Collaborations

• Classes fulfill their responsibilities in one of two ways:

• (1) A class can use its own operations to manipulate its own
attributes, thereby fulfilling a particular responsibility, or
• (2) a class can collaborate with other classes.
• Collaborations are identified by determining whether a class can
fulfill each responsibility itself.
• If it cannot, then it needs to interact with another class. Hence, a
collaboration.
Associations and Dependencies

• In many instances, two

classes are related to one
another in some fashion,
much like two data objects
may be related to one
another
• In UML these relationships
are called associations.
• Class associations have
associations and
dependencies
Packages

• An important part of analysis

modeling is categorization.
That is, various elements of
the analysis model (e.g., use
cases, analysis classes) are
categorized in a manner that
packages them as a
grouping—called an analysis
package—that is given a
representative name
 Real World Example

• Can you identify the classes (nouns) involved in designing a basic

banking system, and categorize them into the problem space or the
solution space? Consider classes such as Bank, Account, Customer,
Transaction, Balance, ATM, Deposit, Withdrawal, Loan, Interest,
Statement, and Security. For each class, identify any related
synonyms and explain whether they belong to the problem space or
the solution space. For example, classes like Bank, Account, and
Customer are part of the solution space, as they directly relate to
the operations of the banking system. However, Security could be
debated as part of the problem space since it is a requirement but
not a direct operation.
Solution

Noun (Class) Synonyms (if any) Belongs to Solution Space?

Bank Financial institution Yes
Account Bank account Yes
Customer Client, account holder Yes
Transaction Transfer, operation Yes
Balance Funds, amount Yes
ATM Automated teller machine Yes
Deposit Payment, credit Yes
Withdrawal Cash withdrawal Yes
Loan Borrowing, credit Yes
Interest Rate, percentage Yes
Statement Account statement Yes
Security Protection, safety No
 Thank You!

Questions!