Building the Analysis Model:

An analysis model is a representation of the requirements for a computer-based system. It helps software engineers
and stakeholders understand what the system needs to do and how it should behave.

1. Dynamic Nature: The analysis model changes over time as software engineers gain more knowledge about
the system and stakeholders refine their requirements. It's a snapshot of the requirements at any given time
and is expected to evolve.

2. Multiple Modes of Representation: There is a debate among software practitioners regarding whether to
use a single representation (e.g., use-cases) exclusively or to use multiple modes of representation. Using
different modes helps uncover omissions, inconsistencies, and ambiguities in requirements.

3. Elements of the Analysis Model: The specific elements of an analysis model may vary depending on the
modeling method used, but some generic elements are common to most analysis models. These elements
include:

 Scenario-based elements: These describe the system from the user's perspective using scenarios or
use-cases. They are often the first part of the analysis model to be developed.

 Class-based elements: These involve categorizing objects manipulated by the system into classes.
Class diagrams depict attributes and behaviors of these classes.

 Behavioral elements: These represent the behavior of the system. State diagrams can be used to
show the system's states and the events that trigger state changes.

 Flow-oriented elements: These describe how information is transformed as it flows through the
system. They include input, transformation, and output components.

4. Analysis Patterns: Analysis patterns are reusable models or templates that capture common elements within
a specific application domain. They can speed up the development of analysis models and assist in
transforming the analysis model into a design model. Analysis patterns are typically described using a
template that includes pattern name, intent, motivation, forces and context, solution, and consequences.

Analysis Modeling

Definition

 The development process starts with the analysis phase.

 This phase results in a specification document that shows what the software will do
without specifying how it will be done.

 The analysis phase can use two separate approaches, depending on whether the
implementation phase is done using a procedural programming language or an
object-oriented language.
Analysis Principles

 The information domain must be represented and understood.

 Models should be developed to give emphasis on system information, function and

behavior.

 Models should uncover and give details of all the layers of the development process.

 The function and the problem statement must be defined.

 The various analysis models are flow oriented modeling, scenario based modeling,
class based modeling, and behavioral modeling.

Need

 Analysis modeling describes the operational and behavioral characteristics.

 Shows the relationship between software interface and other software elements.

 Provides the software developer the representation of the information, function, and
behavior.

 Coverts the design into the more descriptive models like use case, ER diagram.

 Provides the customer and the developer the means to maintain the quality.

Objective

 Describe what the customer requires.

 Establish a basis for the creation of a software design.

 Devise a set of requirements that can be validated once the software is built.

 Analysis model bridges the gap between system level description and the overall
system functionality.
Analysis Rules Of Thumb

 The model should focus on requirements that are visible within the
problem or business domain and be written as a relatively high level of
abstraction.

 Each element of the analysis model should add to the understanding of

the 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 the analysis model provides value to all stakeholders.

 Keep the model as simple as possible.

  The below Figure shows the structure of analysis modeling.

Figure :Structure of analysis modeling

Analysis Modeling Approaches

1. Structured analysis
a. Considers data and the processes that transform the data as separate entities.
b. Data objects are modeled in a way that defines their attributes and relationships.
c. Processes that manipulate data objects are modeled in a manner that shows how they
transform data as data objects flow through the system.

i. Considers data and processes that transform data as separate entities.

ii. Structure analysis is a top down approach.

iii. It focuses on refining the problem with the help of the functions performed
on the problem domain.

2. Object-oriented analysis

a. 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 (Chapter 3)
are predominantly object-oriented.
"[Ajnolysis is frustrating, full of complex interpersonal relationships, indefinite, and difficult. In a word, it is
fascinating. Once you're hooked, the old easy pleasures of system building are never again enough to satisfy you."
Tom DeMarco
Although the analysis model that we propose in this book combines features of
both approaches, software teams often choose one approach and exclude all representations
from the other. The question is not which is best, but what combination
of representations will provide stakeholders with the best model of software requirements
and the most effective bridge to software design.
Analysis modeling leads to the derivation of each of the modeling elements
shown in Figure 8.3. However, the specific content of each element (i.e., the diagrams
that are used to construct the element and the model) may differ from project
to project. As we have noted a number of times in this book, the software team must
work to keep it simple. Only those modeling elements that add value to the model
should be used.
"Why should we build models? Why not just build the system itself? The onswer is that we can construct models in
such a way as to highlight, or emphasize, certain critical features of a system, while simultaneously de-emphasizing
other aspects of the system."
Ed Yourdon
Elements of
i. Focuses on the definition of classes and the manner in which
they collaborate to effect the customer requirements.

ii. Defines the system as a set of objects which interact with each other with
the services provided.

iii. Analyses the problem domain and then partitions the problem with
the help of objects.

iv. The concept of object, attributes, class, operation, inheritance, and

polymorphism should be known to work on object oriented
modelling.