Unit 3

Software Project Management

The main goal of software project management is to enable a group of developers to work
effectively towards the successful completion of a project.
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 As can be inferred
from the above definition, project management involves use of a set of techniques and skills to
steer a project to success.
A project manager is usually an experienced member of the team who essentially works as the
administrative leader of the team.
In this chapter, we first investigate why management of software projects is much more complex
than managing many other types of projects.

SOFTWARE PROJECT MANAGEMENT COMPLEXITIES

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

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. This is especially
true in the later stages of a project. So upto here :- Frequent changes to the requirements and the
invisibility of software are possibly the two major factors making software project management a
complex task.

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. This is unlike projects in other domains,
such as car manufacturing or steel manufacturing where the projects are more predictable

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. This requirement not only makes it difficult to get a software product
up and working, but also makes reusing parts of one software product in another difficult. This
requirement of exact conformity of the parameters of a function introduces additional risks and
contributes to the complexity of managing software projects.

Team-oriented and intellect-intensive work: Software development

projects are akin to 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

We can broadly classify a project manager’s varied responsibilities into the following
two major categories:
• Project planning, and
• Project monitoring and control.

1
Project to success. This surely is a very hazy job description. In fact, 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.
However, 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. 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.

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.
Three skills that are most critical to successful project management are the following:
Project manager must posses these skills
• Knowledge of project management techniques.
• Decision taking capabilities.
• Previous experience in managing similar projects.

Project estimation
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
Heuristic Techniques
2
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)

(IMP) COCOMO Model

COnstructive COst estimation MOdel (COCOMO) was proposed by Boehm [1981].
COCOMO prescribes a three stage process for project estimation. In the 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—basic COCOMO, intermediate

COCOMO, and complete COCOMO.

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—organic, semidetached, and
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.

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:
Effort = a1 × (KLOC)a2 PM
Tdev = b1 × (Effort)b2 months
where, KLOC is the estimated size of the software product expressed in 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).
According to Boehm, every line of source text should be calculated as one LOC irrespective of
the actual number of instructions on that line. Thus, if a single instruction spans several lines (say
n lines), it is considered to be nLOC. The values of a1, a2, b1, b2 for different categories of
products as given by Boehm [1981] are summarised below. He derived these values by examining
historical data collected from a large number of actual projects.
Estimation of development effort: For the three classes of software products, the formulas for
estimating the effort based on the code size are shown below:
Organic (simple) : Effort = 2.4(KLOC)1.05 PM
Semi-detached (moderate): Effort = 3.0(KLOC)1.12 PM
Embedded : Effort = 3.6(KLOC)1.20 PM
Estimation of development time: For the three classes of software products, the formulas for
estimating the development time based on the effort are
given as:
Organic : Tdev = 2.5(Effort)0.38 Months
Semi-detached : Tdev = 2.5(Effort)0.35 Months
Embedded : Tdev = 2.5(Effort)0.32 Months
We can gain some insight into the basic COCOMO model, if we plot the estimated effort and
duration values for different software sizes.

SCHEDULING
Scheduling the project tasks is an important project planning activity. The scheduling problem, in
essence, consists of deciding which tasks would be taken up when and by whom.
Once a schedule has been worked out and the project gets underway, the project manager
monitors the timely completion of the tasks and takes any corrective action that may be necessary
whenever there is a chance of schedule slippage. In order to schedule the project activities, a
software project manager needs to do the following:
1. Identify all the major activities that need to be carried out to Complete the project.
3
2. Break down each activity into tasks.
3. Determine the dependency among different tasks.
4. Establish the estimates for the time durations necessary to complete the tasks.
5. Represent the information in the form of an activity network.
6. Determine task starting and ending dates from the information represented in the activity
network.
7. Determine the critical path. A critical path is a chain of tasks that determines the duration of
the project.
8. Allocate resources to tasks.
After the project manager has broken down the activities into tasks, he has to find the
dependency among the tasks. Dependency among the different tasks determines the order in
which the different tasks would be carried out.
If a task A requires the results of another task B, then task A must be scheduled after task B and A
is said to be dependent on B.
The dependency among the activities are represented in the form of an activity network . Once
the activity network representation has been worked out, resources are allocated to each activity.
Resource allocation is typically done using a Gantt chart. After resource allocation is done, a
project evaluation and review technique (PERT) chart representation is developed. The PERT
chart representation is useful to a project manager to carry out project monitoring and control.

