Software Engineering 1

Unit 2

Software Requirement Analysis and specification

Requirement
1. The requirement for a system is the description of the services provided by the system and its operational constraints.
2. A requirement is simply a high level, abstract statement of a service that the system should provide or a constraint on the system.

Requirement Engineering
The process of finding out, analyzing, documenting and checking these services and constraints is called requirement engineering.

User Requirements
1. These are statements, in a natural language plus diagrams, of what services the system is expected to provide and the constraints
under which it must operate.
2. The user requirements for a system should describe the functional and non-functional requirements so that they are understandable
by system users without detailed technical knowledge.
3. They should only specify the external behavior of the system and should avoid, as for as possible, system design characteristics.
4. The readers of the user requirements are not usually concerned with how the system will be implemented and may be managers
who are not interested in the detailed facilities of the system.
For example
“LIBSYS shall keep track of all data required by copyright licensing agencies in the UK and elsewhere.”
However, various problems can arise when requirements are written in natural language sentences in a text document.
a) Lack of clarity – It is sometimes difficult to use language in a precise and unambiguous way without making the document
wordy and difficult to read.
b) Requirement Confusion – Functional requirements, non-functional requirements, system goals and design information may be
clearly distinguished.
c) Requirements Amalgamation – Several different requirements may be expressed together as a single requirement.

As an illustration of some of these problems, consider one of the requirements for the library

“LIBSYS” shall provide a financial accounting system that maintains records of all payments made by users of the system. System
managers may configure this system so that regular users may receive discounted rates.”
This requirement includes both conceptual and detailed information. It expresses the concept that there should be an accounting
system as an inherent part of LIBSYS. However, it also includes the detail that the accounting system should support discounts for
regular LIBSYS users. This detail would have been left to the system requirements specification.
To minimize misunderstandings when writing user requirements, you follow some simple guidelines:
1. Invent a standard format and ensure that all requirement definitions adhere to that format. Standardizing the format makes
omissions less likely and requirements easier to check. You may also include information on who proposed the
requirement (the requirement source) so that you know whom to consult if the requirement has to be changed.
2. Use language consistently. You should always distinguish between mandatory and desirable requirements. Mandatory
requirements are requirements that the system must support and are usually written using ‘shall’. Desirable requirements are not
essential and are written using ‘should’.
3. Use text highlighting (bold, italic or color) to pick out key parts of the requirement.
 Software Engineering 2
4. Avoid, as for as possible, the use of computer jargon. Inevitably, however, detailed technical terms will creep into the user
requirements.
 Software Engineering 3
System Requirements
1. They set out the system’s functions, services and operational constraints in detail.
2. System requirements are expanded versions of the user requirements that are used by software engineers as the starting point
for the system design.
3. They add detail and explain how the user requirements should be provided by the system.
4. They may be used as part of the contract for the implementation of the system and should therefore be a complete and
consistent specification of the whole system.
5. The readers of the system requirements need to know more precisely what the system will do because they are concerned
with how it will support the business processes or because they are involved in the system implementation.
For examples
 On making a request for a document from LIBSYS, the requester shall be presented with a form that records details of the user
and the request made.
 LIBSYS request forms shall be stored on the system for five years form the date of the request.
 All LIBSYS request forms must be indexed by user, by the name of the material requested and by the supplier of the request.
 LIBSYS shall maintain a log of all requests that have been made to the system.
 For material where author’s lending rights apply, loan details shall be sent monthly to copyright licensing agencies that
have registered with LIBSYS.

Functional and Non-Functional Requirements

Software system requirements are often classified as functional, non-functional or domain requirements.

Functional Requirements
1. These are statement of services the system should provide, how the system should react to particular inputs and how the system
should behave in particular situations.
2. In some cases, the functional requirements may also explicitly state what the system should not do.
3. These requirements depend on the type of software being developed, the expected users of the software and the general approach
taken by the organization when writing requirements.
4. When expressed as user requirements, the requirements are usually described in a fairly abstract way.
5. Functional system requirements describe the system in detail, its inputs and outputs, exceptions, and so on.
6. In principle, the functional requirements specification of a system should be both complete and consistent. Completeness means that
all services required by the user should be defined. Consistency means that requirements should not have contradictory definitions.

For example, here are examples of functional requirements for a university library system called LIBSYS, used by the students and faculty to
order books and documents from other libraries.
a) The user shall be able to search either all of the initial set of databases or select a subset from it.
b) The system shall provide appropriate viewers for the user to read documents in the document store.
c) Every order shall be allocated a unique identifier (ORDER_ID), which the user shall be copy to the document’s
permanent storage area.
 Software Engineering 4
Non Functional Requirements
1. These are constraints on the services or functions offered by the system.
2. They are not directly concerned with the specific functions delivered by the system.
3. They include timing constraints, constraints on the development process and standards.
4. They may relate to emergent system properties such as reliability, response time and store occupancy. Alternatively, they may
define constraints on the system such as the capabilities of I/O devices and the data representations used in system interfaces.
5. Non-functional requirements often apply to the system as a whole. They do not usually just apply to individual system features
or services.
6. Failing to meet a non-functional requirement can mean that the whole system is unusable.
For e.g., if an aircraft system does not meet its reliability requirements, it will not be certified as safe for operation; if a real-time control
system fails to meet its performance requirements, the control functions will not operate correctly.
7. Non-functional requirements arise through user needs, because of budget constraints, because of organizational policies, because of
the need for interoperability with other software or hardware systems, or because of external factors such as safety regulations or privacy
legislation.
8. The types of non-functional requirements
a) Product Requirements
 These requirements specify product behavior.
 Examples include performance requirements on how fast the system must execute and how much memory it
requires.
 Reliability requirements that set out the acceptable failure rate.
 Portability requirements and usability
requirements. For example
 The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets.
b) Organizational Requirements
 These requirements are derived from policies and procedures in the customer’s and developer’s organization.
 Examples include process standards that must be used.
 Implementation requirements such as the programming language or design method used.
 Delivery requirements that specify when the product and its documentation are to be delivered.
For example
 The system development process and deliverable documents shall conform to the process and deliverables
defined in XYZCo-SP-STAN-95.
c) External Requirements
 This broad heading covers all requirements that are derived from factors external to the system and its
development process.
 They may include interoperability requirements that define how the system interacts with systems in
other organizations.
 Legislative requirements that must be followed to ensure that the system operates within the law.
 Ethical requirements that the system which is developed will be acceptable to its users and the general public.
For example
 The system shall not disclose any personal information about system users apart from their name and library
reference number to the library staff who use the system.
 Software Engineering 5
Domain Requirements
1. These requirements that come from the application domain of the system and that reflect characteristics and constraints of
that domain.
2. They may be functional or non-functional requirements.
3. Domain requirements are derived from the application domain of the system rather than from the specific needs of the system users.
4. They usually include specialized domain terminology or reference to domain concepts.
5. They may be new functional requirements in their own right, constrain existing functional requirements or set out how
particular computations must be carried out.
6. Because these requirements are specialized, software engineers often find it difficult to understand how they are related to other
system requirements.
7. Domain requirements are important because they often reflect fundamental of the application domain.
8. If these requirements are not satisfied, it may be impossible to make the system work satisfactorily.
For example
The LIBSYS system includes a number of domain requirements:
a) There shall be a standard user interface to all databases that shall be based on the Z39.50 standard.
b) Because of copyright restrictions, some documents must be deleted immediately on arrival. Depending on the user’s
requirements, these documents will either be printed locally on the system server for manual forwarding to the user or routed to a
network printer.

The first requirement is a design constraint. It specifies that the user interface to the database must be implemented according to a specific
library standard. The developers therefore have to find out about that standard before starting the interface design. The second requirement
has been introduced because of copyright laws that apply to material used in libraries. It specifies that the system must include an automatic
delete-on-print facility for some classes in document. This means that users of the library system cannot have their own electronic copy of
the document.

