Unit II

Software Project Management:- Responsibilities of a Software Project Manager – Project

Planning- Project Estimation Techniques-Risk Management. Requirements Analysis and
Specification:- Requirements Gathering and Analysis – Software Requirements
Specifications (SRS):Users of SRS Document – Characteristics of a Good SRS Document –
Important Categories of Customer Requirements – Functional Requirements – How to
Identify the Functional Requirements? –Organisation of the SRS Document.

Software Project Management

Effective project management is crucial to the success of any software development
project. In the past, several projects have failed not for want of competent
technical professionals neither for lack of resources, but due to the use of faulty
project management practices. Therefore, it is important to carefully learn the latest
software project management techniques.

Software project management is a very vast topic. Let us first understand what exactly
is the principal goal of software projectmanagement.

The main goal of software project management is to enable a group of developers to

work effectively towards the successful completion of a project.
Project management involves use of a set of techniques and skills to steer a project to
success. First consider who should be responsible for managing a project.

A project manager is usually an experienced member of the team who essentially

works as the administrative leader of the team. For small software development projects,
a single member of the team assumes the responsibilities for both project management
and technical management.

For large projects, a different member of the team (other than the project manager)
assumes the responsibility of technical leadership. The responsibilities of the technical
leader includes addressing issues such as which tools and techniques to use in the
project, high-level solution to the problem, specific algorithms to use, etc.
First investigate why management of software projects is much more complex than
managing many other types of projects.

SOFTWARE PROJECT MANAGEMENTCOMPLEXITIES

Management of software projects is much more complex than management of many

other types of projects. The main factors contributing to the complexity of
managing a software project are:
Invisibility: Software remains invisible, until its development is complete and it is
operational. Anything that is invisible,is difficult to manage and control.

Changeability: Because the software part of any system is easier to change as

compared to the hardware part, the software part is the one that gets most frequently
changed.

These changes usually arise from changes to the business practices, changes to the
hardware or underlying software (e.g. operating system, other applications), or just
because the client changes hismind.

Complexity: Even a moderate sized software has millions of parts (functions) that
interact with each other in many ways—data coupling, serial and concurrent runs, state
transitions, control dependency, file sharing, etc. Due to the inherent complexity of the
functioning of a software product in terms of the basic parts making up the software,
many types of risks are associated with its development. This makes managing these
projects much more difficult as compared to many other kinds of projects.

Uniqueness: Every software project is usually associated with many unique features or
situations. This makes every project much different from the others. A software project
manager has to confront many unanticipated issues in almost every project that
hemanages.

Exactness of the solution: Mechanical components such as nuts and bolts typically
work satisfactorily as long as they are within a tolerance of 1 per cent or so of their
specified sizes. However, the parameters of a function call in a program are required to be
in complete conformity with the function definition.

Team-oriented and intellect-intensive work: Software development projects are

similarto research projects in the sense that they both involve team-oriented, intellect-
intensive work. In contrast, projects in many domains are labour-intensive and each
member works in a high degree of autonomy.

RESPONSIBILITIES OF A SOFTWARE PROJECT MANAGER

Job Responsibilities for Managing SoftwareProjects

A software project manager takes the overall responsibility of steering a project to

success. It is very difficult to objectively describe the precise job responsibilities of a
project manager.

The job responsibilities of a project manager ranges from invisible activities like building
up of team morale to highly visible customer presentations. Most managers take the
responsibilities for project proposal writing, project cost estimation, scheduling, project
staffing, software process tailoring, project monitoring and control, software configuration
management, risk management, managerial report writing and presentation, and
interfacing with clients.

These activities are certainly numerous and varied. We can still broadly classify these
activities into two major types—project planning and project monitoring and control.

Project planning: Project planning is undertaken immediately after the feasibility study
phase and before the starting of the requirements analysis and specification phase.

Project planning involves estimating several characteristics of a project and then

planning the project activities based on these estimates made.
The initial project plans are revised from time to time as the project progresses and more
project data become available.
Project monitoring and control: Project monitoring and control activities are
undertaken once the development activities start.

The focus of project monitoring and control activities is to ensure that the software
development proceeds as per plan.
While carrying out project monitoring and control activities, a project manager may
sometimes find it necessary to change the plan to cope up with specific situations at hand.

Skills Necessary for Managing SoftwareProjects

A theoretical knowledge of various project management techniques is certainly important

to become a successful project manager.

However, a purely theoretical knowledge of various project management techniques

would hardly make one a successful project manager. Effective software project
management calls for good qualitative judgment and decision taking capabilities.

In addition to having a good grasp of the latest software project management techniques
such as cost estimation, risk management, and configuration management, etc., project
managers need good communication skills and the ability to get work done.

Some skills such as tracking and controlling the progress of the project, customer
interaction, managerial presentations, and team building are largely acquired through
experience.

