Unit-1

Introduction to
Software & Software Engineering

Reference Book:
Software Engineering -A Practitioner’s Approach (Seventh Edition) -
Roger S. Pressman.

Chapter 1: Software & Software Engineering

Chapter 2: Process Models(till 2.3)
 Outline
✓ Looping
▪ Software, Characteristics of Software, Software Application Domains
▪ Software Engineering
▪ Software Myths
• Management Myth
• Customer Myth
• Practitioner's/Developer Myth)
▪ Software Engineering Layered Approach
▪ Software Process, Process Framework Activities , Umbrella Activities
▪ Software Process Models
• The Waterfall Model
• Incremental Process Model
• Prototyping Model, Spiral Model
• Spiral Model
• Rapid Application Development Model (RAD)
▪ Component based Development
What is Software?

Software is
1)Computer program that when executed provide desired features, function & performance
2)Data Structure that enable programs to easily manipulate information
3)Descriptive information in both hard and soft copy that describes the operation and use of
programs

+ +
Computer Data Documents
Program Structur Soft &
e Hard
 Program vs Software:

● A program is a set of ● Software is when a program is made

instructions that are given to a available for commercial business
computer in order to achieve a and is properly documented along
specific task with its licensing.

● A program is one of the stages ● Software development usually

involved in the development of follows a life cycle
the software. - which involves the feasibility study
of the project, requirement
gathering, development of a
prototype, system design, coding,
and testing.

Software=Program+documentation+licensing.
Dual Role of Software: It is both a product and a vehicle for delivering a product

Software is a product
● Delivers computing potential
● Produces, manages, acquires, modifies, displays, or transmits
information
● Modern software is developed by teams of software specialists
Software is a vehicle for delivering a product
● Supports or directly provides system functionality
● Controls other programs (e.g., an operating system)
● Effects communications (e.g., networking software)
● Helps build other software (e.g., software tools)
Software is dead…..!
� The old School view of Software
⮩ You buy it
⮩ You own it &
⮩ It’s your job to manage it
⮩ That is coming to an end

� Because of web 2.0 & extensive computing power,

there is a different generation of software
⮩ It is delivered via Internet
⮩ It looks exactly like it’s residing on each user’s
computing device
⮩ Actually it reside on far away server
Characteristics of Software
� Software is developed or engineered
⮩ It is not manufactured like hardware
▪ Manufacturing phase can introduce quality problem that are nonexistent (or easily
corrected) for software
▪ Both requires construction of “product” but approaches are different
� Software doesn’t “wear-out”- But it does deteriorate! Increate failure rate due to
Chang side effect
e
Infant
“Wear
moralit
out”
y
Actual
Failure

Failure
Curve
Rate

Rate
Idealized
Tim Tim
Curve
e e
Bathtub curve of hardware failure Software failure curve
Characterics of Software

● Although the industry is moving toward component-based

construction, most software continues to be custom built.
● It can be complex, meaning it can have many interrelated parts and
features.
● It can be affected by changing requirements, meaning it may need to
be updated or modified as the needs of users change.
● It can be affected by bugs and other issues, meaning it may need to
be tested and debugged to ensure it works as intended.
Software Application Domains

System
Software
Point of Sale,
Artificial Customized
Application
intelligence Software
Software
Software

Software
Application Engineering
Web
Domains / Scientific
Application
Software

Product line Embedded

Software Software
Software Application Domains
System software—a collection of programs written to service other
programs. The systems software area is characterized by heavy interaction
with computer hardware; heavy usage by multiple users; concurrent
operation that requires scheduling, resource sharing, and sophisticated
process management; complex data structures; and multiple external
interfaces.(it is a program used to manage the other program. Ex: operating
system, compiler , different device drivers)
Application software—stand-alone programs that solve a specific business
need. Applications in this area process business or technical data in a way
that facilitates business operations or management/technical decision
Engineering/scientific software—has been characterized by “number crunching” algorithms.
Applications range from astronomy to volcanology, from automotive stress analysis to
space shuttle orbital dynamics, and from molecular biology to automated manufacturing.

Embedded software—resides within a product or system and is used to implement and

control features and functions for the end user and for the system itself. Embedded
software can perform limited and esoteric functions (e.g., keypad control for a microwave
oven) or provide significant function and control capability (e.g., digital functions in an
automobile such as fuel control).

Product-line software—designed to provide a specific capability for use by many different

customers. Product-line software can focus on a limited and esoteric marketplace (e.g.,
inventory control products) or address mass consumer markets (e.g., word processing,
spreadsheets, computer graphics).
Artificial intelligence software—makes use of non-numerical algorithms to
solve complex problems that are not amenable to computation or
straightforward analysis. Applications within this area include robotics,
expert systems, pattern recognition (image and voice), artificial neural
networks.
Web applications—called “WebApps,” s can be little more than a set of
linked hypertext files that present information using text and limited
graphics. WebApps are evolving into sophisticated computing environments
that not only provide stand-alone features, and content to the end user, but
also are integrated with corporate databases and business applications.
The IEEE has developed a more comprehensive definition when it
states:

Engineering is the process of designing and building something

that serves a particular purpose and finds a cost-effective
solution to problems.

Software Engineering is a systematic, disciplined, quantifiable

study and approach to the design, development, operation, and
maintenance of a software system.
Why to Study Software Engineering?
Software Development Life Cycle without Software
Engineering

1 2 3 4 5
How the How the How the How the How the
Customer Project System Programmer Business
Explains Leader Analyst Works Consultant
Requirement understand it design it on it describe it
Why to Study Software Engineering?
Software Development Life Cycle without Software
Engineering

6 7 8 9 10

How the What How the How it What the

Project Operations Customer is was customer
documented Installed billed supported really needed
Why to Study Software Engineering?
SDLC without Software Engineering

Customer Requirement Solution The software

• Have one trunk • Have one trunk development
• Have four legs • Have four legs process needs to be
• Should carry load both • Should carry load both engineered
passenger & cargo passenger & cargo
• Black in color • Black in color
to avoid the
• Should be herbivorous • Should be herbivorous communication gap
& to meet the actual
Our value requirements of
customer
added,
within stipulated budget
also gives & time
milk
Objectives of Software Engineering:
Functionality:
It refers to the degree of performance of the software against its intended purpose.
Reliability:
A set of attributes that bears on the capability of software to maintain its level of
performance under the given condition for a stated period of time.
Efficiency:
It refers to the ability of the software to use system resources in the most effective
and efficient manner. The software should make effective use of storage space and
executive command as per desired timing requirements.
Usability:
It refers to the extent to which the software can be used with ease. the amount of
effort or time required to learn how to use the software.
Maintainability:
It refers to the ease with which the modifications can be made in a software
system to extend its functionality, improve its performance, or correct errors.
Portability:
A set of attributes that bears on the ability of software to be transferred from
one environment to another, without or minimum changes.
● Adaptability :
In this case, the software allows differing system constraints and the
user needs to be satisfied by making changes to the software.

● Interoperability :
Capability of 2 or more functional units to process data cooperatively.

● Correctness :
A software product is correct if the different requirements as specified
in the SRS document have been correctly implemented.
Advantages of Software Engineering
Improved quality: By following established software engineering principles and
techniques, software can be developed with fewer bugs and higher reliability.

Increased productivity: Using modern tools and methodologies can streamline the
development process, allowing developers to be more productive and complete
projects faster.

Better maintainability: Software that is designed and developed using sound

software engineering practices is easier to maintain and update over time.

Reduced costs: By identifying and addressing potential problems early in the

development process, software engineering can help to reduce the cost of fixing
bugs and adding new features later on.
Increased customer satisfaction: By involving customers in the development
process and developing software that meets their needs, software engineering can
help to increase customer satisfaction.

Better team collaboration: By using Agile methodologies and continuous

integration, software engineering allows for better collaboration among
development teams.

Better scalability: By designing software with scalability in mind, software

engineering can help to ensure that software can handle an increasing number of
users and transactions.

Better Security: By following the software development life cycle (SDLC) and
performing security testing, software engineering can help to prevent security
breaches and protect sensitive data.
Disadvantages of Software Engineering

● High upfront costs: Implementing a systematic and disciplined approach

to software development can be resource-intensive and require a
significant investment in tools and training.

● Limited flexibility: Following established software engineering principles

and methodologies can be rigid and may limit the ability to quickly adapt
to changing requirements.
● Bureaucratic: Software engineering can create an environment that is
bureaucratic, with a lot of process and paperwork, which may slow down
the development process.
● Complexity: With the increase in the number of tools and methodologies,
software engineering can be complex and difficult to navigate.
Limited creativity: The focus on structure and process can stifle creativity and
innovation among developers.

High learning curve: The development process can be complex, and it requires a
lot of learning and training, which can be challenging for new developers.

High dependence on tools: Software engineering heavily depends on the tools,

and if the tools are not properly configured or are not compatible with the
software, it can cause issues.

High maintenance: The software engineering process requires regular

maintenance to ensure that the software is running efficiently, which can be
costly and time-consuming.
Legacy Software
Some of these are state-of-the-art software—just released to individuals,
industry, and government. But other programs are older, in some cases
much older. These older programs—often referred to as legacy software—
have been the focus of continuous attention and concern since the 1960s.

“Legacy software systems . . . were developed decades ago and

have been continually modified to meet changes in business
requirements and computing platforms. The proliferation of such
systems is causing headaches for large organizations who find
them costly to maintain and risky to evolve”
Many different reasons why a system might earn the
"legacy" label