Requirement Engineering Process

1. The goal of the requirement engineering process is to create and maintain a system requirement specification (SRS) document.
2. The overall process includes four high-level requirements engineering sub-processes.
3. These are concerned with
a) Assessing whether the system is useful to the business i.e. feasibility study,
b) Discovering requirements i.e. requirement elicitation and analysis,
c) Converting these requirements into some standard form i.e. requirements specification, and
d) Checking that the requirements actually define the system that the customer wants i.e. requirement validation.
4. Fig below illustrates the relationship between these activities. It also shows the documents produced at each stage of
the requirements engineering process.
 Software Engineering 6

5. The activities shown in above fig are concerned with the discovery, documentation and checking of requirements. In virtually
all systems, requirements change. The process involved develop a better understanding of what they want the software to do; the
organization buying the system changes; modifications are made to the system’s hardware, software and organizational environment.
The process of managing these changing requirements is called requirements management.

Feasibility Study
1. For all new systems, the requirements engineering process should start with a feasibility study.
2. The input to the feasibility study is a set of preliminary business requirements, an outline description of the system and how
the system is intended to support business processes.
3. The results of the feasibility study should be a report that recommends whether or not it is worth carrying on with the
requirements engineering and system development process.
4. A feasibility study is a short, focused study that aims to answer a number of questions:
a) Does the system contribute to the overall objectives of the organization?
b) Can the system be implemented using current technology and within cost and schedule constraints?
c) Can the system be integrated with other systems which are already in place?
5. The issue of whether or not the system contributes to business objectives is critical. If a system does not support these objectives, it
has no real value to the business.
6. Carrying out a feasibility study involves information assessment, information collection and report writing.
7. The information assessment phase identifies the information that is required to answer these three questions. Once the information
has been identified, you should talk with information sources to discover the answers to these questions. Some of the possible questions
that may be put are:
a) How would the organization cope if this system were not implemented?
b) What are the problems with current processes and how would a new system help to solve these problems?
c) What direct contribution will the system make to the business objectives and requirements?
d) Can information be transferred to and from other organizational systems?
e) Does the system require technology that has not previously been used in the organization?
f) What must be supported by the system and what need not be supported?
 Software Engineering 7
8. In a feasibility study, you may consult information sources such as the managers of the departments where the system will be used,
software engineers who are familiar with the type of the system that is proposed, technology experts and end-users of the system.
9. Once you have the information, you write the feasibility study report. You should make a recommendation about whether or not the
system development should continue. In the report, you may propose changes to the scope, budget and schedule of the system and
suggest further high-level requirements for the system.

Requirements elicitation and analysis (Requirement Gathering)

1. In this activity, software engineers work with customers and system end-users to find out about the application domain,
what services the system should provide, the required performance of the system, hardware constraints, and so on.
2. Requirements elicitation and analysis may involve a variety of people in an organization. The term stakeholder is used to refer to
any person or group who will be affected by the system, directly or indirectly. Stakeholders include end-users who interact with the
system and everyone else in an organization that may be affected by its installation. Other system stakeholders may be engineers
who are developing or maintaining related systems, business managers, domain experts and trade union representatives.
3. Eliciting and understanding stakeholders requirements is difficult for several reasons:
a) Stakeholders often don’t know what they want from the computer system except in the most general terms. They may find
it difficult to articulate what they want the system to do or make unrealistic demands because they are unaware of the cost of
their requests.
b) Stakeholders naturally express requirements in their own terms and with implicit knowledge of their own
work. Requirements engineers, without experience in the customer’s domain, must understand these requirements.
c) Different stakeholders have different requirements, which they may express in different ways. Requirements engineers
have to consider all potential sources of requirements and discover commonalities and conflict.
d) Political factors may influence the requirements of the system. For example, managers may demand specific system
requirements that will increase their influence in the organization.
e) The economic and business environment in which the analysis takes place is dynamic. It inevitably changes during
the analysis process. Hence the importance may emerge from new stakeholders who were not originally consulted.
4. A very general process model of the elicitation and analysis process is shown in fig below. Each organization will have its
own version or instantiation of this general model, depending on local factors such as the expertise of the staff, the type of system
being developed and the standards used.
5. The process activities are:
a) Requirement discovery – This is the process of interacting with stakeholders in the system to collect their requirements.
Domain requirements from stakeholders and documentation are also discovered during this activity.
b) Requirement classification and organization – This activity takes the unstructured collection of requirements, group
related requirements and organizes them into coherent clusters.
c) Requirement prioritization and negotiation – Inevitably, where multiple stakeholders are involved, requirements will
conflict. This activity is concerned with prioritizing requirements, and finding and resolving requirements conflicts through
negotiation.
d) Requirements documentation – The requirements are documented and input into the next round of the spiral. Formal and
informal requirements documents may be produced.
 Software Engineering 8

Requirements Requirements
classifications prioritization and
and organization negotiations

Requirement
Requirements documentation
Discovery

6. The above fig shows that requirements elicitation and analysis is an iterative process with continual feedback from each activity to
other activities. The process cycle starts with requirements discovery and ends with requirements documentation. The analyst’s
understanding of the requirements improves with each round of the cycle.

Software Requirement Specification (SRS) or Software Requirement Plan (SRP): - It contains the following elements –
1. Introduction: - It states the goals and objectives of the software. It represents the scope of the software and the entire project.
2. Information description: - It provides a detailed description of the problem that the software has to solve. Here various
diagrams are created for representing the relationships, data flow and control flow between various elements (example,
DFD).
3. Functional description: - It contains the description related to problem solution attained through partitioning and the
respective functions to implement the partitioning. It also contains a description of design constraints with justification,
performance characteristics and a diagrammatic representation of the overall structure of the software and interrelations among
various system elements.
4. Behavioral description: - It contains the description related to the internal operation of the software including its response to
external events. It may contain various state transition diagrams.
5. Bibliography: - The bibliography contains references to various documents that are related to the software, engineering
documents, technical references, vendor literature and standards.

Structure of a SRS
The general structure of an SRS proposed by IEEE standard is given below:
1. Introduction
• Purpose
• Scope
• Definitions, Acronyms, and Abbreviations
• References
• Overview
2. Overall Description
oduct Perspective
oduct Functions
ser Characteristics
eneral Constraints
 Software Engineering 9
ssumptions and Dependencies
3. Specific Requirements
External Interface Requirements
• User Interfaces
• Hardware Interfaces
• Software Interfaces
• Communication Interfaces
Functional Requirements
• Mode 1
• Functional Requirement 1.1
• Functional Requirement 1.2
• Mode 2
Functional Requirement 2.1
Functional Requirement 2.2
Performance Requirements
Design Constraints
Attributes
Other Requirements

The description of various sections of SRS is:

1. Introduction – This section contains the purpose, scope, overview, etc. of the requirements document. It also contains the
references cited in the document and any definitions that are used.
2. Overall Description – It describes the general factors that affect the product and its requirements. Specific requirements are not
mentioned, but a general overview is presented to make the understanding of the specific requirements easier. Product
perspective is essentially the relationship of the product to other products; defining if the product is independent or is a part of a
larger product, and what the principle interfaces of the product are. A general abstract description of the functions to be
performed by the product is given.
3. Specific Requirements – It describes all the details that the software developer needs to know for designing and developing the
system. This is typically the largest and most important part of the document. The external interface requirements section
specifies all the interfaces of the software: to people, other software, hardware, and other systems. In the functional

requirements section, the functional capabilities of the system are described. For each functional requirement, the required
inputs, desired outputs, and processing requirements will have to be specified.

Benefits of a Great SRS (Need for SRS)

