1

UNIT 2

Software Requirements
Topics covered
Functional and non-functional requirements
Requirements engineering processes
Requirements elicitation
Requirements specification
Requirements validation
Requirements change / Management

2
3
Requirements engineering
The process of establishing the services that a customer
requires from a system and the constraints under which it
operates and is developed.

The system requirements are the descriptions of the system

services and constraints that are generated during the
requirements engineering process.

4
What is a requirement?
It may range from a high-level abstract statement of a service or of
a system constraint to a detailed mathematical functional
specification.

This is inevitable as requirements may serve a dual function

◦ May be the basis for a bid for a contract - therefore must be open to
interpretation;

◦ May be the basis for the contract itself - therefore must be defined in detail;

◦ Both these statements may be called requirements.

5
 Requirements abstraction (Davis)
“If a company wishes to let a contract for a large software development
project, it must define its needs in a sufficiently abstract way that a
solution is not pre-defined.
The requirements must be written so that several contractors can bid for
the contract, offering, perhaps, different ways of meeting the client
organization’s needs.
Once a contract has been awarded, the contractor must write a system
definition for the client in more detail so that the client understands and
can validate what the software will do.
Both of these documents may be called the requirements document for
the system.”
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.

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
User and system requirements

8
Readers of different types of requirements
specification

9
Functional and non-functional
requirements

10
Functional and non-functional requirements

Functional requirements
◦ Statements of services the system should provide, how the system should
react to inputs and how the system should behave situations.
◦ May state what the system should not do.

Non-functional requirements
◦ Constraints on the services or functions offered by the system such as
timing constraints, constraints on the development process, standards, etc.
◦ Often apply to the system as a whole rather than individual features or services.

Domain requirements
◦ Constraints on the system from the domain of operation

11
Functional requirements

• Describe functionality or system services.

• Depend on the type of software, expected users and the type of

system where the software is used.

• Functional user requirements may be high-level statements of

what the system should do.

• Functional system requirements should describe the system

services in detail.

12
Mentcare system: functional requirements
• A user shall be able to search the appointments lists for all
clinics.

• The system shall generate each day, for each clinic, a list of
patients who are expected to attend appointments that day.

• Each staff member using the system shall be uniquely identified

by his or her 8-digit employee number.

13
Requirements imprecision
Problems arise when functional requirements are not precisely
stated.

Ambiguous requirements may be interpreted in different ways by

developers and users.

Consider the term ‘search’ in requirement 1

◦ User intention – search for a patient name across all appointments in all
clinics;

◦ Developer interpretation – search for a patient name in an individual clinic.

User chooses clinic then search.

14
Requirements completeness and consistency

In principle, requirements should be both complete and consistent.

Complete

◦ They should include descriptions of all facilities required.

Consistent

◦ There should be no conflicts or contradictions in the descriptions of the

system facilities.

In practice, because of system and environmental complexity, it is

impossible to produce a complete and consistent requirements document.

15
Non-functional requirements
• These define system properties and constraints e.g. reliability,
response time and storage requirements. Constraints are I/O
device capability, system representations, etc.

• Process requirements may also be specified mandating a

particular IDE, programming language or development method.

• Non-functional requirements may be more critical than

functional requirements. If these are not met, the system may
be useless.

16
Types of nonfunctional requirement

17
Non-functional requirements implementation
Non-functional requirements may affect the overall architecture of
a system rather than the individual components.
◦ For example, to ensure that performance requirements are met, you may
have to organize the system to minimize communications between
components.

A single non-functional requirement, such as a security

requirement, may generate a number of related functional
requirements that define system services that are required.
◦ It may also generate requirements that restrict existing requirements.

18
Non-functional classifications

Product requirements
◦ Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.

Organizational requirements
◦ Requirements which are a consequence of organizational policies and
procedures e.g. process standards used, implementation requirements, etc.

External requirements
◦ Requirements which arise from factors which are external to the system and
its development process e.g. interoperability requirements, legislative
requirements, etc.
19
Examples of nonfunctional requirements in
the Mentcare system
Product requirement
The Mentcare system shall be available to all clinics during normal working
hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not
exceed five seconds in any one day.

Organizational requirement
Users of the Mentcare system shall authenticate themselves using their health
authority identity card.

