Waterfall approach was first SDLC Model to be used widely in Software

Engineering to ensure success of the project. In "The Waterfall" approach,

the whole process of software development is divided into separate phases.
In this Waterfall model, typically, the outcome of one phase acts as the input
for the next phase sequentially.
The following illustration is a representation of the different phases of the
Waterfall Model.

The sequential phases in Waterfall model are −

 Requirement Gathering and analysis − All possible
requirements of the system to be developed are captured in this
phase and documented in a requirement specification document.
 System Design − The requirement specifications from first
phase are studied in this phase and the system design is
prepared. This system design helps in specifying hardware and
system requirements and helps in defining the overall system
architecture.
 Implementation − With inputs from the system design, the
system is first developed in small programs called units, which
are integrated in the next phase. Each unit is developed and
tested for its functionality, which is referred to as Unit Testing.
 Integration and Testing − All the units developed in the
implementation phase are integrated into a system after testing
 of each unit. Post integration the entire system is tested for any
faults and failures.
 Deployment of system − Once the functional and non-
functional testing is done; the product is deployed in the
customer environment or released into the market.
 Maintenance − There are some issues which come up in the
client environment. To fix those issues, patches are released.
Also to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer
environment.
All these phases are cascaded to each other in which progress is seen as
flowing steadily downwards (like a waterfall) through the phases. The next
phase is started only after the defined set of goals are achieved for previous
phase and it is signed off, so the name "Waterfall Model". In this model,
phases do not overlap.

Waterfall Model - Application

Every software developed is different and requires a suitable SDLC approach
to be followed based on the internal and external factors. Some situations
where the use of Waterfall model is most appropriate are −
 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support
the product.
 The project is short.

Waterfall Model - Advantages

The advantages of waterfall development are that it allows for
departmentalization and control. A schedule can be set with deadlines for
each stage of development and a product can proceed through the
development process model phases one by one.
Development moves from concept, through design, implementation, testing,
installation, troubleshooting, and ends up at operation and maintenance.
Each phase of development proceeds in strict order.
Some of the major advantages of the Waterfall Model are as follows −
 Simple and easy to understand and use
 Easy to manage due to the rigidity of the model. Each phase has
specific deliverables and a review process.
  Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well
understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.

Waterfall Model - Disadvantages

The disadvantage of waterfall development is that it does not allow much
reflection or revision. Once an application is in the testing stage, it is very
difficult to go back and change something that was not well-documented or
thought upon in the concept stage.
The major disadvantages of the Waterfall Model are as follows −
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a
moderate to high risk of changing. So, risk and uncertainty is
high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a project.

PROTOTYPE MODEL

The prototype model requires that before carrying out the development of
actual software, a working prototype of the system should be built. A
prototype is a toy implementation of the system. A prototype usually turns
out to be a very crude version of the actual system, possible exhibiting
limited functional capabilities, low reliability, and inefficient performance as
compared to actual software. In many instances, the client only has a
general view of what is expected from the software product. In such a
scenario where there is an absence of detailed information regarding the
input to the system, the processing needs, and the output requirement, the
prototyping model may be employed.
Steps of Prototype Model

1. Requirement Gathering and Analyst

2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product
Advantage of Prototype Model

1. Reduce the risk of incorrect user requirement

2. Good where requirement are changing/uncommitted
3. Regular visible process aids management
4. Support early product marketing
5. Reduce Maintenance cost.
6. Errors can be detected much earlier as the system is made side by
side.

Disadvantage of Prototype Model

1. An unstable/badly implemented prototype often becomes the final

product.
2. Require extensive customer collaboration
o Costs customer money
o Needs committed customer
o Difficult to finish if customer withdraw
o May be too customer specific, no broad market
3. Difficult to know how long the project will last.
4. Easy to fall back into the code and fix without proper requirement
analysis, design, customer evaluation, and feedback.
5. Prototyping tools are expensive.
6. Special tools & techniques are required to build a prototype.
7. It is a time-consuming process.

Iterative Model - Design

Iterative process starts with a simple implementation of a subset of the software requirements
and iteratively enhances the evolving versions until the full system is implemented. At each
iteration, design modifications are made and new functional capabilities are added. The basic
idea behind this method is to develop a system through repeated cycles (iterative) and in smaller
portions at a time (incremental).
The following illustration is a representation of the Iterative and Incremental model −

