Unit 2

Chapter 2
REQUIREMENT ENGINEERING
Dr.Monica Sankat
 SYLLABUS
• Requirements Engineering
• Establishing the Groundwork
• Eliciting Requirements
• Building the Requirements Model
• Requirements Analysis
• Metrics in the Process ... Project Domains
• Software Measurements
• Metrics for Software Quality
• Software Project Estimation
• Decomposition Techniques
• Empirical Estimation Models
• The Make/Buy Decision.
 Requirements Engineering
• Requirements engineering (RE) refers to the process of defining,
documenting, and maintaining requirements in the engineering
design process.
• Requirement engineering provides the appropriate mechanism to
understand what the customer desires.
• Analyzing the need, and assessing feasibility, negotiating a
reasonable solution, specifying the solution clearly, validating the
specifications and managing the requirements as they are
transformed into a working system.
• Thus, requirement engineering is the disciplined application of
proven principles, methods, tools, and notation to describe a
proposed system's intended behavior and its associated
constraints.
• Requirements Engineering Process consists of the following main
activities, known as Requirement Engineering Process  
 Requirements Engineering
• It is a four-step process, which includes - 
– Feasibility Study
– Requirement Elicitation and Analysis
– Software Requirement Specification
– Software Requirement Validation
– Software Requirement Management 
• 1. Feasibility Study:
– To create the reasons for developing the software that is
acceptable to users, flexible to change and conformable to
established standards. 
– Types of Feasibility 
• Technical Feasibility - Evaluates the current technologies,
time and budget.
Requirements Engineering
 Requirements Engineering
• Operational Feasibility - Assesses the range and series of
levels to solve business problems and customer
requirements.
• Economic Feasibility - Generate financial profits for an
organization.

• Requirement Elicitation and Analysis:

– Known as the gathering of requirements.
– Requirements are identified with the help of customers and
existing systems processes, if available.
– The requirements are analyzed to identify inconsistencies,
defects, omission, etc.
– We describe requirements in terms of relationships and also
resolve conflicts if any. 
Requirements Engineering
 Requirements Engineering
• Problems of Elicitation and Analysis
– Getting all, and only, the right people involved.
– Stakeholders often don't know what they want
– Stakeholders express requirements in their terms.
– Stakeholders may have conflicting requirements.
– Requirement change during the analysis process.
– Organizational and political factors may influence system
requirements.
• Software Requirement Specification: 
– Kind of document which is created by a software analyst after
the requirements collected from the various sources - the
requirement received by the customer written in ordinary
language.
– Analyst to write the requirement in technical language so that
they can be understood and beneficial by the development team.
 Requirements Engineering
– The models used at this stage includes
• Data Flow Diagrams: Used widely for modeling the
requirements. DFD shows the flow of data through a
system. The DFD is also known as a data flow graph or
bubble chart.
• Data Dictionaries: Simply repositories to store information
about all data items defined in DFDs. Define customer data
items, to ensure that the customer and developers use the
same definition and terminologies.
• Entity-Relationship Diagrams: Logical representation of the
data for the organization and uses three main constructs i.e.
data entities, relationships, and their associated attributes.
• Software Requirement Validation: 
– After requirement specifications developed, the requirements
discussed in this document are validated.
 Requirements Engineering
– The user might demand illegal, impossible solution or experts
may misinterpret the needs.
– Requirements can be the check against the following
conditions 
• If they can practically implement
• If they are correct and as per the functionality and specially
of software
• If there are any ambiguities
• If they are full
• If they can describe 
• Requirements Validation Techniques
– Requirements reviews/inspections
– Prototyping
– Test-case generation
 Requirements Engineering
– Automated consistency analysis
• Software Requirement Management: 
– Requirement management is the process of managing changing
requirements during the requirements engineering process
and system development.
– New requirements emerge during the process as business
needs a change, and a better understanding of the system is
developed.
– The priority of requirements from different viewpoints changes
during development process.
• Prerequisite of Software requirements
– Collection of software requirements is the basis of the entire
software development project.
– Hence they should be clear, correct, and well-defined. A
complete Software Requirement Specifications should be:
 Requirements Engineering
Clear , Correct , Consistent , Coherent,
Comprehensible , Modifiable , Verifiable , Prioritized,
Unambiguous , Traceable , Credible source,
• Software Requirements: Largely software requirements must be
categorized into two categories:
– Functional Requirements 
– Non-functional Requirements: Non-functional requirements
are divided into two main categories:
• Execution qualities like security and usability, which are
observable at run time.
• Evolution qualities like testability, maintainability,
extensibility, and scalability that embodied in the static
structure of the software system.
• Requirements Engineering Tasks: The software requirements
engineering process includes the following steps of activities: 
 Requirements Engineering
– Inception
– Elicitation
– Elaboration
– Negotiation
– Specification
– Validation
• Requirements Management
– Inception: 1st phase of the requirements analysis process.
Gives an outline of how to get started on a project. A basic
understanding of the problem is gained and the nature of the
solution is addressed. Effective communication is very
important in this stage, as this phase is the foundation as to
what has to be done further.  
• Understanding of the problem.
• The people who want a solution.
 Requirements Engineering
