Analysis Modeling

Requirements Analysis
• Analysis Model - > set of models is the first technical representation of a system
and it specifies structured analysis, object oriented analysis and requirement
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 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.

• Throughout analysis modeling, the SE’s primary focus is on what not on how.

• Analysis model and the requirements specification provide the developer and the
customer with means to assess quality once software is built.
 Analysis Modeling Principles
• Analysis methods are related by a set of operational principles:
1. The information domain of a problem must be represented and
understood.

2. The functions that are software performs must be defined.

3. The behavior of the software must be represented.

4. The models that depict information, function and behavior must be

partitioned in a manner that uncovers detail in a layered fashion.

5. The analysis task should move from essential information toward

implementation detail.
 Analysis Modeling Principles – cntd.,
1. Information domain encompasses that the data flow into the system, out
of the system and data stored.
2. Functions provide direct benefit to end-users and also provide internal
support for those features that are user visible.
3. Behavior driven by its interaction with the external environment.
E.g. Input provided by end-users, control data provided by an external
system, or monitoring data.
4. Key strategy of analysis model, divide complex problem into sub-
problem until each sub-problem is relatively easy to understood. This
concept is called partitioning.
5. The “essence” of the problem is described without any consideration of
how a solution will be implemented.
E.g. Video game requires that player “instruct”
Implementation detail indicates how the essence will be implemented
E.g. Keyboard command might be typed or a joystick used.
 Analysis Model Objectives
Three Primary Objectives:
– To describe what the customer requires.
– To establish a basis for the creation of a software design.
– To devise a set of requirements that can be validated once the
software is built.
• Its bridges the gap between
– a system-level description that describes overall system
functionality achieved by applying software, hardware, data and
human
– a software design describes the software application architecture,
user interface and component level structure.
Guidelines :
• Graphics should be used whenever possible.
• Differentiate between the logical (essential) and physical
(implementation) considerations.
• Develop a way to track and evaluate user interfaces.
Analysis Model - A Bridge
 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 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. - If level of interconnectedness

is high, efforts should be made to reduce it.

• Assured that the analysis model provides value to all stakeholders. –

business stakeholder should validate requirement, Designers should use
the model as a basis for design.

• Keep the model as simple as it can be. - No need to use additional

diagram and use notations.
 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 same function in terms of
common objects, classes, subassemblies and frameworks.
• The goal of domain analysis is straightforward: to find or create those
analysis classes and/or analysis patterns that are broadly applicable so
that they may be reused.
Fig: Input and Output of Domain Analysis
 Elements of Analysis model
Two approaches:
1. Structured Analysis:-
• Data objects are modeled in a way that defines their
attributes and relationships.
• Processes that manipulate data objects in a manner that
shows how they transform data as data objects flow
through the systems.

2. Object Oriented Analysis :-

• Focuses on the definition of classes and the manner in
which they collaborate with one another.
• UML is predominantly object oriented.
Elements of Analysis model
Data Modeling
 Data Modeling
• Analysis model often begin with data modeling is relevant to any data
processing application.
• Data model consists of three interrelated pieces of information:
– The data object,
– The attributes that describe the data object, and
– The relationships that connect data objects to one another.
Many Questions:
• What are the primary data objects to be processed by the system?
• What is the composition of each data object and what attributes describe
the object?
• Where do the objects currently reside?
• What are the relationships between each object and other objects?
• What are the relationships between the objects and the processes that
transform them?
• To answer these questions data modeling use the ER diagram.
 Data Object
• A data object is a representation of almost any composite information
that must be understood by software.

• composite information - number of different properties or attributes.

• A data object 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)
– Event (e.g., an alarm),
– A role (e.g., salesperson),
– An organizational unit (e.g., accounting department),
– A place (e.g., a warehouse),
– A structure (e.g., a file).
 Data Attributes

• Define the properties of a data object.

• Attributes name a data object, describe its characteristics, and in

some cases, make reference to another object.

• In addition, one or more of the attributes must be defined as an

identifier( Key value or Unique value).

• Ex. Data object Car has Id number as identifier.

 Relationships
• Data objects are connected to one another in different ways.

• Consider two data objects

• Book
• Bookstore

• A connection is established between book and bookstore because

the two objects are related.
 Relationships – cntd.,
• To determine relationship between them, must understand the role
of book and bookstore.
• Can define a set of object/relationship pairs that define the
relevant relationships.
For Example:
– A bookstore orders books.
– A bookstore displays books.
– A bookstore stocks books.
– A bookstore sells books.
– A bookstore returns books.
 Example of Data Modeling
Data Objects, Attributes and Relationship:
 Cardinality
• Additional element of data modeling.

