Analysis concepts and principles

Software requirements engineering is a process of

discovery, refinement, modeling, and specification. The
system requirements and role allocated to software—
initially established by the system engineer—are refined
in detail. Models of the required data, information and
control flow, and operational behavior are created.
Alternative solutions are analyzed and a complete
analysis model is created. Donald Reifer describes the
software requirement engineering process in the
following way:
Requirements engineering is the systematic use of
proven principles, techniques, languages, and tools for
the cost effective analysis, documentation, and on-going
evolution of user needs and the specification of the
external behavior of a system to satisfy those user
needs. Notice that like all engineering disciplines,
requirements engineering is not conducted in a sporadic,
random or otherwise haphazard fashion, but instead is
the systematic use of proven approaches.

the Elements of the Analysis Model Data Modifying

 Analysis model operates as a link between the 'system

description' and the 'design model'.
 In the analysis model, information, functions and the
behaviour of the system is defined and these are
translated into the architecture, interface and component
level design in the 'design modeling'.
Elements of the analysis model
1. Scenario based element
 This type of element represents the system user point of
view.
 Scenario based elements are use case diagram, user
stories.
2. Class based elements
 The object of this type of element manipulated by the
system.
 It defines the object,attributes and relationship.
 The collaboration is occurring between the classes.
 Class based elements are the class diagram,
collaboration diagram.
3. Behavioral elements
 Behavioral elements represent state of the system and
how it is changed by the external events.
 The behavioral elements are sequenced diagram, state
diagram.
4. Flow oriented elements
 An information flows through a computer-based system
it gets transformed.
 It shows how the data objects are transformed while
they flow between the various system functions.
 The flow elements are data flow diagram, control flow
diagram.

Analysis Rules of Thumb

The rules of thumb that must be followed while creating
the analysis model.

The rules are as follows:

 The model focuses on the requirements in the business
domain. The level of abstraction must be high i.e there is
no need to give details.
 Every element in the model helps in understanding the
software requirement and focus on the information,
function and behaviour of the system.
 The consideration of infrastructure and nonfunctional
model delayed in the design.
For example, the database is required for a system, but
the classes, functions and behavior of the database are
not initially required. If these are initially considered
then there is a delay in the designing.
 Throughout the system minimum coupling is required.
The interconnections between the modules is known as
'coupling'.
 The analysis model gives value to all the people related
to model.
 The model should be simple as possible. Because simple
model always helps in easy understanding of the
requirement.
Concepts of data modeling
 Analysis modeling starts with the data modeling.
 The software engineer defines all the data object that
proceeds within the system and the relationship between
data objects are identified.
Data objects
 The data object is the representation of composite
information.
 The composite information means an object has a
number of different properties or attribute.
For example, Height is a single value so it is not a valid
data object, but dimensions contain the height, the width
and depth these are defined as an object.
Data Attributes
Each of the data object has a set of attributes.

Data object has the following characteristics:

 Name an instance of the data object.
 Describe the instance.
 Make reference to another instance in another table.
Relationship
Relationship shows the relationship between data objects
and how they are related to each other.

Cardinality
Cardinality state the number of events of one object
related to the number of events of another object.

The cardinality expressed as:

One to one (1:1)

One event of an object is related to one event of another
object.
For example, one employee has only one ID.

One to many (1:N)

One event of an object is related to many events.
For example, One collage has many departments.

Many to many(M:N)
Many events of one object are related to many events of
another object.
For example, many customer place order for many
products.

Modality
 If an event relationship is an optional then the modality
of relationship is zero.
 If an event of relationship is compulsory then modality of
relationship is one.
Functional Modeling and Information Flow and Behavior
Modeling

In the Functional Model, software converts

information. and to accomplish this, it must perform at
least three common tasks- input, processing and output.
When functional models of an application are created,
the software engineer emphasizes problem specific
tasks. The functional model begins with a single
reference level model (i.e., be manufactured). In a
series of iterations, more and more functional detail is
given, until all system functionality is fully represented.
Information is converted because it flows from a
computer-based system. The system takes input in
various forms; Hardware, software, and human elements
are applied to replace it; And produces in various forms.
The transformation (s) or function may be composed of
a single logical comparison, a complex numerical
method, or a rule- the invention approach of an expert
system. The output can light an LED or provide a 200
page report. Instead, we can create a model or flow
model for any computer- based system, regardless of
size and complexity.
Structural analysis started as an Information Flow
Modelling technique. A computer-based system can be
modeled as an information transform function as shown
in figure.
A rectangle represents an external unit. That is, a
system element, such as a hardware, a person or
another system that provides information for
transformation by the software or receives information
provided by the software. A circle is used to represent a
process or transform or a function that is applied to data
and changes it in some way. An arrow is used to
represent one or more data items.