• Nature of the solution.
• Communication and collaboration between the customer
and developer.
– Elicitation: 2nd phase of the requirements analysis process.
This phase focuses on gathering the requirements from the
stakeholders. Understanding the kind of requirements needed
from the customer is very crucial for a developer. The right
people must be involved in this phase. The following problems
can occur in the elicitation phase:
• Problem of Scope: Unnecessary detail, ill-defined, or not
possible to implement.
• Problem of Understanding: Not having a clear-cut
understanding between the developer and customer or
might misunderstand one requirement for another.
• Problem of Volatility: Requirements changing over time can
cause difficulty in leading a project.
 Requirements Engineering
– Elaboration: 3rd phase of the requirements analysis process.
This phase is the result of the inception and elicitation phase. In
the elaboration process, it takes the requirements that have
been stated and gathered in the first two phases and refines
them.  
– Negotiation: 4th phase of the requirements analysis process.
This phase emphasizes discussion and exchanging conversation
on what is needed and what is to be eliminated. Customers are
asked to prioritize the requirements and make guesstimates on
the conflicts that may arise along with it. The following are
discussed in the negotiation phase:
• Availability of Resources.
• Delivery Time.
• Scope of requirements.
• Project Cost.
• Estimations on development. 
 Requirements Engineering
– Specification: 5th phase of the requirements analysis process.
This phase specifies the following:
– Written document.
– A set of models.
– A collection of use cases.
– A prototype
– In the specification phase, the requirements engineer gathers
all the requirements and develops a working model. This final
working product will be the basis of any functions, features or
constraints to be observed.  
– Validation: 6th phase of the requirements analysis process. This
phase focuses on checking for errors and debugging. Scans the
specification document and checks for the following:
• All the requirements have been stated and met correctly
• Errors have been debugged and corrected.
 Requirements Engineering
– This requirements validation mechanism is known as the formal
technical review. The review team that works together and
validates the requirements include software engineers,
customers, users, and other stakeholders. Some of the
validation techniques are the following- 
• Requirements reviews/inspections.
• Prototyping.
• Test-case generation.
• Automated consistency analysis. 
– Requirements Management: This is the last phase of the
requirements analysis process. Requirements management is a
set of activities where the entire team takes part in identifying,
controlling, tracking, and establishing the requirements for the
successful and smooth implementation of the project.
 Requirements Engineering
– In this phase, the team is responsible for managing any changes
that may occur during the project.
– New requirements emerge, and it is in this phase, responsibility
should be taken to manage and prioritize as to where its
position is in the project and how this new change will affect
the overall system, and how to address and deal with the
change.
– Based on this phase, the working model will be analyzed
carefully and ready to be delivered to the customer.
 Establishing the Groundwork
• Ideally everyone from stakeholders to developers would work on
the same team and be of the same mind, but that isn’t always the
case. In fact, that is rarely the case.
– Defining the Stakeholders - The “Anyone who directly or
indirectly benefits from the system being built” is a little too
vague in my opinion. Instead, at inception, determine who you
want to get input from.
– Recognize Different Viewpoints - Don’t pick only people from
the same department. Getting a variety of views is important to
determine who/what is the best options and input to contribute
to the project’s success.
– Work Toward Collaboration - When working with different
groups, that each have their own ideas and agendas, it is
important to work toward a common goal and get people to
work together on what the actual end goals are going to be.
 Establishing the Groundwork
• Who is behind this request?
• Who will use the solution?
• What is the (economic) benefit of this solution?
• Is there another source for the solution?
– The second set of questions focuses on the problem itself. 
• What is considered “good” output?
• What problem(s) will this solution solve?
• What business environment will this solution be used?
• Awareness of any special performance issues or constraints?
• Non Functional Requirements –
– The previous requirement questions should be around getting
the correct answer/response.
– But there are other requirements that are needed as well? These
are not revolving around getting the right result, but are just as
important to making sure the solution is properly used.
 Eliciting Requirements
• Requirements elicitation is perhaps the most difficult, most error-
prone and most communication intensive software development.
• It can be successful only through an effective customer-developer
partnership. It is needed to know what the users really need. 
• Requirements elicitation Activities:
– Knowledge of the overall area where the systems is applied.
– The details of the precise customer problem where the system
are going to be applied must be understood.
– Interaction of system with external requirements.
– Detailed investigation of user needs.
– Define the constraints for system development. 
• Requirements elicitation Methods:
– Interviews
– Brainstorming Sessions
 Eliciting Requirements
– Facilitated Application Specification Technique (FAST)
– Quality Function Deployment (QFD)
– Use Case Approach
• The success of an elicitation technique used depends on the
maturity of the analyst, developers, users, and the customer
involved.  
1. Interviews:  Objective of conducting an interview is to understand
the customer’s expectations from the software.  
• In open-ended interviews there is no pre-set agenda. Context free
questions may be asked to understand the problem.
2. Brainstorming Sessions:  
• It is a group technique and intended to generate lots of new ideas
hence providing a platform to share views
• A highly trained facilitator is required to handle group bias and
group conflicts.
 Eliciting Requirements