The IEEE 830 standard defines the benefits of a good SRS:
1. Establish the basis for agreement between the customers and the suppliers on what the software product is to do. The
complete description of the functions to be performed by the software specified in the SRS will assist the potential users to
determine if the software specified meets their needs or how the software must be modified to meet their needs. [NOTE: We
use it as the basis of our contract with our clients all the time].
2. Reduce the development effort. The preparation of the SRS forces the various concerned groups in the customer’s organization
to consider rigorously all of the requirements before design begins and reduces later redesign, recoding, and retesting. Careful
review of the requirements in the SRS can reveal omissions, misunderstandings, and inconsistencies early in the development
cycle when these problems are easier to correct.
 Software Engineering 10
3. Provide a basis for estimating costs and schedules. The description of the product to be developed as given in the SRS is a
realistic basis for estimating project costs and can be used to obtain approval for bids or price estimates. [NOTE: Again, we
use the SRS as the basis for our fixed price estimates]
4. Provide a baseline for validation and verification. Organizations can develop their validation and Verification plans much
more productively from a good SRS. As a part of the development contract, the SRS provides a baseline against which
compliance can be measured. [NOTE: We use the SRS to create the Test Plan].
5. Facilitate transfer. The SRS makes it easier to transfer the software product to new users or new machines. Customers thus
find it easier to transfer the software to other parts of their organization, and suppliers find it easier to transfer it to new
customers.
6. Serve as a basis for enhancement. Because the SRS discusses the product but not the project that developed it, the SRS serves
as a basis for later enhancement of the finished product. The SRS may need to be altered, but it does provide a foundation for
continued production evaluation. [NOTE: This is often a major pitfall – when the SRS is not continually updated with
changes]

Characteristics of a great SRS

An SRS should be
a) Correct – An SRS is correct if every requirements included in the SRS represents something required in the final system.
b) Unambiguous – An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation.
Requirements are often written in natural language, which are inherently ambiguous. If the requirements are specified in a
natural language, the SRS write has to be especially careful to ensure that there are no ambiguities.
c) Complete – An SRS is complete if everything the software is supposed to do and the responses of the software to all classes of
input data are specified in the SRS.
d) Consistent – An SRS is consistent if there is no requirement that conflicts with another. The SRS should be consistent within
itself and consistent to its reference documents. If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in
another.
e) Ranked for Importance – Generally all the requirements are not of equal importance. Some are critical, others are important but
not critical and there are some which are desirable but not very important. Some requirements are core requirements which are not
likely to change as time passes, while others are more dependent on time. An SRS should be ranked for importance and / or
stability. Stability of a requirement reflects the chances of it changing in future.
f)Verifiable – An SRS is verifiable if and only if every stated requirement is verifiable. A requirement is verifiable if there exists
some cost-effective process that can check whether the final software meets that requirement. This implies that the requirement

should have as little subjectivity as possible because subjective requirements are difficult to verify. Don't put in requirements like
- "It should provide the user a fast response." Another of my favorites is - "The system should never crash." Instead, provide a
quantitative requirement like: "Every key stroke should provide a user response within 100 milliseconds."
g) Modifiable – An SRS is modifiable if its structure and style should be such that any necessary changes can be made easily while
preserving completeness and consistency. Presence of redundancy is a major obstacle to modifiability, as it can easily lead to
errors. For example, assume that a requirement is stated in two places and that the requirement later needs to be changed. If only
one occurrence of the requirements is modified, the resulting SRS will be inconsistent.
h) Traceable – An SRS is traceable if the origin of each or its requirements is clear and if it facilitates the referencing of each
requirement in future development. Forward traceability means that each requirement should be traceable to some design
and code elements. Backward traceability requires that it be possible to trace design and code elements to the requirements
they support. Traceability aids verification and validation.
 Software Engineering 11
Data Flow Diagrams (DFD) or Data Flow Graph or Bubble Chart

A DFD is graphical technique that depicts –

a) The information flow and

b) The transformation activities that are applied on the data, as it moves from input to output.

It’s very useful during software requirements analysis. The DFDs have basic two levels of development, they are as follows –
1) A Level 0 DFD, also known as Fundamental System Model or Context Model, represents the entire system as a single bubble
with incoming arrowed lines as the input data and outgoing arrowed lines as output.

2) A Level 1 DFD might contain 5 or 6 bubbles with interconnecting arrows. Each process represented here is the detailed view
of the functions shown in the level 0 DFD.

 Here the rectangular boxes are used to represent the external entities that may act as input or output outside the system.

 Round Circles are used to represent any kind of transformation process inside the system.

 Arrow headed lines are used to represent the data object and its direction of flow.

A Process Specification (PSPEC) can be used to specify the processing details implied by a bubble within a DFD. It also indicates the
limitations and restrictions imposed on the process.

Following are some guidelines for developing a DFD:-

1) Level 0 DFD should depict the entire software system as a single bubble.

2) Primary input and output should be carefully noted.

3) For the next level of DFD the candidate processes, data objects and stores should be recognized distinctively.

4) All the arrows and bubbles should be labeled with meaningful names.

5) Information flow continuity should be maintained in all the levels.

6) One bubble should be refined at a time.

Output External
Input information entity
External information
entity
Output
Process External
information
(Computer entity
based

External Input Output External

entity information information entity

Fig Data Flow Diagram

 Data Dictionary: - The data dictionary is an organized collection of all data elements related to a system. It contains precise and
complete definitions such that the user and the system analyst will have a common understanding of inputs, outputs, storage components
and intermediate calculations. Some common information found in data dictionaries are as follows:-

1) Name: - It’s the information by which an element in the system can be distinctively recognized.

2) Alias: - It’s a duplicate name for any element.

3) Where-used / how-used: - It’s the listing of the processes that use a particular element and the manner or mode in which the
element is used.

4) Content description: - It contains some standard notations for representing the content of any element.

5) Supplementary notations: - It contains other information about data types, present value, restrictions, and limitations etc,
related to elements of the system.

Advantages of Data Dictionary

1. It is a mechanism for name management – Many people may have to invent names for entities and relationships when developing
a large system model. These names should be used consistently and should not clash. The data dictionary software can check for name
uniqueness where necessary and warn requirements analysts of name duplications.

2. It serves as a store of organizational information – As the system is developed information that can link analysis, design,
implementation and evolution is added to the data dictionary, so that all information about an entity is in one place.

Difference between DFD and ERD

No DFD ERD
1 It is a graphical technique that represents information flow and the transforms It is a graphical technique that represents data objects
that applied as data move form input to output. their relations and associations.
2 It provides a mechanism for functional modeling as well as information flow It provides a mechanism for data modeling.
modeling.
3 It does not contain the relationships among data. It contains the relationships among various entities.

4 Inputs and outputs are represented separately. Inputs and outputs are not represented separately.

5 Classes/objects cannot be clear from DFD i.e. Which data table should be Classes/objects are clear from ERD i.e. which data
kept together. table should be kept together.
6 It can give detailed functional overview of a system. It cannot give detailed functional overview of a
system.

Difference between DRD and Flow Chart

No DFD Flow Chart

1. It is a graphical representation of data flow It is a graphical representation for procedural
in the system. design.
 2. It depicts the functions and sub-functions It cannot depict the sub-functions.
that transform data flow.
3. It cannot depict conditions and loops. It depicts conditions and loops.
4. It provides a mechanism for functional It provides a mechanism for functional modeling.
modeling as well as information modeling.
5. It may be used to represent a system or It may be used to represent a system at only one
software at any level of abstraction. level of abstraction.

HIPO Diagram
HIPO (Hierarchical Input Process Output) diagram is a combination of two organized method to analyze the system and provide the means of
documentation. HIPO model was developed by IBM in year 1970.
HIPO diagram represents the hierarchy of modules in the software system. Analyst uses HIPO diagram in order to obtain high-level view of
system functions. It decomposes functions into sub-functions in a hierarchical manner. It depicts the functions performed by system.
HIPO diagrams are good for documentation purpose. Their graphical representation makes it easier for designers and managers to get the
pictorial idea of the system structure.

In contrast to IPO (Input Process Output) diagram, which depicts the flow of control and data in a module, HIPO does not provide any
information about data flow or control flow.