Work Breakdown Structure

Work breakdown structure (WBS) is used to recursively decompose a given set of activities into
smaller activities. Tasks are the lowest level work activities in a WBS hierarchy. They also form
the basic units of work that are allocated to the developer and scheduled First, let us understand
why it is necessary to break down project activities into tasks. Once project activities have been
decomposed into a set of tasks using WBS, the time frame when each activity is to be performed
is to be determined.

The end of each important activity is called a milestone. The project manager tracks the progress
of a project by monitoring the timely completion of the milestones. If he observes that some
milestones start getting delayed, he carefully monitors and controls the progress of the tasks, so
that the overall deadline can still be met. WBS provides a notation for representing the activities,
sub-activities, and tasks needed to be carried out in order to solve a problem. Each of these is
represented using a rectangle in fig .The root of the tree is labelled by the project name. Each
node of the tree is broken down into
smaller activities that are made the children of the node. To decompose an activity to a sub-
activity, a good knowledge of the activity can be useful.
Figure represents the WBS of a management information system (MIS) software.

How long to decompose?

The decomposition of the activities is carried out until any of the following is satisfied:
A leaf-level sub activity (a task) requires approximately two weeks to develop. Hidden
complexities are exposed, so that the job to be done is understood and can be assigned as a unit of
work to one of the developers.

Breaking down tasks to too coarse levels versus too fine levels Let us first investigate the
implications of carrying out the decompositions to very fine levels versus leaving the
decomposition at rather coarse grained. It is necessary to breakdown large activities into many
smaller tasks, because smaller tasks allow milestones to be placed at shorter distances. This
allows close monitoring of the project and corrective actions can be initiated as soon as any
problems are noticed. However, very fine subdivision means that a disproportionate amount of
time must be spent on preparing and revising various charts.
While breaking down an activity into smaller tasks, a manager often has to make some hard
decisions. If a activity is broken down into a large number of very small sub-activities, these can
be distributed to a larger number of developers. If the task ordering permits that solutions to these
can be carried out independently (parallelly), it becomes possible to develop the product faster.
4
Fig above : Work breakdown structure of an MIS problem

Fig Above :Activity network representation of the MIS problem

Activity Networks
An activity network shows the different activities making up a project, their estimated durations,
and their interdependencies. Two equivalent representations for activity networks are possible
and are in use:

Activity on Node (AoN): In this representation, each activity is represented by a rectangular

(some use circular) node and the duration of the activity is shown alongside each task in the node.
The inter-task dependencies are shown using directional edges

Activity on Edge (AoE): In this representation tasks are associated with the edges. The edges are
also annotated with the task duration. The nodes in the graph represent project milestones.
Activity networks were originally represented using activity on edge (AoE) representation.
However, later activity on node (AoN) has become popular since this representation is easier to
understand and revise.
Managers can estimate the time durations for the different tasks in several ways.

The Critical Path Method (CPM)

The Critical Path Method (CPM) can help you keep your projects on track.

5
Critical path schedules...
Helps us identify the activities that must be completed on time in order to complete the whole
project on time.
Show you which tasks can be delayed and for how long without impacting the overall project
schedule.
Calculate the minimum amount of time it will take to complete the project.
Tell you the earliest and latest dates each activity can start on in order to maintain the schedule.

The duration of each activity is listed above each node in the diagram. For each path, add the
duration of each node to determine it's total duration. The critical path is the one with the longest
duration.There are three paths through this project…