• Every idea is documented so that everyone can see it.
• Finally, a document is prepared which consists of the list of
requirements and their priority if possible.
3. Facilitated Application Specification Technique: It’s objective is to
bridge the expectation gap –what the developers think and what
customers think they are going to get.
• A team oriented approach is developed for requirements
gathering. 
• Each participant prepares his/her list, different lists are then
combined, redundant entries are eliminated, team is divided into
smaller sub-teams to develop mini-specifications and finally a draft
of specifications is written down.
• 4. Quality Function Deployment: In this technique customer
satisfaction is of prime concern, hence it emphasizes on the
requirements which are valuable to the customer. 
 Eliciting Requirements
• 3 types of requirements are identified – 
– Normal requirements – In this the objective and goals of the
proposed software are discussed with the customer.
– Expected requirements – These requirements are so obvious
that the customer need not explicitly state them.
– Exciting requirements – It includes features that are beyond
customer’s expectations and prove to be very satisfying when
present.
• The major steps involved in this procedure are –   
– Identify all the stakeholders, eg. Users, developers, customers etc
– List out all requirements from customer.
– A value indicating degree of importance is assigned to each
requirement.
– In the end the final list of requirements is categorized as –
 Eliciting Requirements
• It is possible to achieve
• It should be deferred and the reason for it
• It is impossible to achieve and should be dropped off
• 5. Use Case Approach: This technique combines text and pictures
to provide a better understanding of the requirements. The use
cases describe the ‘what’, of a system and not ‘how’
• The components of the use case design includes three major things
– Actor, Use cases, use case diagram. 
– Actor – It is the external agent that lies outside the system but
interacts with it in some way. 
• Primary actors – It requires assistance from the system to
achieve a goal.
• Secondary actor – It is an actor from which the system needs
assistance.
 Eliciting Requirements
– Use cases – They describe the sequence of interactions between
actors and the system.
– Use case diagram – A use case diagram graphically represents
what happens when an actor interacts with a system. It captures
the functional aspect of the system. 
• A stick figure is used to represent an actor.
• An oval is used to represent a use case.
• A line is used to represent a relationship between an actor
and a use case.
 Building the Requirements Model
• The analysis model’s goal is to provide a description of the
informational, functional, and behavioural domains required for a
computer-based system.
• The model evolves dynamically as you learn more about the
system to be developed and other stakeholders gain a better
understanding of what they actually require.  
• Elements of the Requirements Model –
– There are numerous approaches to analysing the requirements
for a computer-based system.
– Different modes of representation require you to analyse
requirements from many perspectives—a method that has a
higher likelihood of uncovering omissions, inconsistencies, and
ambiguity.
– The specific elements of the requirements model are dedicated
to the analysis modeling method that is to be used.
Building the Requirements Model
 Building the Requirements Model
• Scenario-based elements –
– A scenario-based approach is used to describe the system from
the perspective of the user.
– For example, basic use cases and their related use-case
diagrams, evolve into more complicated template-based use
cases.
– Scenario-based requirements model elements are frequently
the first parts of the model to be produced.
• Class-based element –
– Each usage scenario entails a collection of objects that are
modified as an actor interacts with the system.
– These objects are classified as classes— a collection of things
with similar characteristics and behaviour. A collection of things
that have similar attributes and common behaviors i.e., objects
are categorized into classes. 
Building the Requirements Model

Class-based element Flow-oriented elements

 Building the Requirements Model
– In addition to class diagrams, other analysis modeling elements
depict manner in which classes collaborate with one another
and relationships and interactions between classes.
• Behavioural elements –
– The behaviour of a computer-based system can have a
significant impact on the design and implementation
techniques used.
– The requirements model must include modelling elements that
represent behaviour.
– The state diagram is one approach of expressing a system’s
behaviour by illustrating its states and the events that cause the
system to change state.
– The state diagram indicates activities taken as a result of a
specific event. Effect of behavior of computer-based system can
be seen on design .
 Building the Requirements Model
• Flow-oriented elements –
– As data moves through a computer-based system, it is
transformed. The system accepts input in a variety of formats,
transforms it using functions, and produces output in a variety
of forms.  
– As it flows through a computer-based system information is
transformed. System accepts input, applies functions to
transform it, and produces output in a various forms.
– Input may be a control signal transmitted by a transducer, a
series of numbers typed by human operator, a packet of
information transmitted on a network link, or a voluminous data
file retrieved from secondary storage.
 Building the Requirements Model
• Analysis Patterns –
• Anyone who has done requirements engineering on a number
of software projects will note that some issues repeat across all
projects within a certain application area.
• These patterns of analysis provide solutions (e.g., a class, a
function, or a behaviour) inside the application domain that can
be reused when modelling several applications.
• By referencing the pattern name, analysis patterns are
integrated into the analysis model.
• They are also stored in a repository so that requirements
engineers can find and apply them using search facilities.
Information about an analysis pattern (and other sorts of
patterns) is contained in a standard template.
 Requirements Analysis