Three skills that are most critical to successful project management are the following:
• Knowledge of project managementtechniques.
• Decision takingcapabilities.
• Previous experience in managing similarprojects.
PROJECT PLANNING

Once a project has been found to be feasible, software project managers undertake project
planning.

Project planning is undertaken and completed before any development activity starts.
Project planning requires utmost care and attention since commitment to unrealistic
time and resource estimates result in schedule slippage. Schedule delays can cause
customer dissatisfaction and adversely affect team morale. It can even cause project
failure.

For this reason, project planning is undertaken by the project managers with utmost
care and attention. For effective project planning, in addition to a thorough knowledge of
the various estimation techniques, past experience is crucial.

During project planning, the project manager performs the following activities. 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 organisation and staffing plans are made.

Risk management: This includes risk identification, analysis, and
abatement planning.

Miscellaneous plans: This includes making several other plans such as quality
assurance plan, and configuration management plan, etc.

Figure 3.1 shows the order in which the planning activities are undertaken. Observe that
size estimation is the first activity that a project manager undertakes during project
planning.

Size is the most fundamental parameter based on which all other estimations and
project plans are made.
 Figure 3.1: Precedence ordering among planning activities.

As can be seen from Figure 3.1, 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.

Other planning activities such as staffing, scheduling etc. are undertaken based on the
effort and duration estimates made.

METRICS FOR PROJECT SIZE ESTIMATION

Accurate estimation of project size is central to satisfactory estimation of all other

project parameters such as effort, completion time, and total project cost.

What does the term “project size” exactly mean. The size of a project is obviously
not the number of bytes that the source code occupies, neither is it the size of the
executable code.

The project size is a measure of the problem complexity in terms of the effort and time
required to develop the product.

Currently, two metrics are popularly being used to measure size—lines of code (LOC)
and function point (FP). Each of these metrics has its own advantages and disadvantages.

Lines of Code (LOC)

LOC is possibly the simplest among all metrics available to measure project size and
this metric is extremely popular. This metric measures the size of a project by
counting the number of source instructions in the developed program. While
counting the number of source instructions, comment lines, and header lines are
 ignored.

Determining the LOC count at the end of a project is very simple. However, accurate
estimation of LOC count at the beginning of a project is a very difficult task. One can
possibly estimate the LOC count at the starting of a project, only by using some form of
systematic guess work.

Systematic guessing involves the project manager divides the problem into modules,
and each module into sub-modules and so on, until the LOC of the leaf-level modules are
small enough to be predicted. To be able to predict the LOC count for the various leaf-
level modules sufficiently accurately, past experience in developing similar modules is very
helpful.

By adding the estimates for all leaf level modules together, project managers arrive at
the total size estimation. In spite of its conceptual simplicity, LOC metric has several
shortcomings when used to measure problem size.

LOC is a measure of coding activity alone: A good problem size measure should
consider the total effort needed to carry out various life cycle activities (i.e. specification,
design, code, test, etc.) and not just the coding effort. LOC, however, focuses on the
coding activity alone

LOC count depends on the choice of specific instructions: LOC gives a numerical
value of problem size that can vary widely with coding styles of individual programmers.

LOC measure correlates poorly with the quality and efficiency of the code:
Larger code size does not necessarily imply better quality of code or higher efficiency.
Some programmers produce lengthy and complicated code as they do not make effective
use of the available instruction set or use improper algorithms.

LOC metric penalises use of higher-level programming languages and code

reuse: A paradox is that if a programmer consciously uses several library routines, then
the LOC count will be lower.

Modern programming methods such as object-oriented programming and reuse of

components makes the relationships between LOC and other project attributes even less
precise.
LOC metric measures the lexical complexity of a program and does not address
the more important issues of logical and structural complexities: Between two
programs with equal LOC counts, a program incorporating complex logic would require
much more effort to develop than a program with very simple logic.

It is very difficult to accurately estimate LOC of the final program from

problem specification: At the project initiation time, it is a very difficult task to
accurately estimate the number of lines of code (LOC) that the program would have after
development. The LOC count can accurately be computed only after the code has fully
been developed.

Function Point (FP) Metric

This metric overcomes many of the shortcomings of the LOC metric. Function point
metric has several advantages over LOC metric. One of the important advantages
of the function point metric over the LOC metric is that it can easily be computed
from the problem specification itself.

The conceptual idea behind the function point metric is the following. The size of a
software product is directly dependent on the number of different high-level functions or
features it supports.

Each feature takes some effort to develop, different features may take very different
amounts of efforts to develop. This has been considered by the function point metric by
counting the number of input and output data items and the number of files accessed by
the function.

Figure 3.2: System function as a mapping of input data to output data.

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.