The Critical Path Method includes a technique called the Forward Pass which is used to
determine the earliest date an activity can start and the earliest date it can finish. These dates are
valid as long as all prior activities in that path started on their earliest start date and didn't slip.
Starting with the critical path, the Early Start (ES) of the first activity is one. The Early Finish
(EF) of an activity is its ES plus its duration minus one. Using our earlier example, Activity 2 is
the first activity on the critical path:
ES = 1, EF = 1 + 5 -1 = 5.

6
You then move to the next activity in the path, in this case Activity 3. Its ES is the previous
activity's EF + 1. Activity 3 ES = 5 + 1 = 6. Its EF is calculated the same as before: EF = 6 + 7 - 1
= 12.

Critical Path Method (CPM)

From the activity network representation following analysis can be made. The minimum time
(MT) to complete the project is the maximum of all paths from start to finish. The earliest start
(ES) time of a task is the maximum of all paths from the start to the task. The latest start time is
the difference between MT and the maximum of all paths from this task to the finish. The earliest
finish time (EF) of a task is the sum of the earliest start time of the task and the duration of the
task. The latest finish (LF) time of a task can be obtained by subtracting maximum of all paths
from this task to finish from MT. The slack time (ST) is LS – EF and equivalently can be written
as LF – EF. The slack time (or float time) is the total time that a task may be delayed before it will
affect the end time of the project.
A critical task is one with a zero slack time. A path from the start node to the finish node
containing only critical tasks is called a critical path. These parameters for different tasks for the
MIS problem are shown in the following table.
Task ES EF LS LF ST
Specification 0 15 0 15 0
Design database 15 60 15 60 0
Design GUI part 15 45 90 120 75
Code database 60 165 60 165 0
Code GUI part 45 90 120 165 75
Integrate and test 165 285 165 285 0
Write user manual 15 75 225 285 210

A critical path in this graph is a path along which every milestone is critical to meeting the
project deadline. In other words, if any delay occurs along a critical path, the entire project would
get delayed. It is therefore necessary to identify all the critical paths in a schedule—adhering to
the schedules of the tasks

Gantt Chart
Gantt charts are mainly used to allocate resources to activities. The resources allocated to
activities include staff, hardware, and software. Gantt charts (named after its developer Henry
Gantt) are useful for resource planning. A Gantt chart is a special type of bar chart where each bar
represents an activity. The bars are drawn along a time line. The length of each bar is proportional
to the duration of time planned for the corresponding activity.
Gantt charts are used in software project management are actually an enhanced version of the
standard Gantt charts. In the Gantt charts used for software project management, each bar consists

7
of a white part and a shaded part. The shaded part of the bar shows the length of time each task is
estimated to take. The white part shows the slack time, that is, the latest time by which a task
must be finished. A Gantt chart representation for the MIS problem

PERT Chart
PERT (Project Evaluation and Review Technique) charts consist of a network of boxes and
arrows. The boxes represent activities and the arrows represent task dependencies. PERT chart
represents the statistical variations in the project estimates assuming a normal distribution. Thus,
in a PERT chart instead of making a single estimate for each task, pessimistic, likely, and
optimistic estimates are made. The boxes of PERT charts are usually annotated with the
pessimistic, likely, and optimistic estimates for every task. Since all possible completion times
between the minimum and maximum duration for every task has to be considered, there are not
one but many critical paths, depending on the permutations of the estimates for each task. This
makes critical path analysis in PERT charts very complex. A critical path in a PERT chart is
shown by using thicker arrows.

8
Organization structure
Usually every software development organization handles several projects at any time. Software
organizations assign different teams of engineers to handle different software projects. Each type
of organization structure has its own advantages and disadvantages so the issue “how is the
organization as a whole structured?” must be taken into consideration so that each software
project can be finished before its deadline.

Organization and Team Structures