Iterative and Incremental development is a combination of both iterative design or iterative

method and incremental build model for development. "During software development, more than
one iteration of the software development cycle may be in progress at the same time." This
process may be described as an "evolutionary acquisition" or "incremental build" approach."
In this incremental model, the whole requirement is divided into various builds. During each
iteration, the development module goes through the requirements, design, implementation and
testing phases. Each subsequent release of the module adds function to the previous release. The
process continues till the complete system is ready as per the requirement.
The key to a successful use of an iterative software development lifecycle is rigorous validation
of requirements, and verification & testing of each version of the software against those
requirements within each cycle of the model. As the software evolves through successive cycles,
tests must be repeated and extended to verify each version of the software.

Iterative Model - Application

Like other SDLC models, Iterative and incremental development has some specific applications
in the software industry. This model is most often used in the following scenarios −
 Requirements of the complete system are clearly defined and understood.
 Major requirements must be defined; however, some functionalities or requested
enhancements may evolve with time.
 There is a time to the market constraint.
 A new technology is being used and is being learnt by the development team
while working on the project.
 Resources with needed skill sets are not available and are planned to be used on
contract basis for specific iterations.
 There are some high-risk features and goals which may change in the future.

Iterative Model - Pros and Cons

The advantage of this model is that there is a working model of the system at a very early stage
of development, which makes it easier to find functional or design flaws. Finding issues at an
early stage of development enables to take corrective measures in a limited budget.
The disadvantage with this SDLC model is that it is applicable only to large and bulky software
development projects. This is because it is hard to break a small software system into further
small serviceable increments/modules.
The advantages of the Iterative and Incremental SDLC Model are as follows −
 Some working functionality can be developed quickly and early in the life cycle.
 Results are obtained early and periodically.
 Parallel development can be planned.
 Progress can be measured.
 Less costly to change the scope/requirements.
 Testing and debugging during smaller iteration is easy.
 Risks are identified and resolved during iteration; and each iteration is an easily
managed milestone.
 Easier to manage risk - High risk part is done first.
 With every increment, operational product is delivered.
 Issues, challenges and risks identified from each increment can be utilized/applied
to the next increment.
 Risk analysis is better.
 It supports changing requirements.
 Initial Operating time is less.
 Better suited for large and mission-critical projects.
 During the life cycle, software is produced early which facilitates customer
evaluation and feedback.
The disadvantages of the Iterative and Incremental SDLC Model are as follows −
 More resources may be required.
 Although cost of change is lesser, but it is not very suitable for changing
requirements.
 More management attention is required.
 System architecture or design issues may arise because not all requirements are
gathered in the beginning of the entire life cycle.
 Defining increments may require definition of the complete system.
 Not suitable for smaller projects.
 Management complexity is more.
 End of project may not be known which is a risk.
 Highly skilled resources are required for risk analysis.
 Projects progress is highly dependent upon the risk analysis phase.

Rational Unified Process (RUP) is a software development process for object-

oriented models. It is also known as the Unified Process Model. It is created by
Rational corporation and is designed and documented using UML (Unified
Modeling Language). This process is included in IBM Rational Method
Composer (RMC) product. IBM (International Business Machine Corporation)
allows us to customize, design, and personalize the unified process. RUP is
proposed by Ivar Jacobson, Grady Bootch, and James Rambaugh. Some
characteristics of RUP include use-case driven, Iterative (repetition of the
process), and Incremental (increase in value) by nature, delivered online using
web technology, can be customized or tailored in modular and electronic form,
etc. RUP reduces unexpected development costs and prevents wastage of
resources.
Phases of RUP: There is total of five phases of the life cycle of
RUP:

1. Inception –
 Communication and planning are the main ones.
 Identifies the scope of the project using a use-case model
allowing managers to estimate costs and time required.
 Customers’ requirements are identified and then it becomes
easy to make a plan for the project.
  The project plan, Project goal, risks, use-case model, and
Project description, are made.
 The project is checked against the milestone criteria and if it
couldn’t pass these criteria then the project can be either
canceled or redesigned.
2. Elaboration –
 Planning and modeling are the main ones.
 A detailed evaluation and development plan is carried out
and diminishes the risks.
 Revise or redefine the use-case model (approx. 80%),
business case, and risks.
 Again, checked against milestone criteria and if it couldn’t
pass these criteria then again project can be canceled or
redesigned.
 Executable architecture baseline.
