Module-2

Requirements
Engineering
 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.
Requirements Engineering — Elicitation,
Analysis & Specification

(The activity of generating the requirements of a system from

users, customers, and other stakeholders)
 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.

 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.
 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.
 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
 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.
 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.
 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.
 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.
 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.
 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
 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,
usability, Security testing, etc are done
API 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 1)Emails should be sent with a latency of no
into the system. greater than 12 hours from such an activity.
2) System shutdown in case of a cyber attack. 2)The processing of each request should be
3)A Verification email is sent to the user done within 10 seconds
whenever he/she registers for the first time on 3) The site should load in 3 seconds when the
some software system. number of simultaneous users are > 10000
 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.
Module-2
Software Requirement
Specifications
 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
 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.
What is an SRS?
Purpose of an SRS?
What is not included in an SRS?
Characteristics of good SRS
 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.

[Link]: 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.
 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.

[Link]: 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.

[Link]: 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.
 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.
Module-2
Software
Measurement
 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
 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.
 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
 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.
 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.
 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.
 Classification of Software Metrics

1. Product
Metrics
2. Process Metrics
3. Project Metrics
 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
 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
 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
 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.
 Disadvantages of Software Metrics :
• It is expensive and diffi cult 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.
Module-2
Software Project
Estimation
 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.
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.
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
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 fl ow of data between them.
 Function points: In this method, the number and type of functions
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
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:
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.
Module-2
Project Estimation
Approaches
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.
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
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.
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
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.
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.