Accurate estimation of these parameters is important, since these not only help in
 quoting an appropriate project cost to the customer, but also form the basis for
resource planning and scheduling.

A large number of estimation techniques have been proposed by researchers. These

can broadly be classified into three main categories:
• Empirical estimation techniques
• Heuristic techniques
• Analytical estimation techniques
In the following subsections, we provide an overview of the different categories of
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.

Heuristic Techniques

Heuristic techniques assume that the relationships that exist among the different
project parameters can be satisfactorily modeled using suitable mathematical
expressions. Different heuristic estimation models can be divided into the following
two broad categories—single variable and multivariable models.

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 characterised by an expression of the following form:

Estimated Parameter = c1 *ed1

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). 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 data collected from past projects (historical data).

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 = c1 *p1d1 + c2 *p2d2 + ...

 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 several independent
parameters.

Analytical Estimation Techniques

Analytical estimation techniques derive the required results starting with certain basic
assumptions regarding a project.

RISK MANAGEMENT

Every project is susceptible to a large number of risks. Without effective management of

the risks, even the most meticulously planned project may go hay ware.

A risk is any anticipated unfavourable event or circumstance that can occur while a
project is underway.
We need to distinguish between a risk which is a problem that might occur from the
problems currently being faced by a project. If a risk becomes real, the anticipated
problem becomes a reality and is no more a risk. If a risk becomes real, it can adversely
affect the project and hamper the successful and timely completion of the project.

Therefore, it is necessary for the project manager to anticipate and identify different
risks that a project is susceptible to, so that contingency plans can be prepared
beforehand to contain each risk.

Risk management aims at reducing the chances of a risk becoming real as well as
reducing the impact of a risks that becomes real. Risk management consists of three
essential activities—risk identification, risk assessment, and risk mitigation.

Risk Identification

The project manager needs to anticipate the risks in a project as early as possible.
As soon as a risk is identified, effective risk management plans are made, so that
the possible impacts of the risks is minimised.

So, early risk identification is important. For example, project manager might be
worried whether the vendors whom you have asked to develop certain modules
might not complete their work in time, whether they would turn in poor quality
work, whether some of your key personnel might leave the organisation, etc. All
such risks that are likely to affect a project must be identified and listed.

A project can be subject to a large variety of risks. In order to be able to systematically

identify the important risks which might affect a project, it is necessary to categorise risks
into different classes. The project manager can then examine which risks from each class
are relevant to the project. There are three main categories of risks which can affect a
software project: project risks, technical risks, and business risks.

Project risks: Project risks concern various forms of budgetary, schedule, personnel,
resource, and customer-related problems. An important project risk is schedule slippage.
Since, software is intangible, it is very difficult to monitor and control a software project.

It is very difficult to control something which cannot be seen. The invisibility of the
product being developed is an important reason why many software projects suffer from
the risk of schedule slippage.

Technical risks: Technical risks concern potential design, implementation, interfacing,

testing, and maintenance problems. Technical risks also include ambiguous specification,
incomplete specification, changing specification, technical uncertainty, and technical
obsolescence. Most technical risks occur due the development team’s insufficient
knowledge about the product.

Business risks: This type of risks includes the risk of building an excellent product that
no one wants, losing budgetary commitments, etc.

Classification of risks in a project

Example: Let us consider a satellite based mobile communication product. The

project manager can identify several risks in this project.

What if the project cost escalates and overshoots what was estimated?: Project
risk.

What if the mobile phones that are developed become too bulky in size to
conveniently carry?: Business risk.

What if it is later found out that the level of radiation coming from the phones is
harmful to human being?: Business risk.

What if call hand-off between satellites becomes too difficult to

implement?: Technical risk.

Risk Assessment

The objective of risk assessment is to rank the risks in terms of their damage causing
potential. For risk assessment, first each risk should be rated in two ways:

The likelihood of a risk becoming real (r).

 The consequence of the problems associated with that risk (s).

Based on these two factors, the priority of each risk can be computed as follows:

p = r *s

where, p is the priority with which the risk must be handled, r is the probability of
the risk becoming real, and sis the severity of damage caused due to the risk
becoming real.

If all identified risks are prioritised, then the most likely and damaging risks can be
handled first and more comprehensive risk abatement procedures can be designed
for those risks.

Risk Mitigation (reduction)

After all the identified risks of a project have been assessed, plans are made to
contain the most damaging and the most likely risks first. Different types of risks
require different containment procedures.

There are three main strategies for risk containment:

Avoid the risk: Risks can be avoided in several ways. Risks often arise due to project
constraints and can be avoided by suitably modifying the constraints. The different
categories of constraints that usually give rise to risks are:

Process-related risk: These risks arise due to aggressive work schedule, budget, and
resource utilisation.

Product-related risks: These risks arise due to commitment to challenging product

features (e.g. response time of one second, etc.), quality, reliability etc.