Essentially there are three broad ways in which a software development organisation can
be structured—,project format, functional format and matrix format
In the project format, the project development staff are divided based on the project for which
they work . In the functional format, the development staff are divided based on the functional
group to which they belong. The different projects borrow engineers from the required functional
groups for specific phases to be undertaken in the project and return them to the functional group
upon the completion of the phase.

In the project format, a set of engineers is assigned to the project at the start of the project and
they remain with the project till the completion of the project. Obviously, the functional format
requires more communication among teams than the project format, because one team must
understand the work done by the previous teams.

Functional Organisation

In the functional format, different teams of programmers perform different phases of a project.
For example, one team might do the requirements specification, another do the design, and so on.
9
The partially completed product passes from one team to another as the project evolves. This
requires good quality documentation to be produced after every activity.

Matrix format
A matrix organisation is intended to provide the advantages of both functional and project
structures. In a matrix organisation, the pool of functional specialists are assigned to different
projects as needed. Thus, the deployment of the different functional specialists in different
projects can be represented in a matrix

Two important problems that a matrix organisation often suffers from are:
Conflict between functional manager and project managers over allocation of workers.
Frequent shifting of workers in a firefighting mode as crises occur in different projects.

Advantages of functional organization over project organization :

Even though greater communication among the team members may appear as an avoidable
overhead, the functional format has many advantages. The main advantages of a functional
organization are:
• Ease of staffing
• Production of good quality documents
• Job specialization
• Efficient handling of the problems associated with manpower turnover.

Unsuitability of functional format in small organizations

The apparent paradox is not difficult to explain. The project format provides job rotation to the
team members. That is, each team member takes on the role of the designer, coder, tester, etc
during the course of the project.
On the other hand, considering the present skill shortage, it would be very difficult for the
functional organizations to fill in slots for some roles such as maintenance, testing, and coding
groups.
Also, another problem with the functional organization is that if an organization handles projects
requiring knowledge of specialized domain areas, then these domain experts cannot be brought in
and out of the project for the different phases, unless the company handles a large number of such
projects.
For obvious reasons the functional format is not suitable for small organizations handling just one
or two projects.

Team Structure

10
Team structure addresses the issue of organization of the individual project teams. There are some
possible ways in which the individual project teams can be organized.
There are mainly three formal team structures:
1. Chief programmer Team
2. Democratic Team
3. The mixed team organizations

Although several other variations to these structures are possible. Problems of different
complexities and sizes often require different team structures for chief solution.

1. Chief programmer Team In this team organization, a senior engineer provides the
technical leadership and is designated the chief programmer. The chief programmer
partitions the
task into many smaller tasks and assigns them to the team members. verifies and integrates the
products developed by different team members However, the chief programmer team leads to
lower team morale, since the team members work under the constant supervision of the chief
programmer.

The fig above is :The democratic team structure

2.The democratic team structure

⚫ The democratic team structure, as the name implies, does not enforce any formal team
hierarchy.
⚫ Typically, a manager provides the administrative leadership. At different times, different
members of the group provide technical leadership.
11
 ⚫ In a democratic organisation, the team members have higher morale and job satisfaction.
Consequently, it suffers from less manpower turnover. Though the democratic teams are
less productive compared to the chief programmer team, the democratic team structure is
appropriate for less understood problems, since a group of developers can invent better
solutions than a single individual as in a chief programmer team.
A democratic team structure is suitable for research-oriented projects requiring less than five
or six developers. For large sized projects, a pure democratic organisation tends to become
chaotic.
⚫ Democratic organization leads to higher morale and job satisfaction.
⚫ Encourages egoless programming
⚫ A programmer is an artist (apply arts of programming)
⚫ Cannot easily locate bugs and issues in their programs
⚫ Programmer takes a lot of pride in their creations
⚫ They should think of the product as an output of a group not an individual
⚫ Wastes a lot of time arguing on trivial points (needs an authority)

3. Mixed Control Team:

Mixed ideas from the chief programmer and democratic team structures
⚫ Hierarchical reporting
⚫ Democratic setup
⚫ Suitable for large teams
⚫ Decompose the problem into simple task and assign them to groups
⚫ Each group communicates democratically
⚫ Very popular and the most used structure

Fig : Mixed Control Team

Risk management: It is a study on how to manage risk in any software development . 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.

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. Risk identification is somewhat
similar to the project manager listing down his nightmares.

A software project can be affected by a large variety of risks. In order to be able to systematically
identify the important risks which might affect a software project, it is necessary to categorize
12
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. Project risks concern varies 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. For any manufacturing project, such as manufacturing of
cars, the project manager can see the product taking shape. He can for instance, see that the
engine is fitted, after that the doors are fitted, the car is getting painted, etc. Thus he can easily
assess the progress of the work and control it. 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 to the development team’s insufficient knowledge about the project.

Business risks. This type of risks include risks of building an excellent product that no one wants,
losing budgetary or personnel commitments, and issue of risk related to market etc.

Software configuration management

Why is Software Configuration Management required? Or why is it required
Software Configuration Management is the process that defines how to control and manage the
changes
Throughout development, software consists of a collection of items (such as programs, data and
documents) that can easily be changed. During software development, the design, code, and even
requirements are often changed, and the changes occur at any time during the development. This
easily changeable nature of software and the fact that changes often take place require that
changes be done in a controlled manner.
Software configuration management (SCM) is the discipline for systematically controlling the
changes that take place during development. Software configuration management is a process
independent of the development process largely because most development models cannot
accommodate change at any time during development. SCM can be considered as having three
major components:
   There are several reasons for putting an object under configuration management. But, possibly
the most important reason for configuration management is to control the access to the different
deliverable objects. Normally, a project manager performs the configuration management activity
by using an automated configuration management tool. A configuration management tool
provides automated support for overcoming all the problems.

S/W REQUIREMENT AND SPECIFICATION:-

The aim of the requirements analysis and specification phase is to understand the exact
requirements of the customer and to document them properly. This phase consists of
two distinct activities, namely
- Requirements gathering and analysis, and
- Requirements specification

a)Requirements gathering and analysis:-

The goal of the requirements gathering activity is to collect all relevant information from the
customer regarding the product to be developed and analyzed. This phase is done to clearly
understand the customer requirements so that incompleteness and inconsistencies are removed.

13
This activity begins by collecting all relevant data regarding the product to be developed from the
user and from the customer through interviews and discussions.
For example, to perform the requirements analysis of a business accounting software required by
an organization, the analyst might interview all the accountants of the organization to ascertain
their requirements. The data collected from such a group of users usually contain several
contradictions and ambiguities, since each user typically has only a partial and incomplete view of
the system. Therefore it is necessary to identify all ambiguities and contradictions in the
requirements phase and resolve them through further discussions with the customer.

b) Requirements specification:-
After all ambiguities, inconsistencies, and incompleteness have been resolved and all the
requirements properly understood, the requirements specification activity can start. During this
activity, the user requirements are systematically organized into a Software Requirements
Specification (SRS) document. The customer requirements identified during the requirements
gathering and analysis activity are organized into a SRS document.
The important components of this document are:
-functional requirements of the system
-nonfunctional requirements of the system
-goal of implementation.
Functional requirements:-

The functional requirements part discusses the functionalities required from the
system. The system is considered to perform a set of high level functions {fi}. The
functional view of the system is shown in fig.3.1. Each function fi of the system can be
considered as a transformation of a set of input data (ii) to the corresponding set of
output data (oi). The user can get some meaningful piece of work done using a highlevel
function.

Nonfunctional requirements:-
Nonfunctional requirements deal with the characteristics of the system which cannot
be expressed as functions - such as the maintainability of the system, portability of the
system, usability of the system, etc. It may include:
# reliability issues,
# accuracy of results,
# human - computer interface issues,

