SEPM- UNIT II

REQUIREMENT
ENGINEERING
INTRODUCTION
Topics:
Functional and non-functional requirements, user requirements, system requirements,
interface specification, the software requirements document. Requirements engineering
process: Feasibility studies, requirements elicitation and analysis, requirements validation,
requirements management. Software project effort and cost estimation – COCOMO model I,
COCOMO Model II, LOC, Function point metrics.
 What is Requirement?

In the software development process, requirement phase is the first software engineering activity.

This phase is a user-dominated phase and translates the ideas or views into a requirements
document.
It is a statement describing either

❑ An aspect of on the system’s development.

❑ In either case it must contribute in some way to what the proposed system must do,or a constraint wards adequately solving

the customer’s problem;

❑ the set of requirements as a whole represents a negotiated agreement among the stakeholders.

❑ A collection of requirements is a requirements document.

4
 What are Requirements?

• Requirements are defined during the early stages of a system development as a

specification of what should be implemented or as a constraint of some kind on the
system.
• They may be:
• a user-level facility description,
• a detailed specification of expected system behaviour,
• a general system property,
• a specific constraint on the system,
• information on how to carry out some computation,
• a constraint on the development of the system. 5
6
 Types of Requirement

User requirements
• Statements in natural language plus diagrams of the services the system provides and its operational
constraints. Written for customers. provides and its operational constraints.

System requirements
• A structured document setting out detailed descriptions of the system’s functions, services and
operational constraints. Defines what should be implemented so may be part of a contract between client
and contractor.

7
Types of System Requirements
• Software Requirements are mainly classified into three types:
• Functional requirements
• Non-functional requirements
• Domain requirements
Functional Requirements

• Functional requirements describe what the software should do. They

define the functions or features that the system must have.
• Examples:
• User Authentication: The system must allow users to log in using a
username and password.
• Search Functionality: The software should enable users to search for
products by name or category.
• Report Generation: The system should be able to generate sales reports
for a specified date range.
• Explanation: Functional requirements specify the actions that the software
needs to perform. These are the basic features and functionalities that
users expect from the software.
Non-functional Requirements

• Non-functional requirements describe how the software performs a task

rather than what it should do. They define the quality attributes,
performance criteria, and constraints.
• Examples:
• Performance: The system should process 1,000 transactions per second.
• Usability: The software should be easy to use and have a user-friendly
interface.
• Reliability: The system must have 99.9% uptime.
• Security: Data must be encrypted during transmission and storage.
• Explanation: Non-functional requirements are about the system’s
behavior, quality, and constraints. They ensure that the software meets
certain standards of performance, usability, reliability, and security.
11
Types of Non- functional Requirements

12
3. Domain Requirements

• Domain requirements are specific to the domain or industry in which the

software operates. They include terminology, rules, and standards relevant
to that particular domain.
• Examples:
• Healthcare: The software must comply with HIPAA regulations for handling
patient data.
• Finance: The system should adhere to GAAP standards for financial
reporting.
• E-commerce: The software should support various payment gateways like
PayPal, Stripe, and credit cards.
• Explanation: Domain requirements reflect the unique needs and
constraints of a particular industry. They ensure that the software is
relevant and compliant with industry-specific regulations and standards.
 Requirement Engineering Process
• It is a four-step process, which includes –

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management
 Feasibility Study
• The objective behind the feasibility study is to create the reasons for
developing the software that is acceptable to users, flexible to change
and conformable to established standards.
Types of Feasibility
1.Technical Feasibility - Technical feasibility evaluates the current technologies, which
are needed to accomplish customer requirements within the time and budget.
2.Operational Feasibility - Operational feasibility assesses the range in which the
required software performs a series of levels to solve business problems and customer
requirements.
3.Economic Feasibility - Economic feasibility decides whether the necessary software
can generate financial profits for an organization.
 Requirement Elicitation and Analysis
❑ This is also known as the gathering of requirements. Here,
requirements are identified with the help of customers and existing
systems processes, if available.

❑ Analysis of requirements starts with requirement elicitation. The