Example
Both parts of HIPO diagram, Hierarchical presentation and IPO Chart are used for structure design of software program as well as documentation
of the same.

Warnier/Orr diagram
Warnier/Orr diagrams show the processes and sequences in which they are performed. Each process is defined in a hierarchical manner i.e. it
consists of sets of subprocesses, that define it. At each level, the process is shown in bracket that groups its components.
Since a process can have many different subprocesses, Warnier/Orr diagram uses a set of brackets to show each level of the system. Critical
factors in software definition and development are iteration or repetition and alternation. Warnier/Orr diagrams show this very well

Using Warnier/Orr diagrams

To develop a Warnier/Orr diagram, the analyst works backwards, starting with systems output and using output oriented analysis. On paper, the
development moves from the set to the element (from left to right) . First, the intended output or results of the processing are defined. At the next
level, shown by inclusion with a bracket, the steps needed to produce the output are defined. Each step in turn is further defined. Additional
brackets group the processes required to produce the result on the next level.
Warnier/Orr diagrams offer some distinct advantages to systems experts. They are simple in appearance and easy to understand. Yet they are
powerful design tools. They have advantage of showing groupings of processes and the data that must be passed from level to level. In addition,
the sequence of working backwards ensures that the system will be result oriented. This method is useful for both data and process definition. It
can be used for each independently, or both can be combined on the same diagram.

Constructs in Warnier/Orr diagrams

There are four basic constructs used on Warnier/Orr diagrams: hierarchy, sequence, repetition, and alternation. There are also two slightly more
advanced concepts that are occasionally needed: concurrency and recursion.

Hierarchy
Hierarchy is the most fundamental of all of the Warnier/Orr constructs. It is simply a nested group of sets and subsets shown as a set of nested
brackets. Each bracket on the diagram (depending on how you represent it, the character is usually more like a brace "{" than a bracket "[", but we
call them "brackets") represents one level of hierarchy. The hierarchy or structure that is represented on the diagram can show the organization of
data or processing. However, both data and processing are never shown on the same diagram .

Sequence
Sequence is the simplest structure to show on a Warnier/Orr diagram. Within one level of hierarchy, the features listed are shown in the order in
which they occur. In other words, the step listed first is the first that will be executed (if the diagram reflects a process), while the step listed last is
the last that will be executed. Similarly with data, the data field listed first is the first that is encountered when looking at the data, the data field
listed last is the final one encountered.

Repetition
Repetition is the representation of a classic "loop" in programming terms. It occurs whenever the same set of data occurs over and over again (for
a data structure) or whenever the same group of actions is to occur over and over again (for a processing structure). Repetition is indicated by
placing a set of numbers inside parentheses beneath the repeating set.
Typically there are two numbers listed in the parentheses, representing the fewest and the most number of times the set will repeat. By convention
the first letter of the repeating set is the letter chosen to represent the maximum.
While the minimum bound and maximum bound can technically be anything, they are most often either "(1,n)" as in the example, or "(0,n)." When
used to depict processing, the "(1,n)" repetition is classically known as a "DoUntil" loop, while the "(0,n)" repetition is called a "DoWhile" loop.
On the Warnier/Orr diagram, however, there is no distinction between the two different types of repetition, other than the minimum bound value.
On occasion, the minimum and maximum bound are predefined and not likely to change: for instance the set "Day" occurs within the set "Month"
from 28 to 31 times (since the smallest month has 28 days, the largest months, 31). This is not likely to change. And on occasion, the minimum
and maximum are fixed at the same number.
In general, though, it is a bad idea to "hard code" a constant other than "0" or "1" in a number of times clause—the design should be flexible
enough to allow for changes in the number of times without changes to the design. For instance, if a company has 38 employees at the time a
design is done, hard coding a "38" as the "number of employees" within company would certainly not be as flexible as designing "(1,n)".
The number of times clause is always an operator attached to some set (i.e., the name of some bracket), and is never attached to an element (a
diagram feature which does not decompose into smaller features). The reason for this will become more apparent as we continue to work with the
diagrams. For now, you will have to accept this as a formation rule for a correct diagram.

Alternation
Alternation, or selection, is the traditional "decision" process whereby a determination is made to execute one process or another. The Exclusive
OR symbol (the plus sign inside the circle) indicates that the sets immediately above and below it are mutually exclusive (if one is present the
other is not). This diagram indicates that an Employee is either Management or Non-Management, one Employee cannot be both. It is also
permissible to use a "negation bar" above an alternative in a manner similar to engineering notation. The bar is read by simply using the word
"not".
Alternatives do not have to be binary as in the previous examples, but may be many-way alternatives.

Concurrency
Concurrency is one of the two advanced constructs used in the methodology. It is used whenever sequence is unimportant. For instance, years and
weeks operate concurrently (or at the same time) within our calendar. The concurrency operator is rarely used in program design (since most
languages do not support true concurrent processing anyway), but does come into play when resolving logical and physical data structure clashes .

Recursion
Recursion is the least used of the constructs. It is used to indicate that a set contains an earlier or a less ordered version of itself. In the classic "bill
of materials" problem components contain parts and other sub-components. Sub-components also contain sub-sub-components, and so on. The
doubled bracket indicates that the set is recursive. Data structures that are truly recursive are rather rare.

Requirements Elicitation
Requirements elicitation is the process of gathering and defining the requirements for a software system. The goal of requirements elicitation is to
ensure that the software development process is based on a clear and comprehensive understanding of the customer needs and requirements.
Requirements elicitation involves the identification, collection, analysis, and refinement of the requirements for a software system. It is a critical
part of the software development life cycle and is typically performed at the beginning of the project. Requirements elicitation involves
stakeholders from different areas of the organization, including business owners, end-users, and technical experts. The output of the requirements
elicitation process is a set of clear, concise, and well-defined requirements that serve as the basis for the design and development of the software
system.
Requirements elicitation is perhaps the most difficult, most error-prone and most communication intensive software development. It
can be successful only through an effective customer-developer partnership. It is needed to know what the users really need.
Requirements elicitation Activities:
Requirements elicitation includes the subsequent activities. Few of them are listed below –
 Knowledge of the overall area where the systems is applied.
 The details of the precise customer problem where the system are going to be applied must be understood.
 Interaction of system with external requirements.
 Detailed investigation of user needs.
 Define the constraints for system development.
Requirements elicitation Methods:
There are a number of requirements elicitation methods. Few of them are listed below –
1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5. Use Case Approach
The success of an elicitation technique used depends on the maturity of the analyst, developers, users, and
the customer involved.
1. Interviews:
Objective of conducting an interview is to understand the customer’s expectations from the software.
It is impossible to interview every stakeholder hence representatives from groups are selected based on their
expertise and credibility.
Interviews maybe be open-ended or structured.
1. In open-ended interviews there is no pre-set agenda. Context free questions may be asked to
understand the problem.
2. In structured interview, agenda of fairly open questions is prepared. Sometimes a proper questionnaire
is designed for the interview.
2. Brainstorming Sessions:
 It is a group technique
 It is intended to generate lots of new ideas hence providing a platform to share views
 A highly trained facilitator is required to handle group bias and group conflicts.
 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the list of requirements and their priority if possible.
3. Facilitated Application Specification Technique:
It’s objective is to bridge the expectation gap – difference between what the developers think they are
supposed to build and what customers think they are going to get.
A team oriented approach is developed for requirements gathering.
Each attendee is asked to make a list of objects that are-
1. Part of the environment that surrounds the system
2. Produced by the system
3. Used by the system
Each participant prepares his/her list, different lists are then combined, redundant entries are eliminated, team
is divided into smaller sub-teams to develop mini-specifications and finally a draft of specifications is written
down using all the inputs from the meeting.
4. Quality Function Deployment:
In this technique customer satisfaction is of prime concern, hence it emphasizes on the requirements which
are valuable to the customer.
3 types of requirements are identified –
 Normal requirements –