• Requirements analysis, also called requirements engineering, is the
process of determining user expectations for a new or modified
product.
• These features, called requirements, must be quantifiable, relevant
and detailed.
• Requirements analysis involves frequent communication with
system users to determine specific feature expectations, resolution
of conflict or ambiguity in requirements as demanded by the
various users.
• Broadly software requirements should be categorized in two
categories: 
– Functional Requirements - Requirements, which are related to
functional aspect of software fall into this category.
– Non-Functional Requirements - Requirements, which are not
related to functional aspect of software, fall into this category.
 Requirements Analysis
• Requirements are categorized logically as 
– Must Have : Software cannot be said operational without them.
– Should have : Enhancing the functionality of software.
– Could have : Software can still properly function with these
requirements.
– Wish list : These requirements do not map to any objectives of
software.
• In software and system engineering, requirement analysis includes
task that governs the condition or requirement to meet for a new
product.
– It includes taking account of conflicting requirements of other
stakeholders. It includes various things; 
– Regular communication with the software users to know about
their expectations.
 Requirements Analysis
– Resolution of complaints made by the user or group of users.
– Avoid feature creep.
– Keep up-to-date all the documentations from starting to present
of project development.

• Necessity Of Requirement Analysis –

– According to statistics major reason of failure of software is that
it does not meet with the requirement of the user.
– It is possible that over years the demands of the client increases
and there can come requirement of updating the software.
– Requirement analysis involves the task that determines the
needs of the software, which mainly includes complaints and
needs of various clients/stakeholders. It is a major key in
the life-cycle of software and is the starting step of the project.
 Requirements Analysis
• Software Requirement Analysis Process –
– On the basis of nature of software project, software analysis is
done by an independent analysis or a team of analysis to know
about the present requirements of the users.
– Requirements include functional and non functional
requirements and require both business and technical experts.
– The steps for effective capturing on present requirements of
users are: 
• Requirement Knowledge
• Identification of Stakeholders
• Collection of Requirements
• Analysis of Collected Requirements
• System requirement Specification (SRS)
Requirements Analysis
 Requirements Analysis
• Management Of Software Requirements:
– The last step of this analysis process is correcting and validating
all elements of requirement specifications document.
– Errors can be corrected at this stage. Minor changes can also be
done according to the requirement of the software user.
– 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.
– Development of a Prototype (optional): One effective way to
find out what the customer wants is to construct a prototype.
We can use their feedback to modify the prototype until the
customer is satisfied continuously.
– Model the requirements: This process usually consists of
various graphical representations of the functions, data
entities, external entities, and the relationships between them.
 Requirements Analysis
– 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.
 Metrics in the Process ... Product
• A software metric is a measure of software characteristics which
are measurable or countable.
• Software metrics are valuable for many reasons, including
measuring software performance, planning work items,
measuring productivity, and many other uses.
• Software metrics are similar to the four functions of management:
Planning, Organization, Control, or Improvement. 
• Classification of Software Metrics
1. Product Metrics: 
– Rational way to improve any process is to measure specific
attributes of the process, develop a set of meaningful metrics
based on these attributes, and then use the metrics to provide
indicators that will lead to a strategy for improvement.
– Process is only one of a number of factors effecting on
improving software quality and organizational performance.
 Metrics in the Process ... Product
The skill of people has been
shown to be the single most
influential factor in quality and
performance.
The technology that populates
the process also has an impact.
In addition, the process triangle
exists within a circle of
environmental conditions that
include:
The development environment
(e.g., CASE tools).
Business conditions (e.g.,
deadlines, business rules).
Customer characteristics (e.g.,
ease of communication) 
 Metrics in the Process ...
– These are the measures of various characteristics of the
software product. The two important software characteristics
are:
• Size and complexity of software.
• Quality and reliability of software.
Process Metrics: 
– Software process metrics are used for strategic purposes.
– Project metrics and the indicators derived from them are used
by a project manager and a software team to adapt project
work flow and technical activities.
– Metrics collected from past projects are used as a basis from
which effort and time estimates are made for current software
work. 
– As a project proceeds, measures of effort and calendar time
expended are compared to original estimates
Metrics in the Process ... Product
 Metrics in the Process …
– As quality improves, defects are minimized, and as the defect
count goes down, the amount of rework required during the
project is also reduced.  
• Inputs
• Outputs
• Results
• These are the measures of various characteristics of the software
development process used to measure the characteristics of
methods, techniques, and tools that are used for developing
software.
• Types of Metrics
– Internal metrics: Used for measuring properties that are
viewed to be of greater importance to a software developer.
For example, Lines of Code (LOC) measure.
 Metrics in the Process …
– External metrics: Used for measuring properties that are
viewed to be of greater importance to the user, e.g.,
portability, reliability, functionality, usability, etc.
– Hybrid metrics: Hybrid metrics are the metrics that combine
product, process, and resource metrics. For example, cost per
FP where FP stands for Function Point Metric. 
– Project metrics: Project metrics are the metrics used by the
project manager to check the project's progress.