All arrows should be labeled in a DFD. The double line is

used to represent data store. There may be implicit
procedure or sequence in the diagram but explicit logical
details are generally delayed until software design.
Behavior Modeling

In software engineering, behavioral model describe the

overall behavior of the system. There are two types of

behavioral models that are used to describe the system

behavior, one is data processing model and another is

state machine models. Data processing models are also

known as DFD (Data Flow Diagram) which is used to

show how data is processed as it moves through the

system. State machine model is also known as State

diagram which is used to show how the system will react

with external events.

Data Flow Diagram

 Data flow diagram is used to model the system’s

data processing.

 It is also cay as the Functional model as it is a

graphical representation of an enterprise function

within a defined scope. Data flow diagram shows end

to end data processing.

 It can be easily converted into software as they just

represent flow of the data objects. DFD diagram

enable Software engineer to develop a model of the

information domain and Functional domain at the

same time.

 It provide a logical model of the system and show

the flow of the data and the flow of logic involved.

Characteristics of Data Flow Diagram

 It shows the process, that transforms incoming data

flows into outgoing data flows.

 Process that performs this transformation normally

creates as well as uses data.

 External entities send and receive data flow from the

systems.

 It is also called a bubble chart.

 Data flow diagram support a top-down approach for

analysis.

Guidelines for Data Flow Diagram

 Level 0 DFD should depict software system as single

bubble.

 Primary input and output are carefully noted.

 Refinement should begin by isolating candidate

processes, data objects, data stores to be

represented at the next level.

 All arrows and bubbles should be labeled with full

names.
 Information flow continuity must be maintained from

level to level. That means the data objects that flow

into the system of any transformation at one level

must be the same. Data objects that flow into

transformation at the more refined level.

 One bubble at a time should be refined.

Data Flow Diagram Notation

Data flow diagram consists of a series of symbols joined

together by a line. Data objects are represented by

circles which are also called bubble charts. Data flow

diagram are represented in hierarchical order. The first

level data flow model is also called as DFD 0 level or

context diagram which represents the system as a whole.

Second level data flow model refines the context diagram

and provides more details of first-level DFD. In a similar

way, third level DFD refines the second level DFD, and so
on. Data flow analysis models are developed by two

organizations – Yourdon incorporation and Gane and

Sarson.

Notations are as follows:

 Data Flow: It represents the movement of data flow

from a specific origin to a destination.

 Process: It represents the users, procedures, or

devices that use the data.

 Entity: It represents the source of data or

destination data external sources or destination of

data which may be users, programs, organizations or

other entities that interact with the system but are

outside its boundary.

 Data Store: There can be a single DFD diagram or

can be exploded into various levels lime level 1, level

2, level 3, etc.

Notation Name Yourdon Gane and Sarson

Incorporation

Data Flow

Process

Entity

Data Store

State Diagram
State diagram is a dynamic model which represents the

changes of state that an object goes through during the

lifetime in response to events. It is used to help the

developer better understand any complex functionality of

specialized areas of the system.

Notations used in state diagram:

1. Initial State

It represents the start point of the diagram. It is also

called as pseudo state where state has no variables and

no activities.

2. Final State

It represents the end point of the diagram. It is also

pseudo state as it doesn’t have any Variable or activities.

State diagram can have zero or more final states.

3. State

It represents the state of the object at an instant of time.

State is a recognizable situation and exists over an

interval of time.
4. Transition

It represents the changes from one state to other. It is

denoted by an arrow. The event or action causing the

transition is written beside the arrow, separated by slash.

Triggerless transition occurs when the state completed an

activity

5. Event and Action

Trigger that causes a transition to occur and changes the

state is called event or action.

6. History State

A flow may require that the object go into a wait state

and on the occurrence of a certain event, go back to the