In this the objective and goals of the proposed software are discussed with the customer. Example – normal
requirements for a result management system may be entry of marks, calculation of results, etc
 Expected requirements –
These requirements are so obvious that the customer need not explicitly state them. Example – protection
from unauthorized access.
 Exciting requirements –
It includes features that are beyond customer’s expectations and prove to be very satisfying when present.
Example – when unauthorized access is detected, it should backup and shutdown all processes.
The major steps involved in this procedure are –
1. Identify all the stakeholders, eg. Users, developers, customers etc
2. List out all requirements from customer.
3. A value indicating degree of importance is assigned to each requirement.
4. In the end the final list of requirements is categorized as –
 It is possible to achieve
 It should be deferred and the reason for it
 It is impossible to achieve and should be dropped off
5. Use Case Approach:
This technique combines text and pictures to provide a better understanding of the requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a functional view of the
system.
The components of the use case design includes three major things – Actor, Use cases, use case diagram.
1. Actor –
It is the external agent that lies outside the system but interacts with it in some way. An actor maybe a
person, machine etc. It is represented as a stick figure. Actors can be primary actors or secondary actors.
 Primary actors – It requires assistance from the system to achieve a goal.
 Secondary actor – It is an actor from which the system needs assistance.
2. Use cases –
They describe the sequence of interactions between actors and the system. They capture who(actors) do
what(interaction) with the system. A complete set of use cases specifies all possible ways to use the
system.
3. Use case diagram –
A use case diagram graphically represents what happens when an actor interacts with a system. It captures
the functional aspect of the system.
  A stick figure is used to represent an actor.
 An oval is used to represent a use case.
 A line is used to represent a relationship between an actor and a use case.

ADVANTAGES OR DISADVANTAGES:

Advantages of Requirements Elicitation:

 Helps to clarify and refine the customer requirements.

 Improves communication and collaboration between stakeholders.
 Increases the chances of developing a software system that meets the customer needs.
 Avoids misunderstandings and helps to manage expectations.
 Supports the identification of potential risks and problems early in the development cycle.
 Facilitates the development of a comprehensive and accurate project plan.
 Increases user and stakeholder confidence in the software development process.
 Supports the identification of new business opportunities and revenue streams.

Disadvantages of Requirements Elicitation:

 Can be time-consuming and expensive.

 Requires specialized skills and expertise.
 May be impacted by changing business needs and requirements.
 Can be impacted by political and organizational factors.
 Can result in a lack of buy-in and commitment from stakeholders.
 Can be impacted by conflicting priorities and competing interests.
 May result in incomplete or inaccurate requirements if not properly managed.
 Can lead to increased development costs and decreased efficiency if requirements are not well-defined.

Functional Point (FP) Analysis

Allan J. Albrecht initially developed function Point Analysis in 1979 at IBM and it has been further
modified by the International Function Point Users Group (IFPUG). FPA is used to make estimate of
the software project, including its testing in terms of functionality or function size of the software
product. However, functional point analysis may be used for the test estimation of the product. The
functional size of the product is measured in terms of the function point, which is a standard of
measurement to measure the software application.
Objectives of FPA
The basic and primary purpose of the functional point analysis is to measure and provide the
software application functional size to the client, customer, and the stakeholder on their request.
Further, it is used to measure the software project development along with its maintenance,
consistently throughout the project irrespective of the tools and the technologies.

Following are the points regarding FPs

1. FPs of an application is found out by counting the number and types of functions used in the
applications. Various functions used in an application can be put under five types, as shown in Table:

Play Video

Types of FP Attributes

Measurements Parameters Examples

[Link] of External Inputs(EI) Input screen and tables

2. Number of External Output (EO) Output screens and reports

3. Number of external inquiries (EQ) Prompts and interrupts.

4. Number of internal files (ILF) Databases and directories

5. Number of external interfaces (EIF) Shared databases and shared routines.

All these parameters are then individually assessed for complexity.

The FPA functional units are shown in Fig:

2. FP characterizes the complexity of the software system and hence can be used to depict the
project time and the manpower requirement.
3. The effort required to develop the project depends on what the software does.

4. FP is programming language independent.

5. FP method is used for data processing systems, business systems like information systems.

6. The five parameters mentioned above are also known as information domain characteristics.

7. All the parameters mentioned above are assigned some weights that have been experimentally
determined and are shown in Table

Weights of 5-FP Attributes

Measurement Parameter Low Average High

1. Number of external inputs (EI) 7 10 15

2. Number of external outputs (EO) 5 7 10

3. Number of external inquiries (EQ) 3 4 6

4. Number of internal files (ILF) 4 5 7

5. Number of external interfaces (EIF) 3 4 6

The functional complexities are multiplied with the corresponding weights against each function, and
the values are added up to determine the UFP (Unadjusted Function Point) of the subsystem.

Here that weighing factor will be simple, average, or complex for a measurement parameter type.

The Function Point (FP) is thus calculated with the following formula.

FP = Count-total * [0.65 + 0.01 * ∑(fi)]

= Count-total * CAF
where Count-total is obtained from the above Table.

CAF = [0.65 + 0.01 *∑(fi)]

and ∑(fi) is the sum of all 14 questionnaires and show the complexity adjustment value/ factor-CAF
(where i ranges from 1 to 14). Usually, a student is provided with the value of ∑(f i)

Also note that ∑(fi) ranges from 0 to 70, i.e.,

0 <= ∑(fi) <=70

and CAF ranges from 0.65 to 1.35 because

a. When ∑(fi) = 0 then CAF = 0.65

b. When ∑(fi) = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 = 1.35

Based on the FP measure of software many other metrics can be computed:

a. Errors/FP
b. $/FP.
c. Defects/FP
d. Pages of documentation/FP
e. Errors/PM.
f. Productivity = FP/PM (effort is measured in person-months).
g. $/Page of Documentation.

8. LOCs of an application can be estimated from FPs. That is, they are interconvertible. This
process is known as backfiring. For example, 1 FP is equal to about 100 lines of COBOL code.

9. FP metrics is used mostly for measuring the size of Management Information System (MIS)
software.

10. But the function points obtained above are unadjusted function points (UFPs). These (UFPs) of a
subsystem are further adjusted by considering some more General System Characteristics (GSCs). It
is a set of 14 GSCs that need to be considered. The procedure for adjusting UFPs is as follows:

a. Degree of Influence (DI) for each of these 14 GSCs is assessed on a scale of 0 to 5. (b) If a
particular GSC has no influence, then its weight is taken as 0 and if it has a strong influence then its
weight is 5.
b. The score of all 14 GSCs is totaled to determine Total Degree of Influence (TDI).
c. Then Value Adjustment Factor (VAF) is computed from TDI by using the formula: VAF =
(TDI * 0.01) + 0.65

Remember that the value of VAF lies within 0.65 to 1.35 because

a. When TDI = 0, VAF = 0.65

b. When TDI = 70, VAF = 1.35
c. VAF is then multiplied with the UFP to get the final FP count: FP = VAF * UFP

Example: Compute the function point, productivity, documentation, cost per function for the
following data:
 1. Number of user inputs = 24
2. Number of user outputs = 46
3. Number of inquiries = 8
4. Number of files = 4
5. Number of external interfaces = 2
6. Effort = 36.9 p-m
7. Technical documents = 265 pages
8. User documents = 122 pages
9. Cost = $7744/ month

Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5.

Solution:

Measurement Parameter Count Weighing factor

1. Number of external inputs (EI) 24 * 4 = 96

2. Number of external outputs (EO) 46 * 4 = 184

3. Number of external inquiries (EQ) 8 * 6 = 48

4. Number of internal files (ILF) 4 * 10 = 40

5. Number of external interfaces (EIF) Count-total → 2 * 5 = 10

378