• Size Oriented Metrics (LOC Metrics) –

– It is one of the earliest and simpler metrics for calculating the
size of the computer program.
– These metrics are derived by normalizing the quality and
productivity measures by considering the size of the product as
a metric. Following are the points regarding LOC measures:
Metrics in the Process …
• LOC is considered to be the normalization value.
• Productivity is defined as KLOC / EFFORT, where effort is
measured in person-months.
• Size-oriented metrics depend on the programming language
used.
• LOC measure requires a level of detail which may not be
practically achievable.
• The more expressive is the programming language, the
lower is the productivity.
• LOC method of measurement does not apply to projects
that deal with visual (GUI-based) programming.
• It requires that all organizations must use the same method
for counting LOC.
• These metrics are not universally accepted. 
 Metrics in the Process …
• Based on the LOC/KLOC count of software, many other metrics
can be computed:
– $/ KLOC.
– Errors/KLOC.
– Defects/KLOC.
– Pages of documentation/KLOC.
– Errors/PM.
– Productivity = KLOC/PM (effort is measured in person-months).
– $/ Page of documentation.
• Software Metrics –
– According to Halstead's "A computer program is an
implementation of an algorithm considered to be a collection
of tokens which can be classified as either operators or
operand."
 Metrics in the Process …
– Token Count - In these metrics, a computer program is
considered to be a collection of tokens, which may be classified
as either operators or operands. These symbols are called as a
token. The basic measures are
– n1 = count of unique operators.
n2 = count of unique operands.
N1 = count of total occurrences of operators.
N2 = count of total occurrence of operands.
– In terms of the total tokens used, the size of the program can
be expressed as
– N = N1 + N2.  
• Halstead metrics are: 
– Program Volume (V) - V=N*log2n
– Program Level (L) - L=V*/V
– Program Difficulty - D= (n1/2) * (N2/n2)
 Metrics in the Process …
– Programming Effort (E) - E=V/L=D*V
– Estimated Program Length - N=N1+N2
– And estimated program length is denoted by N^ where N^ =
n1log2n1 + n2log2n2
– Potential Minimum Volume - V* = (2 + n2*) * log2 (2 + n2*)
Here, n2* is the count of unique input and output parameters
– Size of Vocabulary (n) -       n=n1+n2 Where
n=vocabulary of a program
n1=number of unique operators
n2=number of unique operands
– Language Level -
L' = V / D / D
lambda = L * V* = L2 * V
 Metrics in the Process ...
• Functional Point (FP) Analysis –
– FPA is used to make estimate of the software project, including
its testing in terms of functionality or function size of the
software product.
– Functional point analysis may be used for the test estimation of
the product. The functional size of the product is measured in
terms of the function point, which is a standard of
measurement to measure the software application.
– Objectives of FPA - The basic and primary purpose of the
functional point analysis is to measure and provide the software
application functional size to the client, customer, and the
stakeholder on their request.  
– Following are the points regarding FPs - FPs of an application is
found out by counting the number and types of functions used
in the applications.
 Metrics in the Process ...
Measurements Parameters Examples

1.Number of External Inputs(EI) Input screen and tables

2. Number of External Output (EO) Output screens and reports

3. Number of external inquiries Prompts and interrupts.

(EQ)

4. Number of internal files (ILF) Databases and directories

5. Number of external interfaces Shared databases and shared

(EIF) routines.

• All these parameters are then individually assessed for

complexity.
• FP is programming language independent.
• FP method is used for data processing systems, business
systems like information systems.
 Metrics in the Process ...
– FP characterizes the
complexity of the
software system
and hence can be
used to depict the
project time and
the manpower
requirement.

• The effort required to develop the project depends on what the

software does.
• The five parameters mentioned above are also known as
information domain characteristics.
 Metrics in the Process ...
• Extended Function Point (EFP) Metrics –
– FP metric has been further extended to compute: 
• Feature points.
• 3D function points.

• Feature Points
– Superset of function point measure that can be applied to
systems and engineering software applications.
– Used in those applications in which the algorithmic complexity
is high like real-time systems where time constraints are there,
embedded systems, etc.
– Computed by counting the information domain values and are
weighed by only single weight.
– Includes another measurement parameter-ALGORITHM.
 Metrics in the Process ...
• Data Structure Metrics –
– Some data is input to a system, program or module; some data
may be used internally, and some data is the output from a
system, program, or module.
– Important set of metrics which capture in the amount of data
input, processed in an output form software. A count of this
data structure is called Data Structured Metrics.
– There are some Data Structure metrics to compute the effort
and time required to complete the project. There metrics are: 
– 1. The Amount of Data: To measure the amount of Data, there
are further many different metrics, and these are:
• Number of variable (VARS)
• Number of Operands (η2) η2 = VARS + Constants + Labels
• Total number of occurrence of the variable (N2)
 Metrics in the Process ...
– 2. The Usage of data within a Module