state it was in, in this situation this notation is used.

7. Signal

When even causes the trigger to be sent to a state that

causes the transition, then that message sent by the

event is called a signal.

8. Self Transition

A state that has a transition that returns to itself is called

self-transition.

Mechanics of Structured Analysis

Structured Analysis is a development method that allows

the analyst to understand the system and its activities in
a logical way.
It is a systematic approach, which uses graphical tools
that analyze and refine the objectives of an existing
system and develop a new system specification which can
be easily understandable by user.
It has following attributes −
 It is graphic which specifies the presentation of
application.
 It divides the processes so that it gives a clear
picture of system flow.
 It is logical rather than physical i.e., the elements of
system do not depend on vendor or hardware.
 It is an approach that works from high-level
overviews to lower-level details.
Structured Analysis Tools

During Structured Analysis, various tools and techniques

are used for system development. They are −
 Data Flow Diagrams
 Data Dictionary
 Decision Trees
 Decision Tables
 Structured English
 Pseudocode
Data Flow Diagrams (DFD) or Bubble Chart

It is a technique developed by Larry Constantine to

express the requirements of system in a graphical form.
 It shows the flow of data between various functions
of system and specifies how the current system is
implemented.
 It is an initial stage of design phase that functionally
divides the requirement specifications down to the
lowest level of detail.
 Its graphical nature makes it a good communication
tool between user and analyst or analyst and system
designer.
 It gives an overview of what data a system
processes, what transformations are performed, what
data are stored, what results are produced and
where they flow.
Basic Elements of DFD
DFD is easy to understand and quite effective when the
required design is not clear and the user wants a
notational language for communication. However, it
requires a large number of iterations for obtaining the
most accurate and complete solution.
The following table shows the symbols used in designing
a DFD and their significance −

Symbol Symbol Meaning

Name
Square Source or Destination of
Data

Arrow Data flow

Circle Process transforming data

flow

Open Data Store

Rectangle

Types of DFD
DFDs are of two types: Physical DFD and Logical DFD.
The following table lists the points that differentiate a
physical DFD from a logical DFD.

Physical DFD Logical DFD

It is implementation It is implementation
dependent. It shows which independent. It focuses only
functions are performed. on the flow of data between
processes.

It provides low level details It explains events of

of hardware, software, systems and data required
files, and people. by each event.
It depicts how the current It shows how business
system operates and how a operates; not how the
system will be system can be
implemented. implemented.

Context Diagram
A context diagram helps in understanding the entire
system by one DFD which gives the overview of a
system. It starts with mentioning major processes with
little details and then goes onto giving more details of the
processes with the top-down approach.
The context diagram of mess management is shown
below.

Data Dictionary

A data dictionary is a structured repository of data

elements in the system. It stores the descriptions of all
DFD data elements that is, details and definitions of data
flows, data stores, data stored in data stores, and the
processes.
A data dictionary improves the communication between
the analyst and the user. It plays an important role in
building a database. Most DBMSs have a data dictionary
as a standard feature. For example, refer the following
table −

Sr.No. Data Name Description No. of Characters

1 ISBN ISBN Number 10

2 TITLE title 60

3 SUB Book Subjects 80

4 ANAME Author Name 15

Decision Trees

Decision trees are a method for defining complex

relationships by describing decisions and avoiding the
problems in communication. A decision tree is a diagram
that shows alternative actions and conditions within
horizontal tree framework. Thus, it depicts which
conditions to consider first, second, and so on.
Decision trees depict the relationship of each condition
and their permissible actions. A square node indicates an
action and a circle indicates a condition. It forces analysts
to consider the sequence of decisions and identifies the
actual decision that must be made.

The major limitation of a decision tree is that it lacks

information in its format to describe what other
combinations of conditions you can take for testing. It is
a single representation of the relationships between
conditions and actions.
For example, refer the following decision tree −
Decision Tables

Decision tables are a method of describing the complex

logical relationship in a precise manner which is easily
understandable.
 It is useful in situations where the resulting actions
depend on the occurrence of one or several
combinations of independent conditions.
 It is a matrix containing row or columns for defining
a problem and the actions.
Components of a Decision Table
 Condition Stub − It is in the upper left quadrant
which lists all the condition to be checked.
 Action Stub − It is in the lower left quadrant which
