SDLC

a systematic and disciplined approach

to develop a software with low cost ,
superior quality and with no schedule
slippage

SDLC includes a detailed plan for how

to develop, alter, maintain, and
replace a software system.
1. Feasibility analysis
2. Requirement analysis &
specification
3. Design
4. Coding
5. Testing
6. Maintenance
FEASIBILITY ANALYSIS
FEASIBILITY ANALYSIS
 Is a study made before committing
to a project.
A Feasibility Study leads to a decision:
• Go ahead
• Do not go head
• Think again

In production projects, the feasibility study

often leads to a budget request
FEASIBILITY ANALYSIS

A feasibility study may be in the form

of a proposal
The purpose of a software
development proposal is to convey a
solution that will be read by business
people, so keep it simple and to the
point; stay away from technical terms
as much as possible
FEASIBILITY ANALYSIS
General Structure of a Project Proposal
FEASIBILITY ANALYSIS
 Introduction – a brief overview of the
problem, solution, cost, and benefits.
 Issue – The main definition of the issue,
Including subject, purpose, main
argument, background.
 Solution – The main definition of the
solution, including your step-by-step
plan, the benefits, and hoe potential
obstacles ill be overcome.
FEASIBILITY ANALYSIS
 Qualifications - Overview of the
personnel required, experience.
 Conclusion of the costs and benefits,
and wrap-up – Balance the cost against
the benefit, reinforce your point one
last time
FEASIBILITY ANALYSIS

IDENTIFY AND DEFINE YOUR READER

Just like with any kind of persuasion, it helps if you
understand how to appeal to your audience. Who will
be reading your proposal and deciding if it’s accepted
or rejected? What do they care about? What kind of
language and benefits would resonate with them?
This is the first step because it’s an important thing to
keep in mind as you go along and as information that
informs the way you write from here on.
FEASIBILITY ANALYSIS
DEFINE THE PROBLEM YOUR
PROPOSAL WILL SOLVE
Who: Who will the proposal affect?
What: What’s the reason for you to
write the proposal in the first place?
Explain the current situation and the
problems that come with it.
FEASIBILITY ANALYSIS

DEFINE THE SOLUTION

How: How are you going to solve the
problem? Explain step-by-step in
detail.
Who: Identify the personnel you
need, along with their prior
experience to add persuasion to the
proposal
FEASIBILITY ANALYSIS
CONCLUSION: COSTS, BENEFITS AND
WRAP-UP
Reiterate: The purpose and main argument
Costs: Break down the projected costs
involved for different elements of the
project
Benefits: Break down the benefits to the
organization, monetary and non-monetary,
to persuade the reader there’ll be a return
on investment
FEASIBILITY ANALYSIS
CONCLUSION: COSTS, BENEFITS AND
WRAP-UP
Thanks: Thank the reader for their
time.
Contact information: Where can the
reader get in touch with you? Make
sure to be crystal clear to make the
details easily discoverable.
FEASIBILITY ANALYSIS
Why are Feasibility Studies Difficult?
Uncertainty
• Client – may be unsure of the scope
of the project.
• Benefits – are usually very hard to quantify.
• Approach – is usually ill-defined. Estimates of
resources and timetable are very rough
• Organizational changes may be needed
 Technical feasibility :
focuses on:
• availability of software tools
• availability of hardware
• availability of skilled software
professionals
at the end of this phase a feasibility
report is generated.
1.an SRS ( software requirement specification)
document is generated.

2. SRS is a formal document includes

performance, functional, software ,hardware and
network requirements of the project.

3.it acts as an agreement between development

team and customer .
Requirements Analysis
• Business Requirements
• Stakeholder Requirements
• Solution Requirements
Functional Requirements
Non-functional Requirements
• Transition Requirements
SRS requirement translated into a
raw and logical structure .
 DESIGNING THE SOFTWARE
• Based on the requirements specified in SRS,
usually more than one design approach for
the product architecture is proposed and
documented in a DDS - Design Document
Specification.
• This DDS is reviewed by all the stakeholders
and based on various parameters as risk
assessment, design modularity , budget and
time constraints , the best design approach is
selected for the software.
CODING
developing the software specified in
design document to an executable
programming language code.
 DEVELOPING THE SOFTWARE