Technology-related risks: These risks arise due to commitment to use certain

technology (e.g., satellite communication).

Transfer the risk: This strategy involves getting the risky components developed by a
third party, buying insurance cover, etc.

Risk reduction: This involves planning ways to contain the damage due to a risk. For
example, if there is risk that some key personnel might leave, new recruitment may be
planned.

There can be several strategies to cope up with a risk. To choose the most appropriate
strategy for handling a risk, the project manager must consider the cost of handling the
risk and the corresponding reduction of risk.
 For this we may compute the risk leverage of the different risks. Risk leverage is the
difference in risk exposure divided by the cost of reducing the risk.

Even though we identified three broad ways to handle any risk, effective risk handling
cannot be achieved by mechanically following a set procedure, but requires a lot of
ingenuity on the part of the project manager.
REQUIREMENTS ANALYSIS AND SPECIFICATION

Before starting to develop a software, the exact requirements of the customer must be
understood and documented. In the past, many projects have suffered because the
developers started to implement something without determining whether they were
building what the customers exactly wanted.

Starting development work without properly understanding and documenting the

requirements increases the number of iterative changes in the later life cycle phases, and
thereby alarmingly pushes up the development costs. This also sets the ground for
customer dissatisfaction and bitter customer-developer disputes and protracted legal
battles.

Experienced developers consider the requirements analysis and specification to be a very

important phase of software development life cycle and undertake it with utmost care.

For any type of software development project, availability of a good quality

requirements document has been acknowledged to be a key factor in the successful
completion of the project.

A good requirements document not only helps to form a clear understanding of various
features required from the software, but also serves as the basis for various activities
carried out during later life cycle phases.

When software is developed in a contract mode for some other organisation (that is, an
outsourced project), the documentation plays crucial role. When an organisation develops
a generic software product, the situation is not very different since some personnel from
the organisation’s own marketing department act as the customer.

Therefore, for all types of software development projects, proper formulation of

requirements and their effective documentation is vital.

An overview of requirements analysis and specification phase

The requirements analysis and specification phase starts after the feasibility study
 stage is complete and the project has been found to be financially viable and
technically feasible. The requirements analysis and specification phase ends when
the requirements specification document has been developed and reviewed. The
requirements specification document is usually called as the software requirements
specification (SRS) document.

The goal of the requirements analysis and specification phase is to clearly understand
the customer requirements and to systematically organise the requirements into a
document called the Software Requirements Specification (SRS) document.
Who carries out requirements analysis and specification? Requirements analysis
and specification activity is usually carried out by a few experienced members of the
development team and it normally requires them to spend some time at the customer
site.
The engineers who gather and analyse customer requirements and then write the
requirements specification document are known as system analysts in the software industry
parlance. System analysts collect data pertaining to the product to be developed and
analyse the collected data to conceptualise what exactly needs to be done.
After understanding the precise user requirements, the analysts analyse the requirements
to weed out inconsistencies, anomalies and incompleteness. They then proceed to write
the software requirements specification (SRS) document.

The SRS document is the final outcome of the requirements analysis and specification
phase.
How is the SRS document validated?

Once the SRS document is ready, it is first reviewed internally by the project team to
ensure that it accurately captures all the user requirements, and that it is
understandable, consistent, unambiguous, and complete. The SRS document is then
given to the customer for review. After the customer has reviewed the SRS document
and agrees to it, it forms the basis for all future development activities and also serves
as a contract document between the customer and the development organisation.

What are the main activities carried out during

requirements analysis and specification phase?

Requirements analysis and specification phase mainly involves carrying out the
following two important activities:
• Requirements gathering and analysis
• Requirements specification
 In the next section, we will discuss the requirements gathering and analysis activity and
in the subsequent section we will discuss the requirements specification activity.

REQUIREMENTS GATHERING AND ANALYSIS

The complete set of requirements are almost never available in the form of a single
document from the customer. It would be unrealistic to expect the customers to
produce a comprehensive document containing a precise description of what he
wants.

The complete requirements are rarely obtainable from any single customer
representative. Therefore, the requirements have to be gathered by the analyst
from several sources in bits and pieces. These gathered requirements need to be
analysed to remove several types of problems that frequently occur in the
requirements.

We can conceptually divide the requirements gathering and analysis activity into two
separate tasks:
• Requirements gathering
• Requirements analysis
Requirements Gathering
Requirements gathering is also popularly known as requirements elicitation. The primary
objective of the requirements gathering task is to collect the requirements from the
stakeholders.

Requirements gathering may sound like a simple task. However, in practice it is very
difficult to gather all the necessary information from a large number of stakeholders and
from information scattered across several pieces of documents. Gathering requirements
turns out to be especially challenging if there is no working model of the software being
developed.