So sum of all fi (i ← 1 to 14) = 4 + 1 + 0 + 3 + 5 + 4 + 4 + 3 + 3 + 2 + 2 + 4 + 5 = 43

FP = Count-total * [0.65 + 0.01 *∑(fi)]

= 378 * [0.65 + 0.01 * 43]
= 378 * [0.65 + 0.43]
= 378 * 1.08 = 408

Total pages of documentation = technical document + user document

= 265 + 122 = 387pages

Documentation = Pages of documentation/FP

= 387/408 = 0.94

COCOMO Model
Boehm proposed COCOMO (Constructive Cost Estimation Model) in [Link] is one of the most generally used
software estimation models in the world. COCOMO predicts the efforts and schedule of a software product based on
the size of the software.

The necessary steps in this model are:

1. Get an initial estimate of the development effort from evaluation of thousands of delivered lines of source
code (KDLOC).
2. Determine a set of 15 multiplying factors from various attributes of the project.
3. Calculate the effort estimate by multiplying the initial estimate with all the multiplying factors i.e., multiply
the values in step1 and step2.

The initial estimate (also called nominal estimate) is determined by an equation of the form used in the static single
variable models, using KDLOC as the measure of the size. To determine the initial effort E i in person-months the
equation used is of the type is shown below

Ei=a*(KDLOC)bPlay Video

The value of the constant a and b are depends on the project type.

In COCOMO, projects are categorized into three types:

1. Organic
2. Semidetached
3. Embedded

[Link]: A development project can be treated of the organic type, if the project deals with developing a well-
understood application program, the size of the development team is reasonably small, and the team members are
experienced in developing similar methods of projects. Examples of this type of projects are simple business
systems, simple inventory management systems, and data processing systems.

2. Semidetached: A development project can be treated with semidetached type if the development consists of a
mixture of experienced and inexperienced staff. Team members may have finite experience in related systems but
may be unfamiliar with some aspects of the order being developed. Example of Semidetached system includes
developing a new operating system (OS), a Database Management System (DBMS), and complex
inventory management system.

3. Embedded: A development project is treated to be of an embedded type, if the software being developed is
strongly coupled to complex hardware, or if the stringent regulations on the operational method exist. For
Example: ATM, Air Traffic control.

For three product categories, Bohem provides a different set of expression to predict effort (in a unit of person
month)and development time from the size of estimation in KLOC(Kilo Line of code) efforts estimation takes into
account the productivity loss due to holidays, weekly off, coffee breaks, etc.

According to Boehm, software cost estimation should be done through three stages:

1. Basic Model
2. Intermediate Model
3. Detailed Model

1. Basic COCOMO Model: The basic COCOMO model provide an accurate size of the project parameters. The
following expressions give the basic COCOMO estimation model:

Effort=a1*(KLOC)a2 PM
Tdev=b1*(efforts)b2 Months
Where

KLOC is the estimated size of the software product indicate in Kilo Lines of Code,

a1,a2,b1,b2 are constants for each group of software products,

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

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: Effort = 2.4(KLOC) 1.05 PM

Semi-detached: 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 below:

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

Some insight into the basic COCOMO model can be obtained by plotting the estimated characteristics for different
software sizes. Fig shows a plot of estimated effort versus product size. From fig, we can observe that the effort is
somewhat superliner in the size of the software product. Thus, the effort required to develop a product increases
very rapidly with project size.

Effort is the total effort required to develop the software product, expressed in person months (PMs).

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: Effort = 2.4(KLOC) 1.05 PM

Semi-detached: 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 below:

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

Some insight into the basic COCOMO model can be obtained by plotting the estimated characteristics for different
software sizes. Fig shows a plot of estimated effort versus product size. From fig, we can observe that the effort is
somewhat superliner in the size of the software product. Thus, the effort required to develop a product increases
very rapidly with project size.

The development time versus the product size in KLOC is plotted in fig. From fig it can be observed that the
development time is a sub linear function of the size of the product, i.e. when the size of the product increases by
two times, the time to develop the product does not double but rises moderately. This can be explained by the fact
that for larger products, a larger number of activities which can be carried out concurrently can be identified. The
parallel activities can be carried out simultaneously by the engineers. This reduces the time to complete the project.
Further, from fig, it can be observed that the development time is roughly the same for all three categories of
products. For example, a 60 KLOC program can be developed in approximately 18 months, regardless of whether it
is of organic, semidetached, or embedded type.

From the effort estimation, the project cost can be obtained by multiplying the required effort by the manpower cost
per month. But, implicit in this project cost computation is the assumption that the entire project cost is incurred on
account of the manpower cost alone. In addition to manpower cost, a project would incur costs due to hardware and
software required for the project and the company overheads for administration, office space, etc.

It is important to note that the effort and the duration estimations obtained using the COCOMO model are called a
nominal effort estimate and nominal duration estimate. The term nominal implies that if anyone tries to complete
the project in a time shorter than the estimated duration, then the cost will increase drastically. But, if anyone
completes the project over a longer period of time than the estimated, then there is almost no decrease in the
estimated cost value.
Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and development time for each of
the three model i.e., organic, semi-detached & embedded.

Solution: The basic COCOMO equation takes the form:

Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Estimated Size of project= 400 KLOC

(i)Organic Mode

E = 2.4 * (400)1.05 = 1295.31 PM

D = 2.5 * (1295.31)0.38=38.07 PM

(ii)Semidetached Mode

E = 3.0 * (400)1.12=2462.79 PM
D = 2.5 * (2462.79)0.35=38.45 PM

(iii) Embedded Mode

E = 3.6 * (400)1.20 = 4772.81 PM

D = 2.5 * (4772.8)0.32 = 38 PM

Example2: A project size of 200 KLOC is to be developed. Software development team has average experience on
similar type of projects. The project schedule is not very tight. Calculate the Effort, development time, average staff
size, and productivity of the project.

Solution: The semidetached mode is the most appropriate mode, keeping in view the size, schedule and experience
of development time.

Hence E=3.0(200)1.12=1133.12PM
D=2.5(1133.12)0.35=29.3PM

P = 176 LOC/PM

2. Intermediate Model: The basic Cocomo model considers that the effort is only a function of the number of lines
of code and some constants calculated according to the various software systems. The intermediate COCOMO model
recognizes these facts and refines the initial estimates obtained through the basic COCOMO model by using a set of
15 cost drivers based on various attributes of software engineering.

Classification of Cost Drivers and their attributes:

(i) Product attributes -

o Required software reliability extent

o Size of the application database
o The complexity of the product

Hardware attributes -
 o Run-time performance constraints
o Memory constraints
o The volatility of the virtual machine environment
o Required turnabout time

Personnel attributes -

o Analyst capability
o Software engineering capability
o Applications experience
o Virtual machine experience
o Programming language experience

Project attributes -

o Use of software tools

o Application of software engineering methods
o Required development schedule

The cost drivers are divided into four categories:

Intermediate COCOMO equation:

E=ai (KLOC) bi*EAF

D=ci (E)di
 Coefficients for intermediate COCOMO

Project ai bi ci di

Organic 2.4 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

3. Detailed COCOMO Model:Detailed COCOMO incorporates all qualities of the standard version with an
assessment of the cost driver?s effect on each method of the software engineering process. The detailed model uses
various effort multipliers for each cost driver property. In detailed cocomo, the whole software is differentiated into
multiple modules, and then we apply COCOMO in various modules to estimate effort and then sum the effort.

The Six phases of detailed COCOMO are:

1. Planning and requirements

2. System structure
3. Complete structure
4. Module code and test
5. Integration and test
6. Cost Constructive model

The effort is determined as a function of program estimate, and a set of cost drivers are given according to every
phase of the software lifecycle.

