Module-2

Requirements Engineering

Prepared by: Bhupendra Panchal

 Module-2
● Requirements Engineering
● Establishing the Groundwork
● Eliciting Requirements
● Requirements Analysis
● SRS Documentation
● Metrics in the Process and Project Domains
● Software Measurements
● Software Project Estimation
● Decomposition Techniques
● Empirical Estimation Models
● The Make/Buy Decision.
Prepared & Compiled by: Prof. Bhupendra Panchal
Requirements Engineering — Elicitation,
Analysis & Specification

(The activity of generating the requirements of a system from

users, customers, and other stakeholders)

Prepared & Compiled by: Prof. Bhupendra Panchal

 Requirements Elicitation and Analysis
● It’s a process of interacting with customers and end-users to find out about the
domain requirements, what services the system should provide, and the other
constraints.

● Domain requirements reflect the environment in which the system operates so, when
we talk about an application domain we mean environments such as train operation,
medical records, e-commerce etc.

● It may also involve different kinds of stockholders; end-users, managers, system

engineers, test engineers, maintenance engineers, etc.

● A stakeholder is anyone who has direct or indirect influence on the requirements.

Prepared & Compiled by: Prof. Bhupendra Panchal

 Requirements Elicitation and Analysis
The requirements elicitation and analysis has 4 main process

● We typically start by gathering the requirements, this could be done through a general
discussion or interviews with your stakeholders, also it may involve some graphical
notation.
● Then you organize the related requirements into sub-components and prioritize them,
and finally, you refine them by removing any ambiguous requirements that may arise
from some conflicts.

Prepared & Compiled by: Prof. Bhupendra Panchal

 Requirements Elicitation and Analysis
Here are the 4 main processes of requirements elicitation and analysis-

It shows that it’s an iterative process with

feedback from one activity to another. The
process cycle starts with requirements
discovery and ends with the requirements
document. The cycle ends when the
requirements document is complete.

Prepared & Compiled by: Prof. Bhupendra Panchal

 Requirements Elicitation and Analysis
1. Requirements Discovery
● It’s the process of interacting with, and gathering the requirements from, the
stakeholders about the required system and the existing system (if it exists).
● It can be done using some techniques, like interviews, scenarios, prototypes, etc, which
help the stockholders to understand what the system will be like.

Gathering and understanding the requirements is a difficult process

● That’s because stakeholders may not know what exactly they want the software to do,
or they may give unrealistic requirements.
● They may give different requirements, which will result in conflict between the
requirements, so we have to discover and resolve these conflicts.
● Also, there might be some factors that influence the stakeholder’s decision, like, for
example, managers at a company or professors at the university want to take full control
over the management system.
Prepared & Compiled by: Prof. Bhupendra Panchal
 Requirements Elicitation and Analysis
2. Requirements Classification & Organization
● It’s very important to organize the overall structure of the system.
● Putting related requirements together, and decomposing the system into sub-
components of related requirements.
● Then, we define the relationship between these components.
● What we do here will help us in the decision of identifying the most suitable
architectural design patterns.

Prepared & Compiled by: Prof. Bhupendra Panchal

 Requirements Elicitation and Analysis
3. Requirements Prioritization & Negotiation
● Requirements eliciting and understanding is not an easy process because conflicts may
arise due to different stakeholders involved.
● This activity is concerned with prioritizing requirements and finding and resolving
requirements conflicts through negotiations until you reach a situation where some of
the stakeholders can compromise.
● We shouldn’t reach a situation where a stakeholder is not satisfied because his
requirements are not taken into consideration.
● Prioritizing your requirements will help you later to focus on the essentials and core
features of the system, so you can meet the user expectations.
● It can be achieved by giving every piece of function a priority level. So, functions with
higher priorities need higher attention and focus.

Prepared & Compiled by: Prof. Bhupendra Panchal

 Requirements Elicitation and Analysis
4. Requirements Specification
● It’s the process of writing down the user and system requirements into a document.
● The requirements should be clear, easy to understand, complete, and consistent.
● In practice, this is difficult to achieve as stakeholders interpret the requirements in
different ways and there are often inherent conflicts and inconsistencies in the
requirements.
● As we’ve mentioned before, the process in requirements engineering is interleaved,
and it’s done iteratively. In the first iteration you specify the user requirements, then,
specify a more detailed system requirement.

Prepared & Compiled by: Prof. Bhupendra Panchal

 Requirements Elicitation and Analysis

User Requirements