3. Construction –
 The project is developed and completed.
 System or source code is created and then testing is done.
 Coding takes place.
4. Transition –
 The final project is released to the public.
 Transit the project from development into production.
 Update project documentation.
 Beta testing is conducted.
 Defects are removed from the project based on feedback
from the public.
5. Production –
 The final phase of the model.
 The project is maintained and updated accordingly.
Advantages:
1. It provides good documentation, it completes the process in itself.
2. It provides risk-management support.
3. It reuses the components, and hence total time duration is less.
4. Good online support is available in the form of tutorials and training.
Disadvantages:
1. Team of expert professional is required, as the process is complex.
2. Complex and not properly organized process.
3. More dependency on risk management.
4. Hard to integrate again and again.
TIME BOXING MODEL

In time boxing model, development is done iteratively as in the iterative enhancement

model. However, in time boxing model, each iteration is done in a timebox of fixed
duration. The functionality to be developed is adjusted to fit the duration of the timebox.
Moreover, each timebox is divided into a sequence of fixed stages where each stage
performs a clearly defined task (analysis, implementation, and deploy) that can be
done independently. This model also requires that the time duration of each stage is
approximately equal so that pipelining concept is employed to have the reduction in
development time and product releases.
There is a dedicated team for each stage so that the work can be done in pipelining.
Thus, stages should be chosen in such a way that each stage perform some logical
unit of work that becomes the input for next stage.
In addition to the advantages of iterative model, time boxing model has some other
advantages too. Various advantages and disadvantages associated with timeboxing
model are listed in Table.
Table Advantages and Disadvantages of the Time boxing Model

Advantages Disadvantages
 Speeds up the development process  Project management becomes more
and shortens the delivery time complex.

 Well suited to develop projects with a  Not suited to projects in which entire
number of features in short time development work cannot be divided
period. into multiple iterations of almost
equal duration.
SRS MODEL

SRS is a formal document, which acts as a representation of software that enables the
users to review whether it (SRS) is according to their requirements. In addition, it
includes user requirements for a system as well as detailed specifications of the
system requirements.
IEEE defines software requirements specification as, ‘a document that clearly and
precisely describes each of the essential requirements (functions, performance, design
constraints and quality attributes) of the software and the external interfaces. Each
requirement is defined in such a way that its achievement can be objectively verified by
a prescribed method, for example, inspection, demonstration, analysis or test.’ Note
that requirements specification can be in the form of a written document, a
mathematical model, a collection of graphical models, a prototype, and so on.
Essentially, what passes from requirements analysis activity to the specification activity
is the knowledge acquired about the system. The need for maintaining a requirements
document is that the modeling activity essentially focuses on the problem structure and
not its structural behavior. While in SRS, performance constraints, design constraints,
and standard compliance recovery are clearly specified. This information helps in
developing a proper design of the system. Various other purposes served by SRS are
listed below.

 Feedback: Provides a feedback, which ensures to the user that the organization
(which develops the software) understands the issues or problems to be solved
and the software behavior necessary to address those problems.

 Decompose problem into components: Organizes the information and divides

the problem into its component parts in an orderly manner.

 Validation: Uses validation strategies applied to the requirements to acknowledge

that requirements are stated properly.

 Input to design: Contains sufficient detail in the functional system requirements

to devise a design solution.

 Basis for agreement between the user and the organization: Provides a
complete description of the functions to be performed by the system. In addition, it
helps the users to determine whether the specified requirements are
accomplished.

 Reduce the development effort: Enables developers to consider user

requirements before the designing of the system commences. As a result, ‘rework’
and inconsistencies in the later stages can be reduced.

 Estimating costs and schedules: Determines the requirements of the system

and thus enables the developer to have a ‘rough’ estimate of the total cost and
schedule of the project.
SRS is used by various individuals in the organization. System customers need SRS to
specify and verify whether requirements meet the desired needs. In addition, SRS
enables the managers to plan for the system development processes. System
engineers need a requirements document to understand what system is to be
developed. These engineers also require this document to develop validation tests for
the required system. Lastly, requirements document is needed by system maintenance
engineers to use the requirement and the relationship between its parts.

The requirements document has diverse users. Therefore, along with communicating
the requirements to the users it also has to define the requirements in precise detail for
developers and testers. In addition it should also include information about possible
changes in the system, which can help system designers avoid restricted decisions on
design. SRS also helps maintenance engineers to adapt the system to new
requirements.
We’ll be covering the following topics in this tutorial:

 Characteristics of SRS
 Structure of SRS
