Unit -2

Software Project Management

P Sindhu Ruth
Asst.professor©
CSE Dept
 contents
• Introduction
• Planning
 Introduction
• Software Project Management is a proper way
of planning and leading software.
• It is a part of project management in which
software projects are planned, implemented,
monitored and controlled.
 Contd…
Need of SPM:
• Software is an non physical product, software
development is a new stream in business and
there is very little experience in building software
product.
• Most of the software products are made to fit
clients requirements.
• The most important is that the basic technology
changes and advances so frequently and rapidly
that experience of one product may not be
applied to the other one.
 Contd…
• It is necessary for an organization to deliver
quality product , keeping the cost within
clients budget constrain and deliver the
project as per scheduled.
• Hence In order software project management
is necessary to incorporate user requirements
along with budget and time constraints.
 Aspects of SPM
Planning
Execution
Monitoring
Control
 Advantages of SPM
• It helps in planning of software development
• Implementation of software development in
made easy
• Monitoring and controlling are aspects of
software project management
• It overall manages to save time and cost for
software development.
 Project Management Essentials

• Project Management is an integrated environment where various entities

are interconnected and performed together to produce a quality software
product.
• There are four essential elements of effective software project Management
• They are
 Project
 People
 Process
 Product
• Effective Software Project Management focuses on these elements to fulfill
the customer needs.
People Process

Software
Project
Manage
ment

Product Project

Fig: Software Project

Management
 Contd…
• Project:
A Project is a temporary endeavor with defined starting and ending deadlines, roles and
responsibilities, conditions, budgets, and plans, undertaken to accomplish aim and
objectives.

• Process:
A Software process describes the characteristics and organization of activities order to
produce software. Software process applied in a project to produce a product.

• Product:
A Product is a final outcomes of a project. It is produced with an effective Project
Management Process. The project manager must determine the requirements and
expected outcomes at the begin.
 Contd…
People:
• The people involved in software project management are the key assets. People in a
project are those who are either involved in or are affected by the project.
• The following are the various categories of people involved in an effective software
project management.
 Senior managers
 Project managers
 Programmers
 Support Staff
 Customers
 End-users
 Project Sponsors
 Competitors
 Suppliers
• What is Project Management?

 Why Do Project Failures Occur?

 Keys to project success.

 Why Do Project failures Occur?

• Software Projects frequently fail. Many Stakeholders, consultants, project managers and
practitioners have provide their experiences about the causes of project failures.
• However, following are some common factors that may lead to project failures.
 Inability to clearly understand customer needs.
 Lack of user involvement.
 Unrealistic expectations.
 Lack of top management support
 Incomplete requirements and specifications
 Lack of resources (Hardware, Software, People).
 Lack of good planning.
 Technical incompetence.
 Lack of best practices
 The chosen technology changes.
 Lack of communication among team members.
 Changes are managed poorly.
 Changing business needs and requirements.
 Keys to Project Success
• Project success must be the ultimate goal of project managers to fulfill the customer
needs.
• There are various factors that help in project success.
 Strong support from the top management
 A Sound methodology for the project.
 User involvement in each activity
 Experienced project manager
 Clearly defined business goals
 Clearly defined project scope.
 Feedback mechanism
 Sufficient resource allocation
 Troubleshooting capabilities.
 Project Planning

 Once a project has been found to be feasible, software project

managers undertake project planning.
 Project planning requires at most care and attention since
commitment to unrealistic time and resource estimates result in
scheduling slipping.
 Schedule delays can cause customer dissatisfaction and adversely
affect team morale.
 During project planning the project managers performs the
following activities.
 Contd…
• Note that we have given only a very brief description of the activities.
• Estimation: The following project attributes are estimated.
• Cost: How much is it going to cost to develop the software product?
• Duration: How long is it going to take to develop the product?
• Effort: How much effort would be necessary to develop the product?
• The effectiveness of all later planning activities such as scheduling and staffing are
dependent on the accuracy with which these three estimations have been made.
• Scheduling: After all the necessary project parameters have been estimated, the
schedules for manpower and other resources are developed.
• Staffing: Staff organization and staffing plans are made.
• Risk management: This includes risk identification, analysis and abatement planning.
 Contd…
