Analysis Modeling

UNIT III:

• Requirements Analysis, Scenario-Based

Modeling, UML Models That Supplement the
Use Case, Data Modeling Concepts, Class-
Based Modeling, Requirements Modeling
Strategies, Flow-Oriented Modeling, Creating
a Behavioral Model, Patterns for
Requirements Modelling, Requirements
Modeling for WebApps.
 SOME OF THE FOLLOWING
ADDITIONS TO SET ANALYSIS PHASE
GOALS
• The products of analysis must be highly
maintainable. This applies particularly to the target
Document
• Problem of size must be dealt with using and
effective method partitioning the Victorian novel
specification is out.
• Graphics have to be used whenever possible
• We have to differentiate between logical and
physical considerations.
 Why so difficult?
Users/stakeholders

Interaction….match

Software designer
– Different “worlds”
– using vs designing something
– knowing what should be done vs knowing to let a computer
do that
– Users/stakeholders are not an uniform group
– conflict between cost and usability / performance / features
– conflicting demands from different departments
– Getting the good (ideal) system vs possibility building it good

4
 QUICK LOOK
What is it?

Analysis modeling uses combination of text and diagrammatic forms to depict

requirements for the data,
Function, and behavior in a way that is relatively easy to understand, and more
important, straightforward to review for correctness, completeness and consistency

Who does it?

A software engineer(sometimes called an analyst ) builds the model using

requirement elicited from the customer.

Why is it important?
To validate software requirements, you need to examine them from a number of
different points of view. Analysis modeling represents requirements in multiple
“dimensions”, thereby increasing the probability that errors will be found, that
inconsistency will surface, and that omissions will be uncovered.
 REQUIREMENTS ANALYSIS
Requirement Analysis. ... what the customer requires from a
software system. We talk of Functional & Non-Functional
For example, in context to banking application the
functional requirement will be when customer selects
“View Balance” they must be able to look at their latest
account balance.
Software requirement can also be a non-functional, it
can be a performance requirement. For example, a non-
functional requirement is where every page of the system
should be visible to the users within 5 seconds.
The requirement analysis document collects, organizes, and tracks the
project requirements from key stakeholders. It guides project planning and
ensures you complete your projects aligned with stakeholder and business
goals
 REQUIREMENTS ANALYSIS
• Scenario-based: user interaction with system
– Use-case: descriptions of the interaction
• Data-based: data objects in system
– ER (entity-relation) Diagrams
– Class-based: data + methods
• OO, Class diagrams, implied by scenarios
• Behavioral-based: how external events change system
– State, sequence diagram
• Flow-based: information transforms
– Data flow, control flow diagrams

7
 A Bridge
system
description

analysis
model

design
model

ANALYSIS MODEL: a representation of requirements

in terms of text and diagrams depicting requirements for
data, function and system behavior in a way easy to
understand and review for correctness, completeness
and consistency
 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 (focus on the “WHAT”, not “HOW”).
• Each element of the analysis 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 non-functional
models until design.
• Minimize coupling throughout the system.
• Be certain that the analysis model provides value to all
stakeholders. Each constituency has its own use for the model
• Keep the model as simple as it can be.
 Domain Analysis
The identification, analysis, and specification of common requirements,
typically for reuse on multiple projects within that application domain.

Sources of domain knowledge

Technical literature

Existing application

Customer surveys

Expert advice

Current/future requirements
Modeling approaches

11
 Modeling for WebApps
Content Analysis. the content is identified, including text,
graphics and images, video, and audio data.
Interaction Analysis. The manner in which the user interacts
with the WebApp is described in detail.
Functional Analysis. The usage scenarios (use-cases) created
as part of interaction analysis define the operations that
will be applied to WebApp content and imply other
processing functions.
Configuration Analysis. The environment and infrastructure
in which the WebApp resides are described in detail.
Server-client side.

12
 In which phase of the whole process?

Phase 2
Phase

Phase 1
Design Phase 3 Phase 4
Develop
Information- Realization Implementation
blueprint
system

Needs Feasibilty- Functional Technical

Steps

for system study Design Design

Document

Functional Technical
Definition Feasibility Specification Specification

Requirements
Analysis 13
 Requirements Analysis