● The user requirements for a system should describe the functional and non-functional
requirements so that they are understandable by users who don’t have technical
knowledge.
● You should write user requirements in natural language supplied by simple tables, forms,
and intuitive diagrams.
● The requirement document shouldn’t include details of the system design, and you
shouldn’t use any software jargon or formal notations.

Prepared & Compiled by: Prof. Bhupendra Panchal

 Functional vs Non-Functional Requirements

Functional Requirements:
● These are the requirements that the end user specifically demands as basic facilities
that the system should offer.
● All these functionalities need to be necessarily incorporated into the system as a part
of the contract.
● These are represented or stated in the form of input to be given to the system, the
operation performed and the output expected.
● They are basically the requirements stated by the user which one can see directly in the
final product, unlike the non-functional requirements.

Prepared & Compiled by: Prof. Bhupendra Panchal

 Functional vs Non-Functional Requirements

Non-Functional Requirements:
● These are basically the quality constraints that the system must satisfy according to the
project contract.
● The priority or extent to which these factors are implemented varies from one project
to another. They are also called non-behavioral requirements. They basically deal with
issues like:

● Portability ● Scalability
● Security ● Performance
● Maintainability ● Reusability
● Reliability ● Flexibility
Prepared & Compiled by: Prof. Bhupendra Panchal
 Functional vs Non-Functional Requirements
Functional Requirements Non-Functional Requirements
A functional requirement defines a system or its A non-functional requirement defines the quality
components. attribute of a software system.
It places constraints on “How should the software
It specifies “What should the software system do?”
system fulfil the functional requirements?”
Non-functional requirement is specified by technical
Functional requirement is specified by User. peoples e.g. Architect, Technical leaders and
software developers.
It is mandatory. It is not mandatory.
It is captured in use case. It is captured as a quality attribute.
Helps you to verify the functionality of the software. Helps you to verify the performance of the software.
Functional Testing like System, Integration, End to End, Non-Functional Testing like Performance, Stress,
API testing, etc are done. Prepared & Compiled by: Prof.Usability,
Bhupendra Security
Panchal testing, etc are done.
 Functional vs Non-Functional Requirements
Functional Requirements Non-Functional Requirements
Usually easy to define. Usually more difficult to define.
Example Example

1) Authentication of the user whenever he/she logs into 1) Emails should be sent with a latency of no greater
the system. than 12 hours from such an activity.
2) System shutdown in case of a cyber attack. 2) The processing of each request should be done
3) A Verification email is sent to the user whenever within 10 seconds
he/she registers for the first time on some software 3) The site should load in 3 seconds when the
system. number of simultaneous users are > 10000

Prepared & Compiled by: Prof. Bhupendra Panchal

 Requirement Sources and Elicitation Techniques

System Requirements

● The system requirements on the other hand are an expanded version of the user
requirements that are used by software engineers as the starting point for the system
design.
● They add detail and explain how the user requirements should be provided by the
system. They shouldn’t be concerned with how the system should be implemented or
designed.
● The system requirements may also be written in natural language but other ways based
on structured forms, or graphical notations are usually used.

Prepared & Compiled by: Prof. Bhupendra Panchal

Module-2
Software Requirement Specifications

Prepared by: Bhupendra Panchal

 Software Requirement Spécifications
● A software requirements specification (SRS) is a document that captures
complete description about how the system is expected to perform.

● It is usually signed off at the end of requirements engineering phase.

● This report lays a foundation for software engineering activities and is

constructed when entire requirements are elicited and analysed.

● SRS is a formal report, which acts as a representation of software that enables

the customers to review whether it (SRS) is according to their requirements.
Also, it comprises user requirements for a system as well as detailed
specifications of the system requirements.

Prepared & Compiled by: Prof. Bhupendra Panchal

 Software Requirement Spécifications
● The SRS is a specification for a specific software product, program, or set of
applications that perform particular functions in a specific environment. It serves
several goals depending on who is writing it.

 First, the SRS could be written by the client of a system.

 Second, the SRS could be written by a developer of the system.

● The two methods create entirely various situations and establish different
purposes for the document altogether.

● The first case, SRS, is used to define the needs and expectations of the users.
The second case, SRS, is written for various purposes and serves as a contract
document between customer and developer.
Prepared & Compiled by: Prof. Bhupendra Panchal
What is an SRS?

Prepared & Compiled by: Prof. Bhupendra Panchal

Purpose of an SRS?

Prepared & Compiled by: Prof. Bhupendra Panchal

What is not included in an SRS?

Prepared & Compiled by: Prof. Bhupendra Panchal

Characteristics of good SRS