External requirement
The system shall implement patient privacy provisions as set out in
HStan-03-2006-priv.

20
Goals and requirements

Non-functional requirements may be very difficult to state precisely and

imprecise requirements may be difficult to verify.

Goal

◦ A general intention of the user such as ease of use.

Verifiable non-functional requirement

◦ A statement using some measure that can be objectively tested.

Goals are helpful to developers as they convey the intentions of the system

users.
21
Usability requirements
The system should be easy to use by medical staff and should be
organized in such a way that user errors are minimized. (Goal)

Medical staff shall be able to use all the system functions after
four hours of training.

After this training, the average number of errors made by

experienced users shall not exceed two per hour of system use.
(Testable non-functional requirement)

22
Metrics for specifying nonfunctional requirements
Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
23
Software Requirement Document
(OR)
Software Requirement specification
(SRS)

24
Requirements specification

25
Requirements specification
The process of writing down the user and system requirements in a
requirements document.

User requirements have to be understandable by end-users and

customers who do not have a technical background.

System requirements are more detailed requirements and may include

more technical information.

The requirements may be part of a contract for the system

development
◦ It is therefore important that these are as complete as possible.

26
Ways of writing a system requirements specification
Notation Description
Natural language The requirements are written using numbered sentences in natural
language. Each sentence should express one requirement.

Structured natural The requirements are written in natural language on a standard form or
language template. Each field provides information about an aspect of the requirement.

Design description This approach uses a language like a programming language, but with more
languages abstract features to specify the requirements by defining an operational model
of the system. This approach is now rarely used although it can be useful for
interface specifications.
Graphical notations Graphical models, supplemented by text annotations, are used to define the
functional requirements for the system; UML use case and sequence
diagrams are commonly used.
Mathematical These notations are based on mathematical concepts such as finite-state
specifications machines or sets. Although these unambiguous specifications can reduce
the ambiguity in a requirements document, most customers don’t understand a
formal specification. They cannot check that it represents what they want and
are reluctant to accept it as a system contract

27
Requirements and design

• In principle, requirements should state what the system should

do and the design should describe how it does this.

• In practice, requirements and design are inseparable

• A system architecture may be designed to structure the requirements;

• The system may inter-operate with other systems that generate design
requirements;

• The use of a specific architecture to satisfy non-functional requirements

may be a domain requirement.

• This may be the consequence of a regulatory requirement.

28
Natural language specification
• Requirements are written as natural language sentences
supplemented by diagrams and tables.

• Used for writing requirements because it is expressive, intuitive

and universal. This means that the requirements can be
understood by users and customers.

29
Guidelines for writing requirements

• Invent a standard format and use it for all requirements.

• Use language in a consistent way. Use shall for mandatory

requirements, should for desirable requirements.

• Use text highlighting to identify key parts of the requirement.

• Avoid the use of computer jargon.

• Include an explanation (rationale) of why a requirement is

necessary.

30
Problems with natural language
• Lack of clarity
• Precision is difficult without making the document difficult to read.

• Requirements confusion
• Functional and non-functional requirements tend to be mixed-up.

• Requirements amalgamation
• Several different requirements may be expressed together.

31
Example requirements for the insulin pump
software system

3.2 The system shall measure the blood sugar and deliver insulin, if required,
every 10 minutes. (Changes in blood sugar are relatively slow so more frequent
measurement is unnecessary; less frequent measurement could lead to
unnecessarily high sugar levels.)

3.6 The system shall run a self-test routine every minute with the conditions to
be tested and the associated actions defined in Table 1. (A self-test routine can
discover hardware and software problems and alert the user to the fact the
normal operation may be impossible.)

32
Structured specifications

An approach to writing requirements where the freedom of the

requirements writer is limited and requirements are written in a
standard way.

This works well for some types of requirements e.g. requirements

for embedded control system but is sometimes too rigid for writing
business system requirements.

33
Form-based specifications

• Definition of the function or entity.

• Description of inputs and where they come from.

• Description of outputs and where they go to.

• Information about the information needed for the computation and

other entities used.

• Description of the action to be taken.

• Pre and post conditions (if appropriate).

• The side effects (if any) of the function.

34
A structured specification of a requirement for
an insulin pump

35
A structured specification of a requirement for an
insulin pump