• Requirements analysis
– specifies software’s operational characteristics
– indicates software's interface with other system elements
– establishes constraints that software must meet
• Requirements analysis allows the software engineer (called an
analyst or modeler in this role) to:
– elaborate on basic requirements established during earlier
requirement engineering tasks
– build models that depict user scenarios, functional activities,
problem classes and their relationships, system and class
behavior, and the flow of data as it is transformed.
 Scenario-Based Modeling
• Although the success of a computer-based system or
product is measured in many ways, user satisfaction
resides at the top of the list. If you understand how end
users (and other actors) want to interact with a system,
your software team will be better able to properly
characterize requirements and build meaningful
analysis and design models. Hence, requirements
modeling with UML begins with the creation of
scenarios in the form of use cases, activity diagrams.
 Scenario-Based Modeling
• “[Use-cases] are simply an aid to defining what exists
• outside the system (actors) and what should be
• performed by the system (use-cases).” Ivar Jacobson
• (1) What should we write about?
• (2) How much should we write about it?
• (3) How detailed should we make our description?
• (4) How should we organize the description?
 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.
 How Much to Write About?
• As further conversations with the stakeholders
progress, the requirements gathering team develops
use cases for each of the functions noted.
• In general, use cases are written first in an
• informal narrative fashion.
• If more formality is required, the same use
• case is rewritten using a structured format
• similar to the one proposed.
Use-Cases
• a scenario that describes a “thread of usage”
for a system
• actors represent roles people or devices play
as the system functions
• users can play a number of different roles for
a given scenario
 Developing a Use-Case
• What are the main tasks or functions that are performed
by the actor?
• What system information will the actor acquire,
produce or change?
• Will the actor have to inform the system about changes
in the external environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected
changes?
Creating a Preliminary Use Case
 CREATING A PRELIMINARY USE CASE

Homeowner actor:
•Access camera surveillance via the internet
•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.
 CREATING A PRELIMINARY USE CASE
conversations with the stakeholder (who plays the role of a homeowner) Use case: Access
camera surveillance via the Internet—display camera views (ACS- DCV)

Actor: homeowner:
If I’m at a remote location, I can use any PC with appropriate browser software to log on to the
Safe Home Products website. I enter my user ID and two levels of passwords and once I’m
validated, I have access to all functionality for my installed Safe Home system. To access a
specific camera view, I select “surveillance” from the major function buttons displayed. I then
select “pick a camera” and the floor plan of the house is displayed. I then select the camera that
I’m interested in. Alternatively, I can look at thumbnail snapshots from all cameras
simultaneously by selecting “all cameras” as my viewing choice. Once I choose a camera, I
select “view” and a one- frame-per-second view appears in a viewing window that is identified
by the camera ID. If I want to switch cameras, I select “pick a camera” and the original viewing
window disappears and the floor plan of the house is displayed again. I then select the camera
that I’m interested in. A new viewing window appears.
 CREATING A PRELIMINARY USE CASE

use case: access camera surveillance via the internet—display camera views (acs-dcv)
ACTOR: homeowner
1.the homeowner logs onto the safe home 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?
 Refining a Preliminary Use Case

For example,

consider steps 6 and 7 in the primary scenario presented earlier:

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
Analysis Modeling Approaches
• STRUCTURED ANALYSIS considers data and processes
transforming the data as separate entities. Data objects are
modeled defining their attributes and relationships. Processes
depict transformation of data objects as they flow through
the system.

• OBJECT-ORIENTED ANALYSIS focuses on the definition of

classes and the way they collaborate with one another to
satisfy customer requirements. (UML and Unified Process are
predominantly object-oriented)
 Data Modeling
Data modeling is the process used to structure how data is stored, as well as
modeling relationships within the data .
It is the process of creating a simplified diagram of a software system and
the data elements it contains, using text and symbols to represent the data
and how it flows. Data models provide a blueprint for designing a new
database or reengineering a legacy application.
• 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

Data Modeling
Data modeling essentially works with the same elements as class-based modeling (object,
attributes, relationships), but uses the information to produce a detailed model, termed a
physical model, of what the database structure will be that will hold all the data; for
example, the name, passport number and other details of the travelers that use the airline
application.
 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
They can be used to (1) name an instance of the data object, (2)
describe the instance, or (3) make reference to another instance in
another table.

object:
automobile
attributes:
make
model
body type
price
options code
 What is a Relationship?
Data objects are connected to one another in different ways.
Relationship Consider the two data objects, person and car.