outlines all the action to be carried out to meet such
condition.
 Condition Entry − It is in upper right quadrant
which provides answers to questions asked in
condition stub quadrant.
 Action Entry − It is in lower right quadrant which
indicates the appropriate action resulting from the
answers to the conditions in the condition entry
quadrant.
The entries in decision table are given by Decision Rules
which define the relationships between combinations of
conditions and courses of action. In rules section,
 Y shows the existence of a condition.
 N represents the condition, which is not satisfied.
 A blank - against action states it is to be ignored.
 X (or a check mark will do) against action states it is
to be carried out.
For example, refer the following table −

CONDITIONS Rule Rule Rule Rule

1 2 3 4

Advance payment made Y N N N

Purchase amount = Rs - Y Y N
10,000/-

Regular Customer - Y N -

ACTIONS

Give 5% discount X X - -

Give no discount - - X X

Structured English

Structure English is derived from structured programming

language which gives more understandable and precise
description of process. It is based on procedural logic
that uses construction and imperative sentences
designed to perform operation for action.
 It is best used when sequences and loops in a
program must be considered and the problem needs
sequences of actions with decisions.
 It does not have strict syntax rule. It expresses all
logic in terms of sequential decision structures and
iterations.
For example, see the following sequence of actions −

if customer pays advance

then
Give 5% Discount
else
if purchase amount >=10,000
then
if the customer is a regular customer
then Give 5% Discount
else No Discount
end if
else No Discount
end if
end if
Pseudocode

A pseudocode does not conform to any programming

language and expresses logic in plain English.
 It may specify the physical programming logic
without actual coding during and after the physical
design.
 It is used in conjunction with structured
programming.
 It replaces the flowcharts of a program.
Guidelines for Selecting Appropriate Tools

Use the following guidelines for selecting the most

appropriate tool that would suit your requirements −
 Use DFD at high or low level analysis for providing
good system documentations.
 Use data dictionary to simplify the structure for
meeting the data requirement of the system.
 Use structured English if there are many loops and
actions are complex.
 Use decision tables when there are a large number of
conditions to check and logic is complex.
 Use decision trees when sequencing of conditions is
important and if there are few conditions to be
tested.
Data Dictionary
Data Dictionary is the major component in
the structured analysis model of the system. It lists all
the data items appearing in DFD. A data dictionary in
Software Engineering means a file or a set of files that
includes a database’s metadata (hold records about
other objects in the database), like data ownership,
relationships of the data to another object, and some
other data.
Example a data dictionary entry: GrossPay = regular
pay + overtime pay
Case Tools is used to maintain data dictionary as it
captures the data items appearing in a DFD
automatically to generate the data dictionary.
Components of Data Dictionary:

In Software Engineering, the data dictionary contains the

following information:
 Name of the item: It can be your choice.
 Aliases: It represents another name.
 Description: Description of what the actual text is all
about.
 Related data items: with other data items.
 Range of values: It will represent all possible
answers.
Data Dictionary Notations tables :
The Notations used within the data dictionary are given
in the table below as follows:

Notations Meaning

X = a+b X consists data elements a and b.

X = [a/b] X consists of either elements a or b.

X=aX X consists of optimal data elements a.

X consists of y or more events of data

X = y[a]
element a

X consists of z or less events of data

X = [a] z
element a

X = y [a] X consists of some events of data elements

z between y and z.

Features of Data Dictionary :

Here, we will discuss some features of the data

dictionary as follows.
 It helps in designing test cases and designing the
software.
 It is very important for creating an order list from a
subset of the items list.
 It is very important for creating an order list from a
complete items list.
 The data dictionary is also important to find the
specific data item object from the list.
Uses of Data Dictionary :

Here, we will discuss some use cases of the data

dictionary as follows.
 Used for creating the ordered list of data items
 Used for creating the ordered list of a subset of the
data items
 Used for Designing and testing software in Software
Engineering
 Used for finding data items from a description in
Software Engineering
Importance of Data Dictionary:

 It provides developers with standard terminology for

all data.
 It provides developers to use different terms to refer
to the same data.
 It provides definitions for different data
 Query handling is facilitated if a data dictionary is used
in RDMS.
Advantages of Data Dictionary:
 Consistency and Standardization: A data dictionary