Characteristics of SRS

Software requirements specification 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.
Other characteristics of SRS are discussed below.

 Correct: SRS is correct when all user requirements are stated in the requirements
document. The stated requirements should be according to the desired system.
 This implies that each requirement is examined to ensure that it (SRS) represents
user requirements. Note that there is no specified tool or procedure to assure the
correctness of SRS. Correctness ensures that all specified requirements are
performed correctly.

 Unambiguous: SRS is unambiguous when every stated requirement has only

one interpretation. This implies that each requirement is uniquely interpreted. In
case there is a term used with multiple meanings, the requirements document
should specify the meanings in the SRS so that it is clear and easy to understand.

 Complete: SRS is complete when the requirements clearly define what the
software is required to do. This includes all the requirements related to
performance, design and functionality.

 Ranked for importance/stability: All requirements are not equally important,

hence each requirement is identified to make differences among other
requirements. For this, it is essential to clearly identify each requirement. Stability
implies the probability of changes in the requirement in future.

 Modifiable: The requirements of the user can change, hence requirements

document should be created in such a manner that those changes can be
modified easily, consistently maintaining the structure and style of the SRS.

 Traceable: SRS is traceable when the source of each requirement is clear and
facilitates the reference of each requirement in future. For this, forward tracing and
backward tracing are used. Forward tracing implies that each requirement should
be traceable to design and code elements. Backward tracing implies defining each
requirement explicitly referencing its source.

 Verifiable: SRS is verifiable when the specified requirements can be verified with
a cost-effective process to check whether the final software meets those
requirements. The requirements are verified with the help of reviews. Note that
unambiguity is essential for verifiability.

 Consistent: SRS is consistent when the subsets of individual requirements

defined do not conflict with each other. For example, there can be a case when
different requirements can use different terms to refer to the same object. There
can be logical or temporal conflicts between the specified requirements and some
requirements whose logical or temporal characteristics are not satisfied. For
instance, a requirement states that an event ‘a’ is to occur before another event
‘b’. But then another set of requirements states (directly or indirectly by transitivity)
that event ‘b’ should occur before event ‘a’.

Structure of SRS

The requirements document is devised in a manner that is easier to write, review, and
maintain. It is organized into independent sections and each section is organized into
modules or units. Note that the level of detail to be included in the SRS depends on the
type of the system to be developed and the process model chosen for its development.
For example, if a system is to be developed by an external contractor, then critical
system specifications need to be precise and detailed. Similarly, when flexibility is
required in the requirements and where an in-house development takes place,
requirements documents can be less detailed.
Since the requirements document serves as a foundation for subsequent software
development phases, it is important to develop the document in the prescribed manner.
For this, certain guidelines are followed while preparing SRS. These guidelines are
listed below.

 Functionality: It should be separate from implementation.

 Analysis model: It should be developed according to the desired behavior of a

system. This should include data and functional response of a system to various
inputs given to it.

 Cognitive model: It should be developed independently of design or

implementation model. This model expresses a system as perceived by the users.

 The content and structure of the specification: It should be flexible enough to

accommodate changes.

 Specification: It should be robust. That is, it should be tolerant towards

incompleteness and complexity.

The information to be included in SRS depends on a number of factors, for example,

the type of software being developed and the approach used in its development. If
software is developed using the iterative development process, the requirements
document will be less detailed as compared to that of the software developed for
critical systems. This is because specifications need to be very detailed and accurate
in these systems. A number of standards have been suggested to develop a
requirements document. However, the most widely used standard is by IEEE, which
acts as a general framework. This general framework can be customized and adapted
to meet the needs of a particular organization.
Each SRS fits a certain pattern; thus, it is essential to standardize the structure of the
requirements document to make it easier to understand. For this IEEE standard is used
for SRS to organize requirements for different projects, which provides different ways
of structuring SRS. Note that in all requirements documents, the first two sections are
the same.
This document comprises the following sections.

 Introduction: This provides an overview of the entire information described in

SRS. This involves purpose and the scope of SRS, which states the functions to
be performed by the system. In addition, it describes definitions, abbreviations,
and the acronyms used. The references used in SRS provide a list of documents
that is referenced in the document.
 Overall description: It determines the factors which affect the requirements of the