•A person owns a car.

•A person is insured to drive a car
 Entity-Relationship Diagrams
The object-relationship pair is the cornerstone of the data model. These
pairs can be represented graphically using the entity relationship
diagram (ERD).

A set of primary components is identified for the ERD:

Data objects, attributes, relationships, and various type indicators. The
primary purpose of the ERD is to represent data objects and their
relationships.

CLASS-BASED MODELING
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.
 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
Requirements Modeling Strategies
Following are the requirement modeling strategies:
1. Flow Oriented Modeling
• Data flow model
• Control flow model
• Control Specification
• Process Specification
2. Class-based Modeling
• Classes
• Attributes
• Operations
 1. Flow Oriented Modeling
• It shows how data objects are transformed by processing the
function.
The Flow oriented elements are:
1. Data flow model
• It is a graphical technique. It is used to represent information flow.
• The data objects are flowing within the software and transformed
by processing the elements.
• The data objects are represented by labeled arrows. Transformation
are represented by circles called as bubbles.
• DFD shown in a hierarchical fashion. The DFD is split into
different levels. It also called as 'context level diagram'.
Components of Data Flow Diagram:
Following are the components of the data flow diagram that are used to represent source,
destination, storage and flow of data.

•Entities:
Entities include source and destination of the data. Entities are represented by rectangle
with their corresponding names.
•Process:
The tasks performed on the data is known as process. Process is represented by circle.
Somewhere round edge rectangles are also used to represent process.
•Data Storage:
Data storage includes the database of the system. It is represented by rectangle with both
smaller sides missing or in other words within two parallel lines.
•Data Flow:
The movement of data in the system is known as data flow. It is represented with the help
of arrow. The tail of the arrow is source and the head of the arrow is destination.
Components of DFD
The Data Flow Diagram has 4 components:
Process
Input to output transformation in a system takes place because of process function. The symbols of a process
are rectangular with rounded corners, oval, rectangle or a circle. The process is named a short sentence, in one
word or a phrase to express its essence
Data Flow
Data flow describes the information transferring between different parts of the systems. The arrow symbol is
the symbol of data flow. A relatable name should be given to the flow to determine the information which is
being moved. Data flow also represents material along with information that is being moved. Material shifts
are modeled in systems that are not merely informative. A given flow should only transfer a single type of
information. The direction of flow is represented by the arrow which can also be bi-directional.
Warehouse
The data is stored in the warehouse for later use. Two horizontal lines represent the symbol of the store. The
warehouse is simply not restricted to being a data file rather it can be anything like a folder with documents,
an optical disc, a filing cabinet. The data warehouse can be viewed independent of its implementation. When
the data flow from the warehouse it is considered as data reading and when data flows to the warehouse it is
called data entry or data updation.
Terminator
The Terminator is an external entity that stands outside of the system and communicates with the system. It
can be, for example, organizations like banks, groups of people like customers or different departments of the
same organization, which is not a part of the model system and is an external entity. Modeled systems also
communicate with terminator.
 DFD for Library Management System

•Book request when a student requests for a book.

•Library card when the student has to show or submit his/her identity as a proof.

The overall processing unit will contain the following output that a system will
produce or generate:
• Book will be the output as the book demanded by the student will be given to
them.
• Information of demanded book should be displayed by the library information
system that can be used by the student while selecting the book which makes it
easier for the student.
Level 0 DFD
Level 1 DFD –
At this level, the system has to show or exposed with more details of processing.
The processes that are important to be carried out are:
•Book delivery
•Search by topic
List of authors, List of Titles, List of Topics, the bookshelves from which books can be
located are some information that is required for these processes. Data store is used
to represent this type of information.
Level 2 DFD –
Use Case Diagram for Library Management System
Here, we will understand the designing use case diagram for the library management system.
Some scenarios of the system are as follows :
•User who registers himself as a new user initially is regarded as staff or student for the library
system.
•For the user to get registered as a new user, registration forms are available that is
needed to be fulfilled by the user.
•After registration, a library card is issued to the user by the librarian. On the library card,
an ID is assigned to cardholder or user.
•After getting the library card, a new book is requested by the user as per there requirement.
•After, requesting, the desired book or the requested book is reserved by the user that means
no other user can request for that book.
•Now, the user can renew a book that means the user can get a new due date for the desired
book if the user has renewed them.
•If the user somehow forgets to return the book before the due date, then the user pays fine. Or
if the user forgets to renew the book till the due date, then the book will be overdue and the
user pays fine.
•User can fill the feedback form available if they want to.
•Librarian has a key role in this system. Librarian adds the records in the library database
about each student or user every time issuing the book or returning the book, or paying fine.
•Librarian also deletes the record of a particular student if the student leaves the college or
passed out from the college. If the book no longer exists in the library, then the record of the
particular book is also deleted.
•Updating database is the important role of Librarian.
Levels of DFD
DFD uses hierarchy to maintain transparency thus multilevel DFD’s can be
created. Levels of DFD are as follows:
0-level DFD
1-level DFD:
2-level DFD:

Rules for creating DFD

•The name of the entity should be easy and understandable without any extra

assistance(like comments).
•The processes should be numbered or put in ordered list to be referred easily.
•The DFD should maintain consistency across all the DFD levels.
•A single DFD can have maximum processes upto 9 and minimum 3 processes.
0-level DFD: 
It is also known as a context diagram. It’s designed to be an abstraction view,
showing the system as a single process with its relationship to external entities. It
represents the entire system as a single bubble with input and output data
indicated by incoming/outgoing arrows. 
1-level DFD: 
In 1-level DFD, the context diagram is decomposed into multiple bubbles/processes.
In this level, we highlight the main functions of the system and breakdown the
high-level process of 0-level DFD into sub processes. 
 
2-level DFD: 
2-level DFD goes one step deeper into parts of 1-level DFD. It can be used to
plan or record the specific/necessary detail about the system’s functioning. 
 2. Control flow model

• Large class applications require a control flow

modeling.
• The application creates control information instated
of reports or displays.
• The applications process the information in specified
time.
• An event is implemented as a boolean value.
For example, the boolean values are true or false, on
or off, 1 or 0.
 3 Control Specification
• A short term for control specification is CSPEC.
• It represents the behaviour of the system.
• The state diagram in CSPEC is a sequential
specification of the behaviour.
• The state diagram includes states, transitions,
events and activities.
• State diagram shows the transition from one state
to another state if a particular event has occurred.
 Process Specification
• A short term for process specification is
PSPEC.
• The process specification is used to describe
all flow model processes.
• The content of process specification consists
narrative text, Program Design Language(PDL)
of the process algorithm, mathematical
equations, tables or UML activity diagram.
 Class-Based Modeling
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.
 Class-based modeling represents:
• objects that the system will manipulate
• operations (also called methods or services) that will
be applied to the objects to effect the manipulation
• relationships (some hierarchical) between the objects
• collaborations that occur between the classes that
are defined.
 The elements of a class-based model include classes and
objects, attributes, operations, and collaboration diagrams.
Class-based modeling identifies 
classes, attributes and relationships that the system will use.
In the airline application example, the traveler/user and the boarding pass represent
classes. The traveler's first and last name and travel document type represent
attributes, characteristics that describe the traveler class. The relationship between
traveler and boarding pass classes is that the traveler must enter these details into the
application in order to get the boarding pass and that the boarding pass contains this
information along with other details, like the flight departure gate, seat number, etc.
 Identifying Analysis Classes
 Examining the usage scenarios developed as part of the
requirements model and perform a "grammatical parse" [Abb83]

•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?
Analysis classes manifest them selves in one of the following ways:
• 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.
we can propose a number of potential classes
Coad and Yourdon [Coa91] suggest six selection
characteristics that should be used as you consider
each potential class for inclusion in the analysis
model:
• Retained information.
• Needed services.
• Multiple attributes.
• Common attributes.
• Common operations
• Essential requirements.
Specifying Attributes
• Attributes are the set of data objects that fully define the
class within the context of the problem
• Attributes describe a class that has been selected for
inclusion in the requirements model.
Defining Operations
• Operations define the behavior of an object. When you
define operations for an analysis class, focus on problem-
oriented behavior rather than behaviors required for
implementation
Defining Operations
Class-Responsibility-Collaborator (CRC)
Modeling
Class-responsibility-collaborator (CRC) modeling
provides a simple means for identifying and
organizing the classes that are relevant to system or
product requirements.
class
The taxonomy of class types Section can be extended
by considering the following categories:
•Entity classes, also called model or business classes,
are extracted
directly from the statement of the problem.
•Boundary classes are used to create the interface.