helps to ensure that all data elements and attributes
are consistently defined and named across the
organization, promoting standardization and
consistency in data management practices.
 Data Quality: A data dictionary can help improve
data quality by providing a single source of truth for
data definitions, allowing users to easily verify the
accuracy and completeness of data.
 Data Integration: A data dictionary can facilitate
data integration efforts by providing a common
language and framework for understanding data
elements and their relationships across different
systems.
 Improved Collaboration: A data dictionary can help
promote collaboration between business and technical
teams by providing a shared understanding of data
definitions and structures, reducing misunderstandings
and communication gaps.
 Improved Efficiency: A data dictionary can help
improve efficiency by reducing the time and effort
required to define, document, and manage data
elements and attributes.
Disadvantages of Data Dictionary:
 Implementation and Maintenance
Costs: Implementing and maintaining a data
dictionary can be costly, requiring significant resources
in terms of time, money, and personnel.
 Complexity: A data dictionary can be complex and
difficult to manage, particularly in large organizations
with multiple systems and data sources.
 Resistance to Change: Some stakeholders may be
resistant to using a data dictionary, either due to a
lack of understanding or because they prefer to use
their own terminology or definitions.
 Data Security: A data dictionary can contain sensitive
information, and therefore, proper security measures
must be in place to ensure that unauthorized users do
not access or modify the data.
 Data Governance: A data dictionary requires strong
data governance practices to ensure that data
elements and attributes are managed effectively and
consistently across the organization.
Requirement analysis

Requirement analysis is significant and essential activity

after elicitation. We analyze, refine, and scrutinize the
gathered requirements to make consistent and
unambiguous requirements. This activity reviews all
requirements and may provide a graphical view of the
entire system. After the completion of the analysis, it is
expected that the understandability of the project may
improve significantly. Here, we may also use the
interaction with the customer to clarify points of
confusion and to understand which requirements are
more important than others.

The various steps of requirement analysis are

shown in fig:
(i) Draw the context diagram: The context diagram is
a simple model that defines the boundaries and
interfaces of the proposed systems with the external
world. It identifies the entities outside the proposed
system that interact with the system. The context
diagram of student result management system is given
below:

(ii) Development of a Prototype (optional): One

effective way to find out what the customer wants is to
construct a prototype, something that looks and
preferably acts as part of the system they say they want.
We can use their feedback to modify the prototype until
the customer is satisfied continuously. Hence, the
prototype helps the client to visualize the proposed
system and increase the understanding of the
requirements. When developers and users are not sure
about some of the elements, a prototype may help both
the parties to take a final decision.

Some projects are developed for the general market. In

such cases, the prototype should be shown to some
representative sample of the population of potential
purchasers. Even though a person who tries out a
prototype may not buy the final system, but their
feedback may allow us to make the product more
attractive to others.

The prototype should be built quickly and at a relatively

low cost. Hence it will always have limitations and would
not be acceptable in the final system. This is an optional
activity.

(iii) Model the requirements: This process usually

consists of various graphical representations of the
functions, data entities, external entities, and the
relationships between them. The graphical view may help
to find incorrect, inconsistent, missing, and superfluous
requirements. Such models include the Data Flow
diagram, Entity-Relationship diagram, Data Dictionaries,
State-transition diagrams, etc.
(iv) Finalise the requirements: After modeling the
requirements, we will have a better understanding of the
system behavior. The inconsistencies and ambiguities
have been identified and corrected. The flow of data
amongst various modules has been analyzed. Elicitation
and analyze activities have provided better insight into
the system. Now we finalize the analyzed requirements,
and the next step is to document these requirements in a
prescribed format.

Software prototyping

Software prototypes refers to working models of

software with limited functionality. The prototypes do not
always hold the exact logic used in actual software
application. Prototyping allows the software publisher to
evaluate the product, ensure it’s doing what it’s intended
to, and determine if improvements are needed. It also
provides an opportunity for the manufacturer to get an
actual feel of what the final product will look like before
additional resources, like time and money, are put into
finalizing the product.
The software prototyping process
Software Prototyping Process
The process for software prototyping includes:
1. Basic requirement identification: This step involves
understanding the basic product requirements in
terms of the user interface. The software publisher
decides the functionality, who the user will likely be,
and what the user will want from the product.
2. Developing the initial prototype: In this step, the
developer will consider the requirements provided by
the publisher and begin to assemble a model of what
the finished software product would look like.
3. Review of the prototype: Once the prototype is
developed, it is then offered to the customer and
other stakeholders in the project for review. The
feedback is collected in an organized way and used
for further development of the product.
4. Revising the prototype: The concluding step in this
process is to make revisions to the prototype based
on the feedback of the customer, publisher, and
beta-testers.
Types of software prototyping
There are two main types of prototypes. They are,
the throwaway model and the evolutionary model.
 The throwaway model is designed to be discarded
