This graph represents the Failure Rate vs. Time for software systems.

Explanation

• The Y-axis represents the failure rate of the software.

• The X-axis represents time as the software evolves.
• The Idealized Curve (smooth and decreasing) shows what would happen if software
improvements always reduced failure rates smoothly.
• The Actual Curve (fluctuating) reflects reality:
o When changes are made, failure rates initially spike due to unintended side
effects (new bugs introduced).
o Over time, failure rates decrease again as these bugs are fixed.
o However, each change cycle repeats the pattern—causing a new temporary
spike in failures.
o Long-term, failure rates may increase overall due to accumulated complexity.

Key Takeaways

1. Software is never perfect—changes often introduce new issues before stabilizing.

2. Continuous testing and maintenance are necessary to control failure rates.
3. Real-world software evolution is unpredictable, unlike the idealized curve

Software Engineering is the process of building software in a planned and organized way
so that it works well, is easy to use, and can be maintained over time.

Why is it Important?

• It helps make software reliable and error-free.

• It ensures software is easy to update and improve.
• It allows teams to work together efficiently.

What is a Partially Completed Increment in Software Deployment?

A partially completed increment refers to a part of the software that is functional but not
fully finished. It contains some features that are ready for use while others are still in
development. This is common in incremental and agile software development approaches

Example:

Imagine you're developing a mobile banking app. Instead of waiting until the entire app is
finished, you first release:
✅ Login & Account Balance Feature (Increment 1)
✅ Fund Transfer Feature (Increment 2)
🚧 Bill Payments Feature (Still in development)

Each of these increments is deployed partially completed, allowing users to benefit from
the available features while the rest is being built.
Simple Explanation of the Waterfall Model

1 When is it Used?

• When we clearly understand what the software needs to do.

• When the work can flow step by step from start to finish.
• When making small updates or improvements to an existing system.
• When starting a new project, but only if the requirements won’t change.

2 How Does it Work?

The Waterfall Model is a step-by-step method for developing software. It follows a fixed
order:
✔ Communication – Talking with the customer to understand what they need.
✔ Planning – Deciding how to build the software.
✔ Modeling – Designing how the software will look and work.
✔ Construction – Writing the code and developing the system.
✔ Deployment – Delivering the software for users.
✔ Support – Fixing problems and making updates over time.

3 Key Idea
The Waterfall Model is like a one-way street—each step must be finished before moving to
the next. It works well only when requirements are clear and stable.

V-Model (Variation of the Waterfall Model - V1) Explained Simply

The V-Model is a variation of the Waterfall Model that focuses on quality assurance
(testing) at every stage of software development. It ensures that for every development
phase, there is a corresponding testing phase.

How Does the V-Model Work?

📌 The left side of the "V" represents the development process:

1 Communication – Understand the basic problem and what the customer needs.
2 Modeling – Convert customer needs into a more detailed technical design.
3 Early Construction – Break down the design further into smaller components, getting
ready to code.

📌 Bottom of the V: Code is written based on the design.

📌 The right side of the "V" represents the testing process:

4 Unit Testing – Check if individual pieces of code work correctly.
5 Integration Testing – Verify that different parts of the software work together.
6 System Testing – Ensure the whole system functions properly.
7 Acceptance Testing – Confirm that the final software meets customer requirements.

Key Points to Remember

✔ The V-Model connects each development phase to a corresponding testing phase,
ensuring early error detection.
✔ As the team moves down the left side, requirements and design become more detailed.
✔ As the team moves up the right side, they verify (test) each part to ensure correctness.
✔ The V-Model is similar to the Waterfall Model, but with a strong focus on testing at
every stage.
✔ It helps in better quality assurance by catching errors early.

When is the Waterfall Model Most Appropriate?

The Waterfall Model works best in situations where the project is well-defined, stable, and
predictable. Here are the key conditions where it is most suitable:

✅ 1. Requirements are Clear and Fixed

• The customer knows exactly what they want.

• There are no frequent changes or new features being added later.
• Example: Building a calculator app where all features (addition, subtraction, etc.) are
known beforehand.

✅ 2. The Product Definition is Stable

• The software’s purpose and scope won’t change during development.

• There is no risk of redesigning major parts of the system.
• Example: A payroll system where salary calculations follow fixed rules.

✅ 3. Technology is Well Understood

• The tools, programming languages, and frameworks are already known and tested.
• There’s no need to experiment with new or emerging technologies.
• Example: Developing a desktop application using well-known programming
languages like Java or C++.

✅ 4. No Ambiguous Requirements

• All features and functionalities are clearly defined from the start.
• No confusion about how the software should work.
• Example: A library management system where book records, member details, and
lending rules are straightforward.

✅ 5. Sufficient Resources and Expertise are Available

• Skilled developers, testers, and designers are ready to work on the project.
• There’s enough time and budget to follow each step of the Waterfall model
properly.
• Example: A government project where funding and manpower are fully allocated.
✅ 6. The Project is Short

• Waterfall is not ideal for long, complex projects because changes are hard to make
later.
• It works best for small, well-defined projects with clear goals.
• Example: A simple online survey system that collects responses and generates
reports.

Advantages:

1. Easy to manage due to the rigidity of the model: The Waterfall model is structured
and follows a strict sequence, making it easier to manage because you know what
comes next.
2. Each phase has specific deliverables and a review: Every stage of the project has
clear goals and tasks, making it easy to track progress.
3. Phases are processed and completed one at a time: Each phase is finished before
the next one starts, preventing overlap or confusion.
4. Works well for smaller projects where requirements are well understood: If the
project is small and the requirements are clear from the beginning, this model works
effectively.
5. Clearly defined stages: The project is divided into distinct phases like design,
development, testing, etc., making it easy to follow.
6. Well-understood milestones: The milestones or key goals of the project are clearly
defined, helping to measure progress.
7. Easy to arrange tasks: Since the model is sequential, tasks are organized in a simple
way.
8. Process and results are well documented: Everything is documented, so it's easier
to track progress and refer back to earlier stages if needed.
9. Simple and easy to understand and use: The model is straightforward, so it's easy
for teams to follow and understand.

Disadvantages:

1. No working software is produced until late during the life cycle: The software is
only ready towards the end of the project, which can be frustrating if early feedback is
needed.
2. High amounts of risk and uncertainty: Because you don’t know how well the
project will turn out until later, there’s a lot of uncertainty in this model.
3. Not a good model for complex and object-oriented projects: If the project is
complex or involves many moving parts, the rigid structure of Waterfall can be
limiting.
4. Poor model for long and ongoing projects: Waterfall is not ideal for projects that
evolve over time or that need constant updates.
5. It is difficult to measure progress within stages: Since each phase is only
completed after the previous one, tracking small progress throughout stages can be
challenging.
6. Cannot accommodate changing requirements: If the project needs changes midway
through, it's hard to adapt because the model is very rigid.
 7. Adjusting scope during the life cycle can end a project: If the project's scope
changes, it may cause the whole project to fail or be delayed significantly.

Explanation of the Incremental Model

The Incremental Model is a software development approach that builds a system step by
step by delivering small, usable parts of the system in increments. Each increment adds
functionality to the previous ones, eventually leading to a complete system.

Key Aspects of the Incremental Model:

1. Breaking the System into Small Parts:

o The entire system is divided into smaller, manageable sections.
o Each section (or increment) is developed separately and then integrated.
o This allows developers to focus on delivering high-priority features first.
2. Prioritizing the Most Important Features:
o The first increment includes the most critical features of the system.
o Subsequent increments expand and improve upon previous increments.
o This ensures that the essential parts of the software are available early.
3. Continuous Improvement through Feedback:
o After each increment is delivered, users provide feedback.
o This feedback helps refine the system and address any issues.
o The next increment incorporates this feedback, improving the system step by
step.
4. Phases in Each Increment:
Each iteration of development goes through the same software development stages:
o Requirements gathering (Understanding what needs to be developed)
o Design (Planning the structure of the new increment)
o Coding (Writing the code for the new functionality)
o Testing (Checking if the new feature works correctly)
5. Early Results and Quick Feedback:
o Stakeholders can see a working version of the system early.
o If something is wrong, changes can be made immediately rather than waiting
for the entire system to be built.
o This reduces risk and ensures that the final product meets user needs.
6. Efficiency in Development:
o Developers focus on what is important rather than trying to build the entire
system at once.
o Bugs are detected and fixed as they arise, making the system more stable over
time.
o However, before starting, a clear and complete definition of the whole
system is required to avoid confusion later.
7. Best Use Cases for the Incremental Model:
o Projects with well-defined and complete requirements
o Projects where different parts of the system are loosely connected (i.e.,
they do not depend too much on each other)
o When early feedback from users is important
Iterative Model and Version Control

The Iterative Development Model is a step-by-step approach to building software by

continuously improving and refining it in multiple cycles (iterations). Instead of developing a
complete system in one go, developers start with a basic version and keep enhancing it until
the final product is complete.

Key Aspects of the Iterative Model

1. Developing in Small Portions:

o Instead of completing one feature at a time (like in the Incremental Model),
the Iterative Model builds a small version of all features first.
o This early version may have limited functionality, but it covers all major areas
of the software.
o Each iteration adds improvements, making the software more complete over
time.
2. Quick Release and Early Feedback:
o A working version of the software is released as early as possible to users.
o This allows them to test the system, give feedback, and request changes.
o Based on this feedback, developers modify and enhance the software in the
next iteration.
3. Continuous Improvement through Iterations:
o The development starts with a basic version (which may not have all the
features).
o With each iteration, new functionalities and improvements are added.
o This continues until the system is fully developed and meets user needs.
4. Easy to Manage Risks and Changes:
o Since feedback is received after every iteration, it is easier to fix functional
or design flaws early.
o If user requirements change, developers can adjust the plan without affecting
the entire system.
o This makes it ideal for large projects where requirements are not fully clear
from the beginning.
5. Challenges of the Iterative Model:
o The deadline and budget may change throughout development, especially
for large and complex projects.
o The final system is not defined upfront, which can make it hard to estimate
the total cost and time required.
o Requires good version control to track changes across multiple iterations.
6. Best Use Cases for the Iterative Model:
o Large software projects that can be broken down into modules.
o When requirements are expected to change over time.
o When quick feedback is needed to improve software continuously.

• Incremental Model: Imagine building a house one room at a time. First, you build
the living room, then the kitchen, then the bedrooms, etc. Each room is fully finished
before moving to the next one.
 • Iterative Model: Imagine building the entire house first, but with only basic walls
and a roof. Then, in each iteration, you improve the walls, add windows, install
flooring, etc., until the house is complete.

Difference Between Incremental and Iterative Models

Feature Incremental Model Iterative Model
Development Builds one complete feature at Builds all features at once but in a
Approach a time basic form
Focus of First Fully develops a few key Creates a simple version of the entire
Version features first system
Each new increment adds new Each iteration improves and
Enhancements
functionality enhances existing functionalities
Stakeholders see partial Stakeholders see a full but basic
Feedback Handling
functionality early version early
Reduces risk by developing Manages risk by continuously refining
Risk Management
priority features first and improving the system
Requires a clear plan from the More flexible; can adjust based on
Flexibility
start feedback
Budget and Time
More predictable May change frequently
Estimates

Various phases of incremental model are as follows:

The incremental model of software development breaks down the project into smaller,
manageable phases, with each phase delivering a portion of the product. Here’s a simplified
breakdown of its phases:

1. Requirement Analysis:
o In this phase, the product's requirements are gathered. A team of experts
identifies the system's needs, and these functional requirements are clearly
understood by the team. The main goal is to know exactly what the system
must do.
2. Design & Development:
o During this phase, the system's design and functionality are planned out. The
development team works on creating the system's architecture and core
functions. This is where the first part of the software is designed and built,
with a focus on meeting the requirements identified earlier.
3. Testing:
o After each part of the system is developed, it undergoes testing. The testing
phase checks whether the existing features are working properly, and also
ensures that any new functionality is correctly integrated. Different testing
methods are used to ensure the system behaves as expected and any issues are
fixed.
o
 4. Implementation:
o This is where the actual coding is completed based on the design from the
earlier phase. After coding, the system is tested again to make sure it works as
intended. With each new increment, the software's functionality improves and
new features are added, gradually building up to the final product.

When to Use the Incremental Model:

1. When the requirements are superior:

This means that you have a clear understanding of what the customer needs and
expect from the system. The incremental model is a good choice when the
requirements are well-defined and can be broken down into smaller parts that can be
developed step-by-step.
2. A project has a lengthy development schedule:
If the development of the software is expected to take a long time, the incremental
model allows you to release working parts of the product early. This way, the client
can see progress and get something useful before the entire system is complete.
3. When software teams are not very skilled or trained:
If your team doesn't have a lot of experience, incremental development helps. The
smaller pieces or modules allow them to focus on one part at a time, making it easier
to manage and learn from each iteration.
4. When the customer demands a quick release of the product:
If there’s pressure to release the product quickly, the incremental model helps deliver
working software early. You can develop and release the most important features first,
while continuing to work on other parts in the background.
5. You can develop prioritized requirements first:
You can start with the most critical features or requirements that the client needs first.
Once those are developed, you can move on to the less important ones. This approach
makes sure that essential functionality is ready sooner.