Prepared & Compiled by: Prof. Bhupendra Panchal

 Characteristics of good SRS

1. Correctness: User review is used to provide the accuracy of requirements stated in the SRS. SRS is
said to be perfect if it covers all the needs that are truly expected from the system.

2. Completeness: The SRS is complete if, and only if, it includes the following elements:
(1). All essential requirements, whether relating to functionality, performance, design, constraints, attributes,
or external interfaces.
(2). Full labels and references to all figures, tables, and diagrams in the SRS and definitions of all terms and
units of measure.

3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements described in its
conflict. There are three types of possible conflict in the SRS:
(1). The specified characteristics of real-world objects may conflicts.
(2). There may be a reasonable or temporal conflict between the two specified actions.
(3). Two or more requirements may define the same real-world object but use different terms for that object.
Prepared & Compiled by: Prof. Bhupendra Panchal
 Characteristics of good SRS
4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one interpretation. This
suggests that each element is uniquely interpreted.

5. Ranking for importance and stability: The SRS is ranked for importance and stability if each
requirement in it has an identifier to indicate either the significance or stability of that particular requirement.

6. Modifiability: SRS should be made as modifiable as likely and should be capable of quickly obtain
changes to the system to some extent. Modifications should be perfectly indexed and cross-referenced.

7. Verifiability: SRS is correct when the specified requirements can be verified with a cost-effective system
to check whether the final software meets those requirements. The requirements are verified with the help of
reviews.

8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if it facilitates the
referencing of each condition in future development or enhancement documentation.
Prepared & Compiled by: Prof. Bhupendra Panchal
 Essential properties of a good SRS
• Concise: The SRS report should be concise and at the same time, unambiguous, consistent, and
complete.

• Structured: It should be well-structured. A well-structured document is simple to understand and modify.

• Black-box view: It should only define what the system should do and refrain from stating how to do
these. This means that the SRS document should define the external behavior of the system and not
discuss the implementation issues.

• Conceptual integrity: It should show conceptual integrity so that the reader can merely understand it.
Response to undesired events: It should characterize acceptable responses to unwanted events.

• Verifiable: All requirements of the system, as documented in the SRS document, should be correct. This
means that it should be possible to decide whether or not requirements have been met in an
implementation.
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
Module-2
Software Measurement

Prepared by: Bhupendra Panchal

 Software Measurement:
• A measurement is a manifestation of the size, quantity, amount, or dimension of a
particular attribute of a product or process.
• It is an authority within software engineering. The software measurement process is
defined and governed by ISO Standard.
• The software measurement process can be characterized by five activities-
 Formulation
 Collection
 Analysis
 Interpretation
 Feedback
Prepared & Compiled by: Prof. Bhupendra Panchal
 Need for Software Measurement:

Software is measured to:

• Create and enhance the quality of the current product or process.
• Anticipate future qualities of the product or process.
• Regulate the state of the project in relation to budget and schedule.
• Identify bottlenecks and areas for improvement to drive process improvement
activities.
• Ensure that industry standards and regulations are followed.
• Enable the ongoing improvement of software development practices.

Prepared & Compiled by: Prof. Bhupendra Panchal

 Classification of Software Measurement

There are 2 types of software measurement:

• Direct Measurement: In direct measurement, the product, process, or thing is
measured directly using a standard scale.

• Indirect Measurement: In indirect measurement, the quantity or quality to be

measured is measured using related parameters i.e. by use of reference.

Prepared & Compiled by: Prof. Bhupendra Panchal

 Software Metrics

• 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.
• Within the software development process, many metrics are that are all connected.
• Software metrics are similar to the four functions of management: Planning,
Organization, Control, or Improvement.

Prepared & Compiled by: Prof. Bhupendra Panchal

 Characteristics of Software Metrics:
• Quantitative: Metrics must possess quantitative nature. It means metrics can be
expressed in values.
• Understandable: Metric computation should be easily understood, and the method of
computing metrics should be clearly defined.
• Applicability: Metrics should be applicable in the initial phases of the development of
the software.
• Repeatable: The metric values should be the same when measured repeatedly and
consistent in nature.
• Economical: The computation of metrics should be economical.
• Language Independent: Metrics should not depend on any programming language.
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
 Types of Software Metrics
1. Internal metrics: Internal metrics are used for measuring properties that are viewed to be of
greater importance to a software developer. For example, Lines of Code (LOC).

2. External metrics: External metrics are used for measuring properties that are viewed to be of
greater importance to the users, e.g., portability, reliability, functionality, usability, etc.