• Miscellaneous plans: This includes making several other plans such as
quality assurance plan, and configuration management plan, etc.

• From the figure it shows the order in which the planning activities are
undertaken.
• Based on the size estimation, the effort required to complete a project and
the duration over which the development is to be carried out are estimated.
• Based on the effort estimation, the cost of the project is computed. The
estimated cost forms the basis on which price negotiations with the
customer is carried out.
 Effort Cost
Estimation Estimation

Size
Estimation

Duration Project
Scheduling
Estimation Staffing

Fig: Precedence ordering among planning

activities.
 Sliding Window Planning
 It is usually very difficult to make accurate plans for large projects as project initiation. A part of the

difficulty a raises from the fact that large projects may take several years to complete.

 As a result , during the span of the project, the project parameters scope of the project, project staff,

etc. Often change drastically resulting in the initial plans going haywire.

 Planning a project over a number of stages protects managers from making big commitments at the

start of the project.

 This technique of staggered planning is known as sliding window planning.

 The project parameters are re-estimated periodically as understanding grows and also a periodically

as project parameters change.

 Contd…
 In the sliding window planning technique, starting with an initial plan, the
project is planned more accurately over a number of stages.
 At the start of a project, the project manager has incomplete knowledge
about the nitty-gitty of the project.
 His information base gradually improves as the project progresses through
different development phases.
 The complexities of different project activities become clear, some of the
anticipated risks get resolved, and new risks appear.
 The project parameters are re-estimated periodically as understanding
grows and also a periodically as project parameters change.
SPMP Document of Project Planning

• Once the project planning is complete, project managers document their

plans in a software project management plan(SPMP) document.
• List below are the different items that the SPMP document should discuss.
This list can be used as a possible organization of the SPMP document.
• Organization of the software project management plan (SPMP)
document:
1. Introduction:
a) Objectives
b) Major functions
c) Performance issues
d) Management and technical Constraints.
 Contd…
• . Project Estimates:
a) Historical Data Used
b) Estimation Techniques Used
c) Effect, Resources, Cost and Project Duration estimates.

• 3. Schedule:
a) Work Breakdown structure
b) Task Network Representation
c) Gantt Chart Representation
d) PERT Chart Representation

• 4. Project Resources:
a) People
b) Hardware and Software
c) Special Resources
 Contd…
• 5. Staff Organization:
a) Team Structure
b) Management Reporting

• 6. Risk Management Plan:

a) Risk Analysis
b) Risk Identification
c) Risk Estimation
d) Risk Abatement Procedures

• 7. Project tracking and control plan:

a) Metrics to be traced
b) Tracking Plan
c) Control Plan
 Contd…
• 8. Miscellaneous Plans:
a) Process Tailoring

b) Quality Assurance plan

c) Configuration Management Plan

d) Validation and verification

e) System Testing Plan

f) Delivery, Installation and Maintenance Plan

Thank You…
 Unit -2
Software Project Management
P Sindhu Ruth
Asst.professor©
CSE Dept
 Contents
• Metrics for project size Estimation
• Project Estimation Techniques
• Empirical Estimation Techniques
• COCOMO-A Heuristic Estimation Techniques
Metrics for project size Estimation
• Estimation of size of software is an essential part of Software
Project Management. It helps the project manger to further predict
time and effort which will be needed to build the project.

• Various measures are used in project estimation. Some of these are:

a) Lines of Code(LOC)

b) Number of entities in ER diagram

c) Total number of processes in detailed data flow diagram

d) Function points(FP)
 Contd…
• Lines of Code (LOC):
• As the name suggests, LOC counts the total number of lines of
source code in project. The units of LOC are:
 KLOC: Thousand lines of source code.
 NLOC: Non comment lines of code.
 KDSI: Thousands of delivered source instructions.