Advantages of the Incremental Model:

1. Errors are easy to be recognized:

Since the software is developed in smaller chunks, it’s easier to spot and fix errors.
Each increment is tested thoroughly, so problems can be caught early in the process,
before they affect the whole system.
2. Easier to test and debug:
Testing is more manageable because you are only working with a smaller part of the
system at a time. It’s simpler to identify issues in smaller, isolated components and fix
them without affecting other parts of the system.
3. More flexible:
The incremental model is flexible because you can adjust the development process as
you go. If something needs to change (such as a new requirement from the client), it’s
easier to make adjustments in smaller increments without disrupting the whole
project.
4. Simple to manage risk:
Risk is more manageable in the incremental model because you address it during each
iteration. By breaking down the project, you can identify potential problems earlier
and fix them before they become bigger issues. This helps avoid significant setbacks.
 5. The client gets important functionality early:
Since you can release parts of the product early, the client can start using and
benefiting from the most important features while the rest of the product is still being
developed. This keeps them engaged and satisfied, even before the final product is
complete.

Disadvantages of the Incremental Model:

1. Need for good planning:

While the incremental model is flexible, it still requires careful planning. You need to
decide which features to work on first, determine how each increment will fit
together, and ensure that the system as a whole works well in the end.
2. Total cost is high:
The incremental model may result in a higher overall cost because you have to go
through the development, testing, and release process multiple times. Each iteration
requires time and resources, which adds up over the course of the project.
3. Well-defined module interfaces are needed:
In simple terms, when developing the system in parts, each part (or module) needs to
be clearly separated from the others. The way these parts communicate with each
other (called the "interface") must be carefully designed. If the interfaces aren't clear,
the different parts might not work together properly when they are combined, leading
to issues or errors.

What is RAD (Rapid Application Development)?

RAD is a software development model that focuses on speeding up the development process
while maintaining high-quality results. It emphasizes creating systems quickly using a
construction approach based on existing elements or components, instead of starting from
scratch every time. It’s essentially about developing software faster by using tools and
techniques that allow for quick creation and iteration.

Key Features of RAD:

1. Linear Sequential Process:

o RAD follows a linear or step-by-step process where each phase happens one
after another, but with an emphasis on doing things faster. Unlike traditional
models that might take a long time in each phase, RAD condenses the cycle
and focuses on rapid development.
2. Concise Development Cycle:
o The RAD approach shortens the development cycle by using predefined tools,
templates, and software components that speed up development. Instead of
spending a lot of time designing everything from the ground up, teams can
quickly build and modify using available resources.
3. Well-Understood Requirements:
o For RAD to work best, the requirements of the project should be well
understood from the beginning. If the project scope (what the software needs
to do) is clearly defined, the development team can focus on delivering the
product quickly and efficiently.
 4. Time-Constrained Development:
o RAD works best when there’s pressure to deliver a functional system within a
short timeframe. The goal is to create a fully functional system quickly, even
if it means doing some iterations later to improve the system after it’s already
in use.

RAD (Rapid Application Development) is all about building software quickly and with high
quality by using a few key strategies:

1. Gathering Requirements Quickly: Instead of long meetings, RAD uses workshops

or focus groups to quickly understand what the users need.
2. Prototyping and User Testing: A basic version of the software is built early and
tested with users. Their feedback is used to make improvements right away.
3. Reusing Software Components: RAD takes advantage of pre-built software parts, so
developers don’t have to start from scratch every time.
4. Strict Timelines: The project works on a tight schedule, and if improvements are
needed, they are planned for the next version of the product.
5. Simplified Communication: RAD reduces formal meetings and documentation,
encouraging fast, direct communication among team members to keep things moving
quickly.

Various phases of RAD are as follows: (see figure)

• Business Modeling:
In this phase, you figure out how information flows in the business. You answer questions
like: What data drives the business process? Who generates this data? Where does the data
go? Who processes it?

• Data Modeling:
The data from business modeling is refined into a set of data objects needed for the business.
You identify the important attributes of these data objects and define how they relate to each
other.

• Process Modeling:
The data objects defined in the previous phase are used to create the flow of information
needed to perform business functions. You describe how data will be added, modified,
deleted, or retrieved as part of the process.

• Application Generation:
Automated tools are used to speed up the construction of the software. These tools help
generate code quickly, often using 4th generation programming languages (4GL), which are
easier and faster to work with.

• Testing & Turnover:

Since RAD emphasizes reusing existing code, many components have already been tested.
This reduces overall testing time. However, the new parts still need to be tested, and all the
connections (interfaces) between them must be thoroughly checked to ensure everything
works as expected.
When to Use the RAD Model:

1. When the system needs to be created in a short time (2-3 months):

RAD is best for projects that need to be developed quickly, typically in 2 to 3 months.
It allows the team to rapidly build a working system by breaking it into smaller,
manageable parts that can be developed and tested quickly.
2. When the requirements are well-known:
The RAD model works best when the requirements of the system are clearly
understood from the start. If you already know exactly what the system should do,
you can jump into development without needing to spend too much time on gathering
unclear requirements.
3. When the technical risk is limited:
If the project has minimal technical risk—meaning that there aren’t many
uncertainties or complex technologies involved—RAD can be a good fit. RAD
assumes the team has access to reliable tools and components, and there’s less chance
of unexpected issues arising during development.
4. When you need to create a modular system quickly:
When you need to create a system that is broken down into smaller, separate parts
(modules) and you want to finish it within 2-3 months, the RAD model is a good
choice. This approach helps you quickly develop each part of the system, allowing the
whole project to be completed in a short time frame.
5. If the budget allows the use of automatic code generation tools:
RAD often involves the use of tools that automatically generate code, speeding up the
development process. However, these tools can be costly, so the RAD model is most
suitable if your project’s budget allows for these kinds of tools.

Advantages of the RAD Model:

1. Flexible to Changes:
RAD is flexible and can quickly adapt to changes in requirements or features. Since
development is broken down into smaller parts, it’s easier to modify or adjust one
piece without disrupting the whole system.
2. Changes are easily adoptable:
As the product is built incrementally, it’s easier to incorporate changes based on
feedback or evolving requirements. The user can suggest improvements at each stage,
and the team can quickly implement them.
3. Brings highest priority functionality to the customer:
In RAD, the most important features are developed and delivered first. This ensures
that the customer receives the most valuable parts of the system early, even while
other parts are still being worked on.
4. Reduced development time:
RAD speeds up development by focusing on rapid prototyping and using reusable
components. This significantly reduces the time it takes to build the system compared
to traditional models.
5. Increases reusability of features:
By reusing existing software components and tools, RAD encourages the creation of
systems with more reusable parts. This makes future projects faster to develop, as
components can be reused in new systems.

Disadvantages of the RAD Model:

 1. Requires highly skilled designers:
Since RAD relies on rapid development and prototyping, it requires a team of skilled
designers who can work quickly and efficiently, using the tools and technologies
available. Without experienced designers, the speed of development could suffer.
2. Not all applications are compatible with RAD:
RAD is not suitable for all types of applications, especially those that are highly
complex or have complex dependencies. If the system involves intricate logic or
heavy integration, RAD may not be the best choice.
3. Not suitable for smaller projects:
RAD is often used for medium to large projects, and may not be ideal for very small
projects. The resources and tools required to implement RAD may not be justified for
smaller systems that can be developed using simpler methods.
4. Not suitable for projects with high technical risk:
If the project involves a lot of technical uncertainty or cutting-edge technologies,
RAD might not be suitable. It works best when the team is confident in the tools and
techniques being used, and when the risks are manageable.
5. Requires active user involvement:
RAD needs users to be actively involved throughout the development process. Users
need to give feedback and suggest changes as the system is being built to make sure it
meets their needs. Without their input, it’s hard to make the system work well for
them.

Classical Evolutionary Models (Prototype, Spiral)

In software development, the evolutionary process models are designed to handle projects
that change and develop over time. These models are particularly useful when the full scope
of the project isn’t clear at the start, or when requirements change as the project progresses.

Key Points:

1. Software Evolves Over Time:

Just like complex systems, software doesn't usually come out perfectly at the first try.
It evolves as the development progresses, with new features and improvements added
over time.
2. Changing Business and Product Requirements:
As the development of the software continues, business needs and product
requirements can change. This makes it unrealistic to follow a strict, step-by-step path
to the final product. Instead, the development process needs to be flexible enough to
adjust to these changes.
3. Tight Market Deadlines:
Sometimes, businesses face pressure to release software quickly to stay competitive,
even if the product isn’t fully complete. This often results in releasing a limited
version of the product first, which can then be improved over time.
4. Well-Understood Core Requirements:
In many cases, you may have a good understanding of the core features of the
software, but the details or extensions (additional features) may still be unclear.
Evolutionary models help by allowing for ongoing changes and additions during
development.
5. Need for a Process Model That Accommodates Change:
Because software often evolves, you need a flexible process that can handle changes
 as they come up. Evolutionary models are designed to do just that—they allow you to
adapt and update the software as development progresses.
6. Iterative Process:
Evolutionary models are iterative, meaning they involve repeating certain stages (like
design, development, and testing) multiple times. With each iteration, you develop a
more complete version of the software, adding new features or making improvements
based on feedback.

Classical Evolutionary Models (Prototype Model)

The Prototype Model is a way of developing software by quickly building a working version
(prototype) of the system. This model focuses on gathering feedback early and refining the
software in multiple iterations.

Key Phases of the Prototype Model:

1. Communication (Initial Meetings with Stakeholders):

The process starts with meeting key people involved in the project (stakeholders).
You discuss the overall goals of the software, what’s already known about the system,
and what still needs to be figured out.
2. Quick Design:
After gathering the basic information, a quick, rough design is created. This design
focuses mainly on the visible parts of the software—such as how the user interface
looks and how data is displayed. It doesn’t need to be perfect, just enough to give a
basic idea of how the system will work.
3. Build a Prototype:
Using the quick design, you build a working prototype. This prototype is a simple,
early version of the software that allows stakeholders to see and interact with a basic
working system.
4. Deploy and Evaluate the Prototype:
The prototype is presented to stakeholders for feedback. They use the prototype and
evaluate how well it meets their needs. This helps identify any problems, unclear
areas, or missing features in the software.
5. Refining the Prototype:
Based on the feedback, the prototype is refined. Changes and improvements are made
to better meet user requirements. This step is repeated until the software becomes
closer to the final version.
6. Iteration:
The process of building, testing, and refining the prototype is repeated multiple times.
Each iteration helps improve the system based on stakeholder feedback and a better
understanding of the software’s needs.

Why Prototyping is Useful:

• Helps Identify Requirements:

The prototype helps figure out the software’s requirements by giving users
something they can interact with early in the process.
 • Faster Development:
To build a working prototype quickly, you can use existing code or special tools (like
report generators or window managers) that make it faster to create a functioning
program. This saves time compared to building everything from scratch.

Steps for the Prototype Model:

1. Requirement Gathering and Analysis:

First, you gather the known requirements for the software and understand the main
goals of the project. At this stage, it’s okay if not all details are clear.
2. Quick Decision:
You quickly decide on the basic design, focusing mainly on the most important and
visible parts of the software that the users will interact with.
3. Build a Prototype:
Using the quick design, you build a working model of the software. It’s a basic,
simplified version of the final product, allowing users to see and interact with it.
4. Assessment or User Evaluation:
Stakeholders or users try out the prototype and provide feedback on what works well
and what needs to be improved. This is where you gather valuable input on how to
refine the system.
5. Prototype Refinement:
You take the feedback and make improvements to the prototype. This might involve
adding missing features or changing parts of the system that don’t meet the user’s
needs.
6. Engineer the Final Product:
After several iterations and refinements, you can now start developing the final
product based on the lessons learned from the prototype.

The Prototyping Model is used in the following situations:

1. Unclear or Incomplete Requirements

o When the customer or stakeholders are unsure about the final product's exact
requirements. Prototypes help clarify and refine these requirements.
2. Changing Requirements
o When requirements are expected to evolve over time or due to shifting
business needs, allowing for adjustments as feedback is gathered.
3. High User Interaction
o When the software involves complex user interfaces, and you need early user
feedback to ensure the system is user-friendly and meets their needs.
4. Complex or New Technologies
o When developing innovative or complex systems where it's difficult to predict
the exact outcome. Prototyping helps test feasibility and design concepts early
on.
5. Early Testing and Validation
o When developers need to test ideas, demonstrate concepts, or validate whether
a particular feature or design approach works before proceeding with full-scale
development.
6. To Gather User Feedback
o When it’s crucial to gather user opinions and feedback at different stages of
development to guide adjustments, especially in UI/UX-heavy applications.
Advantages of the Prototype Model:

1. Reduces the risk of incorrect user requirements:

Since users interact with the prototype early, it helps clarify what they really need,
reducing the chances of building something that doesn’t meet their expectations.
2. Good when requirements are changing or unclear:
The prototype model is ideal when the requirements aren’t fully defined or keep
changing. It lets developers adjust as they go based on user feedback.
3. Regular visible process aids management:
With the prototype, there’s something tangible to show stakeholders regularly,
making it easier to track progress and manage the project. It helps ensure everyone is
on the same page.
4. Supports early product marketing:
Since a prototype can be built quickly, businesses can use it to demonstrate the
product early, gather interest, and even begin marketing the product before it's fully
finished.
5. Reduces maintenance costs:
Means that by catching and fixing problems early in the development process
(through prototypes and user feedback), you avoid expensive repairs and changes later
when the software is fully built. This helps save money over time.
6. Errors can be detected earlier:
Since you’re continuously testing and refining the prototype, issues can be identified
and addressed much earlier in the development cycle, saving time and money in the
long run.

Disadvantages of the Prototype Model:

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

prototype isn’t built well or lacks stability, it may end up being used as the base for
the final product. This could lead to performance issues or poor quality in the final
system, as prototypes are typically rushed and not fully polished.
2. Requires extensive customer collaboration:
o Costs the customer money: The prototype model demands frequent input
from the customer, which can add to the project costs due to the time spent in
meetings, reviews, and feedback sessions.
o Needs a committed customer: For the process to succeed, the customer must
be highly involved and dedicated to providing continuous feedback, which can
be demanding.
o Difficult to finish if the customer withdraws: If the customer stops
participating or withdraws from the project, it can lead to delays or incomplete
requirements, making it harder to complete the project.
o May be too customer-specific, no broad market: If the prototype is tailored
too much to the specific needs of one customer, it may not work well for other
potential customers or a wider market.
3. Difficult to know how long the project will last: Because the prototype model is
iterative and involves frequent changes based on feedback, it can be challenging to
predict how long the entire development process will take. The timeline can stretch
out as new iterations are created.
4. Easy to fall back into the code and fix without proper requirement analysis,
design, customer evaluation, and feedback: Developers may become overly
 focused on fixing and adjusting the prototype, losing sight of the initial planning,
requirement analysis, and feedback process. This can lead to a lack of proper design
and direction for the final product.
5. Prototyping tools are expensive: The tools used to create prototypes, such as
specialized software or frameworks, can be expensive to purchase or maintain, adding
to the overall cost of the project.
6. Special tools and techniques are required:
Building a prototype usually requires specific tools and skills, which may not be
available to all development teams or might require additional training.
7. Time-consuming process:
Although prototypes help with early feedback, the process of building, testing, and
refining prototypes can be time-consuming. Each iteration takes time, which can
delay the overall project. Constant revisions and improvements can slow down the
project, making it a more time-consuming approach compared to other models.

Classical Evolutionary Models (Spiral Model)

The Spiral Model, proposed by Barry Boehm, is a software development approach that
combines the iterative nature of prototyping with the structured approach of the
waterfall model. This model focuses on risk assessment and helps in systematically refining
the software through repeated cycles. It allows for rapid development of increasingly
complete versions of the software.

Key Features of the Spiral Model:

1. Iterative Development with Risk Management:

o The development process follows a spiral path, where each cycle builds upon
the previous version.
o With each iteration, the software evolves into a more complete and refined
version while reducing risks.
2. Cyclic Approach for Progressive Growth:
o The model continuously enhances the system’s definition and implementation
while minimizing uncertainties and risks.
3. Anchor Point Milestones:
o These are checkpoints that ensure stakeholder approval and commitment
before moving forward.
o They help verify that the system is evolving in the right direction.

Working of the Spiral Model:

• The spiral path consists of multiple framework activities that the software team
performs in a clockwise direction, starting from the center.
• Each loop in the spiral represents a development phase, such as planning, design,
prototyping, testing, and implementation.
• Risk analysis is done at every phase to identify and address potential problems
before moving forward.

Process of the Spiral Model:

1. Initial Stage (First Spiral Circuit):

 oThe first cycle typically results in a product specification or requirement
gathering.
o Risk assessment is conducted before moving ahead.
2. Subsequent Cycles:
o Later cycles focus on building prototypes and refining the system through
feedback.
o With each iteration, more advanced versions of the software are created.
3. Adjustment of Cost & Schedule:
o After each phase, customer feedback is considered to modify the cost and
timeline of the project.
o The number of iterations required for completion is also adjusted based on
project needs.

The Spiral Model is a software development process that combines prototyping (building a
model of the software) with the structured approach of the waterfall model.

Key Features:

• Quick Development: It helps create new versions of the software quickly, allowing
for regular updates.
• Incremental Releases: The software is developed in parts. Each new version builds
on the previous one.
• Early Stages: Early versions might just be basic models or prototypes to test ideas.
• Later Stages: As development continues, the software becomes more complete and
fully functional.
• "It allows for rapid development of increasingly complete versions of the software"
means that the software is built quickly, and with each new version, it becomes more
complete and refined. At the beginning, the software might only have basic features
or functions, but with each iteration (or cycle), new features are added, existing ones
are improved, and the overall software gets closer to the final version. This process
continues until the software is fully developed, with each version being better than the
last one.

Each cycle in the Spiral Model is divided into four main parts:

1. Objective Setting:
o Define the goal for the current cycle.
o Identify different ways to achieve the goal.
o Consider any limitations or constraints.
2. Risk Assessment and Reduction:
o Evaluate different options based on risks and constraints.
o Identify potential risks that could affect the project.
3. Development and Validation:
o Develop solutions to reduce risks and uncertainties.
o Activities like testing, prototyping, and simulations may be used.
4. Planning:
o Review the progress of the current cycle.
o Decide whether to continue with the next cycle.
o If continuing, create a plan for the next phase.
When to use Spiral Model:

• When deliverance is required to be frequent: The Spiral Model involves iterative