Suppose a customer wants to automate some activity in his organization that is

currently being carried out manually. In this case, a working model of the system that is,
the manual system) exists.

Availability of a working model is usually of great help in requirements gathering. For

example, if the project involves automating the existing accounting activities of an
organisation, then the task of the system analyst becomes a lot easier as he can
immediately obtain the input and output forms and the details of the operational
procedures. The analyst would have to study the input and output forms and then
understand how the outputs are produced from the input data. However, if a project
involves developing something new for which no working model exists, then the
requirements gathering activity becomes all the more difficult. In the absence of a working
system ,much more imagination and creativity is required on the part of the system
analyst.

Even before visiting the customer site, requirements gathering activity is started by
studying the existing documents to collect all possible information about the system to be
developed. During visit to the customer site, the analysts normally interview the end
users and customer representatives, carry out requirements gathering activities such as
questionnaire surveys, task analysis, scenario analysis, and form analysis.

Given that many customers they describe their requirements very vaguely. Good
analysts share their experience and expertise with the customer and give his suggestions
to define certain functionalities more comprehensively, make the functionalities more
general and more complete.

Important ways to gathers requirements:

1. Studying existing documentation: The analyst usually studies all the available
documents regarding the system to be developed before visiting the customer site.
Customers usually provide statement of purpose (SoP) document to the developers.
These documents might discuss issues such as the context in which the software is
required, the basic purpose, the stakeholders, features of any similar software
developed elsewhere, etc.
2. Interview: There are many different categories of users of software. Each category
of users typically requires a different set of features from the software. Therefore, it is
important for the analyst to first identify the different categories of users and then
determine the requirements of each.
For example, the different categories of users of a library automation software could be
the library members, the librarians, and the accountants. The library members would like
to use the software to query availability of books and issue and return books. The
librarians might like to use the software to determine books that are overdue, create
member accounts, delete member accounts, etc. The accounts personnel might use the
software to invoke functionalities concerning financial aspects such as the total fee
collected from the members, book procurement expenditures, staff salary expenditures,
etc.

To systematize this method of requirements gathering, the Delphi technique can be

followed. In this technique, the analyst consolidates the requirements as understood by
him in a document and then circulates it for the comments of the various categories of
users. Based on their feedback, he refines his document. This procedure is repeated till
the different users agree on the set of requirements.
3. Task analysis: The users usually have a black-box view of a software and consider
the software as something that provides a set of services (functionalities). A service
supported by a software is also called a task. We can therefore say that the software
performs various tasks of the users. In this context, the analyst tries to identify and
understand the different tasks to be performed by the software.
For each identified task, the analyst tries to formulate the different steps necessary to
realize the required functionality in consultation with the users.
For example, for the issue book service, the steps may be—authenticate user, check the
number of books issued to the customer and determine if the maximum number of books
that this member can borrow has been reached, check whether the book has been
reserved, post the book issue details in the member’s record, and finally print out a book
issue slip that can be presented by the member at the security counter to take the book
out of the library premises.

Scenario analysis: A task can have many scenarios of operation. The different scenarios
of a task may take place when the task is invoked under different situations. For different
types of scenarios of a task, the behaviour of the software can be different.

Form analysis: During the operation of a manual system, normally several forms are
required to be filled up by the stakeholders, and in turn they receive several notifications
(usually manually filled forms). In form analysis the exiting forms and the formats of the
notifications produced are analysed to determine the data input to the system and the
data that are output from the system

Requirements Analysis

After requirements gathering is complete, the analyst analyses the gathered requirements
to form a clear understanding of the exact customer requirements and to weed out any
problems in the gathered requirements. It is natural to expect that the data collected from
various stakeholders to contain several contradictions, ambiguities, and incompleteness,
since each stakeholder typically has only a partial and incomplete view of the software.
Therefore, it is necessary to identify all the problems in the requirements and resolve
them through further discussions with the customer.

For carrying out requirements analysis effectively, the analyst first needs to develop a clear
grasp of the problem. The following basic questions pertaining to the project should be
clearly understood by the analyst before carrying out analysis:
 What is the problem?

Why is it important to solve the problem?

What exactly are the data input to the system and what exactly are the data
output by 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?

After the analyst has understood the exact customer requirements, he proceeds to
identify and resolve the various problems that he detects in the gathered requirements.

During requirements analysis, the analyst needs to identify and resolve three main
types of problems in the requirements:
• Anomaly
• Inconsistency
• Incompleteness
Anomaly: It is an anomaly is an ambiguity in a requirement. When a requirement is
anomalous, several interpretations of that requirement are possible. Any anomaly in any
of the requirements can lead to the development of an incorrect system, since an
anomalous requirement can be interpreted in the several ways during development

Inconsistency: Two requirements are said to be inconsistent, if one of the requirements

contradicts the other.