36
Tabular specification

• Used to supplement natural language.

• Particularly useful when you have to define a number of possible

alternative courses of action.

• For example, the insulin pump systems bases its computations

on the rate of change of blood sugar level and the tabular
specification explains how to calculate the insulin requirement
for different scenarios.

37
Tabular specification of computation for an
insulin pump

Condition Action

Sugar level falling (r2 < r1) CompDose = 0

Sugar level stable (r2 = r1) CompDose = 0

Sugar level increasing and rate of increase CompDose = 0

decreasing
((r2 – r1) < (r1 – r0))

Sugar level increasing and rate of increase stable CompDose =

or increasing round ((r2 – r1)/4)
((r2 – r1) ≥ (r1 – r0)) If rounded result = 0 then
CompDose = MinimumDose

38
Use cases
• Use-cases are a kind of scenario that are included in the UML.

• Use cases identify the actors in an interaction and which describe the
interaction itself.

• A set of use cases should describe all possible interactions with the
system.

• High-level graphical model supplemented by more detailed tabular

description.

• UML sequence diagrams may be used to add detail to use-cases by

showing the sequence of event processing in the system.

39
Use cases for the Mentcare system

40
The software requirements document

• The software requirements document is the official statement of

what is required of the system developers.

• Should include both a definition of user requirements and a

specification of the system requirements.

• It is NOT a design document. As far as possible, it should set of

WHAT the system should do rather than HOW it should do it.

41
 SRS – Users of requirement doc

- official statement of what the system

developers should implement.
It should include both the user
requirements for a system and a detailed
specification of the system requirements.

The requirements document has a

diverse set of users, ranging from the
senior management of the organization
that is paying for the system to the
engineers responsible for developing the
software

42
Requirements document variability
• Information in requirements document depends on type of
system and the approach to development used.

• Systems developed incrementally will, typically, have less detail

in the requirements document.

• Requirements documents standards have been designed e.g.

IEEE standard. These are mostly applicable to the requirements
for large systems engineering projects.

43
Structure of requirement doc

44
Requirements Engineering
Processes

45
Requirements Engineering Processes
The processes used for RE vary widely depending on the application
domain, the people involved and the organization developing the
requirements.

However, there are a number of generic activities common to all processes

1. Requirements elicitation;

2. Requirements analysis;

3. Requirements validation;

4. Requirements management.

In practice, RE is an iterative activity in which these processes are

interleaved.
46
Process for Capturing the Requirements
• Performed by the rqt. analyst or system analyst
• The final outcome is a Software Requirements Specification (SRS) document

47
48
A spiral view of the requirements engineering
process

49
Requirements elicitation and analysis
• Sometimes called requirements elicitation or requirements
discovery.

• Involves technical staff working with customers to find out

about the application domain, the services that the system
should provide and the system’s operational constraints.

• May involve end-users, managers, engineers involved in

maintenance, domain experts, trade unions, etc. These are
called stakeholders.

50
Requirements elicitation

• Software engineers work with a range of system stakeholders to find out

about the application domain, the services that the system should provide,
the required system performance, hardware constraints, other systems, etc.

• Stages include:
• Requirements discovery,

• Requirements classification and organization,

• Requirements prioritization and negotiation,

• Requirements specification.

51
Problems of requirements elicitation

• Stakeholders don’t know what they really want.

• Stakeholders express requirements in their own terms.

• Different stakeholders may have conflicting requirements.

• Organizational and political factors may influence the system

requirements.

• The requirements change during the analysis process.

• New stakeholders may emerge and the business environment may

52
change.
The requirements elicitation and analysis
process
1) Requirements discovery: This is the process of
interacting with stakeholders of the system to
discover their requirements.

2) This activity takes the unstructured collection of

requirements, groups related requirements, and
organizes them into coherent clusters.

3) when multiple stake holders are involved,

requirements will conflict. This activity is
concerned with prioritizing requirements and
finding and resolving requirements conflicts
through negotiation.

4) The requirements are documented and input into

the next round of the spiral. Formal or informal
requirements documents may be produced

53
Process activities

• Requirements discovery
• Interacting with stakeholders to discover their requirements. Domain
requirements are also discovered at this stage.

• Requirements classification and organization