• The size is estimated by comparing it with existing systems of same
kind. The experts use it to predict the required size of various
components of software and then add them to get the total size.
 Contd…
• Advantages:
a) Universally accepted and is used in many models like COCOMO.
b) Estimation is closer to developer’s perspective.
c) Simple to use.

• Disadvantages:
a) Different Programming languages contains different number of lines.
b) No proper industry standard exist for this technique.
c) It is difficult to estimate the size using this technique in early stages of
project.
 Contd…
Number of Entities in ER diagram:
• ER Model provides a static view of the project. It describes the entities and
its relationships. The number of entities in ER model can be used to
measure the estimation of size of project. Number of entities depend on the
size of the project. This is because more entities needed more classes or
structures thus leading to more coding.

• Advantages:
 Size estimation can be done during initial stages of planning.
 Number of entities is independent of programming technologies used.
 Contd…
• Disadvantages:
No fixed standard exist. Some entities
contribute more project size than others.

Just like FPA, it is less used in cost estimation

model. Hence, it must be converted to LOC
 Contd…
Total number of processes in detailed data flow diagram:
• Data Flow Diagram(DFD) represents the functional view of a software. The model
depicts the main processes or functions involved in software and flow of data
between them. Utilization of number of functions in DFD to predict software size.
Already existing processes of similar type are studied and used to estimate the size
of the process. Sum of the estimated size of each process gives the final estimated
size.
• Advantages:
 It is independent of programming language.
 Each major processes can be decomposed into smaller processes. This will increase
the accuracy of estimation.
 Contd…
• Disadvantages:
Studying similar kind of processes to estimate
size takes additional time and effort.

All software projects are not required to

construction of DFD.
 Contd…
Function Point Analysis:
• In this method, the number and type of functions supported by the
software are utilized to find FPC(Function Point Count). The steps
in function point analysis are:
 Count the number of functions of each proposed type.
 Compute the unadjusted Function Points(UFP)
 Find Total Degree of Influence(TDI)
 Compute Value Adjustment Factor(VAF)
 Find the Function Point Count(FPC)
 Contd…
Count the number of functions of each proposed type:
• Find the number of functions belonging to the following types:
 External inputs: Functions related to data entering the system.
 External Outputs: Functions related to data existing system.
 External Inquires: They leads to data retrieval from system but don’t
change the system.
 Internal Files: Logical files maintained within the system. Log files are
not included here.
 External Interface Files: These are logical files for other applications
which are used by our system.
Compute the unadjusted Function Points(UFP):
• Categories each of the five function types as simple, average
or complex based on their complexity.
Multiply count of each function type with its weighting factor and
find the weighted sum.
The weighting factors for each type based on their complexity are
as follows:
Function Type Simple Average Complex
External Inputs 3 4 6
External 4 5 7
Outputs
External 3 4 6
Inquiries
Internal Logical 7 10 15
Files
External 5 7 10
Interface Files
 Contd…
Find Total Degree of Influence:
• Use the 14 general characteristics of a system to find the degree of
influence of each of them.
• The sum of all 14 degrees of influences will give the TDI.
• The range of TDI is 0 to 70.
• The 14 general characteristics are:
 Data Communications
 Distributed Data processing
 Performance
 Contd…
 Heavily Used Configuration
 Transaction Rate,
 On-Line Data Entry
 End-User Efficiency
 Online Update
 Complex Processing
 Reusability
 Installation Ease
 Operational Ease
 Multiple Sites
 Facilitate Change
 Contd…

• Each of the above characteristics is evaluated

on a scale of 0-5
 Contd…
Compute Value Adjustment Factor(VAF):
• Use the following formula to calculate VAF
• VAF=(TDI*0.01)+0.65

Find the Function Point Count(FPC):

• Use the following formula to calculate FPC
• FPC=UFP*VAF
 Contd…
• Advantages:
 It can be easily used in the early stages of Project Planning.
 It is independing on the Programming language.
 It can be used to compare different projects even if they use