In this stage of SDLC the actual development
starts and the product is built. The programming
code is generated as per DDS during this stage.

Developers have to follow the coding guidelines

defined by their organization and programming
tools like compilers, interpreters, debuggers etc
are used to generate and implement the code.
code is mapped against design document

test plan involves:

1. test case generation
2. testing criteria
3. resource allocation for testing
 TESTING THE SOFTWARE
This stage is usually a subset of all the stages as
in the modern SDLC models, the testing
activities are mostly involved in all the stages of
SDLC.

However this stage refers to the testing only

that stage of the software where defects are
reported, tracked, fixed and retested, until the
software reaches the quality standards defined
in the SRS.
 1. handling errors that may exist in
software even after testing phase

2. implementation of new requirements

after software is deployed at customer
location.
DEPLOYMENT and MAINTENANCE
• Once the software is tested and no bugs
or errors are reported then it is
deployed.
• Then based on the feedback, the software
may be released as it is or with suggested
enhancements in the target segment.
• After the software is deployed then
its maintenance starts.
SDLC APPROACH/ MODELS
• Waterfall Model
• Prototyping Model
• Agile
• Spiral Model
• Iterative or Incremental
Model
• SCRUM
WATERFALL APPROACH
uses linear approach ,
that means it provide no process
to go back to previous phase to
handle changes in the
requirement.
Waterfall Model
• Oldest and most well-known SDLC model.

• Follows a sequential step-by-step process

from requirements analysis to
maintenance/testing.

• Systems that have well-defined and

understood requirements are a good fit for the
Waterfall Model.
Waterfall Model: Strengths
• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff, track)
• Works well when quality is more important
than cost or schedule
 Waterfall Model: Weaknesses
• All requirements must be fully specified upfront
• Deliverables created for each phase are
considered
frozen – inhibits flexibility
• Can give a false impression of progress
• Does not reflect problem-solving nature of
software development – iterations of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the
system (until it may be too late)
When to use the Waterfall Model
• Requirements are very well known
• Product definition is stable
• Technology is understood
• New version of an existing software/product
• Porting an existing product to a new platform
2. a prototype is generated acc to
requirements of software that tells
customer how the software is going to
function and to get better knowledge of
requirements.

until the customer approves the prototype ,

generating a new prototype is continued
( before finalizing and frozing the
requirements )
 types of prototypes :
1. throwaway prototypes: those
prototypes that are eventually
discarded rather than becoming a
part of finally delivered software.

2. evolutionary prototypes: are those

that evolve into the final system
through iterative incoorperation of
user(ustomer) feedback.
AGILE
Agile
approach that prioritizes cross-
functional collaboration and
continuous improvement. It divides
projects into smaller phases and
guides teams through cycles of
planning, execution, and
evaluation..
includes both iterative nature of
prototyping approach and linear
nature of waterfall approach.

example: evolution of windows

operating system from windows 3.1 to
windows 2000
there are number of functional units ,
each containing group of similar tasks.

each functional unit is implemented

with an increment and final product is
acheived after all units are
implemented in the development
process.
limitation:

applicable only to large

applications.
Reasons for Using SDLC Models
• Provides the base for project planning, estimating
& scheduling.

• Provides framework for standard set of

terminologies, activities & deliverables.

• Provides mechanism for project tracking &

control.

• Increases visibility of project progress to all

stakeholders.
Advantages of Choosing an Appropriate SDLC
• Increased development speed
• Increased product quality
• Improved tracking & control
• Improved client relations
• Decreased project risk
• Decreased project management
overhead
 SCRUM
Scrum is a software product development strategy
that organizes software developers as a team to
reach a common goal — creating a ready-for-
market product. It is a widely used subset of
agile software development.
The word scrum also is used in rugby to define a
play where players struggle against each to gain
possession of the ball. The goal of a scrum in
software development is to
perform at a high-performing level like a rugby tea
m
does in a scrum.
Scrum was first
introduced by
professors Hirotaka
Takeuchi and Ikujiro
Nonaka in 1986
How Scrum Works
 Who is in the SCRUM
The forwards are involved in the scrum. In software
development, three roles are defined in the scrum
framework:
•The scrum team does the work. It is the individuals
who are working together in the sprints to produce the
products.
•The scrum master is part of the scrum team makes
sure the team works in compliance with the scrum
rules. This is not a manager.
•The product owner represents the customer. This role
prioritizes the backlog and coordinates the scrum
teamwork. The product owner is a role similar to
project manager in more traditional project
management frameworks.
 Benefits of SCRUM