requirements are analyzed to identify inconsistencies, defects,
omission, etc. We describe requirements in terms of relationships
and also resolve conflicts if any
Problems of Elicitation and Analysis
Elicitation techniques
• Stakeholder analysis
• Analysis of existing systems or documentation,
background reading
• Task observation, ethnography
• Questionnaires
• Interviewing
• Brainstorming
• Joint Application Design (JAD)
• Prototyping
• Pilot system
• Use cases and scenarios
• Risk analysis
 Data-Gathering Techniques[1]

Technique Good for Kind of data Plus Minus

Questionnaires Answering specific questions Quantitative and qualitative Can reach many people with The design is crucial.
data low resource Response rate may be low.
Responses may not be what
you want
Interviews Exploring issues Some quantitative but Interviewer can guide Time consuming. Artificial
mostly qualitative data interviewee. Encourages environment may intimidate
contact between developers interviewee
and users

Focus groups and Collecting multiple Some quantitative but Highlights areas of consensus Possibility of dominant
workshops viewpoints mostly qualitative data and conflict. Encourages characters
contact between developers
and users

Naturalistic observation Understanding context of Qualitative Observing actual work gives Very time consuming. Huge
user activity insight that other techniques amounts of data
cannot give
Studying documentation Learning about procedures, Quantitative No time commitment from Day-to-day work will differ
regulations, and standards users required from documented
procedures

[1] Preece, Rogers, and Sharp “Interaction Design: Beyond human-computer interaction”, p214
18
 Software Requirement Specification
• Software requirement specification is a 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. It is the job of the analyst to write the requirement
in technical language so that they can be understood and beneficial by the development team.
• The models used at this stage include ER diagrams, data flow diagrams (DFDs), function
decomposition diagrams (FDDs), data dictionaries, etc.
• Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the
requirements. DFD shows the flow of data through a system. The system may be a company,
an organization, a set of procedures, a computer hardware system, a software system, or any
combination of the preceding. The DFD is also known as a data flow graph or bubble chart.
• Data Dictionaries: Data Dictionaries are simply repositories to store information about all
data items defined in DFDs. At the requirements stage, the data dictionary should at least
define customer data items, to ensure that the customer and developers use the same definition
and terminologies.
• Entity-Relationship Diagrams: Another tool for requirement specification is the
entity-relationship diagram, often called an "E-R diagram." It is a detailed logical
representation of the data for the organization and uses three main constructs i.e. data entities,
relationships, and their associated attributes.
What is a Software Requirements Specification document?
Table of Contents
Software Requirements Specification (SRS) Document for
Online Shopping System
• Introduction 1.1 Purpose The purpose of this document is to outline the
requirements for developing an Online Shopping System that allows users to
browse products, place orders, and manage their shopping activities online.
• 1.2 Scope The system will provide a user-friendly interface for customers to
search, view, and purchase products. It will also include an admin interface for
managing products, orders, and customer information. The system will support
multiple payment methods and ensure secure transactions.
• 1.3 Definitions, Acronyms, and Abbreviations
• SRS: Software Requirements Specification
• Admin: System Administrator
• User: Customer using the system
• 1.4 References
• IEEE Standard for Software Requirements Specifications
• 1.5 Overview This document is structured to describe the functional and
non-functional requirements of the Online Shopping System.
• General Description
• 2.1 Product Functions
• User Registration and Authentication
• Product Search and Viewing
• Shopping Cart Management
• Order Placement and Payment
• Order Tracking
• Admin Product and Order Management
• 2.2 User Characteristics
• Customers: General users with basic computer literacy
• Admins: Users with higher access levels to manage the system
• 2.3 Operating Environment
• Web-based application accessible via standard web browsers
• Compatible with desktop and mobile devices
• 2.4 Design and Implementation Constraints
• Compliance with security standards (SSL(Secure Socket layer) encryption,
secure payment gateways)
• Scalability to handle a large number of users and transactions
• 2.5 Assumptions and Dependencies
• Reliable internet connection for users
• Availability of third-party payment gateways
• Specific Requirements
• 3.1 Functional Requirements
• 3.1.1 User Registration and Login
• Users can register using their email and password
• Users can log in securely
• 3.1.2 Product Search and Viewing
• Users can search products by name, category, and price
• Users can view detailed product information
• 3.1.3 Shopping Cart
• Users can add/remove products to/from the cart
• Users can view the cart and proceed to checkout
• 3.1.4 Order Processing
• Users can place orders and choose payment methods
• Users receive order confirmation and tracking information
• 3.1.5 Admin Management
• Admins can add, update, and delete products
• Admins can view and manage customer orders
• 3.2 Non-Functional Requirements
• 3.2.1 Performance Requirements
• System should handle up to 1000 concurrent users
• 3.2.2 Security Requirements
• User data must be encrypted
• Secure authentication mechanisms
• 3.2.3 Usability Requirements
• Intuitive and user-friendly interface
• 3.2.4 Reliability Requirements
• System uptime of 99.9%
• 3.3 External Interface Requirements
• 3.3.1 User Interfaces
• Web interface for users and admins
• 3.3.2 Hardware Interfaces
• Compatible with standard hardware devices (PC, mobile)
• 3.3.3 Software Interfaces
• Integration with payment gateways
• Database for storing user, product, and order information
4. Appendices
• List of supported payment methods
Software Requirement Validation
• After requirement specifications developed, the requirements discussed in this document are
validated. 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: systematic manual analysis of the requirements.
• Prototyping: Using an executable model of the system to check requirements.
• Test-case generation: Developing tests for requirements to check testability.
• Automated consistency analysis: checking for the consistency of structured requirements
descriptions.
 Software Requirement Management