different technologies(database, language, etc)
• Disadvantages:
 It is not good for real time systems and embedded systems.
 Many cost estimation models like COCOMO uses LOC and hence
FPC must be converted to LOC
 Project Estimation Techniques

 Estimation of various project parameters is an important project planning

activity
 The different parameters of a project that need to be estimated include project
size, effort required to complete the project, project duration and cost.
 A large number of estimation techniques have been proposed by researchers.
 They can broadly be classified into three main categories.
a) Empirical estimation techniques.
b) Heuristic technique
c) Analytical estimation techniques.
 Empirical Estimation Techniques

 Empirical estimation techniques are essentially based on making an

educated guess of the project parameters.
 While using this technique, prior experience with development of similar
products is helpful.
 Although empirical estimation techniques are based on commonsense and
subjective decisions, over the years, the different activities involved in
estimation have been formalized to a large extent.
 We shall discuss two such formalizations of the basic empirical estimation
techniques known as Expert Judgement and Delphi Techniques.
 Contd…
Expert Judgement:
• Expert judgement is a widely used size estimation technique. In
this technique, an expert makes an educated guess about the
problem size after analyzing the problem thoroughly.
• Usually, the expert estimates the cost of the different
components(i.e modules or subsystems) that would makeup the
system and then combines the estimates for individual modules
to arrive at the overall estimate.
 Contd…
• The outcome of the expert judgement technique is
subject to human errors and individual bias.
• Eg: He may be conversant with database and user
interface parts, but may not be very knowledgeable
about the communication part. Due to these factors, the
size estimation arrived at by the judgement of a single
expert may be far from being accurate
 Contd…
Delphi Cost Estimation:
• Delphi cost estimation technique tries to overcome some of the shortcomings of the
expert judgement approach. Delphi estimation is carried out by a team comprising a
group of experts and a coordinator.
• In this approach , the coordinator provides each estimator with a copy of the
software requirements specifications(SRS) document and a form for recording his
cost estimate. Estimators complete their individual estimates anonymously and
submit them to the co-Ordinator.
• The coordinator prepares the summary of the responses of all the estimators, and
also includes any unusual rationale noted by any of the estimators. The prepared
summary information is distributed to the estimators.
 Contd…
• Based on this summary, the estimators re-estimate. This process is
iterated for several rounds.
• After the completion of several iterations of estimations, the
coordinator takes the responsibility of compiling the results and
preparing the final estimate.
• The Delphi estimation, though consumes more time and effort,
overcomes an important shortcoming of the expert judgement
technique in that the results can not unjustly be influenced by overly
assertive and senior members.
 Heuristic Techniques

• Heuristic techniques assume that the relationships that exist among the
different project parameters can be satisfactorily modelled using suitable
mathematical expressions. Once the basic(independent) parameters are
known, the other(dependent) parameters can be easily determined by
substituting the values of the independent parameters in the corresponding
mathematical expression.
• Different heuristic estimation models can be divided into the following two
broad categories
a) Single Variable
b) Multivariable models.
 Single Variable

• Single variable estimation models assume that various project characteristic can be
predicted based on a single previously estimated basic(independent) characteristic
of the software such as its size.
• A single variable estimation model assumes that the relationship between a
parameter to be estimated and the corresponding independent parameter can be
characterized by an expression of the following form:
• Estimated Parameter=𝐶1 ∗ 𝑒 𝑑1
• In the above expression, e represents a characteristic of the software that has
already been estimated(independent variable).Estimated Parameter is the dependent
Parameter(to be estimated) .
 Contd…
• The dependent parameter to be estimated could be effort,
project duration, staff size, etc.., c1 and d1 are constants.
• The values of the constants c1 and d1 are usually
determined using collected from past projects(historical
data).
• The COCOMO Model discussed in coming slides and is an
example of single variable cost estimation model.
 COCOMO

• Constructive Cost Estimation Model (COCOMO) was proposed by Boehm(1981).