– 3. Program weakness (WM) = LV* γ

– A program is normally a combination of various modules;

hence, program weakness can be a useful measure and is
defined as:
• WMi: Weakness of the ith module
• WP: Weakness of the program
• m: No of modules in the program
– 4.There Sharing of Data among Module
 Metrics in the Process ...
• Information Flow Metrics –
– The basis of information flow metrics is found upon the
following concept the simplest system consists of the
component, and it is the work that these components do and
how they are fitted together that identify the complexity of the
system.
– The following are the working definitions that are used in
Information flow: 
• Component: Any element identified by decomposing a
(software) system into it's constituent's parts.
• Cohesion: The degree to which a component performs a
single function.
• Coupling: The term used to describe the degree of linkage
between one component to others in the same system. 
 Metrics in the Process ...
– Information Flow metrics deal with this type of complexity by
observing the flow of information among system components
or modules. This metrics is given by Henry and Kafura. So it is
also known as Henry and Kafura's Metric.
– This metrics is based on the measurement of the information
flow among system modules. It is sensitive to the complexity
due to interconnection among system component.
– A process contributes complexity due to the following two
factors. 
• The complexity of the procedure code itself.
• The complexity due to the procedure's connections to its
environment.
– The effect of the first factor has been included through LOC
(Line Of Code) measure. For the quantification of the second
factor, Defined two terms, namely FAN-IN and FAN-OUT.
 Metrics in the Process ...
– FAN-IN
– FAN –OUT
– Procedure Complexity = Length * (FAN-IN * FANOUT)**2
• Advantage of Software Metrics
– Comparative study of various design methodology of software
systems.
– For analysis, comparison, and critical study of different
programming language concerning their characteristics.
– In comparing and evaluating the capabilities and productivity of
people involved in software development.
– In the preparation of software quality specifications.
– In the verification of compliance of software systems
requirements and specifications.
– In making inference about the effort to be put in the design and
development of the software systems.
 Metrics in the Process ...
• Disadvantage of Software Metrics
– The application of software metrics is not always easy, and in
some cases, it is difficult and costly.
– The verification and justification of software metrics are based
on historical/empirical data whose validity is difficult to verify.
– These are useful for managing software products but not for
evaluating the performance of the technical staff.
– The definition and derivation of Software metrics are usually
based on assuming which are not standardized and may
depend upon tools available and working environment.
– Most of the predictive models rely on estimates of certain
variables which are often not known precisely.
 Software Measurements
• A measurement is a manifestation of the size, quantity, amount, or
dimension of a particular attribute of a product or process.
• Software measurement is a titrate impute of a characteristic of a
software product or the software process.
• Software Measurement Principles: The software measurement
process can be characterized by five activities-
– Formulation
– Collection
– Analysis
– Interpretation
– Feedback
• Need for Software Measurement: Software is measured to:  
– Create the quality of the current product or process.
– Anticipate future qualities of the product or process.
 Software Measurements
– Enhance the quality of a product or process.
– Regulate the state of the project in relation to budget and
schedule.
• Classification of Software Measurement: There are 2 types of
software measurement:  
– Direct Measurement
– Indirect Measurement 
• The framework for software measurement is based on three
principles −
– Classifying the entities to be examined
– Determining relevant measurement goals
– Identifying the level of maturity that the organization has
reached
• Classifying the Entities to be Examined - In software engineering,
mainly three classes of entities exist. They are −
 Software Measurements
– Processes
– Products
– Resources
• All of these entities have internal as well as external entities.
– Internal attributes are those that can be measured purely in
terms of the process, product, or resources itself.
– External attributes are those that can be measured only with
respect to its relation with the environment.
• The different attributes that can be measured for each of the
entities are as follows − 
• Processes - Processes are collections of software-related activities.  
– The duration of the process or one of its activities
– The effort associated with the process or one of its activities
– The number of incidents of a specified type arising during the
process or one of its activities
 Software Measurements
– The different external attributes of a process are cost,
controllability, effectiveness, quality and stability.
• Products –
– Products are not only the items that the management is
committed to deliver but also any artifact or document
produced during the software life cycle.
– The different internal product attributes are size, effort, cost,
specification, length, functionality, modularity, reuse,
redundancy, and syntactic correctness.  
• Resources –
– These are entities required by a process activity. It can be any
input for the software production.
– It includes personnel, materials, tools and methods. The
different internal attributes for the resources are age, price, size,
speed, memory size, temperature, etc.
 Software Measurements
• Determining Relevant Measurement Goals 
– A particular measurement will be useful only if it helps to
understand the process or one of its resultant products.
– A clear understanding of goals can be used to generate
suggested metrics for a given project in the context of a process
maturity framework.
• The Goal–Question–Metric (GQM) paradigm - The GQM approach
provides a framework involving the following three steps –
– Listing the major goals of the development or maintenance
project
– Deriving the questions from each goal that must be answered to
determine if the goals are being met
– Decide what must be measured in order to be able to answer
the questions adequately 
 Software Measurements