system. It provides a brief description of the requirements to be defined in the next
section called ‘specific requirement’. It comprises the following sub-sections.

 Product perspective: It determines whether the product is an independent

product or an integral part of the larger product. It determines the interface with
hardware, software, system, and communication. It also
defines memory constraints and operations utilized by the user.

 Product functions: It provides a summary of the functions to be performed by the

software. The functions are organized in a list so that they are easily
understandable by the user:

 User characteristics: It determines general characteristics of the users.

 Constraints: It provides the genera1 description of the constraints such as

regulatory policies, audit functions, reliability requirements, and so on.

 Assumption and dependency: It provides a list of assumptions and factors that

affect the requirements as stated in this document.

 Apportioning of requirements: It determines the requirements that can be

delayed until release of future versions of the system.

 Specific requirements: These determine all requirements in detail so that the

designers can design the system in accordance with them. The requirements
include description of every input and output of the system and functions
performed in response to the input provided. It comprises the following
subsections.

 External interface: It determines the interface of the software with other systems,
which can include interface with operating system and so on. External interface
also specifies the interaction of the software with users, hardware, or other
software. The characteristics of each user interface of the software product are
specified in SRS. For the hardware interface, SRS specifies the logical
characteristics of each interface among the software and hardware components. If
the software is to be executed on the existing hardware, then characteristics such
as memory restrictions are also specified.

 Functions: It determines the functional capabilities of the system. For each

functional requirement, the accepting and processing of inputs in order to generate
outputs are specified. This includes validity checks on inputs, exact sequence of
operations, relationship of inputs to output, and so on.

 Performance requirements: It determines the performance constraints of the

software system. Performance requirement is of two types: static requirements
and dynamic requirements. Static requirements (also known as capacity
requirements) do not impose constraints on the execution characteristics of the
system. These include requirements like number of terminals and users to be
supported. Dynamic requirements determine the constraints on the execution of
 the behavior of the system, which includes response time (the time between the
start and ending of an operation under specified conditions) and throughput (total
amount of work done in a given time).

 Logical database of requirements: It determines logical requirements to be

stored in the database. This includes type of information used, frequency of
usage, data entities and relationships among them, and so on.

 Design constraint: It determines all design constraints that are imposed by

standards, hardware limitations, and so on. Standard compliance determines
requirements for the system, which are in compliance with the specified standards.
These standards can include accounting procedures and report format. Hardware
limitations implies when the software can operate on existing hardware or some
pre-determined hardware. This can impose restrictions while developing the
software design. Hardware limitations include hardware configuration of the
machine and operating system to be used.

 Software system attributes: It provide attributes such as reliability, availability,

maintainability and portability. It is essential to describe all these attributes to verify
that they are achieved in the final system.

 Organizing Specific Requirements: It determines the requirements so that they

can be properly organized for optimal understanding. The requirements can be
organized on the basis of mode of operation, user classes, objects, feature,
response, and functional hierarchy.

 Change management process: It determines the change management process

in order to identify, evaluate, and update SRS to reflect changes in the project
scope and requirements.

 Document approvals: These provide information about the approvers of the SRS
document with the details such as approver’s name, signature, date, and so on.

 Supporting information: It provides information such as table of contents, index,

and so on. This is necessary especially when SRS is prepared for large and
complex projects.
 Agile is an iterative way of managing projects and developing software
that makes it easier for teams to deliver value to their customers more
quickly and effectively. An agile team is to deliver small but
consumable increments of work rather than wagering everything on a
"big bang" launch.
 Agile methodologies enable organizations to deliver value to customers
faster and with fewer complications by systematically managing
projects and developing software in an iterative fashion. The approach
of an agile team is to deliver work in small, but consumable,
 increments, rather than wagering everything on a "big bang" launch.
As a result of continuously evaluating requirements, plans, and results,
teams are able to respond to change in a timely manner.

What is Agile: Understanding Agile Methodologies

and Principles
Lesson 1 of 10By Rahul Arun
Last updated on Dec 21, 202257916

PreviousNext

Table of Contents
What is Agile?
Agile is a Mindset
Agile Methodologies
Agile Principles
Key Agile Concepts
View More

There are many tools and techniques in today's world that can help you
maximize the value of the output produced. Among the many options
available, Agile is one of the most commonly used. This is because of its
ability to enable teams to work in small increments and respond to changes
quickly.