• COCOMO prescribes a three process for project estimation.
• In first stage, an initial estimate is arrived at. Over the next two stages, the initial
estimate is refined to arrive at a more accurate estimate.
• COCOMO uses both single and multivariable estimation models at different stages of
estimation.
• The three stages of COCOMO estimation technique are
a) Basic COCOMO
b) Intermediate COCOMO
c) Complete COCOMO
 Contd…
Basic COCOMO Model:
• Boehm postulated that any software development project can be classified
into one of the following three categories based on the development
complexity.
a) Organic
b) Semidetached
c) Embedded
• Based on the category of a software development project, he gave different
sets of formulas to estimate the effort and duration from the size estimate.
 Contd…
Organic:
• We can classify a development project to be of organic type, if the project
deals with developing a well-understood application program, the size of
the development team is reasonably small, and the team members are
experienced in developing similar types of projects.

Semidetached:
• A development project can be classify to be of semidetached type, if the
development team consists of a mixture of experienced and inexperienced
staff. Team members may have limited experience on related systems but
may be unfamiliar with some aspects of the system being developed.
 Embedded

• A development project is considered to be of embedded type, if the

software being developed is strongly coupled to hardware, or if stringent
regulations on the operational procedures exist. Team members may have
limited experience on related systems but may be unfamiliar with aspects
of the system being developed.

• For the three product categories, Boehm provides different sets of

expressions to predict the effort(in units of person-months) and
development time from the size estimation given in kilo lines of source
code (KLSC). But, how much effort is one person-month?
 Contd…
• One person month is the effort an individual can typically put in a month. The
person-month estimate implicitly takes into account the productivity losses that
normally occur due to time lost in holidays, week offs, coffee breaks, etc.
What is a person-month?
• Person-month(PM) is a popular unit for effort measurement.
• Person-Month(PM) is considered to be an appropriate unit for measuring effort,
because developers are typically assigned to a project for a certain number of
months.
General form of the COCOMO expressions
• The basic COCOMO model is a single variable heuristic model that gives an
approximate estimate of the project parameters. The basic COCOMO estimation
model is given by expressions of the following forms:
 Contd…
Effort=𝑎1 ∗ (𝐾𝐿𝑂𝐶)𝑎2 PM
Tdev= 𝑏1 ∗ (𝐸𝑓𝑓𝑜𝑟𝑡)𝑏2 months
Where,
 KLOC is the estimated size of the software product expressed in Kilo Lines
Of Code.
 a1 , a2, b1, b2 are constants for each category of software product.
 Tdev is the estimated time to develop the software, expressed in months.
 Effort is the total effort required to develop the software product, expressed
in person-months(PMs)
Heuristic estimation techniques – Basic COCOMO
Organic :
• Effort = 2.4(KLOC)1.05 PM
• Tdev = 2.5(Effort)0.38 Months
Semi-detached :
• Effort = 3.0(KLOC)1.12 PM
• Tdev = 2.5(Effort)0.35 Months
Embedded :
• Effort = 3.6(KLOC)1.20 PM
• Tdev = 2.5(Effort)0.32 Months
class a1 a2 b1 b2
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
 Contd….
A multivariable cost Estimation Model:
• A multivariable cost estimation model assumes that a parameter can be predicted
based on the values of more than one independent parameter. It takes the following
form.

• Estimated Resource= 𝑐1 ∗ 𝑝1 𝑑1 +𝑐2 ∗ 𝑝2 𝑑2 +….

• Where p1,p2,…. are the basic(independent) characteristics of the software already

estimated, and c1, c2, d1, d2, …….. are constants.

• Multivariable estimation models are expected to give more accurate estimates

compared to the single variable models, since a project parameter is typically
influenced by the several independent parameters.

• Example of a multivariable cost estimation model is Intermediate COCOMO