• To use GQM paradigm, first we express the overall goals of the
organization. Then, we generate the questions such that the
answers are known so that we can determine whether the goals are
being met.
• To help generate the goals, questions, and metrics, Basili &
Rombach provided a series of templates. 
– Purpose −
– Perspective
– Environment
• Measurement and Process Improvement - Normally measurement
is useful for –
– Understanding the process and products
– Establishing a baseline
– Accessing and predicting the outcome 
 Software Measurements
• According to the maturity level of the process given by SEI, the type
of measurement and the measurement program will be different.  
– Level 1: Ad hoc - At this level, the inputs are defined, while the
outputs are expected.
– Level 2: Repeatable - At this level, the inputs and outputs of the
process, constraints, and resources are identifiable.  
– Level 3: Defined - At this level, intermediate activities are
defined, and their inputs and outputs are known and
understood. 
– Level 4: Managed - At this level, the feedback from the early
project activities can be used to set priorities for the current
activities and later for the project activities. We can measure the
effectiveness of the process activities.  
Software Measurements

Level 2 and Level 3

Software Measurements

Level 4
 Software Measurements
– Level 5: Optimizing - At this level, the measures from activities
are used to improve the process by removing and adding
process activities and changing the process structure
dynamically in response to measurement feedback. Thus, the
process change can affect the organization and the project as
well as the process.
• Identifying the Level of Maturity - Process maturity suggests to
measure only what is visible. Thus, the combination of process
maturity with GQM will provide most useful measures.
• At level 1, the project is likely to have -defined requirements. At this
level, the measurement of requirement characteristics is difficult.
• At level 2, the requirements are well-defined and the additional
information such as the type of each requirement and the number
of changes to each type can be collected.
• At level 3, intermediate activities are defined with entry and exit
criteria for each activity.
 Metrics for Software Quality
• Software metrics can be classified into three categories − 
– Product metrics 
– Process metrics
– Project metrics 
• Software quality metrics are a subset of software metrics that focus
on the quality aspects of the product, process, and project.
• Software Quality Metrics (SQMs) are essential management tools;
they are quantities that express information about a piece of
software or the process of development.
• Certain metrics measure the quality of code by analyzing its
complexity or ability to pass tests. 
• Using software quality metrics is standard in software development
companies because metrics tell the company how the development
process is running and how it can be better.
 Metrics for Software Quality
• Software quality metrics can be further divided into three
categories − 
– Product quality metrics
– In-process quality metrics
– Maintenance quality metrics 
• Product Quality Metrics - This metrics include the following –
– Mean Time to Failure
– Defect Density
– Customer Problems
– Customer Satisfaction 
• Mean Time to Failure - It is the time between failures.  
• Defect Density - It measures the defects relative to the
software size expressed as lines of code or function point, etc.
 
 Metrics for Software Quality
• Customer Problems - It measures the problems that
customers encounter when using the product. The problems
metric is usually expressed in terms of Problems per User-
Month (PUM).
•  PUM = Total Problems that customers reported for a time
period + Total number of license months of the software
during the period
Where, Number of license-month of the software = Number
of install license of the software × Number of months in the
calculation period  
– Customer Satisfaction - Customer satisfaction is often measured
by customer survey data through the five-point scale −
• Very satisfied
• Satisfied
• Neutral
 Metrics for Software Quality
• Dissatisfied
• Very dissatisfied
• Satisfaction with the overall quality of the product and its
specific dimensions is usually obtained through various
methods of customer surveys.
– Percent of completely satisfied customers
– Percent of satisfied customers
– Percent of dis-satisfied customers
– Percent of non-satisfied customers 
• In-process Quality Metrics –
• In-process quality metrics deals with the tracking of defect arrival
during formal machine testing for some organizations. This metric
includes −
– Defect density during machine testing
 Metrics for Software Quality
– Defect arrival pattern during machine testing
– Phase-based defect removal pattern
– Defect removal effectiveness
– Defect density during machine testing –
• Defect rate during formal machine testing is correlated with
the defect rate in the field.
• This simple metric of defects per KLOC or function point is a
good indicator of quality, while the software is still being
tested. It is especially useful to monitor subsequent releases
of a product in the same development organization.
– Defect arrival pattern during machine testing –
• The overall defect density during testing will provide only the
summary of the defects. The pattern of defect arrivals gives
more information about different quality levels in the field. It
includes the following −
 Metrics for Software Quality
– The defect arrivals or defects reported during the testing
phase by time interval
– The pattern of valid defect arrivals when problem
determination is done on the reported problems.
– The pattern of defect backlog overtime. This metric is
needed because development organizations cannot
investigate and fix all the reported problems immediately.
 
– Phase-based defect removal pattern –
• This is an extension of the defect density metric during
testing. In addition to testing.
• It tracks the defects at all phases of the development cycle,
including the design reviews, code inspections, and formal
verifications before testing.
 Metrics for Software Quality