• Groups related requirements and organizes them into coherent clusters.

• Prioritization and negotiation

• Prioritizing requirements and resolving requirements conflicts.

• Requirements specification
• Requirements are documented and input into the next round of the spiral.

54
Requirements discovery

• The process of gathering information about the required and

existing systems and distilling the user and system requirements
from this information.

• Interaction is with system stakeholders from managers to external

regulators.

• Systems normally have a range of stakeholders.

55
 Interviewing
• Formal or informal interviews with stakeholders are part of most
RE processes.

• Types of interview
• Closed interviews based on pre-determined list of questions

• Open interviews where various issues are explored with stakeholders.

56
Interviews in practice

• Normally a mix of closed and open-ended interviewing.

• Interviews are good for getting an overall understanding of what

stakeholders do and how they might interact with the system.

• Interviewers need to be open-minded without pre-conceived ideas of what

the system should do

• You need to prompt the use to talk about the system by suggesting

requirements rather than simply asking them what they want.

57
Problems with interviews
• Application specialists may use language to describe their work that isn’t
easy for the requirements engineer to understand.

• Interviews are not good for understanding domain requirements

• Requirements engineers cannot understand specific domain terminology;

• Some domain knowledge is so familiar that people find it hard to

articulate or think that it isn’t worth articulating.

58
Ethnography

•A social scientist spends a considerable time observing and analyzing

how people work.

• People do not have to explain or articulate their work.

• Social and organizational factors of importance may be observed.

• Ethnographic studies have shown that work is usually richer and more

complex than suggested by simple system models.

59
Scope of ethnography

• Requirements that are derived from the way that people work rather than
the way in which process definitions suggest that they ought to work.

• Requirements that are derived from cooperation and awareness of other

people’s activities.

• Awareness of what other people are doing leads to changes in the ways
in which we do things.

• Ethnography is effective for understanding existing processes but

cannot identify new features that should be added to a system.

60
Focused ethnography

• Developed in a project studying the air traffic control process

• Combines ethnography with prototyping

• Prototype development results in unanswered questions which

focus the ethnographic analysis.

• The problem with ethnography is that it studies existing

practices which may have some historical basis which is no
longer relevant.

61
Ethnography and prototyping for
requirements analysis

62
Stories and scenarios
• Scenarios and user stories are real-life examples of how a
system can be used.

• Stories and scenarios are a description of how a system may be

used for a particular task.

• Because they are based on a practical situation, stakeholders

can relate to them and can comment on their situation with
respect to the story.

63
Photo sharing in the classroom (iLearn)
• Jack is a primary school teacher in Ullapool (a village in northern Scotland). He has decided that a class project

should be focused around the fishing industry in the area, looking at the history, development and economic impact
of fishing.

• As part of this, pupils are asked to gather and share reminiscences from relatives, use newspaper archives and

collect old photographs related to fishing and fishing communities in the area.

• Pupils use an iLearn wiki to gather together fishing stories and SCRAN (a history resources site) to access

newspaper archives and photographs.

• However, Jack also needs a photo sharing site as he wants pupils to take and comment on each others’ photos and

to upload scans of old photographs that they may have in their families.

• Jack sends an email to a primary school teachers group, which he is a member of to see if anyone can recommend

an appropriate system.

• Two teachers reply and both suggest that he uses KidsTakePics, a photo sharing site that allows teachers to check

and moderate content.

• As KidsTakePics is not integrated with the iLearn authentication service, he sets up a teacher and a class account.

• He uses the iLearn setup service to add KidsTakePics to the services seen by the pupils in his class so that when

they log in, they can immediately use the system to upload photos from their mobile devices and class computers.
64
Scenarios

• A structured form of user story

• Scenarios should include

• A description of the starting situation;

• A description of the normal flow of events;

• A description of what can go wrong;

• Information about other concurrent activities;

• A description of the state when the scenario finishes.

65
Uploading photos (iLearn)

• Initial assumption: A user or a group of users have one or more digital photographs
to be uploaded to the picture sharing site. These are saved on either a tablet or laptop
computer. They have successfully logged on to KidsTakePics.

• Normal: The user chooses upload photos and they are prompted to select the
photos to be uploaded on their computer and to select the project name under which
the photos will be stored. They should also be given the option of inputting keywords
that should be associated with each uploaded photo. Uploaded photos are named by
creating a conjunction of the user name with the filename of the photo on the local
computer.