• Requirement management is 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.
• The business and technical environment of the system changes during
the development.
 Software Project Effort and Cost Estimation
• Software projects are inherently effort driven because most of work involves human effort to build the
software product.
• Estimating the effort required to build the software product is difficult as the result of effort is intangible and
difficult to make effort estimation in building software artifacts.
• There are many techniques like Function point analysis, wide band Delphi, COCOMO etc. for making effort
estimation on software projects.
• Depending on requirement, a suitable effort estimation technique is chosen for any software project.
• Since effort estimation techniques are not foolproof, effort estimates need to be revised as the project
progresses.
• Once effort estimates are made for the project, cost estimates are calculated based on the effort estimate
and cost parameters like hourly salary of individual employees.
• Cost estimates are done using techniques like activity based costing or cost factor analysis.
 Software Project Effort and Cost Estimation
• Estimation of resources, cost, and schedule for a software engineering effort requires
• Experience
• Access to good historical information (metrics)
• The courage to commit to quantitative predictions when qualitative information is all that exists
• Estimation carries inherent risk and this risk leads to uncertainty.
• Project scope must be understood
• Elaboration (decomposition) is necessary
• Historical metrics are very helpful
• At least two different techniques should be used
• Uncertainty is inherent in the process
• Estimation Techniques:
• Past (similar) project experience
• Conventional estimation techniques
• Task breakdown and effort estimates
• Size (e.g., FP) estimates
• Empirical models
• Automated tools
 Software Project Effort and Cost Estimation
• Software projects use different kinds of software development life cycle models like waterfall model,
iterative model etc.
• Effort estimation for each type of software development lifecycle model requires understanding the
difference in the way the software product is built.
• In iterative models, software products are built in small incremental cycles.
• On the contrary in the waterfall model, software products are built in one go and thus all product features
are fully built in the same one cycle.
• This fundamental difference necessitates a different approach to effort estimation for each type of software
development lifecycle model projects.
• Software products are made manually by software engineers.
• How many of these people are needed on the project and for how long, is determined by the effort estimate
and project duration.
• Resource estimation also needs to take into consideration the skill set required on the project.
• Of course, speed with which a software engineer can build a software product varies and thus this factor can
affect resource estimation on the project.
 Software Project Effort and Cost Estimation
Function point count for effort estimate (function point analysis technique)