development, allowing for frequent releases of the product or software. This is ideal
when you need to deliver updates or new features regularly.
• When the project is large: For large projects, the Spiral Model works well because it
breaks the project into smaller, manageable segments. Each segment is developed in
iterations, making it easier to handle complex tasks.
• When requirements are unclear and complex: If the project’s requirements are not
fully understood at the start or are likely to change as the project progresses, the Spiral
Model allows flexibility. It helps in gathering feedback and adjusting the project
scope as new information becomes available.
• When changes may require at any time: Since the model is iterative, it
accommodates changes throughout the development process. This makes it suitable
for projects where the requirements or market needs can change unexpectedly.
• Large and high-budget projects: Due to its focus on managing risk and its
structured, flexible approach, the Spiral Model is ideal for large, high-budget projects.
It helps in managing potential issues early on while keeping the project within budget
and scope.

Advantages:

• High amount of risk analysis: The Spiral Model focuses heavily on identifying and
managing risks early in the project. This helps in addressing potential issues before
they become bigger problems, ensuring a smoother development process.
• Useful for large and mission-critical projects: It’s ideal for projects that are large,
complex, or have high stakes (e.g., systems with safety concerns). The model's focus
on iterative development and risk management makes it perfect for ensuring that these
projects succeed.

Disadvantages:

• Can be a costly model to use: The Spiral Model involves multiple phases of
planning, development, and risk analysis, which can make it more expensive
compared to other models. The repeated iterations add up in terms of resources and
time.
• Risk analysis needs highly particular expertise: Performing risk analysis
effectively requires specialized knowledge. Teams need to have experts who can
accurately identify and assess risks, which can be a challenge if such expertise is
lacking.
• Doesn't work well for smaller projects: Due to its complex nature and the focus on
risk management, the Spiral Model is not well-suited for smaller projects. Smaller
projects may not justify the resources needed for detailed planning and iterations.

Concurrent Model

The Concurrent Model (or Concurrent Engineering) is a software development approach

that allows multiple activities to happen at the same time, instead of following a strict
sequence. This means that various tasks such as design, prototyping, analysis, and
construction can overlap and occur in parallel, making the process more flexible and
adaptive.

States in Software Engineering Activities:

Each software engineering activity, like modeling, design, or prototyping, can exist in one of
several possible states at any given time. Some common states include:

1. Inactive: The activity hasn’t started yet.

2. Under Development: Work on the activity is actively taking place.
3. Completed: The activity has been finished.
4. Awaiting Changes: The activity is awaiting input, feedback, or changes (often
triggered by new requirements or issues).
5. Pending Review: The activity is completed, but it needs to be reviewed for validation
or correctness.

Explanation of the Concurrent Model Process:

• Iterative and Concurrent: In this model, software engineering activities are done
simultaneously, but they are also iterative. For instance, activities like modeling,
design, and prototyping can be carried out at the same time.
• Example of How It Works: In a project, the "modeling activity" might involve
analysis and design tasks. These tasks can happen concurrently, so while one part of
the project is being designed, another part might be analyzed or prototyped.
• State Transitions: The software engineering activities are considered to be in
different states. For example:
o Modeling Activity: In the early stages, modeling may be in an "inactive" state
until the communication phase is done. Later, it may move into an "under
development" state when the team starts working on it.
o If there are changes in requirements, the modeling activity may shift back into
the "awaiting changes" state.
• Events Triggering State Changes: Specific events trigger transitions between states.
For example:
o If a design phase reveals a problem, it might trigger a change in the
requirements, which could move the requirements analysis task from the
"done" state to "awaiting changes."

When to Use the Concurrent Model:

• Large Projects with Complex Tasks: If your project involves many tasks that can be
worked on in parallel, the Concurrent Model is ideal. It’s great for projects where
different aspects of development are interconnected and can be progressed
simultaneously.
• Projects Needing Flexibility and Fast Adaptation: This model is useful if you
expect frequent changes during development or if the project requires quick response
to customer feedback, as tasks can easily shift between states.
• Collaborative Teams: It works well when you have a large team that can handle
various tasks in parallel, enabling different groups to handle different components
simultaneously.
Advantages of the Concurrent Model:

1. Faster Delivery: Since multiple tasks are carried out in parallel, the overall time to
complete the project is often reduced.
2. Flexible and Adaptable: The model’s structure allows for easy handling of changes,
especially when new requirements arise or issues are discovered during development.
Activities can quickly transition between different states.
3. Continuous Progress: Even if one task is delayed or requires revision, other tasks
can continue, preventing the whole project from getting stalled. The project moves
forward through parallel development.
4. Early Detection of Issues: Since tasks happen in parallel, problems can be
discovered early when different tasks or models are compared and analyzed against
each other.
5. Better Coordination: Encourages better communication between teams because
everyone is working together in parallel, leading to smoother integration of different
components.

Disadvantages of the Concurrent Model:

1. Complexity in Coordination: Managing multiple tasks in parallel can be complex,

requiring careful synchronization and constant monitoring to ensure that dependencies
between tasks are properly handled.
2. Requires More Resources: Running multiple activities at the same time typically
requires more resources, including more personnel, tools, and infrastructure, which
can increase costs.
3. Risk of Overlap and Confusion: Because activities are done concurrently, there’s a
chance that tasks may overlap or lead to confusion if the dependencies and state
transitions aren’t clearly defined.
4. Difficulty in Managing Changes: While the model allows for flexibility, the
constant change in requirements or scope can disrupt the workflow, especially if the
different tasks are not synchronized properly.
5. Requires Skilled Team Members: Since many activities are happening
simultaneously, the team members must be skilled at handling complex, parallel
processes. Lack of expertise or coordination may lead to inefficiencies or mistakes.

Introduction to Agility and Agile Process

Agile is a method used in software development that emphasizes flexibility and speed. The
term "Agile" means being quick and adaptable.

In an Agile process, the development is divided into smaller chunks called iterations, which
are short development cycles, usually lasting one to four weeks. Unlike traditional methods,
Agile does not involve extensive long-term planning.

At the start of the project, the overall goals and requirements are defined. However, instead of
planning every detail in advance, the number of iterations, their duration, and the scope of
each are decided early on.
Each iteration follows a full development cycle, including planning, requirement analysis,
design, coding, and testing. By the end of each iteration, a working version of the product is
shown to the client.

Dividing the project into smaller parts helps reduce risks and ensures quicker delivery,
making it easier to adapt to changes during development.

Phases in the Agile model

• Requirements Gathering: In this phase, you identify and define what the project needs to
achieve. You discuss the business goals and estimate the time and effort needed to complete
the project. You also check if the project is technically and economically feasible. In this
phase, you must define the requirements.