Model.
Intermediate COCOMO Model
• Intermediate COCOMO model is an extension of the Basic COCOMO
model which includes a set of cost drivers into account in order to
enhance more accuracy to the cost estimation model as a result. The
estimation model makes use of a set of “cost driver attributes” to compute
the cost of the software . The estimated effort and scheduled time are
given by the relationship:
Effort (E) = a*(KLOC)b *EAF PM
D = c x (Effort)d
Where,
• E = Total effort required for the project in Person-Months (MM).
KLOC = The size of the code for the project in Kilo lines of code.
a, b = The constant parameters for the software project.
• EAF = It is an Effort Adjustment Factor, which is calculated by multiplying
the parameter values of different cost driver parameters. For ideal, the
value is 1.
Classification of Cost Drivers and their attributes:
Product attributes
• Required software reliability extent
• Size of the application database
• The complexity of the product
Hardware attributes
• Run-time performance constraints
• Memory constraints
• The volatility of the virtual machine environment
• Required turnabout time
Personal attributes –
• Analyst capability
• Software engineering capability
• Applications experience
• Virtual machine experience
• Programming language experience
Project attributes
• Use of software tools
• Application of software engineering methods
• Required development schedule
Example: For a given project was estimated with a size of 300 KLOC.
Calculate the Effort, Scheduled time for development by considering
the developer having high application experience and very low
experience in programming.
Solution –
• Given the estimated size of the project is: 300 KLOC
Developer having highly application experience: 0.82 (as per above
table)
Developer having very low experience in programming: 1.14(as per
above table)
• EAF = 0.821.14 = 0.9348 Effort (E) = a(KLOC)b EAF = 3.0(300)1.12
0.9348 = 1668.07 MM
Scheduled Time (D) = c(E)d = 2.5*(1668.07)0.35 = 33.55 Months(M)
Detailed/Advanced COCOMO model
• The model incorporates all qualities of both Basic COCOMO and
Intermediate COCOMO strategies on each software engineering
process.
• The model accounts for the influence of the individual development
phase (analysis, design, etc.) of the project.
• it uses multipliers for each phase of the project .it is a complex
mode.it includes more factors that influence the software projects
and give more accurate estimations.
• In this, the whole software is divided into different modules and
then we apply COCOMO in different modules to estimate effort and
then sum the effort. For instance, detailed COCOMO will perform
cost estimation in each development phase of the Waterfall Model-
The Six phases of detailed COCOMO are:
• Planning and requirements
• System design
• Detailed design
• Module code and test
• Integration and test
• Cost Constructive model
In the Detailed COCOMO Model, the cost of each
subsystem is estimated separately. This approach
reduces the margin of error in the final estimate.
Advantages of COCOMO Model
• COCOMO is transparent, one can see how it works unlike
other models such as SLIM
• Drivers are particularly helpful to the estimator to
understand the impact of different factors that affect
project costs.
• COCOMO Provides ideas about historical projects.
• The COCOMO model is easy to estimate the total cost of
the project.
• The drivers are very helpful to understand the impact of
the different factors that affect project crises.
Limitations of COCOMO Model
• It is hard to estimate KDSI early on in the project when
most effort estimates are required.
• KDSI, actually, is not a size measure, it is a length
measurement.
• Extremely vulnerable to misclassification of the
development mode.
• Success depends largely on tuning the model to the needs
of the organization, using historical data which is not always
available.
• It limits the accuracy of software costs.
• It also ignores customer skills, cooperation, and knowledge.
 Analytical Estimation Technique