• Function points are derived using an empirical relationship based on countable (direct) measures of
software’s information domain and qualitative assessments of software complexity.
• The function point (FP) metric can be used effectively as a means for measuring the functionality delivered
by a system.
• Using historical data, the FP metric can then be used to – a) estimate the cost or effort required to design,
code and test the software, b) predict the number of errors that will be encountered during testing, c)
forecast the number of components and/or the number of projected source lines in the implemented
system.
Software Project Effort and Cost Estimation
Function count type for effort estimate (function point analysis technique)

Effort sizing for effort estimate (function point analysis technique)

Software Project Effort and Cost Estimation

Effort estimate for iterative projects

Software Project Effort and Cost Estimation
Comparison of effort estimate techniques

Effort and cost for

various project tasks
 Software Project Effort and Cost Estimation
Project Planning – Task Set
• Estimate cost and effort
• Decompose the problem
• Develop two or more estimates using size, function points, process tasks or use-cases
• Reconcile the estimates

• Develop a project schedule

• Establish a meaningful task set
• Define a task network
• Use scheduling tools to develop a timeline chart
• Define schedule tracking mechanisms
 Software Project Effort and Cost Estimation – Software Sizing
• Predicated on …
• The degree to which the planner has properly estimated the size of the
product to be built
• The ability to translate the size estimate into human effort, calendar time,
and dollars (a function of the availability of reliable software metrics from
past projects)
• The degree to which the project plan reflects the abilities of the software
team
• The stability of product requirements and the environment that supports the
software engineering effort.
 Software Project Effort and Cost Estimation - Techniques
Functional Decomposition

Statement Functional
of decomposition
Scope
Perform a
Grammatical “parse”

38
 Software Project Effort and Cost Estimation - Techniques
Conventional Methods – LOC/FP Approach
• Compute LOC/FP using estimates of information domain values
• Use historical data to build estimates for the project
• Example – LOC Approach

Average productivity for systems of this type = 620 LOC/pm.

Burdened labor rate =$8000 per month, the cost per line of code is
approximately $13.
Based on the LOC estimate and the historical productivity data, the
total estimated project cost is $431,000 and the estimated effort is
39
54 person-months.
 Software Project Effort and Cost Estimation - Techniques
Conventional Methods – LOC/FP Approach
Example: FP
Approach

The estimated number of FP is derived:

FPestimated = count-total 3 [0.65 + 0.01 3 S (Fi)]
FPestimated = 375
organizational average productivity = 6.5 FP/pm.
burdened labor rate = $8000 per month, approximately $1230/FP.
Based on the FP estimate and the historical productivity data, total estimated project
cost is $461,000 and estimated effort is 58 person-months.
40
 Software Project Effort and Cost Estimation - Techniques
Process Based Estimation

Obtained from “process framework”

Framework activities

Application Effort required to

functions accomplish
each framework
activity for each
application function

41
 Software Project Effort and Cost Estimation - Techniques
Process Based Estimation - Example

Based on an average burdened labor rate of $8,000 per month, the

total estimated project cost is $368,000 and the estimated effort
is 46 person-months.
42
 Software Project Effort and Cost Estimation - Techniques
Tool Based Estimation

Project Characteristics

Calibration Factors

LOC/FP data

43
 Software Project Effort and Cost Estimation - Techniques
Estimation with Use Cases

Using 620 LOC/pm as the average productivity for systems of this

type and a burdened labor rate of $8000 per month, the cost per line
of code is approximately $13. Based on the use-case estimate and
the historical productivity data, the total estimated project cost is
$552,000 and the estimated effort is 68 person-months.

44
 Software Project Effort and Cost Estimation -
Problems
• Estimated LOC count is 56,100 . Assuming that your organization produces 450
LOC/pm with a burdened labor rate of $7000 per person-month, find the cost
/LOC, total estimated project cost and estimated effort in person months.
To Compute:
• Cost per LOC = Labor rate per month/LOC per pm
• Total Estimated Project Cost = Estimated LOC * Cost per LOC
• Estimated Effort in pm = Total Estimated Project Cost/ Labor rate per month

45
 COCOMO I
