Analysis Concept & Principle

kal@ittelkom.ac.id

Outline
Requirement Analysis
Rule Of Thumb
Operational Principle
Information Domain
Modeling
Partitioning

Analysis Modeling

Requirements Analysis
Specifies softwares operational
characteristics
Indicates software's interface with other
system elements
Establishes constraints that software
must meet

Requirements Analysis
Requirements analysis allows the software
engineer (analyst or modeler in this
context) 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.

A Bridge
system
description

analysis
model
design
model

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 nonfunctional models until design.
Minimize coupling throughout the system.
Be certain that the analysis model provides value to all
stakeholders.
Keep the model as simple as it can be.

Operational Principles
The information domain of a problem must be
represented and understood.
The functions that the software is to perform must be
defined.
The behavior of the software must be represented.
The models that depict information, function, and
behavior must be partitioned in a manner that uncovers
detail in a layered (or hierarchical) fashion.
The analysis process should move from essential
information toward implementation detail.

Information Domain
The information domain contains three
different views of the data and control
information content and relationships (the
data model),
information flow, and
information structure.

Information Content
Represents the individual data and
control objects that constitute some
larger collection of information
transformed by the software.
Data and control objects can be related
to other data and control objects.
During the analysis of the information
domain, the relationships should be
defined.

Information Flow
Represents the manner in which data and
control change as each moves through a
system.

Information Structure
Represents the internal organization of
various data and control items.
Within the context of the structure, what
information is related to other information?
Is all information contained within a single
structure or are distinct structures to be used?
How does information in one information
structure relate to information in another
structure?

Modeling
Create functional models to gain a better
understanding of the actual entity to be
built.
It must be capable of representing the
information that software transforms, the
functions (and sub-functions) that enable
the transformation to occur, and the
behavior of the system as the
transformation is taking place.

Functional models
Software transforms information, and in order to
accomplish this, it must perform at least three
generic functions: input, processing, and output.
When functional models of an application are
created, the software engineer focuses on
problem specific functions.
The functional model begins with a single context
level model
Over a series of iterations, more and more functional
detail is provided, until a thorough delineation of all
system functionality is represented.

Behavioral models
Most software responds to events from the
outside world.
For example, software will remain in the wait
state until:
an internal clock indicates that some time interval
has passed,
an external event causes an interrupt, or
an external system signals the software to act in
some manner.

A behavioral model creates a representation of

the states of the software and the events that
cause a software to change state.

Model
Models created during requirements analysis
serve a number of important roles:
The model aids the analyst in understanding the
information, function, and behavior of a system,
thereby making the requirements analysis task easier
and more systematic.
The model becomes the focal point for review and,
therefore, the key to a determination of
completeness, consistency, and accuracy of the
specifications.
The model becomes the foundation for design,
providing the designer with an essential
representation of software that can be "mapped" into
an implementation context.

Partitioning
Problems are often too large and complex to be
understood as a whole.
In essence, partitioning decomposes a problem
into its constituent parts.
Conceptually, we establish a hierarchical
representation of function or information and
then partition the uppermost element by
exposing increasing detail by moving vertically in the
hierarchy, or
functionally decomposing the problem by moving
horizontally in the hierarchy

Horizontal Partitioning

Vertical Partitioning

Analysis Modeling
The analysis model must achieve three
primary objectives:
to describe what the customer requires,
to establish a basis for the creation of a
software design, and
to define a set of requirements that can be
validated once the software is built.

The structure of the analysis

model

Review
Requirement Analysis
Rule Of Thumb
Operational Principle
Information Domain
Modeling
Partitioning

Analysis Modeling