● End of life
● Outdated architecture
● Lack of internal system knowledge
● Lack of internal system skills
● Scalability
● Challenging to update and innovate
Most organizations keep their legacy systems because of at least one of
the following reasons:
● High migration costs: the IT system is running aging or end-of-life technology
that may lack current documentation, making migration complex and, usually,
expensive.
● Skills gap: the technology is supported by “mature” developers with hard-to-
find skills, or, in case of migration to another technology, organizations lack
enough manpower to focus on the migration while keeping the business
running as usual.
● Fear: legacy systems are often a mission-critical technology, and the
organization is afraid of the impact changing it or replacing it can have on the
business.
● Familiarity: In some cases, a company may keep its older software
because its staff is familiar with it. Introducing new technology can disrupt
the pace of operations and may require extensive training. It can also be
expensive to invest in new software and devices.

● Data loss: When transferring to a new system, companies risk losing

valuable data. Although it's uncommon, data may download incorrectly to
the new software or become lost during data transfer. To avoid losing
data, companies may perform a system backup or archive important
information.
What to do with Legacy Software?

● Software should be adapted to met new computing

environment and technology.
● Enhanced for new business requirements.
● Ensure new design is extensible and interoperable with
other system.
Software Myths Beliefs about software and the process used to build
it.

Management Myths

Customer Myths

“Misleading Attitudes
Practitioner's
that cause serious (Developer) Myths
problem” are myths.
Management myth - 1 & 2
We have standards and procedures We have the newest computers and
to build a system, which is enough. development tools.

Reality Reality
� Are software practitioners aware of � It takes much more than the latest
standard’s existence? model computers to do high-quality
� Does it reflect modern software software development.
engineering practice? � Computer-aided software engineering
� Is it complete? (CASE) tools are more important than
hardware.
� Is it streamlined to improve time to delivery
while still maintaining a focus on quality?
� In many cases, the answer to all of these
questions is "no.“
Management myth - 3 & 4
We can add more programmers and I outsourced the development activity,
can catch up the schedule. now I can relax and can wait for the
final working product.
Reality Reality
� Software development is not a mechanistic � If an organization does not understand
process like manufacturing. how to manage and control software
� In the words of Fred Brooks : "adding projects internally, it will invariably
people to a late software project makes it struggle when it outsources software
later." projects.
� People who were working must spend time
educating the newcomers.
� People can be added but only in a planned
and well-coordinated manner.
Customer myth - 1 & 2
A general statement of objectives Requirement Changes can be easily
(requirements) is sufficient to start a accommodated because software is
development. very flexible.
Reality Reality
� Comprehensive (detailed) statements of � It is true that software requirements
requirements is not always possible, an change, but the impact of change varies
ambiguous (unclear) “statement of with the time at which it is introduced.
objectives” can lead to disaster. � When requirements changes are
� Unambiguous (clear) requirements can be requested early the cost impact is
gathered only through effective and relatively small.
continuous communication between
customer and developer.
Practitioner's (Developer) myth – 1 & 2
Once we write the program, our job is I can’t access quality until it is
done. running.

Reality Reality
� Experts say "the sooner you begin 'writing � One of the most effective software
code', the longer it will take you to get quality assurance mechanisms can be
done." applied from the beginning of a project -
� Industry data indicates that 60 to 80 % the technical review.
effort expended on software will be after it � Software reviews are more effective
is delivered to the customer for the first “quality filter” than testing for finding
time. software defects.
Practitioner's (Developer) myth – 3 & 4
Working program is the only Software engineering is about
deliverable work product. unnecessary documentation.

Reality Reality
� A working program is only one part of a � Software engineering is not about
software configuration. creating documents. It is about creating
� A variety of work products (e.g., models, a quality product.
documents, plans) provide a foundation for � Better quality leads to reduced rework.
successful engineering and, more And reduced rework results in faster
important, guidance for software support. delivery times.
Software Engineering Layered Approach

Software Engineering Tools allows automation of activities which helps

to perform systematic activities. A system for the support of software
development, called computer-aided software engineering (CASE).
Examples: Testing Tools, Bug/Issue Tracking Tools etc…

It provides technical how-to’s for building software, it

encompasses many tasks including communication,
requirement analysis, design modeling, program construction,
testing and support

It is a foundation of Software Engineering, It is the glue that

holds the technology layers, It defines a framework activities

Defines continuous process improvement principles

Software Engineering Layered Approach [Link] Engineering is a layered technology
Quality
� Main principle of Software Engineering is Quality Focus.
� An engineering approach must have a focus on quality.
� Total Quality Management (TQM), Six Sigma, ISO 9001, ISO 9000-3, CAPABILITY MATURITY
MODEL (CMM), CMMI & similar approaches encourages a continuous process improvement
culture
Process Layer
� It is a foundation of Software Engineering, It is the glue the holds the technology layers together
and enables logical and timely development of computer software.
� It defines a framework with activities for effective delivery of software engineering technology
� It establish the context in which technical methods are applied, work products (models,
documents, data, reports, forms, etc.) are produced, milestones are established, quality is
ensured, and change is properly managed.
Software Engineering Layered Approach Cont.
Method
� It provides technical how-to’s for building software
� It encompasses many tasks including communication, requirement analysis, design
modeling, program construction, testing and support

Tools
� Software engineering tools provide automated or semi-automated support for the process
and the methods
� Computer‐aided software engineering (CASE) is the scientific application of a set of tools
and methods to a software system which is meant to result in high‐quality, defect‐free, and
maintainable software products.
� CASE tools automate many of the activities involved in various life cycle phases.
Software Process
� A process is a collection of activities, actions and tasks that are performed when some work
product is to be created
� A process is not a rigid prescription for how to build the software, rather it is adaptable
approach that enables the people doing the work to pick and choose the appropriate set of
work actions and tasks
� An activity try to achieve a broad objective (e.g., communication with stakeholders)
� An activity is applied regardless of the application domain, size of the project, complexity of
the effort, or degree of accuracy with which software engineering is to be applied.
� An action (e.g., architectural design) encompasses a set of tasks that produce a major work
product (e.g., an architectural design model).
� A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that
produces a noticeable outcome.
� Each of these activities, actions & tasks reside within a framework or model
Software Process SoftwareProcess Framework
� Figure represents “The Software Process” Process
� Each framework activity is populated by
framework
Umbrella activities
set of software engineering actions framework activity #1
� Each software engineering action is
Software Engineering action
#1.1
Task Work tasks
defined by a task set that identifies work Sets
… Work products
to be completed, product to be produced, … Quality assurance points
quality assurance points & milestones to Software Engineering action
indicate progress #1.k
Task Work tasks
Sets
… Work products
Quality assurance points
The purpose of software process is …

� to deliver software in timely manner and framework activity #n

� within sufficient quality to satisfy those

⮩ Who has given proposal for software
development and
⮩ Those who will use software
Process Framework Activities (CPMCD)
A process framework establishes the foundation for complete software engineering process, it encompasses five activities

Communication Communication with Planning Software Project Plan which

Customers / stockholders defines workflow that is to follow.
to understand project It describes technical task, risks,
requirements for defining resources, product to be
software features produced & work schedule
Modeling Creating models to Construction Code Generation
understand requirements (manual or automated)
and shows design of &
software to achieve Testing
requirements (to uncover errors in the code)
Deliver Software to Customer
Deployment Collect feedback from customer based on evaluation
Software Support
PROCESS FLOWS
Umbrella Activities
� Umbrella activities applied throughout the software project & help
a software team to manage and control progress, quality, change
& risks
� Umbrella activities are those which keep
running in the background throughout the
software development

Software project Software quality

Risk Management It establish a
Tracking & Control assurance
skeleton
Technical Reviews Measurement
Reusability
architecture
Management for software
Software Configuration Management engineering
Work product preparation and production work.
Umbrella Activities Cont.
� Software project tracking and control: allows the software team to assess progress against
the project plan and take any necessary action to maintain the schedule.
� Risk management: assesses (evaluates) risks that may affect the outcome of the project or
the quality of the product.
� Software quality assurance: defines and conducts the activities required to ensure software
quality.
� Technical reviews: assesses software engineering work products in an effort to uncover
and remove errors before they are propagated to the next activity.
� Measurement: defines and collects process, project and product measures that assist the
team in delivering software that meets stakeholders’ needs.
� Software configuration management: it manages the effects of change throughout the
software process.
Umbrella Activities Cont.
� Reusability management: it defines criteria for work product reuse (including software
components) and establishes mechanisms to achieve reusable components.
� Work product preparation and production: it encompasses (includes) the activities required
to create work products such as models, documents, logs, forms and lists.
 7. Principles of Software Engineering
● A software system exists for one reason: to provide value to its users.
● All design should be as simple as possible, but no simpler.
● A clear vision is essential to the success of a software project.
● Always specify, design, and implement knowing someone else will
have to understand what you are doing.
● Never design yourself into a corner- Be Open to the Future.
● Planning ahead for reuse reduces the cost and increases the value of
both the reusable components and the systems into which they are
incorporated.
● Placing clear, complete thought before action almost always
produces better results.
Software Process Models The process model is the abstract representation of
process.

� Also known as Software development life cycle SDLC

(SDLC) or Application development life cycle
Models Communication Phases
� Process models prescribe a distinct set of
activities, actions, tasks and milestones
(deliverables) required to engineer high quality
software.
Deployment SDLC Planning

Software
� Process models are not perfect but provide Development
roadmap for software engineering work.
Life
� Software models provide stability, control and Cycle
organization to a process that if not managed can
easily get out of control. Construction Modeling
� Software process models are adapted (adjusted)
to meet the needs of software engineers and
managers for a specific project.
Software Development Life Cycles

A generic process framework for

software engineering defines five
framework activities
communication, planning, modeling,
construction, and deployment.

There are many different software