The development time versus the product size in KLOC is plotted in fig. From fig it can be observed that the
development time is a sub linear function of the size of the product, i.e. when the size of the product increases by
two times, the time to develop the product does not double but rises moderately. This can be explained by the fact
that for larger products, a larger number of activities which can be carried out concurrently can be identified. The
parallel activities can be carried out simultaneously by the engineers. This reduces the time to complete the project.
Further, from fig, it can be observed that the development time is roughly the same for all three categories of
products. For example, a 60 KLOC program can be developed in approximately 18 months, regardless of whether it
is of organic, semidetached, or embedded type.

From the effort estimation, the project cost can be obtained by multiplying the required effort by the manpower cost
per month. But, implicit in this project cost computation is the assumption that the entire project cost is incurred on
account of the manpower cost alone. In addition to manpower cost, a project would incur costs due to hardware and
software required for the project and the company overheads for administration, office space, etc.

It is important to note that the effort and the duration estimations obtained using the COCOMO model are called a
nominal effort estimate and nominal duration estimate. The term nominal implies that if anyone tries to complete
the project in a time shorter than the estimated duration, then the cost will increase drastically. But, if anyone
completes the project over a longer period of time than the estimated, then there is almost no decrease in the
estimated cost value.

Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and development time for each of
the three model i.e., organic, semi-detached & embedded.

Solution: The basic COCOMO equation takes the form:

Effort=a1*(KLOC)a2 PM
Tdev=b1*(efforts)b2 Months
Estimated Size of project= 400 KLOC

(i)Organic Mode

E = 2.4 * (400)1.05 = 1295.31 PM

D = 2.5 * (1295.31)0.38=38.07 PM

(ii)Semidetached Mode

E = 3.0 * (400)1.12=2462.79 PM
D = 2.5 * (2462.79)0.35=38.45 PM

(iii) Embedded Mode

 E = 3.6 * (400)1.20 = 4772.81 PM
D = 2.5 * (4772.8)0.32 = 38 PM

Example2: A project size of 200 KLOC is to be developed. Software development team has average experience on
similar type of projects. The project schedule is not very tight. Calculate the Effort, development time, average staff
size, and productivity of the project.

Solution: The semidetached mode is the most appropriate mode, keeping in view the size, schedule and experience
of development time.

Hence E=3.0(200)1.12=1133.12PM
D=2.5(1133.12)0.35=29.3PM

P = 176 LOC/PM

2. Intermediate Model: The basic Cocomo model considers that the effort is only a function of the number of lines
of code and some constants calculated according to the various software systems. The intermediate COCOMO model
recognizes these facts and refines the initial estimates obtained through the basic COCOMO model by using a set of
15 cost drivers based on various attributes of software engineering.

Classification of Cost Drivers and their attributes:

(i) Product attributes -

o Required software reliability extent

o Size of the application database
o The complexity of the product

Hardware attributes -

o Run-time performance constraints

o Memory constraints
o The volatility of the virtual machine environment
o Required turnabout time

Personnel attributes -

o Analyst capability
o Software engineering capability
o Applications experience
o Virtual machine experience
o Programming language experience

Project attributes -

o Use of software tools

o Application of software engineering methods
 o Required development schedule

The cost drivers are divided into four categories:

Intermediate COCOMO equation:

 E=ai (KLOC) bi*EAF
D=ci (E)di

Coefficients for intermediate COCOMO

Project ai bi ci di

Organic 2.4 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

3. Detailed COCOMO Model:Detailed COCOMO incorporates all qualities of the standard version with an
assessment of the cost driver?s effect on each method of the software engineering process. The detailed model uses
various effort multipliers for each cost driver property. In detailed cocomo, the whole software is differentiated into
multiple modules, and then we apply COCOMO in various modules to estimate effort and then sum the effort.

The Six phases of detailed COCOMO are:

1. Planning and requirements

2. System structure
3. Complete structure
4. Module code and test
5. Integration and test
6. Cost Constructive model

The effort is determined as a function of program estimate, and a set of cost drivers are given according to every
phase of the software lifecycle.

COCOMO-II is the revised version of the original Cocomo (Constructive Cost Model) and is developed at
University of Southern California. It is the model that allows one to estimate the cost, effort and schedule when
planning a new software development activity.
It consists of three sub-models:
1. End User Programming:
Application generators are used in this sub-model. End user write the code by using these application
generators.
Example – Spreadsheets, report generator, etc.
2. Intermediate Sector:

 (a). Application Generators and Composition Aids –

This category will create largely prepackaged capabilities for user programming. Their product will have
many reusable components. Typical firms operating in this sector are Microsoft, Lotus,
Oracle, IBM, Borland, Novell.
 (b). Application Composition Sector –
This category is too diversified and to be handled by prepackaged solutions. It includes GUI, Databases,
domain specific components such as financial, medical or industrial process control packages.
 (c). System Integration –
This category deals with large scale and highly embedded systems.
3. Infrastructure Sector:
This category provides infrastructure for the software development like Operating System, Database
Management System, User Interface Management System, Networking System, etc.
Stages of COCOMO II:
1. Stage-I:
It supports estimation of prototyping. For this it uses Application Composition Estimation Model. This model
is used for the prototyping stage of application generator and system integration.
2. Stage-II:
It supports estimation in the early design stage of the project, when we less know about it. For this it
uses Early Design Estimation Model. This model is used in early design stage of application generators,
infrastructure, system integration.
3. Stage-III:
It supports estimation in the post architecture stage of a project. For this it uses Post Architecture
Estimation Model. This model is used after the completion of the detailed architecture of application
generator, infrastructure, system integration.

Earned Value Management (EVM)

Earned Value Management (EVM) is a technique that is used to track the progress and status of a project and forecast its likely
future performance.
This is a brief tutorial that acquaints the reader with the basics of EVM and explains how to utilize it for better project management.
Earned Value Management (EVM) is a project management technique that objectively tracks physical accomplishment of work.
More elaborately:
 EVM is used to track the progress and status of a project and forecasts the likely future performance of the project.
 EVM integrates the scope, schedule, and cost of a project.
 EVM answers a lot of questions to the stakeholders in a project related to its performance.
 EVM can be used to show the past and the current performance of a project and predict the future performance of the project
by the use of statistical techniques.
 Good planning coupled with effective use of EVM will reduce a lot of issues arising out of schedule and cost overruns.
EVM has emerged as a financial analysis specialty in United States Government programs in the 1960s, but it has since become a
significant branch of project management.
In the late 1980s and early 1990s, EVM emerged as a project management methodology to be understood and used by managers
and executives, not just EVM specialists. Today, EVM has become an essential part of every project tracking.
EVM consists of the following three basic elements:

 Planned Value
 Actual Cost
 Earned Value
All the three elements are captured on a regular basis as of a reporting date.

Planned Value
Planned value (PV) is also referred to as Budgeted Cost of Work Scheduled (BCWS). PV or BCWS is the total cost of the work
scheduled/planned as of a reporting date.
It is calculated as:
PV or BCWS = Hourly Rate × Total Hours Planned or Scheduled
NOTE: Hourly Rate is the rate at which effort will be valued.

Actual Cost
Actual cost (AC) is also referred to as Actual Cost of Work Performed (ACWP). AC or ACWP is the total cost taken to complete the
work as of a reporting date.
It is calculated as:
AC or ACWP = Hourly Rate × Total Hours Spent

Earned Value
Earned value (EV) is also referred to as Budgeted Cost of Work Performed (BCWP). EV or BCWP is the total cost of the work
completed/performed as of a reporting date.
It is calculated as:
EV or BCWP = Baselined Cost × % Complete Actual
All these three elements can be derived from Work Breakdown Structure by associating the costs to each of the tasks. For a big
project, it will be a tedious task to calculate these elements manually. Scheduling software tools like Microsoft Project is used to
calculate these three elements.
NOTE: % Completed Planned and % Completed Actual are defined below.

% Completed Planned
The percentage of work which was planned to be completed by the Reporting Date. It is calculated using the following formula:
% Completed Planned = PV / BAC