Incompleteness: An incomplete set of requirements is one in which some requirements

have been overlooked.

SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

After the analyst has gathered all the required information regarding the software to
be developed, and has removed all incompleteness, inconsistencies, and anomalies
from the specification, he starts to systematically organise the requirements in the
form of an SRS document. The SRS document usually contains all the user
requirements in a structured though an informal form.

Among all the documents produced during a software development life cycle, SRS
document is probably the most important document and is the toughest to write. One
reason for this difficulty is that the SRS document is expected to cater to the needs of a
wide variety of audience.

Users of SRS Document

Usually a large number of different people need the SRS document for very different
purposes. Some of the important categories of users of the SRS document and their needs
for use are as follows:

Users, customers, and marketing personnel: These stakeholders need to refer to

the SRS document to ensure that the system as described in the document will meet their
needs. Remember that the customer may not be the user of the software, but may be
some one employed or designated by the user. For generic products, the marketing
personnel need to understand the requirements that they can explain to the customers.

Software developers: The software developers refer to the SRS document to make sure
that they are developing exactly what is required by the customer.

Test engineers: The test engineers use the SRS document to understand the
functionalities, and based on this write the test cases to validate its working. They need
that the required functionality should be clearly described, and the input and output data
should have been identified precisely.

User documentation writers: The user documentation writers need to read the SRS
document to ensure that they understand the features of the product well enough to be
able to write the users’ manuals.

Project managers: The project managers refer to the SRS document to ensure that they
can estimate the cost of the project easily by referring to the SRS document and that it
contains all the information required to plan the project.

Maintenance engineers: The SRS document helps the maintenance engineers to under-
stand the functionalities supported by the system. A clear knowledge of the functionalities
can help them to understand the design and code. Also, a proper understanding of the
functionalities supported enables them to determine the specific modifications to the
system’s functionalities would be needed for a specific purpose.

Many software engineers in a project consider the SRS document to be a reference

document. However, it is often more appropriate to think of the SRS document as the
documentation of a contract between the development team and the customer. In fact,
the SRS document can be used to resolve any disagreements between the developers
and the customers that may arise in the future. The SRS document can even be used as a
legal document to settle disputes between the customers and the developers in a court of
law. Once the customer agrees to the SRS document, the development team proceeds to
develop the software and ensure that it conforms to all the requirements mentioned in
the SRS document.

Characteristics of a Good SRS Document

The skill of writing a good SRS document usually comes from the experience gained from
writing SRS documents for many projects. The analyst should be aware of the desirable
qualities that every good SRS document should possess. IEEE Recommended Practice for
Software Requirements Specifications [IEEE830] describes the content and qualities of a
good software requirements specification (SRS). Some of the identified desirable qualities
of an SRS document are the following:

Concise: The SRS document should be concise and at the same time
unambiguous, consistent, and complete. Verbose and irrelevant descriptions
reduce readability and also increase the possibilities of errors in the document.

Implementation-independent: The SRS should be free of design and

implementation decisions unless those decisions reflect actual requirements. It
should only specify what the system should do and refrain from stating how to do
these. This means that the SRS document should specify the externally visible
behaviour of the system and not discuss the implementation issues.

The SRS document should describe the system to be developed as a black box, and
should specify only the externally visible behaviour of the system. For this reason, the
SRS document is also called the black-box specification of the software being
developed.

 Traceable: It should be possible to trace a specific requirement to the design

elements that implement it and vice versa. Similarly, it should be possible to trace a
requirement to the code segments that implement it and the test cases that test
this requirement and vice versa.

 Modifiable: Customers frequently change the requirements during the software

development due to a variety of reasons. Therefore, in practice the SRS document
undergoes several revisions during software development. Also, an SRS document
is often modified after the project completes to accommodate future enhancements
and evolution. To cope up with the requirements changes, the SRS document should
be easily modifiable. For this, an SRS document should be well-structured. A well-
structured document is easy to understand and modify.
 Identification of response to undesired events: The SRS document should
 discuss the system responses to various undesired events and exceptional
conditions that may arise.

 Verifiable: All requirements of the system as documented in the SRS document

should be verifiable. This means that it should be possible to design test cases
based on the description of the functionality as to whether or not requirements
have been met in an implementation. Any feature of the required system that is
not verifiable should be listed separately in the goals of the implementation section
of the SRS document.

Important Categories of Customer Requirements

A good SRS document, should properly categorize and organise the requirements into
different sections. As per the IEEE 830 guidelines, the important categories of user
requirements are the following.

An SRS document should clearly document the following aspects of a software:

• Functional requirements
• Non-functional requirements
— Design and implementation constraints
— External interfaces required
— Other non-functional requirements
• Goals ofimplementation.

Functional requirements