Get Your CSM Certification the Easy

Way
Certified ScrumMaster® Certification TrainingEXPLORE COURSE

Before we can get started with Agile, we’ll need to really understand
the waterfall model.

Gain deep insights into the highly popular Agile Scrum project methodology with
the Agile Scrum Master Certification Training! Check out the course now.

What is Agile?

Agile is an iterative way of managing projects and developing software that

makes it easier for teams to deliver value to their customers more quickly
and effectively. An agile team is to deliver small but consumable increments
of work rather than wagering everything on a "big bang" launch.

Agile methodologies enable organizations to deliver value to customers

faster and with fewer complications by systematically managing projects and
developing software in an iterative fashion. The approach of an agile team is
to deliver work in small, but consumable, increments, rather than wagering
everything on a "big bang" launch. As a result of continuously evaluating
requirements, plans, and results, teams are able to respond to change in a
timely manner.
Agile is a Mindset

The values and principles of the Agile Manifesto serve as the foundation for
the agile mindset. These values and principles offer direction on change,
react, and handle uncertainty. Try something you think might work when
faced with uncertainty, get feedback, and make adjustments as needed.

Master Scrum with 2-Day Immersive

Online Training
Certified ScrumMaster® Certification TrainingEXPLORE COURSE

Agile Methodologies

1. Extreme Programming

It is a framework that enables teams to create high-quality software that

helps improve their quality of life. It enables software development alongside
appropriate engineering practices. It is applicable while handling changing
software requirements risks caused due to new software, working with a
small, extended development team, and technology that allows automated
unit and functional tests.

2. Kanban

It is a method that’s used to design, manage, and improve the flow of

systems. Kanban enables organizations to visualize their flow of work and
limit the amount of work in progress. It is used in situations where work
arrives unpredictably, and where it needs to be deployed immediately
without waiting for other work items.

3. Lean

It is a set of tools and principles that focuses on identifying and removing

waste to speed up process development. Value is maximized, and waste is
minimized. It is used in just about every industry that produces waste in
some form.

4. Scrum

It is a framework used by teams to establish a hypothesis, test it, reflect on

the experience, and make adjustments. It enables teams to incorporate
practices from other frameworks depending on the requirements. It is used
by cross-functional teams that are working on product development, and the
work is split into more than one 2-4 week iterations.

5. Crystal

It focuses on people and their interactions, rather than on tools and

processes. Aimed to streamline processes and improve optimization, Crystal
works on the principle that projects are unique and dynamic. It is used when
the focus is on strengthening team communication, continuous integration,
active user involvement, and configurable processes.

Agile Principles

To make a process Agile, the following principles need to be satisfied.

1. Customer Satisfaction

The customer needs to be satisfied with the quick delivery of the product.

2. Welcome Change

Even late in the development process, changing needs need to be

addressed.
3. Deliver Frequently

Focus on a shorter timescale, and ensure products are delivered frequently.

4. Work Together

The business and development team need to work together through the
course of the project.
 Get Your CSM Certification the Easy
Way
Certified ScrumMaster® Certification TrainingEXPLORE COURSE

5. Motivated Team

Team members must be motivated and trusted to complete the project

successfully and on time.

6. Face-to-face
Having face-to-face interactions is one of the most effective forms of
communication.

7. Working Software

Having working output is an indication of the progress made towards the

final product.

8. Constant Pace

Agile promotes sustainable development.

9. Good Design

Improve agility by focusing on good design and technical excellence.

10. Simplicity

The amount of time where work isn’t being done needs to be reduced.
11. Self-Organization

These types of teams provide the best designs, requirements, and

architectures.

12. Reflect and Adjust

The effectiveness of the team can be improved by regularly reflecting on

their work and making improvements.

What is Agile: Understanding Agile Methodologies

and Principles
Lesson 1 of 10By Rahul Arun
Last updated on Dec 21, 202257916
PreviousNext

Table of Contents
What is Agile?
Agile is a Mindset
Agile Methodologies
Agile Principles
Key Agile Concepts
View More

There are many tools and techniques in today's world that can help you
maximize the value of the output produced. Among the many options
available, Agile is one of the most commonly used. This is because of its
ability to enable teams to work in small increments and respond to changes
quickly.

Get Your CSM Certification the Easy

Way
Certified ScrumMaster® Certification TrainingEXPLORE COURSE
Before we can get started with Agile, we’ll need to really understand
the waterfall model.