% Completed Actual
The percentage of work which was actually completed by the Reporting Date. It is calculated using the following formula:
% Completed Actual = AC / EAC
Cost Variance (CV) is a very important factor to measure project performance. CV indicates how much over - or under-budget the
project is.
CV can be calculated using the following formula:
Cost Variance (CV) = Earned Value (EV) − Actual Cost (AC)
OR
Cost Variance (CV) = BCWP − ACWP
 The formula mentioned above gives the variance in terms of cost.
 Positive CV indicates the project is under-budget.
 Negative CV indicates the project is over-budget.

Cost Variance %
Cost Variance % indicates how much over - or under-budget the project is in terms of percentage.
Cost Variance % can be calculated using the following formula:
CV % = Cost Variance (CV) ⁄ Earned Value (EV)
OR
CV % = CV ⁄ BCWP
 The formula mentioned above gives the variance in terms of percentage.
 Positive Variance % indicates % under budget
 Negative Variance % indicates % over budget.
Cost Performance Indicator
Cost Performance Indicator (CPI) is an index showing the efficiency of the utilization of the resources on the project. CPI can be
calculated using the following formula:
CPI = Earned Value (EV) ⁄ Actual Cost (AC)
OR
CPI = BCWP ⁄ ACWP
 The formula mentioned above gives the efficiency of the utilization of the resources allocated to the project.
 A CPI value above 1 indicates the efficiency of utilizing the resources allocated to the project is good.
 A CPI value below 1 indicates the efficiency of utilizing the resources allocated to the project is not good.

To Complete Cost Performance Indicator

To Complete Cost Performance Indicator (TCPI) is an index showing the efficiency at which the resources on the project should be
utilized for the remainder of the project. It can be calculated using the following formula:
TCPI = ( Total Budget − EV ) ⁄ ( Total Budget − AC )
OR
TCPI = ( Total Budget − BCWP ) ⁄ ( Total Budget − ACWP )
 The formula mentioned above gives the efficiency at which the project team should be utilized for the remainder of the
project.
 A TCPI value above 1 indicates the utilization of the project team for the remainder of the project can be stringent.
 A TCPI value below 1 indicates the utilization of the project team for the remainder of the project should be lenient.
Schedule Variance (SV) indicates how much ahead or behind the schedule a project is running.
It can be calculated using the following formula:
Schedule Variance (SV) = Earned Value (EV) − Planned Value (PV)
OR
Schedule Variance (SV) = BCWP − BCWS
 The formula mentioned above gives the variance in terms of cost which indicates how much cost of the work is yet to be
completed as per schedule or how much cost of work has been completed over and above the scheduled cost.
 A positive SV indicates we are ahead of schedule.
 A negative SV indicates we are behind schedule.

Schedule Variance %
Schedule Variance % indicates how much ahead or behind the schedule a project is running in terms of percentage.
Schedule Variance % can be calculated using the following formula:
SV % = Schedule Variance (SV) ⁄ Planned Value (PV)
OR
SV % = SV ⁄ BCWS
 The formula mentioned above gives the variance in terms of percentage which indicates how much percentage of work is yet
to be completed as per schedule or how much percentage of work has been completed over and above the scheduled cost.
 Positive Variance % indicates % ahead of schedule.
 Negative Variance % indicates % behind of schedule.

Schedule Performance Indicator

Schedule Performance Indicator (SPI) is an index showing the efficiency of the time utilized on the project. SPI can be calculated
using the following formula:
SPI = Earned Value (EV) ⁄ Planned Value (PV)
OR
SPI = BCWP ⁄ BCWS
 The formula mentioned above gives the efficiency of the project team in utilizing the time allocated for the project.
 An SPI value above 1 indicates the project team is very efficient in utilizing the time allocated to the project.
 An SPI value below 1 indicates the project team is less efficient in utilizing the time allocated to the project.
To Complete Schedule Performance Indicator
To Complete Schedule Performance Indicator (TSPI) is an index showing the efficiency at which the remaining time on the project
should be utilized. It can be calculated using the following formula:
TSPI = ( Total Budget − EV ) ⁄ ( Total Budget − PV )
OR
TSPI = ( Total Budget − BCWP ) ⁄ ( Total Budget − BCWS )
 The formula mentioned above gives the efficiency at which the project team should utilize the remaining time allocated for
the project.
 A TSPI value below 1 indicates the project team can be lenient in utilizing the remaining time allocated to the project.
 A TSPI value above 1 indicates the project team needs to work harder in utilizing the remaining time allocated to the project.

Budget at Completion
 Budget at Completion (BAC) is the total budget allocated to the project.
 BAC is generally plotted over time. For example, periods of reporting (Monthly, Weekly, etc.)
 BAC is used to compute the Estimate at Completion (EAC), explained in the next section.
 BAC is also used to compute the TCPI and TSPI.
BAC is calculated using the following formula:
BAC = Baselined Effort − hours × Hourly Rate

Estimate to Complete
 Estimate to Complete (ETC) is the estimated cost required to complete the remainder of the project.
 ETC is calculated and applied when the past estimating assumptions become invalid and a need for fresh estimates arises.
 ETC is used to compute the Estimation at Completion (EAC).

Estimate at Completion
Estimate at Completion (EAC) is the estimated cost of the project at the end of the project.
There are three methods to calculate EAC:
 Variances are typical - This method is used when the variances at the current stage are typical and are not expected to
occur in the future.
 Past estimating assumptions are not valid - This method is used when the past estimating assumptions are not valid and
fresh estimates are applied to the project.
 Variances will be present in the future - This method is used when the assumption is that the current variances will
continue to be present in the future.
The formulas for calculation of the three methods are as given below:

 AC + (BAC − EV)
 AC + ETC (Estimate To Complete)
 AC + (BAC − EV) ⁄ CPI

Variance at Completion
Variance at completion (VAC) is the variance on the total budget at the end of the project.
This is the difference between what the project was originally expected (baselined) to cost versus what it is now expected to cost.
VAC is calculated using the following formula:
VAC = BAC − EAC

% Completed Planned
The percentage of work which was planned to be completed by the Reporting Date. It is calculated using the following formula:
% Completed Planned = PV ⁄ BAC
% Completed Actual
The percentage of work which was actually completed by the Reporting Date. It is calculated using the following formula:
% Completed Actual = AC ⁄ EAC
To illustrate the concept of EVM and all the formulas, assume a project that has exactly one task. The task was baselined at 8 hours,
but 11 hours have been spent and the estimate to complete is 1 additional hour. The task would have been completed already.
Assume an Hourly Rate of $100 per hour.
Using this information -
PV or BCWS = Hourly Rate × Total Hours Planned or Scheduled
PV = $100 × 8 hours = $800
AC or ACWP = Hourly Rate × Total Hours Spent
AC = $100 × 11 hours = $1100
EV or BCWP = Baselined Cost × % Complete Actual
EV = baseline of $800 × 91.7% complete = $734
(NOTE % Complete Actual (below) to get the 91.7%)
BAC = Baselined Effort − hours × Hourly Rate
BAC = 8 hours × $100 = $800
EAC = AC + ETC
EAC = 1100 + 100 = $1200
VAC = BAC − EAC
VAC = $800 − $1200 = −$400
% Completed Planned = PV ⁄ BAC
% Complete Planned = $800 PV ⁄ $800 BAC = 100%
% Completed Actual = AC ⁄ EAC
% Complete Actual = $1100 AC ⁄ $1200 EAC = 91.7%
SV = Earned Value (EV) − Planned Value (PV)
SV = $734 EV − $800 PV = −$66
SPI = Earned Value (EV) ⁄ Planned Value (PV)
SPI = $734 EV ⁄ $800 PV = 0.91
CV = Earned Value (EV) − Actual Cost (AC)
CV = ($734 EV − $1100 AC) = −$366*
* indicates a cost overrun
CPI = Earned Value (EV) ⁄ Actual Cost (AC)
CPI = $734 EV ⁄ $1100 AC = 0.66*
* indicates over-budget