The functional requirements capture the functionalities required by the users from
the system. A software as offering a set of functions {fi} to the user. These
functions can be considered similar to a mathematical function f : I → O, meaning
that a function transforms an element (ii) in the input domain (I) to a value (oi) in
the output (O). This functional view of a system is shown schematically in Figure
4.1.
 Figure 4.1: The black-box view of a system as performing a set of functions.

Each function fi of the system can be considered as reading certain data ii, and then
transforming a set of input data (ii) to the corresponding set of output data (oi). The
functional requirements of the system, should clearly describe each functionality that the
system would support along with the corresponding input and output data set.

Non-functional requirements

The non-functional requirements are non-negotiable obligations that must be supported

by the software. The non-functional requirements capture those requirements of the
customer that cannot be expressed as functions (i.e., accepting input data and producing
output data).

Non-functional requirements usually address aspects concerning external interfaces, user

interfaces, maintainability, portability, usability, maximum number of concurrent users,
timing, and throughput (transactions per second, etc.).

The non-functional requirements can be critical in the sense that any failure by the
developed software to achieve some minimum defined level in these requirements can be
considered as a failure and make the software unacceptable by the customer.

The different categories of non- functional requirements that are described under three
different sections:

Design and implementation constraints: Design and implementation constraints are

an important category of non-functional requirements describe any items or issues that
will limit the options available to the developers.

Some of the example constraints can be—hardware limitations; interfaces with other
applications; specific technologies, tools, and databases to be used; specific
communications protocols to be used; security considerations; design conventions or
programming standards to be followed, etc.
External interfaces required: Examples of external interfaces are— hardware,
software and communication interfaces, user interfaces, report formats, etc. To specify the
user interfaces, each interface between the software and the users must be described.

The description may include sample screen images, any GUI standards or style guides
that are to be followed, screen layout constraints, standard buttons and functions (e.g.,
help) that will appear on every screen, keyboard shortcuts, error message display
standards, and so on.

Other non-functional requirements: This section contains a description of non-

functional requirements that are neither design constraints and nor are external interface
requirements. An important example is a performance requirement such as the number of
transactions completed per unit time. Besides performance requirements, the other non-
functional requirements may include reliability issues, accuracy of results, and security
issues.

Goals of implementation

The ‘goals of implementation’ part of the SRS document offers some general suggestions
regarding the software to be developed. These are not binding on the developers, and
they may take these suggestions into account if possible.

The goals of implementation section might document issues such as easier revisions to
the system functionalities that may be required in the future, easier support for new
devices to be supported in the future, reusability issues, etc.

Functional Requirements

In order to document the functional requirements of a system, it is necessary to first

learn to identify the high-level functions of the systems by reading the informal
documentation of the gathered requirements. The high-level functions would be
split into smaller sub requirements.

A high-level function is one using which the user can get some useful piece of work
done.

The above is not a very accurate definition of a high-level function. For example, how
useful must a piece of work be performed by the system for it to be called ‘a useful piece
of work’ ? Can the printing of the statements of the ATM transaction during withdrawal of
money from an ATM be called a useful piece of work?

Printing of ATM transaction should not be considered a high-level requirement, because

the user does not specifically request for this activity. The receipt gets printed
automatically as part of the withdraw money function. Usually, the user invokes
(requests) the services of each high-level requirement. It may therefore be possible to
treat print receipt as part of the withdraw money function rather than treating it as a high-
level function.

Each high-level requirement typically involves accepting some data from the user
through a user interface, transforming it to the required response, and then displaying the
system response in proper format.

For example, in a library automation software, a high-level functional requirement

might be search-book. This function involves accepting a book name or a set of key words
from the user, running a matching algorithm on the book list, and finally outputting the
matched books. The generated system response can be in several forms, e.g., display on
the terminal, a print out, some data transferred to the other systems, etc.

In Figure 4.2, the different scenarios occur depending on the amount entered for
withdrawal. The different scenarios are essentially different behaviour exhibited by the
system for the same high-level function.

Each user input and the corresponding system action may be considered as a sub-
requirement of a high-level requirement. Thus, each high-level requirement can consist of
several sub-requirements.
 Figure 4.2: User and system interactions in high-level functional requirement.

How to Identify the Functional Requirements?

The high-level functional requirements often need to be identified either from an informal
problem description document or from a conceptual understanding of the problem.

Remember that there can be many types of users of a system and their requirements
from the system may be very different. So, it is often useful to first identify the different
types of users who might use the system and then try to identify the different services
expected from the software by different types of users.

The decision regarding which functionality of the system can be taken to be a high-level
functional requirement and the one that can be considered as part of another function
(that is, a sub function) leaves scope for some subjectivity.

How to Document the Functional Requirements?

Once all the high-level functional requirements have been identified and the
requirements problems have been eliminated, these are documented. A function can be
documented by identifying the state at which the data is to be input to the system, its input
data domain, the output data domain, and the type of processing to be carried on the input
data to obtain the output data.