• On completion of the upload, the system automatically sends an email to the project
moderator asking them to check new content and generates an on-screen message
to the user that this has been done.

66
Uploading photos
What can go wrong:

• No moderator is associated with the selected project. An email is automatically generated to the school
administrator asking them to nominate a project moderator. Users should be informed that there could be
a delay in making their photos visible.

• Photos with the same name have already been uploaded by the same user. The user should be asked if
they wish to re-upload the photos with the same name, rename the photos or cancel the upload. If they
chose to re-upload the photos, the originals are overwritten. If they chose to rename the photos, a new
name is automatically generated by adding a number to the existing file name.

• Other activities: The moderator may be logged on to the system and may approve photos as they are
uploaded.

• System state on completion: User is logged on. The selected photos have been uploaded and assigned
a status ‘awaiting moderation’. Photos are visible to the moderator and to the user who uploaded them.

67
Requirements validation
• Concerned with demonstrating that the requirements define the system
that the customer really wants.

• Requirements error costs are high so validation is very important

• Fixing a requirements error after delivery may cost up to 100 times the
cost of fixing an implementation error.

68
Requirements checking

• Validity. Does the system provide the functions which best support the

customer’s needs?

• Consistency. Are there any requirements conflicts?

• Completeness. Are all functions required by the customer included?

• Realism. Can the requirements be implemented given available budget

and technology

• Verifiability. Can the requirements be checked?

69
Requirements validation techniques

• Requirements reviews
• 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.

70
Requirements reviews
• Regular reviews should be held while the requirements
definition is being formulated.

• Both client and contractor staff should be involved in reviews.

• Reviews may be formal (with completed documents) or

informal.

• Good communications between developers, customers and

users can resolve problems at an early stage.

71
Review checks
Verifiability

◦ Is the requirement realistically testable?

Comprehensibility

◦ Is the requirement properly understood?

Traceability

◦ Is the origin of the requirement clearly stated?

Adaptability

◦ Can the requirement be changed without a large impact on other

requirements?

72
Changing requirements
• The business and technical environment of the system always changes after
installation.
• New hardware may be introduced, it may be necessary to interface the system
with other systems, business priorities may change (with consequent changes
in the system support required), and new legislation and regulations may be
introduced that the system must necessarily abide by.

• The people who pay for a system and the users of that system are rarely the same
people.
• System customers impose requirements because of organizational and
budgetary constraints. These may conflict with end-user requirements, and,
after delivery, new features may have to be added for user support if the
system is to meet its goals.

73
Changing requirements

• Large systems usually have a diverse user community, with many users
having different requirements and priorities that may be conflicting or
contradictory.

• The final system requirements are inevitably a compromise between

them and, with experience, it is often discovered that the balance of
support given to different users has to be changed.

74
Requirements evolution

75
Requirements management
• Requirements management is the process of managing changing

requirements during the requirements engineering process and system

development.

• New requirements emerge as a system is being developed and after it has

gone into use.

• You need to keep track of individual requirements and maintain links

between dependent requirements so that you can assess the impact of
requirements changes.

• You need to establish a formal process for making change proposals and
linking these to system requirements.
76
Requirements management planning
• Establishes the level of requirements management detail that is
required.

• Requirements management decisions:

• Requirements identification: Each requirement must be uniquely identified so
that it can be cross-referenced with other requirements.
• A change management process This is the set of activities that assess the
impact and cost of changes. I discuss this process in more detail in the following
section.
• Traceability policies These policies define the relationships between each
requirement and between the requirements and the system design that should
be recorded.
• Tool support Tools that may be used range from specialist requirements
management systems to spreadsheets and simple database systems. 77
Requirements change management
Deciding if a requirements change should be accepted

◦ Problem analysis and change specification

◦ During this stage, the problem or the change proposal is analyzed to check that it is valid.
This analysis is fed back to the change requestor who may respond with a more specific
requirements change proposal, or decide to withdraw the request.

◦ Change analysis and costing

◦ The effect of the proposed change is assessed using traceability information and general
knowledge of the system requirements. Once this analysis is completed, a decision is made
whether or not to proceed with the requirements change.