Analytical estimation is a type of technique that is used to measure
work. In this technique, firstly the task is divided or broken down into
its basic component operations or elements for analyzing.
Second, if the standard time is available from some other source, then
these sources are applied to each element or component of work.
Third, if there is no such time available, then the work is estimated
based on the experience of the work. In this technique, results are
derived by making certain basic assumptions about the project. Hence,
the analytical estimation technique has some scientific basis.
Halstead’s software science is based on an analytical estimation
model.
• Analytical techniques – Halstead’s Software Science -
The following is a suggested list of operators for the
ANSI C language:
( [ . , -> * + - ~ ! ++ -- * / % + - << >> < > <= >= != == & ^ |
&& || = *= /= %= += -= <<= >>= &= ^= |= : ? { ; CASE
DEFAULT IF ELSE SWITCH WHILE DO FOR GOTO
CONTINUE BREAK RETURN and a function name in a
function call.
• Operands are those variables and constants which are
being used with operators in expressions. Note that
variable names appearing in declarations are not
considered as operands
• Analytical techniques – Halstead’s Software
Science –
• Program length (N): N = N1 + N2
• Program vocabulary (h): h = h1 + h2
• Program volume (V): V = N log2 h
• Potential minimum volume (V*): The volume of
the most succinct program in which a problem
can be coded.
V* = (2 + h2) log2 (2 + h2)
Analytical techniques – Halstead’s Software
Science
Program level (L): L = V*/V
Programmer’s Effort (E): E = V /L ⇒ E = V2/V*
(since L = V*/V)
Programmer’s time (T): T = E/S
Where S is the speed of mental discriminations.
Recommended value for programming
applications is 18
 Unit-2
Software Requirements &
Specifications
P Sindhu Ruth
Asst.professor©
CSE Dept
 Content
• Gathering
• Analysis
• Specification
• Characteristics
• Organization
 Requirement Gathering
• Requirement gathering activity also known as
requirements elicitation.
• Primary objective: Collecting requirements
from stakeholders
 Contd..
Different ways to gather the requirements: -
• Studying existing documentation.
• Task analysis.
• Scenario analysis.
• Form analysis
• Interviews:
– Delphi method – Analyst consolidates and documents
all the requirements according to understanding.
Circulate it all, gather the feedback from them and
refine the document. The process is repeated until the
users are satisfied.
 Analysis
Purpose: To analyze the gathered required
requirements to remove
• Ambiguity
• Incompleteness
• Inconsistencies
and obtain the clear understanding of software
to be developed
 Contd..
Basic question to carry out the analysis:
• What is the problem?
• Why is it important to solve the problem? –
• What exactly are the data inputs and data output of the
system?
• What are the possible procedures that need to be followed
to solve the problem?
• What are the likely complexities that might arise while
solving the problem?
• If there are external software or hardware with which the
developed software has to interface, then what should be
the data interchange formats with the external systems?
 Contd…
Major problems in the requirements:
• Anomaly.
– - It is an ambiguity in the requirement.
– - Ambiguity may leads to several interpretations.
– - Anomaly can lead to the incorrect development
of software.
• Inconsistency.
– - We can say two requirements are inconsistent if
one of the requirement contradicts other
 Contd…
• Incompleteness
– - Lack of requirements. - It is caused by the
inability of the customer to visualize the system
that is to be developed and to anticipate the all
the features that would be required
 Requirements Specification
• In SRS document, the analyst systematically
organizes the requirements.
• SRS documents contains all the user
requirements in a structured through an
informal form.
• In entire SDLC among other documents
writing SRS is difficult because it need to cater
various users
 Contd…
• Users of SRS document —
– End users, customers, marketing persons.
– Software developers.
– Test engineers.
– User documentation writers.
– Project managers.
– Maintenance engineers
 Contd…
Uses of SRS document
• Forms an agreement between the customers and
the developers.
• Reduces future reworks.
• Provides a basis for estimating costs and
schedules.
• Provides a baseline for validation and
verification.
• Facilitates future extensions
 Characteristics of SRS

• Correctness:
User review is used to ensure the correctness of requirements
stated in the SRS. SRS is said to be correct if it covers all the
requirements that are actually expected from the system.
• Completeness:
Completeness of SRS indicates every sense of completion including
the numbering of all the pages, resolving the to be determined
parts to as much extent as possible as well as covering all the
functional and non-functional requirements properly.
• Consistency:
Requirements in SRS are said to be consistent if there are no
conflicts between any set of requirements. Examples of conflict
include differences in terminologies used at separate places, logical
conflicts like time period of report generation, etc.
 Contd..
• Unambiguousness:
A SRS is said to be unambiguous if all the requirements
stated have only 1 interpretation. Some of the ways to
prevent unambiguousness include the use of modelling
techniques like ER diagrams, proper reviews and buddy
checks, etc.
• Ranking for importance and stability:
There should a criterion to classify the requirements as
less or more important or more specifically as desirable
or essential. An identifier mark can be used with every
requirement to indicate its rank or stability.
 Contd..
• Modifiability:
SRS should be made as modifiable as possible and should be capable of
easily accepting changes to the system to some extent. Modifications
should be properly indexed and cross-referenced.
• Verifiability:
A SRS is verifiable if there exists a specific technique to quantifiably
measure the extent to which every requirement is met by the system. For
example, a requirement starting that the system must be user-friendly is
not verifiable and listing such requirements should be avoided.
• Traceability:
One should be able to trace a requirement to design component and then
to code segment in the program. Similarly, one should be able to trace a
requirement to the corresponding test cases.
• Design Independence:
There should be an option to choose from multiple design alternatives for
the final system. More specifically, the SRS should not include any
implementation details.
 Contd..
• Testability:
A SRS should be written in such a way that it is easy to
generate test cases and test plans from the document.
• Understandable by the customer:
An end user maybe an expert in his/her specific domain but
might not be an expert in computer science. Hence, the use
of formal notations and symbols should be avoided to as
much extent as possible. The language should be kept easy
and clear.
• Right level of abstraction:
If the SRS is written for the requirements phase, the details
should be explained explicitly. Whereas, for a feasibility
study, fewer details can be used. Hence, the level of
abstraction varies according to the purpose of the SRS.
 Contd..
Attributes of bad SRS document
• Over specification.
• Forward references.
• Wishful thinking.
• Noise
 Contd..
Important Categories of Customer Requirements
• Functional requirements.
• Non functional requirements.
– Design and implementation constraints.
– External interfaces required.
– Other non-functional requirements.
• Goals of implementation.
 Organization
In order to form a good SRS, here you will see some points which can
be used and should be considered to form a structure of good SRS.
These are as follows :
1. Introduction
– (i) Purpose of this document
– (ii) Scope of this document
– (iii) Overview
2. General description
3. Functional Requirements
4. Interface Requirements
5. Performance Requirements
6. Design Constraints
7. Non-Functional Attributes
8. Preliminary Schedule and Budget
9. Appendices
 Contd..
• Introduction :
– (i) Purpose of this Document –
At first, main aim of why this document is necessary and what’s
purpose of document is explained and described.
– (ii) Scope of this document –
In this, overall working and main objective of document and
what value it will provide to customer is described and
explained. It also includes a description of development cost
and time required.
– (iii) Overview –
In this, description of product is explained. It’s simply summary
or overall review of product.
 Contd..

• General description :
In this, general functions of product which includes
objective of user, a user characteristic, features,
benefits, about why its importance is mentioned. It
also describes features of user community.
• Functional Requirements :
In this, possible outcome of software system which
includes effects due to operation of program is fully
explained. All functional requirements which may
include calculations, data processing, etc. are placed in
a ranked order.
 Contd..
• Interface Requirements :
In this, software interfaces which mean how software program communicates with
each other or users either in form of any language, code, or message are fully
described and explained. Examples can be shared memory, data streams, etc.

• Performance Requirements :
In this, how a software system performs desired functions under specific condition
is explained. It also explains required time, required memory, maximum error rate,
etc.

• Design Constraints :
In this, constraints which simply means limitation or restriction are specified and
explained for design team. Examples may include use of a particular algorithm,
hardware and software limitations, etc.
 Contd..
• Non-Functional Attributes :
In this, non-functional attributes are explained that are required by
software system for better performance. An example may include Security,
Portability, Reliability, Reusability, Application compatibility, Data integrity,
Scalability capacity, etc.

• Preliminary Schedule and Budget :

In this, initial version and budget of project plan are explained which
include overall time duration required and overall cost required for
development of project.

• Appendices :
In this, additional information like references from where information is
gathered, definitions of some specific terms, acronyms, abbreviations, etc.
are given and explained.
THANK YOU….