• The constructive cost model was developed by Barry W. Boehm in the late
1970s and published in Boehm's 1981 as a model for estimating effort, cost and
schedule for software projects.
• Basic model - It estimates the software in a rough and quick manner.
• Mostly used in small and medium sized projects.
• 3 modes of development:
a) Organic,
b) Semi Detached,
c) Embedded

46
 COCOMO - I
• Equation & Example

47
 COCOMO I
Numerical
• Suppose a project was estimated to be 400 KLOC. Calculate effort and time for
organic mode.
• Organic:
Effort = a (KLOC)b
Effort = 2.4 (400)1.05
Effort = 1295PM
Development Time = c (Effort)d
Development Time = 2.5 (1295)0.38
Development Time = 38 Months, Find Effort Staff Size, Productivity??
• Semi-detached:
Effort = a (KLOC)b
Effort = 3.0 (400)1.12
Person Months = 2462PM, Find Development Time, Effort Staff Size,
Productivity??
• Embedded:
Effort = a (KLOC)b
Effort = 3.6 (400)1.20
Person Months = 4772PM , Find Development Time , Effort Staff Size,
Productivity??
48
 COCOMO II
• Barry Boehm introduced a hierarchy of software estimation models bearing the
name COCOMO, for Constructive Cost Model.
• The original COCOMO model became one of the most widely used and discussed
software cost estimation models in the industry.
• It has evolved into a more comprehensive estimation model, called COCOMO II.
• Like its predecessor, COCOMO II is actually a hierarchy of estimation models that
address the following areas:
• Application composition model: Used during the early stages of software engineering, when
prototyping of user interfaces, consideration of software and system interaction, assessment of
performance, and evaluation of technology maturity are paramount.
• Early design stage model: Used once requirements have been stabilized and basic software
architecture has been established.
• Post-architecture-stage model: Used during the construction of the software.
• Like all estimation models for software, the COCOMO II models require sizing
information.
• Three different sizing options are available as part of the model hierarchy: object
points, function points and lines of source code.

51
 COCOMO II
• The COCOMO II application composition model uses object points and is
illustrated below.
• It should be noted that other, more sophisticated estimation models (using FP
and KLOC) are also available as part of COCOMO II.

Complexity weighting for object types

• Like function points, the object point is an indirect software measure that is
computed using counts of the number of (a) screens (at the user interface), (b)
reports, and (c) components likely to be required to build the application.
• Each object instance (e.g., a screen or report) is classified into one of three
complexity levels (i.e., simple, medium, or difficult) using criteria suggested by
Boehm.
• In essence, complexity is a function of the number and source of the client and
server data tables that are required to generate the screen or report and the
52
number of views or sections presented as part of the screen or report.
 COCOMO II
• Once complexity is determined, the number of screens, reports and
components are weighted according to the table illustrated in above figure.
• The object point count is then determined by multiplying the original number of
object instances by the weighting factor in the figure and summing to obtain a
total object point count.
• When component-based development or general software reuse is to be
applied, the percent of reuse (%reuse) is estimated and the object point count is
adjusted:
NOP = (object points) * [(100 - % reuse) / 100], where NOP is defined as new
object points
• To derive an estimate of effort based on the computed NOP value, a
“productivity rate” must be derived.

53
 COCOMO II
• The figure above presents the productivity rate,
PROD = NOP / person-month, for different levels of developer experience and
development environment maturity.
• Once the productivity rate has been determined, an estimate of project effort is
computing using,
Estimated effort = NOP / PROD
• In more advanced COCOMO II models (these models use FP and KLOC counts of
the size variable), a variety of scale factors, cost drivers, and adjustment
procedures are required.

54
 COCOMO II - Problems

• Use the COCOMO II model to estimate the effort required to build software for
a simple ATM that produces 12 screens, 10 reports, and will require
approximately 80 software components, Percentage of reuse is 20%, Value of
Prod=9. Use the application composition model with object points.
To Compute:
• Object points = screen + report + components
• NOP = Object Points * [(100 - % reuse)/100]
• Estimated Effort = NOP/PROD

55