• Design the Requirements: Once you understand the project, you work with stakeholders
(like clients or team members) to define what the project will include. You can use tools like
user flow diagrams or high-level diagrams (UML) to plan how new features will work and fit
into the existing system.

• Construction/Iteration: The actual work begins here. Designers and developers start
creating the product. The focus is on creating a working version of the product with basic
features that can be improved over time through iterations.

• Testing: In this phase, the Quality Assurance (QA) team tests the product to make sure it
works as expected and to find any bugs that need fixing.

• Deployment: Once the product is tested and ready, it’s deployed (released) to the user’s
environment, meaning it becomes available for use.

• Feedback: After the product is released, the team gathers feedback from users. This
feedback helps the team make improvements and address any issues that users experience.
The process of getting feedback and making improvements continues throughout the project.

Till page 73

Down below module 3 ( till page 16)

What Are Software Requirements?

Software requirements define what a software system must do. They can be broad and
abstract or very detailed and mathematical. These requirements describe what users expect
from the software and help developers create a functional and efficient system.

• They outline the characteristics and functionalities of the software.

• They represent what users expect from the software.
• Requirements should be clear enough to understand but also flexible for interpretation.
• Understanding software requirements helps save time, effort, and costs during
development.
• Requirement engineering and its process play a key role in defining and managing these
requirements.

Software Requirements & Types

1. Business Requirements

Definition: Business requirements define the overall goals of a project from a business
perspective. These requirements ensure that the software aligns with the company's
objectives.

Business requirements are the goals of a business that the software must fulfill.

Key Points:

✅ Business requirements are created at the beginning of a project.

✅ They are written in a Business Requirements Document (BRD).
✅ Business analysts and project leaders prepare the BRD.
✅ The BRD explains why the software is being made.
✅ For software development companies, the BRD helps in preparing more detailed
documents for clients.

How Business Requirements Are Written:

There is no fixed format, but a common way to write them is:

"The [project name] software will [meet a business goal] to [achieve a business
benefit]."

Example:
"The Online Shopping App software will allow customers to order products
online to increase sales."
2. User Requirements

Definition: User requirements focus on how customers will interact with the software. They
are typically detailed in a separate document when software has complex UI features.

User requirements describe what the users (customers) need from the software.

Key Points:

✅ User requirements focus on how people interact with the software.

✅ Some companies include them in the BRD, but if the software is complex (e.g., lots of UI
features), they are kept in a separate document.
✅ They are similar to user stories in software development.

How User Requirements Are Written:

There is no universal format, but a common way is:

"The [user type] shall [interact with the software] to [meet a goal or achieve a
result]."

Example:
"The customer shall log in and place an order to buy a product online."

3. Software Requirements

Software requirements are the key instructions that define what a software system should
do. There are three main types of software requirements:

1. Functional Requirements
2. Non-Functional Requirements
3. Domain Requirements

1. Functional Requirements
Functional requirements describe the specific features and functions that a software system
must provide.

Key Points:

✅ These are the core functionalities expected by the users.

✅ They must be included in the system as part of the contract.
✅ They describe how the system behaves under different conditions.
✅ Users can directly see these functions in the final product.
✅ They define how the system processes inputs, behaves, and produces outputs.
✅ Functional requirements include:

• Calculations
• Data processing
 • User interactions
• Business processes

How Functional Requirements Are Written:

• They can be written in natural language.

• They can also be written using structured formats or formal specification
languages (which follow strict syntax rules).

2. Non-Functional Requirements (NFRs)

Non-functional requirements define the quality standards and performance
constraints that the software must meet.

Key Points:

✅ These requirements focus on how well the system should perform, rather than what it
does.
✅ The level of importance of NFRs may vary between projects.
✅ They are also called non-behavioral or quality attributes.

Types of Non-Functional Requirements:

• Performance Constraints: Storage space, response time, security, etc.

• Interface Constraints: Requirements related to user interfaces.
• Economic Constraints: Budget limitations and cost considerations.
• Operating Constraints: Conditions under which the system must work.
• Life Cycle Constraints: Portability, maintainability, and long-term usability.

Examples of Non-Functional Requirements:

• Performance: The system should respond within 2 seconds.

• Security: Only authorized users should access confidential data.
• Reliability: The system should work 24/7 without failure.

3. Domain Requirements
Domain requirements are specific to an industry or field. They ensure that the software
meets the standards and expectations of that domain.

Key Points:

✅ They can be functional or non-functional.

✅ They define essential functions that a system in a particular field must have.
✅ These requirements follow industry standards and regulations.
✅ They are not user-specific but industry-specific.
Examples of Domain Requirements:

1. Medical Software
o Medical equipment software must follow the IEC 60601 standard for safety
and performance.
o Even if the software works well, it cannot be used if it does not meet this
standard.
2. Academic Software
o A school management system must have features to track students and
teachers.
o The ability to access faculty and student lists is a domain-
specific requirement.

• Functional requirements define what the software should do (features and

functions).
• Non-functional requirements define how well the software should
perform (quality and constraints).
• Domain requirements are specific to an industry and must follow certain standards.

Requirements Engineering Process (RE)

Requirements Engineering (RE) is the process of defining, documenting, and managing

what a software system needs to do. It helps ensure that the software meets the customer’s
needs and works as expected. It involves understanding what the customer wants, analyzing
those needs, and ensuring the solution fits the project’s goals.

The RE process includes four main steps:

1. Feasibility Study: This step checks whether it’s possible to develop the software
based on factors like technology, business needs, and costs.
o Technical Feasibility: Looks at the current technology to see if it can meet
the customer’s requirements within the project’s budget and timeline.
o Operational Feasibility: Examines whether the software can solve the
business problems and meet customer needs at various levels.
o Economic Feasibility: Evaluates if the software can provide financial benefits
to the organization, justifying the investment.
2. Requirement Elicitation and Analysis: This is the process of gathering and
analyzing the requirements from customers and existing systems.
o Requirement Elicitation: This involves collecting all the needs and
expectations from stakeholders (the people involved in the project, like clients,
users, and developers).
o Requirement Analysis: After gathering the requirements, they are analyzed to
check for any issues, like missing details or inconsistencies.
o The goal is to clearly define what the software must do and resolve any
conflicts or unclear points.

Problems during Elicitation and Analysis:

 o Getting the right people involved: It’s important to involve all the necessary