processes but all must include four
activities that are fundamental to
software engineering:
1. Software specification
2. Software design and
implementation
3. Software validation
4. Software evolution
Different Process Models/ Prescriptive process models
� Process model is selected based on Process Models
different parameters
⮩ Type of the project & people � Waterfall Model (Linear Sequential Model)
⮩ Complexity of the project � Incremental Process Model
⮩
� Prototyping Model
Size of team
⮩ Expertise of people in team
⮩ Working environment of team � The Spiral Model
⮩ Software delivery deadline � Rapid Application Development Model
� Agile Model
The Waterfall Model
When to use ? Advantages
� Requirements are very well known, clear � Simple to implement and manage
and fixed
� Product definition is stable Drawbacks
� Technology is understood � Unable to accommodate changes at later
� There are no ambiguous (unclear)
stages, that is required in most of the
cases.
requirements
� Working version is not available during
� Ample (sufficient) resources with required
development. Which can lead the
expertise are available freely
development with major mistakes.
� The project is short
� Deadlock can occur due to delay in any
step.
� Not suitable for large projects.
The Waterfall Model Classic life cycle or linear sequential model

Communication
• Project initiation
Planning
• Requirements
gathering • Estimating
Modeling
• Scheduling
• Tracking • Analysis
Constructio
• Design
n
Deployment
• Coding
• Testing • Delivery
• Support
• Feedback

When requirements for a problems are well understood then this model is used in
which workflow from communication to deployment is linear
V- Process Model
The V-model, or Validation and Verification
model, expands on the Waterfall model with
the addition of early test planning.

It follows a sequential design process same

as the waterfall model.

Testing of the device is planned in parallel

with a corresponding stage of development.

The V-shaped model should be used for

small to medium-sized projects where
requirements are clearly defined and fixed.
V- Process Model
Advantages Disadvantages
● Each development stage has a
corresponding testing activity. ● Inflexible.

● This allows the team to detect errors ● A team can only start the
in requirement specifications, code, next stage when the current
and architecture early in the stage is complete.
development of the project.
● Adjustments are difficult,
● The addition of early test planning expensive, and time-
gives the V-Model a greater chance of
intensive.
success than that of the Waterfall
model.
Incremental Process Model
� There are many situations in which initial software requirements are reasonably well defined,
but the overall scope of the development effort prevent a purely linear process.

� In addition, there may be a compelling need to provide a limited set of software functionality to
users quickly and then refine and expand on that functionality in later software releases.

� In such cases, there is a need of a process model that is designed to produce the software in
increments.
Incremental Process Model
Software
Functionality &
Features

Project Calendar
Time

� The incremental model combines elements of linear and parallel process flows.
� This model applies linear sequence in an iterative manner.
� Initially core working product is delivered.
� Each linear sequence produces deliverable “increments” of the software.
Incremental Process Model
e.g., word-processing software developed using the incremental model
� It might deliver basic file management, editing and
document production functions in the first increment
� more sophisticated editing in the second increment; Advantages
� spelling and grammar checking in the third increment; � Generates working software quickly
and and early during the software life
cycle.
� advanced page layout capability in the fourth
increment. � It is easier to test and debug during a
smaller iteration.
When to use ?
� Customer can respond to each built.
� When the requirements of the complete system � Lowers initial delivery cost.
are clearly defined and understood but staffing is � Easier to manage risk because risky
unavailable for a complete implementation by pieces are identified and handled
the business deadline. during iteration.
Prototyping model
When to use ?
� Customers have general objectives of software but do not have detailed requirements for
functions & features.
� Developers are not sure about efficiency of an algorithm & technical feasibilities.

� It serves as a mechanism for identifying software requirements.

� Prototype can be served as “the first system”.
� “quick and dirty” – quality not important, scripting etc. can be used
� Things like exception handling, recovery, standards are omitted
� Both stakeholders and software engineers like prototyping model
⮩ Users get feel for the actual system
⮩ Developers get to build something immediately
Prototyping model cont.
It works as follow
� Communicate with stockholders & define
objective of Software
Deployment & Communication � Identify requirements & design quick plan
Feedback
� Model a quick design (focuses on visible
part of software)

� Construct Prototype & deploy

Construction of
Prototype Quick Plan � Stakeholders evaluate this prototype and
provides feedback
� Iteration occurs and prototype is tuned
Modeling Quick based on feedback
Design
Prototyping model cont.
Problem Areas
� Potential hit on cost and schedule
� Customer demand that “a few fixes” be applied to make the prototype a working product,
due to that software quality suffers as a result
� Developer often makes implementation in order to get a prototype working quickly; without
considering other factors in mind like OS, Programming language, etc.
� Potential false sense of security if prototype does not focus on key (high risk) issues

Advantages
� Users are actively involved in the development
� Since in this methodology a working model of the system is provided, the users get a better
understanding of the system being developed
� Errors can be detected much earlier
The Spiral Model

� It provides the potential for rapid development.

� Software is developed in a series of
evolutionary releases.
� Early iteration release might be prototype but
later iterations provides more complete
version of software.
� It is divided into framework activities
(C,P,M,C,D). Each activity represent one
segment of the spiral
� Each pass through the planning region results
in adjustments to
⮩ the project plan
⮩ Cost & schedule based on feedback
The Spiral Model Cont.
When to use Spiral Model? Advantages
For development of large scale / � High amount of risk analysis hence, avoidance of Risk
high-risk projects. is enhanced.
� When costs and risk evaluation � Strong approval and documentation control.
is important. � Additional functionality can be added later.
� Users are unsure of their needs. � Software is produced early in the Software Life Cycle.
� Requirements are complex.
Disadvantages
� New product line.
� Can be a costly model to use.
� Significant (considerable)
changes are expected. � Risk analysis requires highly specific expertise.
� Project’s success is highly dependent on the risk
analysis phase.
� Doesn’t work well for smaller projects.
Rapid Application Development Model (RAD) It is a type of
incremental model in
Team - 1 which; components or
Communication functions are
Modeling
developed in parallel.
Construction
Planning • Integration
• Delivery Rapid development
Team - 2 • Feedback is achieved by
• Business Modeling
component based
Modeling Deployment construction
• Data Modeling Construction
• Process
Modeling This can quickly
Team - 3
• Component give the customer
Modeling Reuse something to see
• Automatic Code
Construction Generation
and use and to
• Testing provide feedback.
Rapid Application Development Model (RAD) Cont.
Communication � This phase is used to understand business problem.

Planning � Multiple software teams work in parallel on different systems/modules.

Modeling Construction
� Business Modeling: Information flow among the � It highlighting the use of pre-
business. existing software component.
⮩ Ex. What kind of information drives (moves)?
⮩ Who is going to generate information? Deployment
⮩ From where information comes and goes?
� Integration of modules
� Data Modeling: Information refine into set of data developed by parallel teams,
objects that are needed to support business. delivery of integrated software
� Process Modeling: Data object transforms to and feedback comes under
information flow necessary to implement deployment phase.
business.
Rapid Application Development Model (RAD) Cont.
When to Use?
� There is a need to create a system that can be modularized in 2-3 months of time.
� High availability of designers and budget for modeling along with the cost of automated
code generating tools.
� Resources with high business knowledge are available.
Advantages Drawback
� Reduced development time. � For large but scalable projects, RAD requires
sufficient human resources.
� Increases reusability of components.
� Projects fail if developers and customers are
� Quick initial reviews occur. not committed in a much-shortened time-frame.
� Encourages customer feedback. � Problematic if system can not be modularized.
� Integration from very beginning solves � Not appropriate when technical risks are high
a lot of integration issues. (heavy use of new technology).
Component based Development
 Commercial off the shelf (COTS) software components are offered as product.
 COTS provides set of functionality with well defined interfaces that enables component to be
integrated into software.
 The component based development model incorporates many characteristics of the spiral
model.
 It is evolutionary in nature.
 Component based development model constructs applications from prepackaged software
components.
 Modeling and construction activities begin with the identification of components.
Component based Development
Component based development incorporates the following steps
1. Available component-based products are researched & evaluated for software
development.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Testing is conducted to insure proper functionality.

Advantages
 It leads to software reuse.
 It reduces development cycle time.
 Reduction in project cost.
Typical Effort Distribution

� Req. - ? � Req. - 15-20%

� Design - ? � Design - 25-30%
� Coding - ? � Coding - 25-30%
� Testing - ? � Testing - 20-30%

Coding is not the most expensive!

How programmers spend their time?

� Writing programs -?
� Reading programs and manuals -? • Programmers spend
� Job communication -? more time in reading
programs than in
� Others -? writing them.
� Writing programs - 13% • Writing programs is a
� Reading programs and manuals - 16% small part of their lives.
� Job communication - 32%
� Others - 39%
When are defects introduced?

� Requirement - ?
� Design -? • Defects can be injected
� Coding -? at any of the major
phases.

� Requirement - 20% • Cost of latency: Cost of

defect removal
� Design - 30% increases exponentially
� Coding - 50% with latency time.
When are defects introduced?

• Cheapest way to detect

and remove defects
close to where it is
Cost to fix injected.
Error
(log scale)
• Hence must check for
defects after every
phase.
Time
Product & Process
� If the process is weak, the end product will suffer. But more confidence on process is also
dangerous.
� People gain more satisfaction from the creative process as they do from the end product.
⮩ Like an artist enjoys the brush strokes as much as the framed result.
⮩ A writer enjoys the search for the proper metaphor (comparison) as much as the finished book.
� As software professional, you should also derive as much satisfaction from the process as
the end product.
� The duality (contrast) of product and process is one important element in keeping creative
people engaged as software engineering continues to evolve.
Thank You!
Unit-1
Requirement
Analysis & Specification

Reference Book:
Software Engineering -A Practitioner’s Approach (Seventh Edition) -
Roger S. Pressman.

Chapter 5:Understanding Requirements