SRS (software requirement specification)

for a software to evolve from the requirements specification stage to the design stage, the
developers need to elicit requirements from the customers, analyse those requirements, and
formally document the requirements in the form of an SRS document.

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,
14
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

REQUIREMENTS GATHERING AND ANALYSIS

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

We can conceptually divide the requirements gathering and analysis activity

into two separate tasks:
• Requirements gathering
• Requirements analysis

The primary objective of the requirements gathering task is to collect the requirements from the
stakeholders.

Requirements Analysis
After requirements gathering is complete activity is to analyse the gathered requirements to
remove all ambiguities, incompleteness, and inconsistencies from the gathered customer
requirements and to obtain a clear understanding of the software to be developed.

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. In the
following subsection, we discuss the different categories of users of an SRS document and their
needs from it.

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.

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

Properties of a good SRS document

• Some of the important properties of a good SRS document are the following:
a)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 error
possibilities.
b)Structured:
It should be well-structured. A well-structured document is easy to understand and modify. In
practice, the SRS document undergoes several revisions to cope up with the customer
requirements. Often, the customer requirements evolve over a period of time. Therefore, in order
to make the modifications to the SRS document easy, it is important to make the document well-
structured.
c)Black-box view:
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 external behavior of the system and not discuss
the implementation issues. The SRS document should view the system to be developed as black
box, and should specify the externally visible behavior of the system. For this reason, the SRS
document is also called the black-box specification of a system.
d)Conceptual integrity:
It should show conceptual integrity so that the reader can easily understand it.
e)Response to undesired events:
It should characterize acceptable responses to undesired events. These are called system response
to exceptional conditions.
f)Verifiable:
All requirements of the system as documented in the SRS document should be verifiable. This
means that it should be possible to determine whether or not requirements have been met in an
implementation.
Problems without a SRS document
• The important problems that an organization would face if it does not develop an SRS document
are as follows:
-Without developing the SRS document, the system would not be implemented according to
customer needs.
-Software developers would not know whether what they are developing is what exactly required
by the customer.
-Without SRS document, it will be very much difficult for the maintenance engineers to
understand the functionality of the system.
-It would be very much difficult for user document writers to write the users’ manuals properly
without understanding the SRS document.

16
Problems with an unstructured specification
• It would be very much difficult to understand that document.
• It would be very much difficult to modify that document.
• Conceptual integrity in that document would not be shown.
• The SRS document might be unambiguous and inconsistent.
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. However, 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 a nd not discuss the implementation issues.

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.
Traceability is also important to verify the results of a phase with respect to the previous phase
and to analyse the impact of changing a requirement on the design elements and the code.

Modifiable: Customers frequently change the requirements during the software development
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 wellstructured document is easy to understand and
modify. Having the description of a requirement scattered across many places in the SRS
document may not be wrong—but it tends to make the requirement difficult to understand and
also any modification to the requirement would become difficult as it would require changes to
be made at large number of places in the document.

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. A
requirement such as “the system should be user friendly” is not verifiable. On the other hand, the
requirement—“When the name of a book is entered, the software should display whether the book
is available for issue or it has been loaned out” is verifiable. 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 [IEEE830]. 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
17
— External interfaces required
— Other non-functional requirements
• Goals of implementation.

TECHNIQUES FOR REPRESENTING COMPLEX LOGIC:-

Good SRS documents sometimes may have the conditions which are complex & which may have
overlapping interactions & processing sequences. There are two main techniques available to
analyze & represent complex processes logic are.
A) Decision tree
B) Decision table
After these two techniques are finalizing the decision making logic is captured in form of tree or
table. We can automatically find out the test cases to validate the decision from the decision
making logic. These two techniques are widely used in applications of information theory &
switching theory.
Decision tree:
A decision tree gives a graphic view of the processing logic involved in decision making and the
corresponding actions taken. The edges of a decision tree represent conditions and the leaf nodes
represent the actions to be performed depending on the outcome of testing the condition.