•Developers who want the freedom to make decisions thrive in
scrum teams. Team morale tends to be high.
•Each sprint produces a product that is ready for market even
though the project is ongoing. The highest priority requirements
are addressed first so a high-quality, low-risk product can be on
the market.
•The incremental process shortens the time to market by about 30
percent to 40 percent. Because the product owner is part of the
scrum team, requirements can be delivered as they are needed.
•Scrum projects often realize a higher return on investment (ROI).
This is attributed to:
• Decreased time to market.
• Early and regular feedback that prompts course corrections
early when they are less costly.
• Defects that are fewer and less costly.
• Projects failing early and quickly when it’s less costly.
•Reviewing each sprint before the team moves on to the next
sprint spreads testing throughout development.
•Project focus and goals can change with evolving business goals.
 Disadvantages of SCRUM
While a rugby scrum may get rough and bloody, software
developers shouldn’t have to worry about that. Nonetheless,
scrum is not for all developer teams or software development
projects. There are disadvantages to implementing scrum
projects:
• There is a danger of scope creep if stakeholders keep adding
functionality to the backlog. This could be encouraged by the
fixed deadline.
• Scrum works best with small teams of experienced software
developers. They need to be able to work quickly.
• Scrum teams do not work well when the scrum master
micromanages their work.
• Losing any team members can hurt the progress of the
project.
 SCRUM Best Practices
Teamwork wins rugby games and helps software
developers create quality products. To get the
best quality out of scrum:
• Define requirements just in time to keep product
features as relevant as possible.
• Test and incorporate product owner feedback daily.
• Sprint reviews with stakeholders need to be regular.
• The scrum team needs to use the sprint
retrospectives to improve how they work.
• Conduct face-to-face conversations to reduce
miscommunications.
• Trust the teams to do the best job possible.
• Allow the teams to self-organize around people’s
skills, work styles and personalities.
• Don’t burn out the team members. Respect the
balance between their personal and professional lives
SRS
 Software Requirements Specifications (SRS)
• The production of the requirements
stage of the software development process
-also called a requirements
documents
-is a formal report, which acts as a
representation of software that enables the
customer to review whether it (SRS)
according to their requirements.
 Software Requirements Specifications (SRS)
The SRS is a specification for a specific software
product, program, or set of applications that perform
particular functions in a specific environment.
It serves several goals depending on who is writing it.
• First, the SRS could be written by the client of a system.
• Second, the SRS could be written by a developer of the
system.
• The first case, SRS, is used to define the needs and
expectation of the users.
• The second case, SRS, is written for various purposes and
serves as a contract document between customer and
developer.
Software Requirements Specifications (SRS)
 Following are the features of a good SRS
document
1. Correctness: User review is used to provide the
accuracy of requirements stated in the SRS. SRS is said to be
perfect if it covers all the needs that are truly expected from
the system
2. Completeness: The SRS is complete if, and only if, it
includes the following elements:
- All essential requirements, whether relating to
functionality, performance, design, constraints, attributes, or
external interfaces.
-Definition of their responses of the software to all
realizable classes of input data in all available categories of
situations.
 Following are the features of a good SRS
document
2. Completeness:
- Full labels and references to all figures, tables, and
diagrams in the SRS and definitions of all terms and units of
measure.
3. Consistency: The SRS is consistent if, and only if, no
subset of individual requirements described in its conflict.

4. Unambiguousness: SRS is unambiguous when every

fixed requirement has only one interpretation. This suggests
that each element is uniquely interpreted. In case there is a
method used with multiple definitions, the requirements
report should determine the implications in the SRS so that it
is clear and simple to understand.
 Following are the features of a good SRS
document
5. Ranking for importance and stability: The SRS is ranked
for importance and stability if each requirement in it has an
identifier to indicate either the significance or stability of that
particular requirement.
6. Modifiability: SRS should be made as modifiable as likely
and should be capable of quickly obtain changes to the
system to some extent. Modifications should be perfectly
indexed and cross-referenced.
7. Verifiability: SRS is correct when the specified
requirements can be verified with a cost-effective system to
check whether the final software meets those requirements.
The requirements are verified with the help of reviews.
 Following are the features of a good SRS