Gain deep insights into the highly popular Agile Scrum project methodology with
the Agile Scrum Master Certification Training! Check out the course now.

What is Agile?

Agile is an iterative way of managing projects and developing software that

makes it easier for teams to deliver value to their customers more quickly
and effectively. An agile team is to deliver small but consumable increments
of work rather than wagering everything on a "big bang" launch.

Agile methodologies enable organizations to deliver value to customers

faster and with fewer complications by systematically managing projects and
developing software in an iterative fashion. The approach of an agile team is
to deliver work in small, but consumable, increments, rather than wagering
everything on a "big bang" launch. As a result of continuously evaluating
requirements, plans, and results, teams are able to respond to change in a
timely manner.

Agile is a Mindset

The values and principles of the Agile Manifesto serve as the foundation for
the agile mindset. These values and principles offer direction on change,
react, and handle uncertainty. Try something you think might work when
faced with uncertainty, get feedback, and make adjustments as needed.
 Master Scrum with 2-Day Immersive
Online Training
Certified ScrumMaster® Certification TrainingEXPLORE COURSE

Agile Methodologies

1. Extreme Programming

It is a framework that enables teams to create high-quality software that

helps improve their quality of life. It enables software development alongside
appropriate engineering practices. It is applicable while handling changing
software requirements risks caused due to new software, working with a
small, extended development team, and technology that allows automated
unit and functional tests.

2. Kanban

It is a method that’s used to design, manage, and improve the flow of

systems. Kanban enables organizations to visualize their flow of work and
limit the amount of work in progress. It is used in situations where work
arrives unpredictably, and where it needs to be deployed immediately
without waiting for other work items.

3. Lean

It is a set of tools and principles that focuses on identifying and removing

waste to speed up process development. Value is maximized, and waste is
minimized. It is used in just about every industry that produces waste in
some form.

4. Scrum

It is a framework used by teams to establish a hypothesis, test it, reflect on

the experience, and make adjustments. It enables teams to incorporate
practices from other frameworks depending on the requirements. It is used
by cross-functional teams that are working on product development, and the
work is split into more than one 2-4 week iterations.

5. Crystal

It focuses on people and their interactions, rather than on tools and

processes. Aimed to streamline processes and improve optimization, Crystal
works on the principle that projects are unique and dynamic. It is used when
the focus is on strengthening team communication, continuous integration,
active user involvement, and configurable processes.

Read more: Agile vs Scrum: Know the Main Differences and Similarities

Read more: Benefits of Agile Methodology

Next up, let’s take a look at some Agile principles.

FREE Agile Scrum Foundation Course

Master the fundamentals of agile and scrum nowSTART LEARNING

Agile Principles
To make a process Agile, the following principles need to be satisfied.

1. Customer Satisfaction

The customer needs to be satisfied with the quick delivery of the product.

2. Welcome Change

Even late in the development process, changing needs need to be

addressed.
3. Deliver Frequently

Focus on a shorter timescale, and ensure products are delivered frequently.

4. Work Together

The business and development team need to work together through the
course of the project.
 Get Your CSM Certification the Easy
Way
Certified ScrumMaster® Certification TrainingEXPLORE COURSE

5. Motivated Team

Team members must be motivated and trusted to complete the project

successfully and on time.

6. Face-to-face
Having face-to-face interactions is one of the most effective forms of
communication.

7. Working Software

Having working output is an indication of the progress made towards the

final product.

8. Constant Pace

Agile promotes sustainable development.

9. Good Design

Improve agility by focusing on good design and technical excellence.

10. Simplicity

The amount of time where work isn’t being done needs to be reduced.
11. Self-Organization

These types of teams provide the best designs, requirements, and

architectures.

12. Reflect and Adjust

The effectiveness of the team can be improved by regularly reflecting on

their work and making improvements.

Agile Concepts

Here are a few essential Agile concepts.

  User Stories: The team divides the work into functional units known as
"user stories" in consultation with the client or product owner. Each user
story must add something valuable to the final product.

 Daily Meeting: The team meets every day at the same time to update
everyone on the information necessary for coordination:

 Personas: When the project requires it, the team creates in-depth,
fabricated biographies of hypothetical users of the intended product.

 Team: A small group of individuals assigned to the same project or effort,

almost all of whom work full-time, is referred to as a "team" in the Agile
context.

 Incremental Development: Agile teams prefer to use an incremental