Requirements analysis is hard
“The hardest single part What is Requirement Engineering?
“The seeds of major
of building a software
software disasters are Tasks and techniques that lead
system is deciding what
usually sown in the to an understanding of
to build. No part of the
first three months of requirements is called
work so cripples the
commencing the requirement engineering.
resulting system if done
software project.”
wrong.”

"Fred" Brooks Jr. is an American Capers Jones is an American

computer architect, software engineer, specialist in software
and computer scientist, best known for engineering methodologies
managing the development of IBM's
System/360 family of computers
User requirements to mean the high-level abstract requirements

● Often referred to as user needs.

● Such as what activities that users must be able to perform using the system.
● User requirements are generally documented in a User Requirements Document
(URD) using narrative text.
● User requirements are generally signed off by the user and used as the primary
input for creating system requirements.
● An important and difficult step of designing a software product is determining what
the user actually wants it to do.
● This is because the user is often not able to communicate the entirety of their
needs and wants, and the information they provide may also be incomplete,
inaccurate and self-conflicting.
System requirements to mean the detailed description of what the system
should do.

● System requirements are the building blocks developers use to build the
system.
● These are the traditional “shall” statements that describe what the system
“shall do.”
● System requirements are classified as either functional or supplemental
requirements/non-functional requirements.
● A functional requirement specifies something that a user needs to perform
their work. For example, a system may be required to enter and print cost
estimates; this is a functional requirement.
● Supplemental or non-functional requirements are sometimes called quality
of service requirements.
 Requirement Engineering
It provides the appropriate mechanism for Requirements fall into two types
understanding Functional requirements Non-Functional requirements

What customer wants

Non-
Analyzing needs Assessing feasibility Functional
Functional
requirements
requirements
Negotiating a reasonable solution

Specifying solution unambiguously

Validating the specification

Managing requirements

Don't put what you want to do - before how you need to do it

Functional requirements Non-functional requirements
Any requirement which specifies what the system Any requirement which specifies how the
Should do. system performs a certain function.
A functional requirement will describe a particular
A non-functional requirement will
behavior of function of the system when certain
describe how a system should behave
conditions are met, for example: “Send email when
and what limits there are on its
a new customer signs up” or “Open a new
account”.
functionality.

Typical functional requirements Typical non-functional requirements

Business Rules Administrative functions Historical Data Response time Availability Regulatory
Throughput Reliability Manageability
Transaction corrections, Legal or Regulatory
adjustments and cancellations Requirements Utilization Recoverability Environmental
External Interfaces Reporting Requirements Authentication Static volumetric Maintainability Data Integrity

Authorization levels Scalability Serviceability Usability

Audit Tracking Capacity Security Interoperability

Library Management System
Function Requirements Non-function Requirements
� Add Article: New entries must be entered in database � Safety Requirements: The database may get
crashed at any certain time due to virus or
� Update Article: Any changes in articles should be updated
operating system failure. So, it is required to
in case of update
take the database backup.
� Delete Article: Wrong entry must be removed from system
� Security Requirements: We are going to develop
� Inquiry Members: Inquiry all current enrolled members to a secured database for the university. There are
view their details different categories of users namely teaching
� Inquiry Issuance: Inquiry all database articles staff, administrator, library staff ,students etc.,
Depending upon the category of user the access
� Check out Article: To issue any article must be checked rights are decided.
out
� Software Constraints: The development of the
� Check In article: After receiving any article system will system will be constrained by the availability of
reenter article by Checking required software such as database and
� Inquiry waiting for approvals: Librarian will generate all development tools. The availability of these
newly application which is in waiting list tools will be governed by
� Reserve Article: This use case is used to reserve any book
with the name of librarian, it can be pledged
Feasibility studies

A feasibility study is a short, focused study that should take place early in the
RE process. It should answer three key questions:

(1)Does the system contribute to the overall objectives of the organization?

(1)Can the system be implemented within schedule and budget using current
technology?

(1) Can the system be integrated with other systems that are used?

If the answer to any of these questions is no, you should probably not go
ahead with the project.
Requirements Engineering Tasks
1 Inception 2 Elicitation (Requirement Gathering) 3 Elaboration

Roughly define scope Define requirements Further define requirements

A basic understanding The practice of collecting the Expand and refine
of a problem, people requirements of a system from requirements obtained from
who want a solution, users, customers and other inception & elicitation
the nature of solution stakeholders
Creation of User scenarios,
desired
extract analysis class and
business domain entities
Requirements Engineering Tasks Cont.
4 Negotiation 5 Specification

Reconcile conflicts Create analysis model

Agree on a deliverable It may be written document, set of graphical models, formal
system that is realistic for mathematical model, collection of user scenarios, prototype or
developers and customers collection of these
SRS (Software Requirement Specification) is a document that
is created when a detailed description of all aspects of software
to build must be specified before starting of project
Requirements Engineering Tasks Cont.
6 Validation 7 Requirements Management

Ensure quality of requirements It is a set of activities to identify, control &

trace requirements & changes to
Review the requirements specification for requirements (Umbrella Activities) at any
errors, ambiguities, omissions (absence) and time as the project proceeds.
conflicts
Elicitation is the Hardest Part! Project Inception
� Problems of scope During the initial project meetings, the following
⮩ System boundaries are ill-defined tasks should be accomplished
⮩ Customers will provide irrelevant information
� Problems of understanding � Identify the project stakeholders
⮩ These are the folks we should be talking to
⮩ Customers never know exactly what they
want � Recognize multiple viewpoints
⮩ Customers don’t understand capabilities and ⮩ Stakeholders may have different (and
limitations conflicting) requirements
⮩ Customers have trouble fully communicating
needs
� Work toward collaboration
⮩ It’s all about reconciling conflict
� Problems of volatility
⮩ Requirements always change
� Ask the first questions
⮩ Who? What are the benefits? Another source?
⮩ What is the problem? What defines success?
Other constraints?
⮩ Am I doing my job right?
Collaborative Elicitation Elicitation work products
Collaborative elicitation should result in several work products

A bounded statement of scope A list of stakeholders

A description of the technical environment
A list of requirements and constraints
Any prototypes developed
A set of use cases
• Characterize how users will
One-on-one Q&A sessions interact with the system
rarely succeed in practice; • Use cases tie functional
collaborative strategies are requirements together
more practical
Quality Function Deployment (QFD)
� This is a technique that translates the needs of the customer into technical requirements for
software
� It emphasizes an understanding of what is valuable to the customer and then deploys these
values throughout the engineering process through functions, information, and tasks
� It identifies three types of requirements
Normal requirements: These requirements are the objectives and goals stated for a product or system
during meetings with the customer

Expected requirements: These requirements are implicit to the product or system and may be so
fundamental that the customer does not explicitly state them

Exciting requirements: These requirements are for features that go beyond the customer's expectations and
prove to be very satisfying when present
The requirement analysis model

Describe what the customer wants to built

Purpose

System Information
Establish the foundation for the software design
System Function
Provide a set of validation requirements
System Behaviors
Analysis rule of Thumb Elements of the Requirements Model
� Make sure all points of view are Scenario-based Class Models
covered Models e.g.
� Every element should add value e.g. Class diagrams
Use cases Collaboration
� Keep it simple User Stories diagrams

� Maintain a high level of abstraction

Software
� Focus on the problem domain Requirements
� Minimize system coupling
� Model should provide value to all Behavioral Flow Models
stakeholders Models e.g.
e.g. DFDs
State diagrams Data models
Sequence diagrams
Elements of the Requirements Model Cont.
Scenario-based elements Behavioral elements
Describe the system from the user's point of view Use state diagrams to represent the state of the
using scenarios that are depicted (stated) in use system, the events that cause the system to change
cases and activity diagrams state, and the actions that are taken as a result of a
particular event. This can also be applied to each
Class-based elements class in the system.
Identify the domain classes for the objects Flow-oriented elements
manipulated by the actors, the attributes of these
classes, and how they interact with one another; Use data flow diagrams to show the input data that
which utilize class diagrams to do this. comes into a system, what functions are applied to
that data to do transformations, and what resulting
Use Case Diagram Activity Diagram Class Diagram output data are produced.

Diagram
State
Data Flow
Diagram
Analysis Modeling Approaches
Structured Analysis Object Oriented Analysis
• Models data elements • Model analysis classes
⁻ Attributes ⁻ Data
⁻ Relationships ⁻ Processes
• Models processes that • Models class
transform data collaborations

Techniques from both approaches are typically used in practice.

List of documentation & manuals
Formal Specification
Documentation
Analysis / Manuals
Context Diagram
Specification
Data Flow Diagram
User Operational
Documentation

Flow Charts
Manuals Manuals
Manuals

Design
ER Diagram System Installation
Overview Guide
Source Code Listings
Beginner’s
Implementation Guide
Cross-Reference Listings Tutorials System
Administration
Test Data Guide
Reference
Testing Guide
Test Results
SRS (Software Requirements Specification)

Software Requirement Specification (SRS) is a document that completely describes what the
proposed software should do without describing how software will do it.

SRS is also helping the clients to understand their own needs.

SRS Contains

A complete information description A detailed functional description

A representation of system behaviour

An indication of performance requirements and design constraints

Appropriate validation criteria

Other information suitable to requirements
Characteristics of a Good SRS
� SRS should be accurate, complete, efficient, and of high quality, so that it does not affect the
entire project plan.
� An SRS is said to be of high quality when the developer and user easily understand the
prepared document.
� Characteristics of a Good SRS:
Correct Unambiguous Complete
SRS is correct when all user SRS is unambiguous SRS is complete when the
requirements are stated in the when every stated requirements clearly define
requirements document. requirement has only what the software is required
one interpretation. to do.
Note that there is no specified
tool or procedure to assure the
correctness of SRS.
Characteristics of a Good SRS Cont.
Ranked for Importance/Stability Modifiable
All requirements are not equally important, hence The requirements of the user can
each requirement is identified to make differences change, hence requirements
among other requirements. document should be created in such
Stability implies the probability of changes in the a manner that those changes can be
requirement in future. modified easily.