• Object X relates to object Y does not provide enough information.

• How many occurrences of object X are related to how many occurrences of

object Y called cardinality.

• Representing the number of occurrences objects in a given relationship.

• Cardinality is the specification of the number of occurrences of one object that

can be related to the number of occurrences of another.

• Cardinality is usually expressed as simply 'one' or 'many’.

• 1:1 – One object can relate to only one other object.
• 1:M – one object can relate to many objects.
• M:N – Some no. of occurrences of an object can relate to some other no. of
occurrences of another object.
 Modality
• Cardinality does not provide an indication of whether or not a
particular data object must participate in the relationship.

• Modality of a relationship is 0 if there is no explicit need for the

relationship to occur or the relationship is optional.

• The modality is 1 if an occurrences of the relationship is mandatory.

 Entity Relationship Diagram
• The primary purpose of the ERD is to represent data objects and their
relationships.
Entity Relationship Diagram – cntd.,
Data Dictionary
 Data dictionary

• The data dictionary has been proposed for describing the content of
objects defined during structured analysis.

Definition:
• Data dictionary is an organized listing of all data elements that are
relevant to the system, with precise, rigorous definitions so that both
user and system analyst will have a common understanding of inputs,
outputs, components of stores and intermediate calculations.

• Data dictionary is always implemented as part of a CASE "structured

analysis and design tool.“
 Information of Data dictionary
• Name —the primary name of the data or control item, the data store
or an external entity.

• Alias —other names used for the first entry.

• Where-used/how-used —a listing of the processes that use the data

or control item and how it is used (e.g., input to the process, output
from the process, as a store, as an external entity.

• Content description—a notation for representing content.

• Supplementary information—other information about data types,

preset values (if known), restrictions or limitations, and so forth.
Notation
Data dictionary example
 Library Management System
Data Name Description Type Size Constraints Example
Unique ID Must be
Book_ID for each Integer 5 unique 10023
book
Title of the "Clean
Title book String 100 Not null Code"
Author of Alphabet "Robert
Author the book String 50 only Martin"
Unique ID Must be
Member_ID for each Integer 5 unique 20105
library user

Date when Must be ≤

Issue_Date book was Date — Today’s Date 2025-09-01
issued

Date when Must be ≥

Return_Date book should Date — Issue_Date 2025-09-15
be returned
Data Dictionary for an Online Shopping
System
Data Name Description Type Size Constraints Example
Unique
Customer_I Unique, not
identifier for Integer 6 100452
D null
user
Customer "Amit
Name String 50 Not null
full name Sharma"
Customer’s "
Must
Email email String 100 amit@gmail
contain “@” .com
address
"
Customer Digits only,
"987654321
Phone_No contact String 10 10
0"
number characters
Unique
Unique, not
Product_ID product Integer 6 202155
null
identifier
Price of
Price Decimal 8,2 ≥0 999.99
product
Number of
Quantity items Integer 3 ≥1 2
ordered
Date order Must be ≤
Order_Date Date — 2025-08-30
was placed Today’s Date
 Disadvantages of Data dictionary
Three fundamental ways:
1. As a sequence of data items
2. As a selection from among a set of data items
3. As a repeated grouping of data items.
• The data dictionary defines information items unambiguously.

Disadvantages:
1. For large projects, it is often quite difficult to determine the impact of a
change. Because the data dictionary can be treated as a database
2. For larger computer based systems the data dictionary grows rapidly in
size and complexity.
3. Difficult to maintain a dictionary manually because case tools should
be used.
Design heuristics (Heuristics = rules of thumb /
guidelines for making good design decisions.
Level Key Heuristics Example
Modularity, abstraction, Separate Book Module &
Architectural
low coupling, info hiding Member Module
Use DepartmentID not full
Info hiding, normalization,
Data Design DeptName in student
proper structures
record
Single responsibility, small Separate registerStudent()
Component-Level
functions, no side effects & collectFees()
Consistency, feedback, ATM showing “Insufficient
Interface Design
error handling Balance” message
Structured constructs,
Early returns instead of
Procedural Design avoid deep nesting,
nested ifs
meaningful names
 Steps in Real-Time Design

• Define System Objectives → What must the real-time system do?

• Identify Real-Time Events → External/internal events that trigger
tasks.
• Establish Timing Constraints → Define deadlines and response times.
• Model the System → Use DFDs, state diagrams, or UML to represent
flow.
• Design Architecture → Partition into tasks (processes/threads).
• Design Task Scheduling → Priority-based, round robin, or real-time
OS support.
• Design Interfaces → Communication between tasks (message
queues, shared memory).
• Design Error Handling → Fail-safe mechanisms for missed deadlines
or invalid input.