development strategy, which in an Agile setting means that each iteration
of the product improves on the one before it by including user-visible
functionality.

 Iterative development: Agile projects intentionally permit "repeating"

software development activities and the potential for "revisiting" the same
work products, known as iterative development.

 Milestone Retrospective: After a project has been running for a while, the
team dedicates one to three days to examine the key moments

Advantages of Agile

 Agile enables a large amount of collaboration and interaction

between the client and the project team.

 Thanks to this, clients have improved transparency, and therefore a

clearer understanding of the phases of the project is present.
  The product is delivered predictably, or sometimes earlier than
expected.

 The cost of the project is predictable and follows a rigid schedule.

 Changes can refine and re-prioritize the product backlog.

 Enables the client to prioritize different features, allowing the team

to ensure maximum project value.

 The project is broken down into smaller units, providing high-quality

development, testing, and collaboration.

Agile Disadvantages

 Organizational cultures can conflict with agile values

 Teams may use inconsistent practices

 Teams may encounter resistance from organizations to change in

adoption.

Software Requirement Specifications

The production of the requirements stage of the software development
process is Software Requirements Specifications (SRS) (also called
a requirements document). This report lays a foundation for software
engineering activities and is constructing when entire requirements are
elicited and analyzed. SRS is a formal report, which acts as a representation
of software that enables the customers to review whether it (SRS) is
according to their requirements. Also, it comprises user requirements for a
system as well as detailed specifications of the system requirements.

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 two methods create entirely various situations
and establish different purposes for the document altogether. 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.

Characteristics of good 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.
 Play Video

2. Completeness: The SRS is complete if, and only if, it includes the
following elements:

(1). All essential requirements, whether relating to functionality,

performance, design, constraints, attributes, or external interfaces.

(2). Definition of their responses of the software to all realizable classes of

input data in all available categories of situations.

Note: It is essential to specify the responses to both valid and invalid values.

(3). 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. There are three types of possible
conflict in the SRS:

(1). The specified characteristics of real-world objects may conflicts. For

example,

(a) The format of an output report may be described in one requirement as

tabular but in another as textual.

(b) One condition may state that all lights shall be green while another states
that all lights shall be blue.

(2). There may be a reasonable or temporal conflict between the two

specified actions. For example,

(a) One requirement may determine that the program will add two inputs,
and another may determine that the program will multiply them.
(b) One condition may state that "A" must always follow "B," while other
requires that "A and B" co-occurs.

(3). Two or more requirements may define the same real-world object but
use different terms for that object. For example, a program's request for user
input may be called a "prompt" in one requirement's and a "cue" in another.
The use of standard terminology and descriptions promotes consistency.

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.

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.

Typically, all requirements are not equally important. Some prerequisites

may be essential, especially for life-critical applications, while others may be
desirable. Each element should be identified to make these differences clear
and explicit. Another way to rank requirements is to distinguish classes of
items as essential, conditional, and optional.

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.

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.

There are two types of Traceability:

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.
The forward traceability of the SRS is especially crucial when the software
product enters the operation and maintenance phase. As code and design
document is modified, it is necessary to be able to ascertain the complete
set of requirements that may be concerned by those modifications.

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.

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.

Properties of a good SRS document

The essential properties of a good SRS document are the following:

Concise: The SRS report should be concise and at the same time,
unambiguous, consistent, and complete. Verbose and irrelevant descriptions
decrease readability and also increase error possibilities.

Structured: It should be well-structured. A well-structured document is

simple to understand and modify. In practice, the SRS document undergoes
several revisions to cope up with the user requirements. Often, user
requirements evolve over a period of time. Therefore, to make the
modifications to the SRS document easy, it is vital to make the report well-
structured.

Black-box view: It should only define what the system should do and
refrain from stating how to do these. This means that the SRS document
should define the external behavior of the system and not discuss the
implementation issues. The SRS report should view the system to be
developed as a black box and should define the externally visible behavior of
the system. For this reason, the SRS report is also known as the black-box
specification of a system.
Conceptual integrity: It should show conceptual integrity so that the
reader can merely understand it. Response to undesired events: It should
characterize acceptable responses to unwanted events. These are called
system response to exceptional conditions.

Verifiable: All requirements of the system, as documented in the SRS

document, should be correct. This means that it should be possible to decide
whether or not requirements have been met in an implementation.