stakeholders, but sometimes the right people aren’t included.
o Unclear requirements: Stakeholders might not fully understand what they
want or express their needs in unclear terms.
o Conflicting requirements: Different stakeholders may have different or
opposing needs.
o Changing requirements: During the analysis phase, the requirements might
change as new information comes up.
o Political and organizational influences: Company politics or other external
factors may affect the requirements.
3. Software Requirement Specification (SRS)

The Software Requirement Specification (SRS) is a document created by a software

analyst after collecting requirements from different sources, including the customer.

• Customers usually describe their needs in simple language, while the analyst
translates them into technical terms that the development team can understand.
• This document helps ensure that everyone involved in the project has a clear
understanding of what the software should do.
• Several models are used to represent these requirements visually, such as:
o Data Flow Diagrams (DFDs)
o Entity-Relationship (E-R) Diagrams
o Function Decomposition Diagrams (FDDs)
o Data Dictionaries

Key Models Used in SRS

1. Data Flow Diagrams (DFDs)

o DFDs are used to visually represent how data moves through a system.
o They help understand the flow of information in a company, software, or
any other system.
o Sometimes called data flow graphs or bubble charts.
2. Data Dictionaries
o A data dictionary stores details about all data elements used in the
system.
o It ensures that both customers and developers use the same definitions and
terminology.
o It is essential for maintaining consistency in how data is handled.
3. Entity-Relationship (E-R) Diagrams
o E-R diagrams visually describe how different entities (objects) in a system
relate to each other.
o They include three main components:
§ Entities (e.g., customers, products)
§ Relationships (e.g., a customer buys a product)
§ Attributes (e.g., product name, customer ID)

4. Software Requirement Validation

Once the SRS document is prepared, it must be reviewed to ensure that all requirements are
clear, correct, and feasible.

• Sometimes, users may ask for features that are unrealistic or too complex to
implement.
• Validation ensures that all requirements:
o Can be practically implemented
o Are correct and match the expected software functionality
o Are clear and free of ambiguities
o Are complete and cover all necessary aspects
o Are properly described for developers to follow

Requirement Validation Techniques

1. Requirement Reviews/Inspections
o A manual process where experts carefully analyze requirements to check for
errors or missing details.
2. Prototyping
o A small working model of the system is created to demonstrate and verify
requirements.
o Helps users visualize how the final product will function.
3. Test-Case Generation
o Test cases are created to check whether the requirements are testable.
o Ensures that each requirement can be verified through testing.
4. Automated Consistency Analysis
o Software tools are used to check whether the requirements are consistent and
free of contradictions.

What is Requirement Elicitation?

Requirement elicitation is the process of gathering and defining what a software system
should do. The goal is to ensure a clear understanding of the customer's needs before
development starts.

Why is Requirement Elicitation Important?

1. Aligns with Business Goals: Ensures the software meets the company's objectives.
2. Improves User Satisfaction: Engaging users in the process helps create software that
meets their expectations.
3. Saves Time and Cost: Clear requirements reduce misunderstandings, preventing
costly rework.
4. Ensures Compliance: Essential for industries like healthcare, finance, and aerospace
to meet legal requirements.
5. Provides Traceability: Links each requirement to specific parts of the software for
testing, validation, and maintenance.
Key Activities in Requirement Elicitation

1. Understanding the general area where the system will be used.

2. Identifying the specific customer problem the system will solve.
3. Analyzing how the system interacts with external requirements.
4. Investigating user needs in detail.
5. Defining system constraints, such as performance limits or security needs.

Methods of Requirement Elicitation

1. Interviews

• Used to understand what the customer expects from the software.

• Representatives from different user groups are selected based on expertise.
• Types of interviews:
o Open-ended interviews: No fixed questions; used to explore issues freely.
o Structured interviews: Predefined questions; sometimes a questionnaire is
used.

2. Brainstorming Sessions

• A group technique to generate many ideas.

• A trained facilitator helps manage discussions and conflicts.
• All ideas are recorded, and a final document lists requirements with priorities.

3. Facilitated Application Specification Technique (FAST)

• Bridges the gap between what developers think they need to build and what customers
expect.
• Participants list system-related objects:
o Objects in the system’s environment
o Objects produced by the system
o Objects used by the system
• Lists are combined, redundancies removed, and small teams develop detailed
specifications.

4. Quality Function Deployment (QFD)

• Focuses on customer satisfaction by identifying three types of requirements:

1. Normal requirements: Basic system functions (e.g., data entry, report
generation).
2. Expected requirements: Obvious but unstated needs (e.g., security,
reliability).
3. Exciting requirements: Unexpected features that impress users (e.g.,
automatic backups when security is breached).

5. Use Case Approach

• Uses diagrams and text to explain system functionality.

• Focuses on what the system should do, not how it should work.
 • Components:
1. Actors: External agents (users, machines) interacting with the system.
§ Primary actors: Need system assistance to complete tasks.
§ Secondary actors: Assist the system in completing tasks.
2. Use Cases: Describe interactions between actors and the system.
3. Use Case Diagram: A visual representation of actor-system interactions.

Steps in Requirement Elicitation

1. Identify all stakeholders (users, developers, customers, etc.).

2. Collect and list all requirements.
3. Assign importance to each requirement.
4. Categorize requirements into:
o Achievable (can be implemented).
o Deferred (postponed with a reason).
o Not feasible (should be dropped).

❑Advantages of Requirements Elicitation:

1. Clear requirements: Helps to clarify and refine customer requirements.

2. Improves communication: Improves communication and collaboration between
stakeholders.
3. Results in good quality software: Increases the chances of developing a software system
that meets customer needs.
4. Avoids misunderstandings: Avoids misunderstandings and helps to manage expectations.
5. Supports the identification of potential risks: Supports the identification of potential
risks and problems early in the development cycle.
6. Facilitates development of accurate plan: Facilitates the development of a
comprehensive and accurate project plan.
7. Increases user confidence: Increases user and stakeholder confidence in the software
development process.

❑Disadvantages of Requirements Elicitation:

1. Time consuming: Can be time-consuming and expensive.

2. Skills required: Requires specialized skills and expertise.
3. Impacted by changing requirements: May be impacted by changing business needs and
requirements.
4. Impacted by other factors: Can be impacted by political and organizational factors.
5. Lack of commitment from stakeholders: Can result in a lack of buy-in and commitment
from stakeholders.
6. Impacted by conflicting priorities: Can be impacted by conflicting priorities and
competing interests.
7. Sometimes inaccurate requirements: May result in incomplete or inaccurate
requirements if not properly managed.