Traceable Verifiable Consistent

SRS is traceable when the SRS is verifiable when the SRS is consistent when the
source of each requirement is specified requirements can be subsets of individual
clear and facilitates the verified with a cost-effective requirements defined do not
reference of each requirement process to check whether the conflict with each other.
in future. final software meets those
requirements.
Problems Without SRS
� Without developing the SRS document, the system would not be properly implemented
according to customer needs.
� Software developers would not know whether what they are developing is what exactly is
required by the customer.
� Without SRS, it will be very difficult for the maintenance engineers to understand the
functionality of the system.
� It will be very difficult for user document writers to write the users’ manuals properly without
understanding the SRS.
Standard Template for writing SRS
1. Introduction 3. System Features
1.1 Purpose 3.1 System Feature 1
1.2 Document Conventions 3.2 System Feature 2 (and so on)
1.3 Intended Audience and Reading Suggestions 4. External Interface Requirements
1.4 Project Scope 4.1 User Interfaces
1.5 References 4.2 Hardware Interfaces
2. Overall Description 4.3 Software Interfaces
2.1 Product Perspective 4.4 Communications Interfaces
2.2 Product Features 5. Other Non-functional Requirements
2.3 User Classes and Characteristics 5.1 Performance Requirements
2.4 Operating Environment 5.2 Safety Requirements
2.5 Design and Implementation Constraints 5.3 Security Requirements
2.6 User Documentation 5.4 Software Quality Attributes
2.7 Assumptions and Dependencies
6. Other Requirements
Appendix A: Glossary | Appendix B: Analysis Models | Appendix C: Issues List
Thank
You
 Outline
Looping
 W5 of Project Management
 Software Metrics
 Process, Product and Project Metrics
 Software Project Estimations
 Software Project Planning (MS Project Tool)
 Project Scheduling and Tracking
Software Project Management
W5HH of Project Management
Boehm suggests an approach (W5HH) that addresses project
objectives, milestones and schedules, responsibilities, management
and technical approaches, and required resources
Why is the system being developed?
Enables all parties to assess the validity of business reasons for the software
work. In another words - does the business purpose justify the expenditure of
people, time, and money?

What will be done?

The answers to these questions help the team to establish a project schedule by
identifying key project tasks and the milestones that are required by the
customer

When will it be accomplished?

Project schedule to achieve milestone
W5HH of Project Management Cont.
Who is responsible?
Role and responsibility of each member

Where are they organizationally located?

Customer, end user and other stakeholders also have responsibility

How will the job be done technically and managerially?

Management and technical strategy must be defined

How much of each resource is needed?

Develop estimation

W5HH
It is applicable regardless of size or complexity of
software project
Terminologies
 Measure  Indirect Metrics
 It provides a quantitative indication of the  Aspects that are not immediately quantifiable
extent (range), amount, dimension, capacity or  Ex., Functionality, Quantity, Reliability
size of some attributes of a product or process
 Ex., the number of uncovered errors  Indicators
 It is a metric or combination of metrics that
 Metrics provides insight into the software process, project
 It is a quantitative measure of the degree or the product itself
(limit) to which a system, component or  It enables the project manager or software
process possesses (obtain) a given attribute engineers to adjust the process, the project or the
 It relates individual measures in some way product to make things better
 Ex., number of errors found per review  Ex., Product Size (analysis and specification
metrics) is an indicator of increased coding,
 Direct Metrics integration and testing effort
 Immediately measurable attributes
 Ex., Line of Code (LOC), Execution Speed,
 Faults
Defects Reported  Errors - Faults found by the practitioners during
software development
 Defects - Faults found by the customers after
release
Why Measure Software?
1 To determine (to define) quality of a product or process.
2 To predict qualities of a product or process.
3 To improve quality of a product or process.
Metric Classification Base
 Process
 Specifies activities related to production of software.
 Specifies the abstract set of activities that should be performed to go from user needs to final product.
 Project
 Software development work in which a software process is used
 The actual act of executing the activities for some specific user needs
 Product
 The outcomes of a software project
 All the outputs that are produced while the activities are being executed
Process Metrics
 Process Metrics are an invaluable tool for We measure the effectiveness of a process by
companies to monitor, evaluate and improve deriving a set of metrics based on outcomes
their operational performance across the of the process such as,
enterprise
Errors uncovered before release of the software
 They are used for making strategic decisions
Defects delivered to and reported by the end users
 Process Metrics are collected across all
projects and over long periods of time Work products delivered
 Their intent is to provide a set of process Human effort expended
indicators that lead to long-term software
process improvement Calendar time expended

Conformance to the schedule

Ex., Defect Removal Efficiency (DRE) metric
Relationship between errors (E) and defects (D) Time and effort to complete each generic activity
The ideal is a DRE of 1
DRE = E / ( E + D )
Project Metrics
 Project metrics enable a software project manager to,
 Assess the status of an ongoing project
 Track potential risks
 Uncover problem areas before their status becomes critical
 Adjust work flow or tasks
 Evaluate the project team’s ability to control quality of software work products
 Many of the same metrics are used in both the process and project domain
 Project metrics are used for making tactical (smart) decisions
 They are used to adapt project workflow and technical activities
 Project metrics are used to
 Minimize the development schedule by making the adjustments necessary to avoid delays and
mitigate (to reduce) potential (probable) problems and risks
 Assess (evaluates) product quality on an ongoing basis and guides to modify the technical
approach to improve quality
Product Metrics
 Product metrics help software engineers to gain insight into the design and construction of
the software they build
 By focusing on specific, measurable attributes of software engineering work products
 Product metrics provide a basis from which analysis, design, coding and testing can be
conducted more objectively and assessed more quantitatively
 Ex., Code Complexity Metric
Types of Measures
Categories of Software Measurement Software Measurement
Direct measures of the Indirect measures of the Metrics for Software
Software process Software product Cost and Effort estimations
Ex., cost, effort, etc. Ex. functionality, quality, Size Oriented Metrics
complexity, efficiency,
Software product
reliability, etc. Function Oriented Metrics
Ex., lines of code produced,
execution speed, Object Oriented Metrics
defects reported, etc.
Use Case Oriented Metrics
Size-Oriented Metrics
 Derived by normalizing (standardizing) quality and/or productivity measures by considering
the size of the software produced
 Thousand lines of code (KLOC) are often chosen as the normalization value
A set of simple size-oriented metrics can  Size-oriented metrics are not universally accepted
be developed for each project as the best way to measure the software process
Errors per KLOC (thousand lines of code)
Defects per KLOC $ per KLOC Opponents argue that KLOC measurements
Pages of documentation per KLOC Are dependent on the programming language
In addition, other interesting metrics can Penalize well-designed but short programs
be computed, like Cannot easily accommodate nonprocedural languages
Errors per person-month Require a level of detail that may be difficult to achieve
KLOC per person-month
$ per page of documentation
Function Oriented Metrics
 Function-oriented metrics use a measure of the functionality delivered by the application as
a normalization value
 Most widely used metric of this type is the Function Point
 FP = Count Total * [0.65 + 0.01 * Sum (Value Adjustment Factors)]
 Function Point values on past projects can be used to compute,
 for example, the average number of lines of code per function point
 Advantages
 FP is programming language independent
 FP is based on data that are more likely to be known in the early stages of a project, making it more
attractive as an estimation approach
 Disadvantages
 FP requires some “sleight of hand” because the computation is based on subjective data
 Counts of the information domain can be difficult to collect
 FP has no direct physical meaning, it’s just a number
Object-Oriented Metrics Use Case Oriented Metrics
 Conventional software project metrics  Like FP, the use case is defined early in the
(LOC or FP) can be used to estimate software process, allowing it to be used for
object-oriented software projects estimation before significant (valuable)
 However, these metrics do not provide modeling and construction activities are
enough granularity (detailing) for the initiated
schedule and effort adjustments that are  Use cases describe (indirectly, at least) user-
required as you iterate through an visible functions and features that are basic
evolutionary or incremental process requirements for a system
 Lorenz and Kidd suggest the following set  The use case is independent of programming
of metrics for OO projects language, because use cases can be created at
 Number of scenario scripts vastly different levels of abstraction, there is no
 Number of key classes (the highly standard “size” for a use case
independent components)
 Without a standard measure of what a use case
 Number of support classes
is, its application as a normalization measure is
suspect (doubtful).
 Ex., effort expended / use case
Function Point Metrics
 The function point (FP) metric can User / Event
be used effectively as a means for
measuring the functionality Other
delivered by a system User / Event external Applications
 Using historical data, the FP metric inquiries (EQs)
can be used to
external
 Estimate the cost or effort required to external interface
inputs (EIs)
design, code, and test the software files (EIFs)
 Predict the number of errors that will
be encountered during testing external
 Forecast the number of components outputs (EOs) Internal
and/or the number of projected
source lines in the implemented Logic Files
system

Function / Application
Function Point Components Cont.
Information domain values (components) are defined in the following manner
 Number of external inputs (EIs)
 input data originates from a user or is transmitted from another application
 Number of external outputs (EOs)
 external output is derived data within the application that provides information to the user
 output refers to reports, screens, error messages, etc.
 Number of external inquiries (EQs)
 external inquiry is defined as an online input that results in the generation of some immediate software
response in the form of an online output
 Number of internal logical files (ILFs)
 internal logical file is a logical grouping of data that resides within the application’s boundary and is
maintained via external inputs
 Number of external interface files (EIFs)
 external interface file is a logical grouping of data that resides external to the application but provides