Example: -
Consider Library Membership Automation Software (LMS) where it should support the following
three options:
-New member to join
-Renewal books
-Cancel membership
-New member option-
Decision:
When the 'new member' option is selected, the software asks details about the member like the
member's name, address, phone number, id etc. Action: If proper information is entered then a
membership record for the member is created and a bill is printed for the annual membership
charge plus the security deposit payable.
Renewal option-
Decision: If the 'renewal' option is chosen, the LMS asks for the member's name and
membership number to check whether he is a valid member or not.

Action: If the membership is valid then membership expiry date is updated and the
annual membership bill is printed, otherwise an error message is displayed.
Cancel membership option-
Decision: If the 'cancel membership' option is selected, then the software asks for
member's name and his membership number.
Action: The membership is cancelled, a cheque for the balance amount due to the
member is printed and finally the membership record is deleted from the database.
Decision tree representation of the above example -
The following tree (fig. 3.4) shows the graphical representation of the above example. After
getting information from the user, the system makes a decision and then performs the
corresponding actions. Ask for member’s name, address, etc. Create membership details Print
cheque.

18
Decision table
A decision table is used to represent the complex processing logic in a tabular or a
matrix form. The upper rows of the table specify the variables or conditions to be
evaluated. The lower rows specify the actions to be taken when the corresponding
conditions are satisfied. A column in a table is called a rule. A rule implies that if a
condition is true, then the corresponding action is to be executed.

Example: -
Consider the previously discussed LMS example. The following decision table (fig. 3.5)
shows how to represent the LMS problem in a tabular form. Here the table is divided
into two parts, the upper part shows the conditions and the lower part shows what
actions are taken. Each column of the table is a rule.
From

Characteristics of a good software design

The definition of “a good software design” can vary depending on the application
being designed.
The characteristics are listed below:
• Correctness: A good design should correctly implement all the
functionalities identified in the SRS document.
• Understandability: A good design is easily understandable.
19
. Efficiency: It should be efficient.
• Maintainability: It should be easily amenable to change.
Possibly the most important goodness criterion is design correctness. A design has to be correct to
be acceptable. Given that a design solution is correct, understandability of a design is possibly the
most important issue to be considered while judging the goodness of a design. A design that is
easy to understand is also easy to develop, maintain and change. Thus, unless a design is easily
understandable, it would require tremendous effort to implement and maintain it.

Cohesion
Most researchers and engineers agree that a good software design implies clean decomposition of
the problem into modules, and the neat arrangement of these modules in a hierarchy. The primary
characteristics of neat module decomposition are high cohesion and low coupling..

Another def : When function of one module cooperates with another to perform single objective
then module is said to be good cohesion. The primary characteristics of neat module
decomposition are high cohesion and low coupling. Cohesion is a measure of functional strength
of a module. A module having high cohesion and low coupling is said to be functionally
independent of other modules. By the term functional independence, we mean that a cohesive
module performs a single task or function. A functionally independent module has minimal
interaction with other modules. High cohesion has features of reliability, robustness and
reusability where as low cohesion has difficult to test, reuse even difficult to understand and
maintenance.

Coincidental cohesion: A module is said to have coincidental cohesion, if it performs a set of

tasks that relate to each other very loosely. In this case, the module contains a random collection
of functions. It is likely that the functions have been put in the module out of pure coincidence
without any thought or design or parts of the module grouped arbitrarily.

Logical cohesion: A module is said to be logically cohesive, if all elements of the module
perform similar operations, e.g. error handling, data input, data output, etc. An example of logical
cohesion is the case where a set of print functions generating different output reports are arranged
into a single module, such as module contain set of print functions to generate various type of
output report such as salary, grade sheet, manual report etc.