3. Hybrid metrics: Hybrid metrics combine product, process, and resource metrics. For example, cost
per FP where FP stands for Function Point Metric.

4. Project metrics: Project metrics are used by the project manager to check the project's progress.
Data from the past projects arePrepared
used &toCompiled
collect various metrics, like time and cost.
by: Prof. Bhupendra Panchal
 Classification of Software Metrics

1. Product Metrics
2. Process Metrics
3. Project Metrics

Prepared & Compiled by: Prof. Bhupendra Panchal

 Classification of Software Metrics
1. Product Metrics: Product metrics are used to evaluate the state of the product,
tracing risks and identify the problem areas. For example-
• Size and complexity of software.
• Quality and reliability of software.
• Performance
• Reliability
• Availability
• Usability
• Safety and security

Prepared & Compiled by: Prof. Bhupendra Panchal

 Classification of Software Metrics
2. Process Metrics: Process metrics pay particular attention to enhancing the long-
term process of the team or organization. They are used to measure the characteristics
of methods, techniques, and tools that are used for developing software. For example,
• Efficiency of fault detection
• Defects,
• Reliability
• Maintenance
• Management
• Effort and schedule variance

Prepared & Compiled by: Prof. Bhupendra Panchal

 Classification of Software Metrics
3. Project Metrics: They describe the project characteristic and execution process.
Examples-
• Cycle time
• Productivity
• Rate of Requirements Change
• Estimation Accuracy
• Staffing Change Pattern
• Cost, Scope, Risk

Prepared & Compiled by: Prof. Bhupendra Panchal

 Advantages of Software Metrics :

• It helps to identify the particular area for improvising.

• It helps to increase the product quality.
• Managing the workloads and teams.
• Reduction in overall time to produce the product.
• Reduction in cost or budget.
• It helps to determine the complexity of the code and to test the code with resources.
• It helps in providing effective planning, controlling and managing of the entire
product.

Prepared & Compiled by: Prof. Bhupendra Panchal

 Disadvantages of Software Metrics :

• It is expensive and difficult to implement the metrics in some cases.

• Performance of the entire team or an individual from the team can’t be determined.
Only the performance of the product is determined.
• Sometimes the quality of the product is not met with the expectation.
• It leads to measure the unwanted data which is wastage of time.
• Measuring the incorrect data leads to make wrong decision making.

Prepared & Compiled by: Prof. Bhupendra Panchal

Module-2
Software Project Estimation

Prepared by: Bhupendra Panchal

 Software Project Estimation

• Effective software project estimation is one of the most challenging and important
activities in software development. Proper project planning and control is not
possible without a sound and reliable estimate.
• Estimation is the process of finding an estimate, or approximation, which is a value
that can be used for some purpose even if input data may be incomplete, uncertain,
or unstable.
• Software development estimation revolves around predicting the project’s time,
effort, cost, and resources; all this information is necessary for the planning
stage and to ensure the project’s success.

Prepared & Compiled by: Prof. Bhupendra Panchal

Software Project Estimation
Estimation is based on −
• Past Data/Past Experience
• Available Documents/Knowledge
• Assumptions
• Identified Risks

The four basic steps in Software Project Estimation are −

1. Estimate the size of the development product.
2. Estimate the effort in person-months or person-hours.
3. Estimate the schedule in calendar months.
4. Estimate the project cost in agreed currency.
Prepared & Compiled by: Prof. Bhupendra Panchal
Software Project Estimation
1. Estimate the size of the development product:
• Estimation of the size of the software is an essential part of Software Project
Management.
• It helps the project manager to further predict the effort and time which will be
needed to build the project.
• 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

Prepared & Compiled by: Prof. Bhupendra Panchal

Software Project Estimation
 Lines of Code: Lines of Code (LOC): As the name suggests, LOC counts the total
number of lines of source code in a project.
 Number of entities in ER diagram: 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. This is because more entities needed more
classes/structures thus leading to more coding.
 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.
 Function points: In this method, the number and type of functions supported by the