information that may be of use to the another application
Compute Function Points
Value Adjustment Factors
FP = Count Total * [ 0.65 + 0.01 * ∑(Fi) ]
• F1. Data Communication
Count Total is the sum of all FP entries • F2. Distributed Data Processing
• F3. Performance
Fi (i=1 to 14) are complexity value adjustment factors (VAF).
• F4. Heavily Used Configuration
Value adjustment factors are used to provide an indication of problem
• F5. Transaction Role
complexity • F6. Online Data Entry
• F7. End-User Efficiency
• F8. Online Update
• F9. Complex Processing
• F10. Reusability
• F11. Installation Ease
• F12. Operational Ease
• F13. Multiple Sites
• F14. Facilitate Change
Function Point Calculation Example
Used Adjustment
Factors and assumed
values are,
F09. Complex internal
processing = 3
F10. Code to be reusable =
2
F03. High performance = 4

FP = Count Total * [ 0.65 + 0.01 * ∑(Fi) ] F13. Multiple sites = 3

F02. Distributed
FP = [50]* [0.65 + 0.01 * 17]
processing = 5
FP = [50]* [0.65 + 0.17]
Project Adjustment
FP = [50]* [0.82] = 41 Factor (VAF) = 17
Function Point Calculation Example 2
Study of requirement specification
for a project has produced following
results 7 28
10 40
6 18
Need for 7 inputs, 10 outputs, 6
inquiries, 17 files and 4 external 17 119
interfaces 4 28
233
Input and external interface
function point attributes are of
Value adjustment factors (VAF) = 32 given
average complexity and all other
function points attributes are of low
complexity FP = Count Total * [ 0.65 + 0.01 * ∑(Fi) ]
= 233 * [ 0.65 + 0.01 * 32]
Determine adjusted function points
assuming complexity adjustment = 233 * 0.97 = 226.01
value is 32.
Software Project Estimation
To achieve reliable cost and effort estimates, a number of options arise:
 Delay estimation until late in the project (obviously, we can
achieve 100 percent accurate estimates after the project is
complete!)
 Base estimates on similar projects that have already been
completed
 Use relatively simple decomposition techniques to generate
project cost and effort estimates
It can be transformed
 Use one or more empirical models for software cost and effort
from a black art to a estimation.
series of systematic
steps that provide
estimates with
acceptable risk
Software Project Decomposing
 Software project estimation is a form of problem solving and in most cases, the problem to be
solved is too complex to be considered in one piece
 For this reason, decomposing the problem, re-characterizing it as a set of smaller problems is
required
 Before an estimate can be made, the project planner must understand the scope of the
software to be built and must generate an estimate of its “size”

Decomposition Techniques

1. Software Sizing 3. Process based Estimation

2. Problem based Estimation 4. Estimation with Use-cases
LOC (Lines of Code) based,
FP (Function Point) based
Software Sizing
Putnam and Myers suggest four different approaches to the sizing problem

 “Fuzzy logic” sizing

 This approach uses the approximate reasoning techniques that are the cornerstone of fuzzy logic.
 Function Point sizing
 The planner develops estimates of the information domain characteristics
 Standard Component sizing
 Estimate the number of occurrences of each standard component
 Use historical project data to determine the delivered LOC size per standard component.
 Change sizing
 Used when changes are being made to existing software
 Estimate the number and type of modifications that must be accomplished
 An effort ratio is then used to estimate each type of change and the size of the change
Problem Based Estimation
 Start with a bounded statement of scope
 Decompose the software into problem functions that can each be estimated individually
 Compute an LOC or FP value for each function
 Derive cost or effort estimates by applying the LOC or FP values to your baseline productivity
metrics
 Ex., LOC/person-month or FP/person-month
 Combine function estimates to produce an overall estimate for the entire project
 In general, the LOC/pm and FP/pm metrics should be computed by project domain
 Important factors are team size, application area and complexity
Problem Based Estimation Cont.
 LOC and FP estimation differ in the level of detail required for decomposition with each value
 For LOC, decomposition of functions is essential and should go into considerable detail (the more detail, the
more accurate the estimate)
 For FP, decomposition occurs for the five information domain characteristics and the 14 adjustment factors
 External Inputs, External Outputs, External Inquiries, Internal Logical Files, External Interface Files
 For both approaches, the planner uses lessons learned to estimate,
 An optimistic (Sopt), most likely (Sm), and pessimistic (Spess) estimates Size (S) value for each function or
count
 Then the expected Size value S is computed as
 S = (Sopt + 4 Sm + Spess)/6

Historical LOC or FP data is then compared to S in order to cross-check it.

Process Based Estimation
 This is one of the most commonly used technique
Process-based estimation is
obtained from “process  Identify the set of functions that the software needs to perform as
obtained from the project scope
framework”
 Identify the series of framework activities that need to be performed
for each function
Framework Activities
Frame
 Estimate the effort (in person months) that will be required to
accomplish each software process activity for each function
Effort required to  Apply average labor rates (i.e., cost/unit effort) to the effort
Application
Functions

accomplish estimated for each process activity

each framework  Compute the total cost and effort for each function and each
activity for each framework activity.
application  Compare the resulting values to those obtained by way of the LOC
function and FP estimates
 If both sets of estimates agree, then your numbers are highly reliable
 Otherwise, conduct further investigation and analysis concerning the
function and activity breakdown
Estimation with Use Cases
Developing an estimation approach with use  Before use cases can be used for estimation,
cases is problematic for the following reasons:  the level within the structural hierarchy is
established,
 Use cases are described using many different
 the average length (in pages) of each use
formats and styles—there is no standard form. case is determined,
 Use cases represent an external view (the  the type of software (e.g., real-time,
user’s view) of the software and can therefore business, engineering/scientific, WebApp,
be written at many different levels of embedded) is defined, and
abstraction  a rough architecture for the system is
considered
 Use cases do not address the complexity of
the functions and features that are described  Once these characteristics are established,
 empirical data may be used to establish the
 Use cases can describe complex behavior (Ex., estimated number of LOC or FP per use
interactions) that involve many functions and case (for each level of the hierarchy).
features  Historical data are then used to compute the
 Although a number of investigators have effort required to develop the system.
considered use cases as an estimation input.
Empirical Estimation Models
Source Lines of Code (SLOC)

 The project size helps to determine the resources, effort,

and duration of the project.
 SLOC is defined as the Source Lines of Code that are
delivered as part of the product
 The effort spent on creating the SLOC is expressed in
relation to thousand lines of code (KLOC)
Source Lines of Code (SLOC)  This technique includes the calculation of Lines of Code,
Documentation of Pages, Inputs, Outputs, and Components
Function Point (FP) of a software program
Constructive Cost Model  The SLOC technique is language-dependent
(COCOMO)  The effort required to calculate SLOC may not be the same
for all languages
Software Development Project Based on the development complexity

Software Development Project Classification

Organic Semidetached Embedded

Application programs Utility programs System programs

e.g. data processing programs e.g Compilers, linkers e.g OS real-time systems
A development project can be A development project can be A development project is
considered of organic type, if considered of semidetached type, considered to be of embedded
the project deals with if the development consists of a type, if the software being
developing a well understood mixture of experienced & developed is strongly coupled
application program, the size inexperienced staff. Team to complex hardware, or if the
of the development team is members may have limited strict regulations on the
reasonably small, and the team experience on related systems but operational procedures exist
members are experienced in may be unfamiliar with some
developing similar types of aspects of the system being
projects developed.
 Software Development Project Cont.

Not Tight Dead Line

Little Innovation
Project Development
Model Size Nature of Project Environment
Organic Typically Small Size Project, Experienced developers in
Familiar &
2-50 the familiar environment, E.g. Payroll,
In-house
KLOC Inventory projects etc.
Semi Typically Medium Size Project, Medium Size Team,

Medium

Medium
Detached 50-300 Average Previous Experience, e.g. Utility Medium
KLOC Systems like Compilers, Database Systems,
editors etc.
Complex hardware &
Embedded Typically Large Project, Real Time Systems, Complex

Significant

Tight
Required
Over 300 interfaces, very little previous Experience. E.g. customer Interfaces
KLOC ATMs, Air Traffic Controls
COCOMO Model Basic COCOMO Model
The basic COCOMO model gives an approximate estimate of the project parameters
COCOMO (Constructive
Cost Estimation Model) The basic COCOMO estimation model is given by the following expressions
was proposed by 𝑬𝒇𝒇𝒐𝒓𝒕 = 𝑎1 + 𝐾𝐿𝑂𝐶 𝑎2
𝑃𝑀 𝑻𝒅𝒆𝒗 = 𝑏1 × 𝐸𝑓𝑓𝑜𝑟𝑡 𝑏2
𝑀𝑜𝑛𝑡ℎ𝑠
Boehm
• KLOC is the estimated size of the software product expressed in Kilo Lines of Code
• a1, a2, b1, b2 are constants for each category of software products,
According to Boehm, • Tdev is the estimated time to develop the software, expressed in months,
software cost estimation • Effort is the total effort required to develop the software product, expressed in
person months (PMs).
should be done through
three stages: Project a1 a2 b1 b2
Basic COCOMO Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Intermediate COCOMO
Embedded 3.6 1.20 2.5 0.32
Complete COCOMO
Basic COCOMO Model Cont.
 The effort estimation is expressed in units of person-months (PM)
 It is the area under the person-month plot (as shown in fig.)
 An effort of 100 PM
 does not imply that 100 persons should work for 1 month
 does not imply that 1 person should be employed for 100 months
 it denotes the area under the person-month curve (fig.)
 Every line of source text should be calculated as one LOC irrespective of the actual number of
instructions on that line
 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 (i.e. organic, semidetached, and
embedded) as given by Boehm
 He derived the expressions by examining historical data collected from a large number of