Temporal cohesion: When a module contains functions that are related with each other and all
the functions must be executed in the same time span, then module is said to exhibit temporal
cohesion. For example when computer booted several functions need to be performed at the same
time one by one such as initialization of memory, devices, loading OS etc. and The set of
functions in a single module responsible for initialization, start-up, shutdown of some process,
etc. exhibit temporal cohesion.
Another example we can consider as a functions which called after catching an exception which
closes opened files, give notification to user, create error log etc.

Procedural cohesion: A module is said to possess procedural cohesion, if the set of functions of
the module are all part of a procedure (algorithm)in which certain sequence of steps have to be
carried out for achieving an objective, e.g. the algorithm for decoding a message. As in the above,
the parts/functions of the modules always follow certain sequence of execution.

Communicational cohesion: Communicational cohesion is also called informational cohesion.

Parts/functions of the modules grouped together to operate on same data. A module is said to have
communicational cohesion, if all functions of the module refer to or update the same data
structure, e.g. the set of functions defined on an array or a stack.

Sequential cohesion: A module is said to possess sequential cohesion, if the elements of a

module form the parts of sequence, where the output of one function is input to the next. For
example, in a Transaction Processing System, the get-input (), validate-input (), sort-input ()
functions are grouped into one module.

20
Functional cohesion: Functional cohesion is said to exist, if different elements/parts/functions of
a module cooperate to achieve a single task. For example, a module containing all the functions
required to manage employees’ pay-roll exhibits functional cohesion such as compute-overtime(),
compute-workhr(), computededuction()
etc . It is considered one of the most superior cohesion in the module but in certain cases not
achievable and instead communicational cohesion overcome the solution.

Coupling
Coupling between two modules/classes/components is a measure of the degree of
interdependence or interaction between the two modules or mutual interdependence between
modules. A module having high cohesion and low coupling is said to be functionally independent
of other modules. Two modules are said to be highly coupled when:
-function calls between two modules involve & shared large chunk of data.
-interaction occurs through shared data.
If two modules interchange large amounts of data, then they are highly interdependent. The
degree of coupling between two modules depends on their interface complexity. The interface
complexity is determined based on the parameter, no. of parameter etc. Module with low coupling
is better.

Data coupling: Two modules are data coupled, if they communicate through a parameter. An
example is an elementary data item passed as a parameter between two modules, e.g. an integer, a
float, a character, etc. This data item should be problem related and not used for the control
purpose.
Stamp coupling: Two modules are stamp coupled, if they communicate using a composite data
item such as a record in PASCAL or a structure in C.
Control coupling: Control coupling exists between two modules, if data from one module is used
to direct the order of instructions execution in another. An example of control coupling is a flag
set in one module and tested in another module.

Common coupling: Two modules are common coupled, if they share data through some global
data items.
Content coupling: Content coupling exists between two modules, if they share code, e.g. a
branch from one module into another module.

Function-oriented design
The following are the salient features of a typical function-oriented design approach:
1. A system is viewed as something that performs a set of functions. Starting at this high-level
view of the system, each function is successively refined into more detailed functions. For
example, consider a function create-new library- member which essentially creates the record for
a new member, assigns a unique membership number to him, and prints a bill towards his
membership charge. This function may consist of the following subfunctions:
• assign-membership-number
• create-member-record
• print-bill
Each of these sub-functions may be split into more detailed subfunctions and so on.
2. The system state is centralized and shared among different functions, e.g.
data such as member-records is available for reference and updation to several functions such as:
• create-new-member
• delete-member
• update-member-record

Object-oriented design
In the object-oriented design approach, the system is viewed as collection of objects (i.e. entities).
The state is decentralized among the objects and each object manages its own state information.
For example, in a Library Automation Software, each library member may be a separate object
with its own data and functions to operate on these data. In fact, the functions defined for one
21
object cannot refer or change data of other objects. Objects have their own internal data which
define their state. Similar objects constitute a class. In other words, each object is a member of
some class. Classes may inherit features from super class.
Conceptually, objects communicate by message passing.

Function-oriented vs. object-oriented design approach

22