◦ Change implementation

◦ The requirements document and, where necessary, the system design and implementation,
are modified. Ideally, the document should be organized so that changes can be easily
implemented.
78
Requirements change management

79
Key points

• Requirements for a software system set out what the system should
do and define constraints on its operation and implementation.

• Functional requirements are statements of the services that the

system must provide or are descriptions of how some computations
must be carried out.

• Non-functional requirements often constrain the system being

developed and the development process being used.

• They often relate to the emergent properties of the system and

therefore apply to the system as a whole.

80
Key points
The requirements engineering process is an iterative process that includes
requirements elicitation, specification and validation.

Requirements elicitation is an iterative process that can be represented as a

spiral of activities – requirements discovery, requirements classification and
organization, requirements negotiation and requirements documentation.

You can use a range of techniques for requirements elicitation including

interviews and ethnography. User stories and scenarios may be used to
facilitate discussions.

81
Key points
Requirements specification is the process of formally documenting
the user and system requirements and creating a software
requirements document.

The software requirements document is an agreed statement of

the system requirements. It should be organized so that both
system customers and software developers can use it.

82
Key points
Requirements validation is the process of checking the
requirements for validity, consistency, completeness, realism and
verifiability.

Business, organizational and technical changes inevitably lead to

changes to the requirements for a software system. Requirements
management is the process of managing and controlling these
changes.

83
Software Project Effort
and Cost Estimation
 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.
Function point count for effort estimate (function point
analysis technique)
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 Pricing
• Estimates are made to discover the cost, to the developer, of producing a
software system.

• You take into account, hardware, software, travel, training and effort costs.

• There is not a simple relationship between the development cost and the price
charged to the customer.

• Broader organisational, economic, political and business considerations

influence the price charged.
Factors affecting Software
Pricing
Factor Description

A customer may be willing to allow the developer to retain ownership

of the source code and reuse it in other projects. The price charged
Contractual terms
may then be less than if the software source code is handed over to
the customer.
If an organization is unsure of its cost estimate, it may increase its
Cost estimate uncertainty
price by a contingency over and above its normal profit.
Developers in financial difficulty may lower their price to gain a
contract. It is better to make a smaller than normal profit or break
Financial health
even than to go out of business. Cash flow is more important than
profit in difficult economic times.
A development organization may quote a low price because it wishes
to move into a new segment of the software market. Accepting a low
Market opportunity profit on one project may give the organization the opportunity to
make a greater profit later. The experience gained may also help it
develop new products.

If the requirements are likely to change, an organization may lower

Requirements volatility its price to win a contract. After the contract is awarded, high prices
can be charged for changes to the requirements.
 Software Pricing

• Pricing Strategies

• Under pricing

• A company may under price a system in order to gain a contract that allows
them to retain staff for future opportunities

• A company may under price a system to gain access to a new market area

• Increased pricing

• The price may be increased when a buyer wishes a fixed-price contract and
so the seller increases the price to allow for unexpected risks
 Pricing to Win
• The software is priced according to what the software developer believes the
buyer is willing to pay.

• If this is less that the development costs, the software functionality may be
reduced accordingly with a view to extra functionality being added in a later
release.

• Additional costs may be added as the requirements change and these may be
priced at a higher level to make up the shortfall in the original price.
 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”

103
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
 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

105
Weights of 5 Functional Point Attributes
• 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,600 and the
estimated effort is 54 person-months.
 Software Project Effort and Cost Estimation - Techniques
Conventional Methods – LOC/FP Approach
Example: FP
Approach

109
• The estimated number of FP is derived:
• FPestimated = count-total * [0.65 + 0.01 * 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,250 and estimated effort
is 58 person-months.
Software Project Effort and Cost Estimation - Techniques
Process Based Estimation

Obtained from “process

framework”

Framework activities

Applicatio Effort required to

n accomplish
functions each framework activity
for each application
function

111
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.
112
Software Project Effort and Cost Estimation - Techniques
Tool Based Estimation

Project Characteristics

Calibration Factors

LOC/FP data

113
 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.

114
 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

115
 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

116
 COCOMO - I
• Equation & Example

118
 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??

119
 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.

120
• 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.
 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

123
• 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 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.
125
 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.

127
 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

128