actual projects
Basic COCOMO Model Cont.
 Insight into the basic COCOMO model can be obtained by plotting the
estimated characteristics for different software sizes
 Fig.1 shows a plot of estimated effort versus product size
 From fig. we can observe that the effort is somewhat superlinear in the
size of the software product
 The effort required to develop a product increases very rapidly with
project size Fig. 1
 The development time versus the product size in KLOC is plotted in fig. 2
 From fig., it can be observed that the development time is a sublinear
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
Fig. 2
 From fig., it can be observed that the development time is roughly the
same for all the three categories of products
Basic COCOMO Model Cont.
 Effort and the duration estimations obtained using the COCOMO model are called as 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

Example: Assume that the size of an organic type software product has been estimated to be 32,000 lines of
source code. Assume that the average salary of software engineers be Rs. 15,000/- per month. Determine the
effort required to develop the software product and the nominal development time
𝑬𝒇𝒇𝒐𝒓𝒕 = 𝑎1 + 𝐾𝐿𝑂𝐶 𝑎2 𝑃𝑀 𝑻𝒅𝒆𝒗 = 𝑏1 × 𝐸𝑓𝑓𝑜𝑟𝑡 𝑏2 𝑀𝑜𝑛𝑡ℎ𝑠
= 2.4 + 32 1.05 𝑃𝑀 = 2.5 × 91 0.38 𝑀𝑜𝑛𝑡ℎ𝑠
= 91 𝑃𝑀 = 14 𝑀𝑜𝑛𝑡ℎ𝑠
Cost required to develop the product = 14 x 15000 = Rs. 2,10,000/-
Intermediate COCOMO model
 The basic COCOMO model assumes that effort and development time are functions of the
product size alone
 However, a host of other project parameters besides the product size affect the effort required
to develop the product as well as the development time
 Therefore, in order to obtain an accurate estimation of the effort and project duration, the
effect of all relevant parameters must be taken into account
 The intermediate COCOMO model recognizes this fact and refines the initial estimate obtained
using the basic COCOMO expressions by using a set of 15 cost drivers (multipliers) based on
various attributes of software development
 For example, if modern programming practices are used, the initial estimates are scaled downward by
multiplication with a cost driver having a value less than 1
 It is requires the project manager to rate these 15 different parameters for a particular project
on a scale of one to three.
 Then, depending on these ratings, appropriate cost driver values which should be multiplied
with the initial estimate obtained using the basic COCOMO.
Intermediate COCOMO model Cont.
The cost drivers can be classified as being attributes of the following items
 Product: The characteristics of the product that are considered include the inherent complexity
of the product, reliability requirements of the product, etc.
 Computer: Characteristics of the computer that are considered include the execution speed
required, storage space required etc.
 Personnel: The attributes of development personnel that are considered include the experience
level of personnel, programming capability, analysis capability, etc.
 Development Environment: Development environment attributes capture the development
facilities available to the developers. An important parameter that is considered is the
sophistication of the automation (CASE) tools used for software development
Complete COCOMO model
 A major shortcoming of both the basic and intermediate COCOMO models is that they consider
a software product as a single homogeneous entity
 Most large systems are made up several smaller sub-systems
 These sub-systems may have widely different characteristics
 E.g., some sub-systems may be considered as organic type, some semidetached, and some embedded
 Also for some subsystems the reliability requirements may be high, for some the development team might
have no previous experience of similar development etc.
 The complete COCOMO model considers these differences in characteristics of the
subsystems and estimates the effort and development time as the sum of the estimates for
the individual subsystems
 The cost of each subsystem is estimated separately
 This approach reduces the margin of error in the final estimate
Project Scheduling & Tracking

It is an action that distributes estimated effort across the planned project duration, by
allocating the effort to specific software engineering tasks

Scheduling Principles

Compartmentalization Interdependency Time Allocation Define Responsibilities

Define Outcomes Define Milestones Effort Validation
Scheduling Principles
 Compartmentalization
 The product and process must be decomposed into a manageable number of activities and tasks
 Interdependency
 Tasks that can be completed in parallel must be separated from those that must completed serially
 Time Allocation
 Every task has start and completion dates that take the task interdependencies into account
 Effort Validation
 Project manager must ensure that on any given day there are enough staff members assigned to complete
the tasks within the time estimated in the project plan
 Define Responsibilities
 Every scheduled task needs to be assigned to a specific team member
 Define Outcomes
 Every task in the schedule needs to have a defined outcome (usually a work product or deliverable)
 Defined Milestones
 A milestone is accomplished when one or more work products from an engg task have passed quality review
Effort Distribution
 General guideline: 40-20-40 rule
 40% or more of all effort allocated to analysis and design tasks
 20% of effort allocated to programming
 40% of effort allocated to testing
 Characteristics of each project dictate the distribution of effort
 Although most software organizations encounter the following projects types:
 Concept Development
 initiated to explore new business concept or new application of technology
 New Application Development
 new product requested by customer
 Application Enhancement
 major modifications to function, performance or interfaces (observable to user)
 Application Maintenance
 correcting, adapting or extending existing software (not immediately obvious to user).
 Reengineering
 rebuilding all (or part) of a existing (legacy) system
Scheduling methods
 Two project scheduling methods that can be applied to software development.
 Program Evaluation and Review Technique (PERT)
 Critical Path Method (CPM)
 Both techniques are driven by information already developed in earlier project planning
activities:
 estimates of effort
 a decomposition of the product function
 the selection of the appropriate process model and task set
 decomposition of the tasks that are selected
 Both PERT and CPM provide quantitative tools that allow you to:
 Determine the critical path—the chain of tasks that determines the duration of the project
 Establish “most likely” time estimates for individual tasks by applying statistical models
 Calculate “boundary times” that define a “time window” for a particular task
Project Schedule Tracking Gantt chart
 The project schedule provides a road map for a A Gantt chart, commonly used in project
software project manager. management, is one of the most popular
 It defines the tasks and milestones. and useful ways of showing activities
(tasks or events) displayed against time.
 Several ways to track a project schedule:
 Conducting periodic project status meeting On the left of the chart is a list of the
 Evaluating the review results in the software process activities and along the top is a suitable
 Determine if formal project milestones have been time scale.
accomplished
 Compare actual start date to planned start date for each task
Each activity is represented by a bar;
 Informal meeting with practitioners
the position and length of the bar
 Using earned value analysis to assess progress
reflects the start date, duration and end
quantitatively
date of the activity. This allows you to
 Project manager takes the control of the schedule in see at a glance:
the aspects of
 Project Staffing, Project Problems, Project Resources,
Reviews, Project Budget
Gantt chart Cont.
What the various
activities are

When each activity

begins and ends

How long each activity

is scheduled to last

Where activities
overlap with other
activities, and by how
much

The start and end date

of the whole project
Thank You
Unit- 1
Agile Development

Reference Book:
Software Engineering -A Practitioner’s Approach (Seventh Edition) -
Roger S. Pressman.

Chapter 3: Agile Development

✓ Outline
Looping
▪ What is Agility?
▪ Agile Process
▪ Agility Principles
▪ Where agile methodology not work?
▪ Agile Process Models
• Extreme Programming (XP)
• Scrum
• Adaptive Software Development (ASD)
• Dynamic Systems Development Method (DSDM)
• Feature Driven Development (FDD)
• Agile Modelling (AM)
Agility Agility is ability to move quickly and easily.

It is an ability of quickness, lightness, & ease of movement.

� The ability to create and respond to change in order to profit in an unstable global
business environment.
� The ability to quickly re-prioritize use of resources when requirements, technology, and
knowledge shift.
� A very fast response to sudden market changes and emerging threats by intensive
customer interaction.
� Use of evolutionary, incremental, and iterative delivery to converge on an optimal
customer solution.
� Maximizing BUSINESS VALUE with right sized, just- enough, and just-in-time
processes and documentation.
 What is Agility? Cont.
Current Functionality
Rapid and Incremental delivery of software
Effective
response
to change
Change Request

Organizing a team Effective

so that it is in communication
control to perform among all
the work stakeholders
Development

Drawing the Eliminate the

Team

customer onto “us and them”

the team attitude
Customer
Agile Process
� Agile software process addresses few assumptions

Difficulty in predicting changes of requirements and customer priorities.

For many types of software; design and construction are interleaved (mixed).

Analysis, design, construction and testing are not as predictable as we might like.

� An agile process must adapt incrementally.

� To accomplish incremental adaptation, an agile team requires customer feedback (so that
the appropriate adaptations can be made).
Agility Principles
� Highest priority is to satisfy the customer through early & continuous delivery of
software
� Welcome changing requirements
� Deliver working software frequently
� Businesspeople and developers must work together
� Build projects around motivated individuals
� Emphasize face-to-face conversation
� Working software is the measure of progress
� Continuous attention to technical excellence and good design
� Simplicity – the art of maximizing the amount of work done
� The best designs emerge from self-organizing teams
� The team tunes and adjusts its behaviour to become more effective
Where agile methodology not work

Project plan & Unclear understanding Big Enterprises where

requirements are clear of Agile Approach team collaboration is
& unlikely to change among Teams tough
Extreme Programming (XP)
� The most widely used approach to agile software development
� A variant of XP called Industrial XP (IXP) has been proposed to target process for
large organizations
� It uses object-oriented approach as its preferred development model
XP Values
� Communication: To achieve effective communication, it emphasized close & informal
(verbal) collaboration between customers and developers
� Simplicity: It restricts developers to design for immediate needs not for future needs
� Feedback: It is derived from three sources the implemented software, the customer and other
software team members, it uses Unit testing as primary testing
� Courage: It demands courage (discipline), there is often significant pressure to design for
future requirements, XP team must have the discipline (courage) to design for today
� Respect: XP team respect among members
 The XP Process