once the review process has been completed. It
looks at what the end product may look like and it’s
typically not well defined.
 The evolutionary model for prototyping is based on
building actual functional prototypes with minimal
functionality in the beginning. By using evolutionary
prototyping, the well-understood requirements are
included in the prototype and the requirements are
added when they are understood.
The advantages and disadvantages of software
prototyping
The advantages of software prototyping are:
 It reduces time and cost, as the defects are detected
much earlier.
 Quicker feedback from users.
 Increased user involvement in the software product
production.
 Missing functionalities are identified easily.
The disadvantages of software prototyping are:
 Users may get confused between the prototypes and
actual systems.
 Too much effort may be invested in building
prototypes.
 A risk of insufficient requirement analysis due to
over-dependency on the prototype.

Specification Principles
 Specification, regardless of the mode through which
we accomplish it, may be viewed as a representation
process. Requirements are represented in a manner
that ultimately leads to successful software
implementation. A number of specification principles,
adapted from the work of Balzer and Goodman, can
be proposed:
1. Separate functionality from implementation.

2. Develop a model of the desired behavior of a system

that encompasses data and the functional responses of a
system to various stimuli from the environment.
3. Establish the context in which software operates by
specifying the manner in which other system components
interact with software.
4. Define the environment in which the system operates
and indicate how ―a highly intertwined collection of
agents react to stimuli in the environment (changes to
objects) produced by those agents".
5. Create a cognitive model rather than a design or
implementation model. The cognitive model describes a
system as perceived by its user community.
6. Recognize that ―the specifications must be tolerant of
incompleteness and augmentable.‖ A specification is
always a model—an abstraction—of some real (or
envisioned) situation that is normally quite complex.
Hence, it will be incomplete and will exist at many levels
of detail.
7. Establish the content and structure of a specification in
a way that will enable it to be amenable to change.
This list of basic specification principles provides a basis
for representing software requirements. However,
principles must be translated into realization.
Representation
 We have already seen that software requirements
may be specified in a variety of ways. However, if
requirements are committed to paper or an
electronic presentation medium (and they almost
always should be!) a simple set of guidelines is
well worth following:
 Representation format and content should be
relevant to the problem. A general outline for
the contents of a Software Requirements
Specification can be developed. However, the
representation forms contained within the
specification are likely to vary with the application
area. For example, a specification for a
manufacturing automation system might use
different symbology, diagrams and language than
the specification for a programming language
compiler.
 Information contained within the specification
should be nested. Representations should reveal
layers of information so that a reader can move to
the level of detail required. Paragraph and diagram
numbering schemes should indicate the level of
detail that is being presented. It is sometimes
worthwhile to present the same information at
different levels of abstraction to aid in
understanding.
 Diagrams and other notational forms should be
restricted in number and consistent in
use. Confusing or inconsistent notation, whether
graphical or symbolic, degrades understanding and
fosters errors.
 Representations should be revisable. The
content of a specification will change. Ideally, CASE
tools should be available to update all
representations that are affected by each change.
 Investigators have conducted numerous studies on
human factors associated with specification. There
appears to be little doubt that symbology and
arrangement affect understanding. However,
software engineers appear to have individual
preferences for specific symbolic and diagrammatic
forms. Familiarity often lies at the root of a person's
preference, but other more tangible factors such as
spatial arrangement, easily recognizable patterns,
and degree of formality often dictate an individual's
choice.
Software requirements Specification
 SRS is short used for Software Requirement
Specification.
 SRS is also called a Product Requirement
Specification and System Requirement Specification.
 It is maintained by Business Analyst or System
Analyst.
 Focus on the functional and non-functional requirements.
 Bridges gap between user and developer.
 Used for planning phase.