software are utilized to find FPC(function point count).
Prepared & Compiled by: Prof. Bhupendra Panchal
Software Project Estimation
2. Estimate the effort in person-months or person-hours:
• Once you have an estimate of the size of your product, you can derive the effort
estimate.
• This conversion from software size to total project effort can only be done if you
have a defined software development lifecycle and development process that you
follow to specify, design, develop, and test the software.
There are two main ways to derive effort from size:
use your organization’s own historical data to determine how much effort previous
projects of the estimated size have taken.
use a mature and generally accepted algorithmic approach such as COCOMO
model to convert a size estimate into an effort estimate.
Prepared & Compiled by: Prof. Bhupendra Panchal
Software Project Estimation
3. Estimate the schedule in calendar months:
• This generally involves estimating the number of people who will work on the
project, what they will work on, when they will start working on the project and
when they will finish.
• Again, historical data from your organization’s past projects or industry data models
can be used to predict the number of people you will need for a project of a given
size and how work can be broken down into a schedule.
• If you have nothing else, a schedule estimation rule of thumb can be used to get a
rough idea of the total calendar time required:
Schedule in months = 3.0 * (effort-months) 1/3

Prepared & Compiled by: Prof. Bhupendra Panchal

Software Project Estimation
4. Estimate the project cost in agreed currency:
• There are many factors to consider when estimating the total cost of a project.
• These include labour, hardware and software purchases or rentals, travel for
meeting or testing purposes, telecommunications (e.g., longdistance phone calls,
video-conferences, dedicated lines for testing, etc.), training courses, office space,
and so on.
• You would have to determine what percentage of total project effort should be
allocated to each position. Again, historical data or industry data models can help.

Prepared & Compiled by: Prof. Bhupendra Panchal

Prepared & Compiled by: Prof. Bhupendra Panchal
Module-2
Project Estimation Approaches

Prepared by: Bhupendra Panchal

General Project Estimation Approach: Decomposition Technique.
• The Project Estimation Approach that is widely used is Decomposition Technique.
• Decomposition techniques take a divide and conquer approach.
• Size, Effort and Cost estimation are performed in a stepwise manner by breaking
down a Project into major Functions or related Software Engineering Activities.

• Step 1 − Understand the scope of the software to be built.

• Step 2 − Generate an estimate of the software size.
• Step 3 − Generate an estimate of the effort and cost by breaking down a project into
related software engineering activities.
• Step 4 − Reconcile estimates: Compare the resulting values of Step 3 and Step 2. If
both sets of estimates agree, then your numbers are highly reliable.
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
Types :
• 1. Organic – A software project is said to be an organic type if the team size required is
adequately small, the problem is well understood and has been solved in the past and also
the team members have a nominal experience regarding the problem.

• 2. Semi-detached – A software project is said to be a Semi-detached type if the vital

characteristics such as team size, experience, and knowledge of the various programming
environment lie in between that of organic and Embedded.

• 3. Embedded – A software project requiring the highest level of complexity, creativity, and
experience requirement fall under this category. Such software requires a larger team size
than the other two models and also the developers need to be sufficiently experienced and
creative to develop such complex models.
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
2. Intermediate Model –
• 2. Intermediate Model – The basic Cocomo model assumes that the effort is only a function
of the number of lines of code and some constants evaluated according to the different
software systems. However, in reality, no system’s effort and schedule can be solely
calculated on the basis of Lines of Code.
• For that, various other factors such as reliability, experience, and Capability. These factors
are known as Cost Drivers and the Intermediate Model utilizes 15 such drivers for cost
estimation.

Prepared & Compiled by: Prof. Bhupendra Panchal

3. Detailed Model
• 3. Detailed Model – Detailed COCOMO incorporates all characteristics of the intermediate
version with an assessment of the cost driver’s impact on each step of the software
engineering process.
• The detailed model uses different effort multipliers for each cost driver attribute.
• In detailed cocomo, the whole software is divided into different modules and then we
apply COCOMO in different modules to estimate effort and then sum the effort. The Six
phases of detailed COCOMO are:
• Planning and requirements
• System design
• Detailed design
• Module code and test
• Integration and test
• Cost Constructive modelPrepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
COCOMO Model
• Advantages of the COCOMO model:

• Provides a systematic way to estimate the cost and effort of a software project.
• Can be used to estimate the cost and effort of a software project at different stages of the
development process.
• Helps in identifying the factors that have the greatest impact on the cost and effort of a
software project.
• Can be used to evaluate the feasibility of a software project by estimating the cost and
effort required to complete it.

Prepared & Compiled by: Prof. Bhupendra Panchal

COCOMO Model
• Disadvantages of the COCOMO model:

• Assumes that the size of the software is the main factor that determines the cost and effort
of a software project, which may not always be the case.
• Does not take into account the specific characteristics of the development team, which can
have a significant impact on the cost and effort of a software project.
• Does not provide a precise estimate of the cost and effort of a software project, as it is
based on assumptions and averages.

Prepared & Compiled by: Prof. Bhupendra Panchal

Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal
Prepared & Compiled by: Prof. Bhupendra Panchal