It considers four framework activities Planning
1. Planning ⬥ 2. Design ⬥ 3. Coding ⬥ 4. Testing User Stories
• Customers assigns value (priority)
• Developers assigns cost (number of development
weeks)
Project velocity
• Computed at the end of first release
• Number of stories implemented in first release
• Estimates for future release
• Guard against over-commitment
The XP Process cont.
CRC card • Keep-it-Simple (Design of extra functionality is discouraged)
• Preparation of CRC card is work project
• CRC cards identify and organize object-oriented classes
Design

• Spike Solutions (in case of difficult design problem is encountered)

• Operational prototype intended to clear confusion
• Refactoring
• Modify internals of code, No observable change

• Develops a series of Unit test for stories included in current release

• Complete code perform unit-test to get immediate feedback
Coding

• XP recommend pair-programming, “Two heads are better than one”

• Integrate code with other team members, this “continuous integration” helps to
avoid compatibility & interfacing problems, “smoke testing” environment to uncover
errors early

• Unit test by developers & fix small problems

Testing

• Acceptance tests - Specified by customer

• This encourages regression testing strategy whenever code is modified
What is Scrum? Scrum is an agile process model which is used for developing the complex software systems.

It is a lightweight process framework.

Lightweight means the overhead of the process is kept as
small as possible in order to maximize the productivity.
Product Backlog
Product Owner

Product
A scrum is a method of restarting

Daily Scrum Meeting

Sprint
play in rugby that involves players
packing closely together with their
heads down and attempting to gain
possession of the ball.
Scrum framework at a glance
Inputs from Customers,
Team Selects starting at
Team, Managers
top as much as it can
commit to deliver by end Scrum
Daily Scrum
Master
of sprint Meetings

Sprint Review

Product Owner

Finished Work

Product Sprint Planning Sprint

Backlog Meeting Backlog

Sprint end date and team Sprint Retrospective

Prioritized list of what is deliverable do not change
required: features, bugs to fix...
Scrum cont.
Backlog
� It is a prioritized list of project requirements or features that must be provided to the
customer.
� The items can be included in the backlog at any time.
� The product manager analyses this list and updates the priorities as per the requirements.
Sprint
� These are the work units that are needed to achieve the requirements mentioned in the
backlogs.
� Typically the sprints have fixed duration or time box (of 2 to 4 weeks, 30 days).
� Change are not introduced during the sprint.
� Thus sprints allow the team members to work in stable and short-term environment
Scrum cont.
Scrum Meetings
� There are 15 minutes daily meetings to report the completed activities, obstacles and plan
for next activities.
� Following are three questions that are mainly discussed during the meetings.
1. What are the tasks done since last meeting ?
2. What are the issues that team is facing ?
3. What are the next activities that are planned?
� The scrum master leads the meeting and analyses the response of each team member.
� Scrum meeting helps the team to uncover potential problems as early as possible
� It leads to “knowledge socialization” & promotes “self-organizing team structure”
Demo
� Deliver software increment to customer
� Implemented functionalities are demonstrated to the customer
Adaptive Software development (ASD)
� This is a technique for building complex software systems using iterative approach.
� ASD focus on working in collaboration and team self-organization.

ASD incorporates three phases Speculation

1. Speculation, 2. Collaboration & 3. Learning � The adaptive cycle planning is conducted.
� In this cycle planning mainly three types of
information is used
Customer’s mission statement

Project constraints
(Delivery date, budgets etc…)

Basic requirements of the project

Adaptive Software development (ASD) cont.
Collaboration Learning
� In this, collaboration among the members � Emphasize is on learning new skills and
of development team is a key factor. techniques.
� For successful collaboration and � There are three ways by which the team
coordination it is necessary to have members learn
following qualities in every individual
Focus groups
The feedback from the end-users is obtained.
Assist each other without resentment (offense)
Formal technical review
Work hard Posses the required skill set This review is conducted for better quality.
Postmortems
Communicate problems and help each other Team analyses its own performance and makes
Criticize without any hate appropriate improvements.
Dynamic Systems Development Methods (DSDM)
Various phases of this life cycle model

� Feasibility study: By analysing the business requirements and constraints

the viability of the application is determined
� Business study: The functional and informational requirements are
identified and then the business value of the application is determined
� Functional model iteration: The incremental approach is adopted for
development
� Design and build iteration: If possible design and build activities can be
carried out in parallel
� Implementation: The software increment is placed in the working
environment
Feature Driven Development (FDD)

It is practical
process model
for object
oriented
software
engineering

In FDD, the feature means client valued function.

Feature Driven Development (FDD) cont.
1. Develop overall model Design by feature
� The high-level walkthrough of scope and � For each feature the sequence diagram
detailed domain walkthrough are conducted is created
to create overall models.
Build by feature
2. Build feature list
� Finally the class owner develop the
� List of features is created and expressed in actual code for their classes
the following form
<action> the <result> <by for of to> a(n) <object>
For Ex. “Display product-specifications of the product”

3. Plan by feature
� After completing the feature list the
development plan is created
Agile Modeling
There are many situations in which software engineers must build large, business
critical systems. The scope and complexity of such systems must be modeled so
that
(1) All constituencies can better understand what needs to be accomplished.
(2) The problem can be partitioned effectively among the people who must solve
it.
(3) Quality can be assessed as the system is being engineered and built.

Various methods have been introduced throughout the years -These methods have
merit, but they have proven to be difficult to apply and challenging to sustain
(over many projects). Part of the problem is the “weight” of these modeling
methods.
Agile Modeling
“Agile Modeling (AM) is a practice-based methodology for effective modeling
and documentation of software-based systems. Simply put, Agile Modeling (AM)
is a collection of values, principles, and practices for modeling software that can
be applied on a software development project in an effective and light-weight
manner. Agile models are more effective than traditional models because they
are just barely good, they don’t have to be perfect.”

The agile modeling philosophy recognizes that an agile team must have the
courage to make decisions that may cause it to reject a design and refactor -
We might not have all the answers!
Agile Modeling

Modeling principles that make AM unique are :

Model with a purpose Know the models and the tools you use
to create them
Use multiple models Adapt locally

Travel light

Content is more important

than representation
Thank
You
Need of SRS
Chrysler Comprehensive Compensation
System (C3)
• Overview: In the late 1990s, Chrysler attempted to develop the C3 payroll system to
manage paychecks for its 87,000 employees. The project was abandoned after several
years of development, costing millions.
• SRS Issue: The requirements for the system were poorly defined, leading to
misalignment between what Chrysler needed and what the developers built. The SRS
lacked clarity on critical functional requirements, such as how the system should handle
complex payroll calculations across different employee categories. Additionally, there
was insufficient stakeholder involvement, resulting in missing or ambiguous
requirements that failed to address key business needs.
• Impact: The system could not handle the complexity of Chrysler’s payroll processes,
leading to significant rework and delays. The project was eventually shut down, wasting
substantial time and resources.
• Classroom Takeaway: Highlight how a lack of stakeholder input and incomplete
functional requirements in the SRS can derail a project. Discuss the importance of
involving end-users (e.g., HR staff) during requirements elicitation to ensure all needs are
captured.
Sainsbury’s Supply Chain System
• Overview: In 2004, British retailer Sainsbury’s wrote off a $526 million investment in an
automated supply-chain management system intended to streamline warehouse
operations.
• SRS Issue: The SRS failed to adequately specify integration requirements with existing
systems and overlooked non-functional requirements like scalability and reliability under
real-world conditions. The requirements were not thoroughly validated with warehouse
staff, leading to a system that didn’t align with operational workflows. Ambiguities in the
SRS also caused developers to misinterpret how the system should handle inventory
tracking.
• Impact: The system was inefficient and unable to handle the high volume of
transactions, resulting in supply chain disruptions. Sainsbury’s had to revert to manual
processes, incurring massive financial losses.
• Classroom Takeaway: Emphasize the need for clear integration and non-functional
requirements in the SRS. Use this example to show how failing to involve end-users and
test requirements for real-world scenarios can lead to catastrophic outcomes.
U.S. Federal Aviation Administration (FAA)
Advanced Automation System
• Overview: In the 1990s, the FAA spent $2.6 billion on an air traffic control system
upgrade that was ultimately abandoned due to persistent issues.
• SRS Issue: The SRS was overly complex and contained vague, untestable
requirements. For example, performance requirements like response times under
high traffic were not clearly defined, and the document failed to prioritize critical
safety features. The lack of traceability in the SRS made it difficult to verify
whether requirements were met during development.
• Impact: The system suffered from delays, cost overruns, and technical issues,
such as inability to handle peak loads. The FAA eventually scaled back the project,
scrapping much of the work.
• Classroom Takeaway: Use this to illustrate the importance of testable and
prioritized requirements in the SRS. Discuss how traceability ensures
requirements can be tracked through development and testing, preventing costly
oversights.
Ford Motor Company’s Purchasing System
• Overview: In 2004, Ford abandoned a $400 million purchasing system designed
to streamline supplier interactions after it failed to meet expectations.
• SRS Issue: The SRS lacked clarity on functional requirements, such as how the
system should integrate with Ford’s existing procurement processes. There was
also insufficient stakeholder input from suppliers, leading to requirements that
didn’t account for their workflows. The SRS failed to address usability
requirements, resulting in a system that was difficult for end-users to adopt.
• Impact: The system was unusable for many suppliers, leading to inefficiencies and
resistance to adoption. Ford scrapped the project, absorbing significant financial
losses.
• Classroom Takeaway: Highlight the need for stakeholder collaboration and clear
usability requirements in the SRS. Demonstrate how a poorly defined SRS can
lead to a system that users reject, wasting resources.