Organisation of the SRS Document

IEEE 830 standard has been intended to serve only as a guideline for organizing a
requirements specification document into sections and allows the flexibility of tailoring it,
as may be required for specific projects.

Depending on the type of project being handled, some sections can be omitted,
introduced, or interchanged as may be considered by the analyst. However, organisation
of the SRS document to a large extent depends on the preferences of the system analyst
himself, and he is often guided in this by the policies and standards being followed by the
development company.

Also, the organisation of the document and the issues discussed in it to a large extent
depend on the type of the product being developed. However, irrespective of the
company’s principles and product type, the three basic issues that any SRS document
should discuss are—functional requirements, non-functional requirements, and guidelines
for system implementation.

The introduction section should describe the context in which the system is being
developed, and provide an overall description of the system, and the environmental
characteristics.

The introduction section may include the hardware that the system will run on, the
devices that the system will interact with and the user skill-levels.

It is desirable to describe the formats for the input commands, input data, output
reports, and if necessary the modes of interaction.

We outline the important sections that an SRS document should contain as suggested by
the IEEE 830 standard, for each section of the document, we also briefly discuss the
aspects that should be discussed in it.

Introduction

Purpose: This section should describe where the software would be deployed and and
how the software would be used.

Project scope: This section should briefly describe the overall context within which the
software is being developed. For example, the parts of a problem that are being
automated and the parts that would need to be automated during future evolution of the
software.
Environmental characteristics: This section should briefly outline the environment
(hardware and other software) with which the software will interact.

Overall description of organisation of SRS document

Product perspective: This section needs to briefly state as to whether the software is
intended to be a replacement for a certain existing systems, or it is a new software. If the
software being developed would be used as a component of a larger system, a simple
schematic diagram can be given to show the major components of the overall system,
subsystem interconnections, and external interfaces can be helpful.

Product features: This section should summarize the major ways in which the software
would be used. So, only a brief summary should be presented here.

User classes: Various user classes that are expected to use this software are identified
and described here. The different classes of users are identified by the types of
functionalities that they are expected to invoke, or their levels of expertise in using
computers.

Operating environment: This section should discuss in some detail the hardware
platform on which the software would run, the operating system, and other application
software with which the developed software would interact.
Design and implementation constraints: In this section, the different constraints on
the design and implementation are discussed. These might include—corporate or
regulatory policies; hardware limitations (timing requirements, memory requirements);
interfaces to other applications; specific technologies, tools, and databases to be used;
specific programming language to be used; specific communication protocols to be used;
security considerations; design conventions or programming standards.

User documentation: This section should list out the types of user documentation, such
as user manuals, on-line help, and trouble-shooting manuals that will be delivered to the
customer along with the software.
Functional requirements for organisation of SRS document. The functionalities
either based on the specific functionalities invoked by different users, or the
functionalities that are available in different modes, etc., depending what may be
appropriate.
1. User class 1
(a) Functional requirement 1.1
(b) Functional requirement 1.2
2. User class 2
(a) Functional requirement 2.1
(b) Functional requirement 2.2
External interface requirements

User interfaces: This section should describe a high-level description of various

interfaces and various principles to be followed. The user interface description may include
sample screen images, any GUI standards or style guides that are to be followed, screen
layout constraints, standard push buttons (e.g., help) that will appear on every screen,
keyboard shortcuts, error message display standards, etc.

Hardware interfaces: This section should describe the interface between the software
and the hardware components of the system. This section may include the description of
the supported device types, the nature of the data and control interactions between the
software and the hardware, and the communication protocols to be used.
Software interfaces: This section should describe the connections between this
software and other specific software components, including databases, operating systems,
tools, libraries, and integrated commercial components, etc.

Communications interfaces: This section should describe the requirements associated

with any type of communications required by the software, such as e-mail, web access,
network server communications protocols, etc.

It should also identify any communication standards that will be used, such as TCP
sockets, FTP, HTTP, or SHTTP. Specify any communication security or encryption issues that
may be relevant, and also the data transfer rates, and synchronization mechanisms.

Other non-functional requirements for organisation of SRS document

Performance requirements: Aspects such as number of transaction to be completed

per second should be specified here. Some performance requirements may be specific to
individual functional requirements or features. These should also be specified here.

Safety requirements: Those requirements that are concerned with possible loss or
damage that could result from the use of the software are specified here. For example,
recovery after power failure, handling software and hardware failures, etc. may be
documented here.

Security requirements: This section should specify any requirements regarding

security or privacy requirements on data used or created by the software. Any user
identity authentication requirements should be described here. It should also refer to any
external policies or regulations concerning the security issues. Define any security or
privacy certifications that must be satisfied.