• Because a large percentage of programming defects is related
to design problems, conducting formal reviews, or functional
verifications to enhance the defect removal capability of the
process at the front-end reduces error in the software.  
– Defect removal effectiveness –
• It can be defined as follows −
• $$DRE = \frac{Defect \: removed \: during \: a \:
development\:phase } {Defects\: latent \: in \: the\:
product} \times 100\%$$
• This metric can be calculated for the entire development
process, for the front-end before code integration and for
each phase.
• It is called early defect removal when used for the front-end
and phase effectiveness for specific phases.
 Metrics for Software Quality
• Maintenance Quality Metrics –
• Following are the fixes that can be carried out to eliminate the
defects as soon as possible with excellent fix quality.
– Fix backlog and backlog management index
– Fix response time and fix responsiveness
– Percent delinquent fixes
– Fix quality
– Fix backlog and backlog management index –
• Fix backlog is related to the rate of defect arrivals and the rate
at which fixes for reported problems become available.
• It is a simple count of reported problems that remain at the
end of each month or each week.
• Backlog Management Index (BMI) is used to manage the
backlog of open and unresolved problems 
 Metrics for Software Quality
• $$BMI = \frac{Number \: of \: problems \: closed \:
during \:the \:month }{Number \: of \: problems \: arrived \:
during \:the \:month} \times 100\%$$
• If BMI is larger than 100, it means the backlog is reduced. If
BMI is less than 100, then the backlog increased. 
– Fix response time and fix responsiveness –
• The fix response time metric is usually calculated as the mean
time of all problems from open to close. Short fix response
time leads to customer satisfaction.
• The important elements of fix responsiveness are customer
expectations, the agreed-to fix time, and the ability to meet
one's commitment to the customer.
– Percent delinquent fixes –It is calculated as follows −
• $Percent \:Delinquent\: Fixes =$
 Metrics for Software Quality
• $\frac{Number \: of \: fixes \: that\: exceeded \:
the \:response \:time\:criteria\:by\:ceverity\:level}{Number \:
of \: fixes \: delivered \: in \:a \:specified \:time} \times 100\%
$ 
– Fix Quality –
• Fix quality or the number of defective fixes is another
important quality metric for the maintenance phase.
• A fix is defective if it did not fix the reported problem, or if it
fixed the original problem but injected a new defect.
• A defective fix can be recorded in two ways:
• Record it in the month it was discovered or record it in the
month the fix was delivered.
– The first is a customer measure;
– The second is a process measure.
 Software Project Estimation
• Estimation of the size of the software is an essential part of
Software Project Management. Various measures are used in
project size estimation. Some of these are: 
– Lines of Code
– Number of entities in ER diagram
– Total number of processes in detailed data flow diagram
– Function points 
• 1. Lines of Code (LOC): As the name suggests, LOC count the total
number of lines of source code in a project. The units of LOC are: 
– KLOC- Thousand lines of code
– NLOC- Non-comment lines of code
– KDSI- Thousands of delivered source instruction 
• The size is estimated by comparing it with the existing systems of
the same kind.
 Software Project Estimation
• The experts use it to predict the required size of various
components of software and then add them to get the total size.  
• Two separate source files having a similar number of lines may not
require the same effort. A file with complicated logic would take
longer to create than one with simple logic.
• Proper estimation may not be attainable based on LOC. The length
of time it takes to solve an issue is measured in LOC.
• Advantages: 
– Universally accepted and is used in many models like COCOMO.
– Estimation is closer to the developer’s perspective.
– Simple to use.
• Disadvantages:
– Different programming languages contain a different number of
lines.
 Software Project Estimation
– No proper industry standard exists for this technique.
– It is difficult to estimate the size using this technique in the
early stages of the project.
• 2. Number of entities in ER diagram: 
• ER model provides a static view of the project. It describes the
entities and their relationships.
• The number of entities in ER model can be used to measure the
estimation of the size of the project. The number of entities
depends on the size of the project.
• Advantages: 
– Size estimation can be done during the initial stages of
planning.
– The number of entities is independent of the programming
technologies used.
 Software Project Estimation
• Disadvantages: 
– No fixed standards exist.
– Just like FPA, it is less used in the cost estimation model. Hence,
it must be converted to LOC. 
• 3. Total number of processes in detailed data flow diagram: 
• Data Flow Diagram(DFD) represents the functional view of
software. The model depicts the main processes/functions
involved in software and the flow of data between them.
• Utilization of the number of functions in DFD to predict software
size. Sum of the estimated size of each process gives the final
estimated size. 
• Advantages: 
– It is independent of the programming language.
– Each major process can be decomposed into smaller processes.
This will increase the accuracy of estimation 
 Software Project Estimation
• Disadvantages: 
– Studying similar kinds of processes to estimate size takes
additional time and effort.
– All software projects are not required for the construction of
DFD.
• 4. Function Point Analysis: 
• In this method, the number and type of functions supported by the
software are utilized to find FPC(function point count). The steps in
function point analysis are: 
– Count the number of functions of each proposed type.
– Compute the Unadjusted Function Points(UFP).
– Find Total Degree of Influence(TDI).
– Compute Value Adjustment Factor(VAF).
– Find the Function Point Count(FPC).