document
8. Traceability: The SRS is traceable if the origin of each of
the requirements is clear and if it facilitates the referencing of
each condition in future development or enhancement
documentation.
1. Backward Traceability: This depends upon each
requirement explicitly referencing its source in earlier documents.
2. Forward Traceability: This depends upon each element in
the SRS having a unique name or reference number.
9. Design Independence: There should be an option to select
from multiple design alternatives for the final system. More
specifically, the SRS should not contain any implementation
details.
 Following are the features of a good SRS
document
10. Testability: An SRS should be written in such a method
that it is simple to generate test cases and test plans from the
report.
11. Understandable by the customer: An end user may be an
expert in his/her explicit domain but might not be trained in
computer science. Hence, the purpose of formal notations
and symbols should be avoided too as much extent as
possible. The language should be kept simple and clear.
12. The right level of abstraction: If the SRS is written for
the requirements stage, the details should be explained
explicitly. Whereas, for a feasibility study, fewer analysis can
be used. Hence, the level of abstraction modifies according
to the objective of the SRS.
 (SRS) Format
Introduction
•Purpose of this Document – At first, main aim of why this document
is necessary and what’s purpose of document is explained and
described.
•Scope of this document – In this, overall working and main objective
of document and what value it will provide to customer is described
and explained. It also includes a description of development cost and
time required.
•Overview – In this, description of product is explained. It’s simply
summary or overall review of product.

General description
In this, general functions of product which includes objective of user, a
user characteristic, features, benefits, about why its importance is
mentioned. It also describes features of user community.
 (SRS) Format
Interface Requirements
In this, software interfaces which mean how software
program communicates with each other or users either in
form of any language, code, or message are fully described
and explained. Examples can be shared memory, data
streams, etc.
Performance Requirements
In this, how a software system performs desired functions
under specific condition is explained. It also explains
required time, required memory, maximum error rate, etc.
The performance requirements part of an SRS specifies the
performance constraints on the software system. All the
requirements relating to the performance characteristics of
 (SRS) Format
Performance Requirements
There are two types of performance requirements:
• Static requirements are those that do not impose constraint
on the execution characteristics of the system.
• Dynamic requirements specify constraints on the
execution behavior of the system.

Design Constraints
In this, constraints which simply means limitation or
restriction are specified and explained for design team.
 (SRS) Format
Non-Functional Attributes
In this, non-functional attributes are explained that
are required by software system for better
performance.

Preliminary Schedule and Budget

In this, initial version and budget of project plan are
explained which include overall time duration
required and overall cost required for development of
project.
 (SRS) Format
Appendices
In this, additional information like references from
where information is gathered, definitions of some
specific terms, acronyms, abbreviations, etc. are
given and explained.
 Uses of SRS Document
•Development team require it for developing product
according to the need.
•Test plans are generated by testing group based on
the describe external behavior.
•Maintenance and support staff need it to understand
what the software product is supposed to do.
•Project manager base their plans and estimates of
schedule, effort and resources on it.
 Uses of SRS Document

•customer rely on it to know that product they

can expect.
•As a contract between developer and
customer.
•in documentation purpose.
 FAQs on SRS Format
1. Why is it important to define the scope of an
SRS document?

Defining the scope in an SRS document helps the

customer understand the goals and worth of the
software. It also has details about how much it will
cost to create and how long it will take, so that the
project’s limits are clear.
 FAQs on SRS Format
2. What are functional requirements in an SRS
document, and why are they important?

Functional requirements describe how the software

system is supposed to work, including how it should
react to inputs and make outputs. They help you
figure out what the software needs to do and give you
a place to start building and testing it.
 Conclusion
Conclusion
Software development requires a well-structured
Software Requirement Specification (SRS). It helps
stakeholders communicate, provides a roadmap for
development teams, guides testers in creating
effective test plans, guides maintenance and support
employees, informs project management decisions,
and sets customer expectations. The SRS document
helps ensure that the software meets functional and
non-functional requirements, resulting in a quality
product on time and within budget.
“IF YOU DON’T FEED YOUR MIND
WITH SUCCESS. IT WILL ROT WITH
MEDIOCRITY!”
― BLONDEL SEUMO