Waterfall Process Model

Advantages of the SDLC Waterfall Model

The classical waterfall model is an idealistic model for software development. It is very
simple, so it can be considered the basis for other software development life cycle
models. Below are some of the major advantages of this SDLC model.
 Easy to Understand: The Classical Waterfall Model is very simple and easy to
understand.
 Individual Processing: Phases in the Classical Waterfall model are processed
one at a time.
 Properly Defined: In the classical waterfall model, each stage in the model is
clearly defined.
 Clear Milestones: The classical Waterfall model has very clear and well-
understood milestones.
 Properly Documented: Processes, actions, and results are very well documented.
 Reinforces Good Habits: The Classical Waterfall Model reinforces good habits
like define-before-design and design-before-code.
 Working: Classical Waterfall Model works well for smaller projects and projects
where requirements are well understood.

Disadvantages of the SDLC Waterfall Model

The Classical Waterfall Model suffers from various shortcomings we can’t use it in real
projects, but we use other software development lifecycle models which are based on
the classical waterfall model. Below are some major drawbacks of this model.
 No Feedback Path: In the classical waterfall model evolution of software from one
phase to another phase is like a waterfall. It assumes that no error is ever
committed by developers during any phase. Therefore, it does not incorporate any
mechanism for error correction.
 Difficult to accommodate Change Requests: This model assumes that all the
customer requirements can be completely and correctly defined at the beginning of
the project, but the customer’s requirements keep on changing with time. It is
difficult to accommodate any change requests after the requirements specification
phase is complete.
 No Overlapping of Phases: This model recommends that a new phase can start
only after the completion of the previous phase. But in real projects, this can’t be
maintained. To increase efficiency and reduce cost, phases may overlap.
 Limited Flexibility: The Waterfall Model is a rigid and linear approach to software
development, which means that it is not well-suited for projects with changing or
uncertain requirements. Once a phase has been completed, it is difficult to make
changes or go back to a previous phase.
 Limited Stakeholder Involvement: The Waterfall Model is a structured and
sequential approach, which means that stakeholders are typically involved in the
early phases of the project (requirements gathering and analysis) but may not be
involved in the later phases (implementation, testing, and deployment).
 Late Defect Detection: In the Waterfall Model, testing is typically done toward the
end of the development process. This means that defects may not be discovered
 until late in the development process, which can be expensive and time-consuming
to fix.
 Lengthy Development Cycle: The Waterfall Model can result in a lengthy
development cycle, as each phase must be completed before moving on to the
next. This can result in delays and increased costs if requirements change or new
issues arise.

What is Unified Process (UP)

Unified Process (UP) 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 the 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 UP include being use-case driven, Iterative (repetition of the process),
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 the wastage of resources.
Phases of RUP
There is a total of five phases of the life cycle of RUP:
1. Inception
2. Elaboration
3. Construction
4. Transition
5. Production
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 of Unified Process (UP)
1. UP provides good documentation, it completes the process in itself.
2. UP provides risk-management support.
3. UP reuses the components, and hence total time duration is less.
 4. Good online support is available in the form of tutorials and training.
Disadvantages of Unified Process (UP)
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.

Requirements Elicitation – Software Engineering

Requirements elicitation is the process of gathering and defining the requirements
for a software system. The goal of requirements elicitation is to ensure that the
software development process is based on a clear and comprehensive understanding
of the customer’s needs and requirements.
What is Requirement Elicitation?
The process of investigating and learning about a system’s requirements from users,
clients, and other stakeholders is known as requirements elicitation. Requirements
elicitation in software engineering is perhaps the most difficult, most error-prone, and
most communication-intensive software development.
1. Requirement Elicitation can be successful only through an effective customer-
developer partnership. It is needed to know what the users require.
2. Requirements elicitation involves the identification, collection, analysis, and
refinement of the requirements for a software system.
3. Requirement Elicitation is a critical part of the software development life cycle and
is typically performed at the beginning of the project.
4. Requirements elicitation involves stakeholders from different areas of the
organization, including business owners, end-users, and technical experts.
5. The output of the requirements elicitation process is a set of clear, concise, and
well-defined requirements that serve as the basis for the design and development
of the software system.
6. Requirements elicitation is difficult because just questioning users and customers
about system needs may not collect all relevant requirements, particularly for
safety and dependability.
7. Interviews, surveys, user observation, workshops, brainstorming, use cases, role-
playing, and prototyping are all methods for eliciting requirements.

Importance of Requirements Elicitation

1. Compliance with Business Objectives: The process of elicitation guarantees
that the software development endeavors are in harmony with the wider company
aims and objectives. Comprehending the business context facilitates the
development of a solution that adds value for the company.
2. User Satisfaction: It is easier to create software that fulfills end users’ needs and
expectations when they are involved in the requirements elicitation process. Higher
user pleasure and acceptance of the finished product are the results of this.
3. Time and Money Savings: Having precise and well-defined specifications aids in
preventing miscommunication and rework during the development phase. As a
result, there will be cost savings and the project will be completed on time.
4. Compliance and Regulation Requirements: Requirements elicitation is crucial
for projects in regulated industries to guarantee that the software conforms with
applicable laws and norms. In industries like healthcare, finance, and aerospace,
this is crucial.
5. Traceability and Documentation: Throughout the software development process ,
traceability is based on well-documented requirements. Traceability helps with
testing, validation, and maintenance by ensuring that every part of the software can
be linked to a particular requirement.

Requirements Elicitation Activities

Requirements elicitation includes the subsequent activities. A few of them are listed
below:
1. Knowledge of the overall area where the systems are applied.
2. The details of the precise customer problem where the system is going to be
applied must be understood.
3. Interaction of system with external requirements.
4. Detailed investigation of user needs.
5. Define the constraints for system development.

Requirements Elicitation Methods

There are several requirements elicitation methods. A few of them are listed below:
Requirement Elicitation Techniques

1. Interviews
The objective of conducting an interview is to understand the customer’s expectations
of the software.

It is impossible to interview every stakeholder hence representatives from groups are

selected based on their expertise and credibility. Interviews may be open-ended or
structured.
1. In open-ended interviews, there is no pre-set agenda. Context-free questions may
be asked to understand the problem.
2. In a structured interview, an agenda of fairly open questions is prepared.
Sometimes a proper questionnaire is designed for the interview.

2. Brainstorming Sessions
 Brainstorming Sessions is a group technique
 It is intended to generate lots of new ideas hence providing a platform to share
views
 A highly trained facilitator is required to handle group bias and conflicts.
 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the list of requirements and their
priority if possible.
3. Facilitated Application Specification Technique
Its objective is to bridge the expectation gap – the difference between what the
developers think they are supposed to build and what customers think they are going
to get. A team-oriented approach is developed for requirements gathering. Each
attendee is asked to make a list of objects that are:
1. Part of the environment that surrounds the system.
2. Produced by the system.
3. Used by the system.
Each participant prepares his/her list, different lists are then combined, redundant
entries are eliminated, the team is divided into smaller sub-teams to develop mini-
specifications and finally, a draft of specifications is written down using all the inputs
from the meeting.
4. Quality Function Deployment
In this technique customer satisfaction is of prime concern, hence it emphasizes the
requirements that are valuable to the customer.
3 types of requirements are identified:
 Normal requirements: In this the objective and goals of the proposed software
are discussed with the customer. For example – normal requirements for a result
management system may be entry of marks, calculation of results, etc.
 Expected requirements: These requirements are so obvious that the customer
need not explicitly state them. Example – protection from unauthorized access.
 Exciting requirements: It includes features that are beyond customer’s
expectations and prove to be very satisfying when present. For example – when
unauthorized access is detected, it should back up and shut down all processes.
5. Use Case Approach
Use Case technique combines text and pictures to provide a better understanding of
the requirements. The use cases describe the ‘what’, of a system and not ‘how’.
Hence, they only give a functional view of the system.

The components of the use case design include three major things – Actor, use cases,
and use case diagram.
1. Actor: It is the external agent that lies outside the system but interacts with it in
some way. An actor may be a person, machine, etc. It is represented as a stick
figure. Actors can be primary actors or secondary actors.
 Primary actors: It requires assistance from the system to achieve a goal.
 Secondary actor: It is an actor from which the system needs assistance.
2. Use cases: They describe the sequence of interactions between actors and the
system. They capture who(actors) do what(interaction) with the system. A
complete set of use cases specifies all possible ways to use the system.
3. Use case diagram: A use case diagram graphically represents what happens
when an actor interacts with a system. It captures the functional aspect of the
system.
 A stick figure is used to represent an actor.
 An oval is used to represent a use case.
A line is used to represent a relationship between an actor and a use case.
The success of an elicitation technique used depends on the maturity of the analyst,
developers, users, and the customer involved.
Steps of Requirements Elicitation
Following are the Steps of Requirement Elicitation

1. Identify all the stakeholders, e.g., Users, developers, customers, etc.

2. List out all requirements from the customer.
3. A value indicating the degree of importance is assigned to each requirement.
4. In the end, the final list of requirements is categorized as:
 It is possible to achieve.
 It should be deferred and the reason for it.
 It is impossible to achieve and should be dropped off.

Features of Requirements Elicitation

1. Stakeholder engagement: Requirements elicitation involves engaging with
stakeholders such as customers, end-users, project sponsors, and subject-matter
experts to understand their needs and requirements.
2. Gathering information: Requirements elicitation involves gathering information
about the system to be developed, the business processes it will support, and the
end-users who will be using it.
3. Requirement prioritization: Requirements elicitation involves prioritizing
requirements based on their importance to the project’s success.
4. Requirements documentation: Requirements elicitation involves documenting
the requirements clearly and concisely so that they can be easily understood and
communicated to the development team.
5. Validation and verification: Requirements elicitation involves validating and
verifying the requirements with the stakeholders to ensure they accurately
represent their needs and requirements.
6. Iterative process: Requirements elicitation is an iterative process that involves
continuously refining and updating the requirements based on feedback from
stakeholders.
7. Communication and collaboration: Requirements elicitation involves effective
communication and collaboration with stakeholders, project team members, and
other relevant parties to ensure that the requirements are clearly understood and
implemented.
8. Flexibility: Requirements elicitation requires flexibility to adapt to changing
requirements, stakeholder needs, and project constraints.

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.
8. Supports identification of new business opportunities: Supports the
identification of new business opportunities and revenue streams.

Disadvantages of Requirements Elicitation

1. Time-consuming: It can be time-consuming and expensive.
2. Skills required: Requires specialized skills and expertise.
3. Impacted by changing requirements: This 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: This 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: This may result in incomplete or inaccurate
requirements if not properly managed.
8. Increased development cost: This can lead to increased development costs and
decreased efficiency if requirements are not well-defined.

BUILDING THE REQUIREMENT MODEL

The intent of the analysis model is to provide a description of the required informational,
functional, and behavioral domains for a computer-based system. The analysis model is
a snapshot of requirements at any given time.
Elements of the Requirements Model
The specific elements of the requirements model are dictated by the analysis modeling
method that is to be used. However, a set of generic elements is common to most
requirements models.
Scenario Based Elements: The system is described from the user’s point of view
using a scenariobased approach Ex: Use Case diagrams and Activity diagrams.
Class-based Elements: Each usage scenario implies a set of objects that are
manipulated as an actor interacts with the system. These objects are categorized into
classes—a collection of things that have similar attributes and common
behaviors(operations). Ex: Class diagram, Collaboration diagram.
Behavioral Elements: In Software Engineering, the Behavioral Elements Model is a
concept used to describe the dynamic behavior of a software system. It focuses on how
the system's components interact with each other and with external entities to achieve
specific tasks or behaviors. The state diagram is one method for representing the
behavior of a system by depicting its states and the events that cause the system to
change state. This model indicates how the software will respond on occurrence of
external event. Ex: State diagram and Sequential Diagram.
Flow-Oriented elements: Information is transformed as it flows through a computer-
based system. The system accepts input in a variety of forms, applies functions to
transform it, and produces output in a variety of forms. Ex: Data-Flow diagram, Control
Flow diagram.

In the context of a requirements model, there are various types of requirements,

including functional, non-functional, and behavioral requirements. Together, these
ensure a comprehensive understanding of the system’s intended behavior, quality
attributes, and interaction with users or other systems.

1. Functional Requirements

 Definition: Functional requirements specify the core actions or functionalities

that the system must perform to meet user needs. They focus on "what" the
system should do.
 Examples:
o User authentication (login, logout)
o Data input, validation, and processing (form submissions, calculations)
o Workflow management (e.g., a system for processing orders)
o API communication (data retrieval from or sending to other systems)
 Role in Model: Functional requirements are at the heart of system design. They
describe specific features or behaviors that the system should support. These
are usually documented through:
o Use Cases: Descriptions of how different actors interact with the system
to accomplish tasks.
o User Stories: Simplified narratives explaining desired functionality from
the user's perspective.
o Data Flow Diagrams (DFD): Illustrate the flow of data within the system.

2. Non-Functional Requirements

 Definition: Non-functional requirements specify the constraints and quality

attributes of the system, focusing on how the system performs its functions rather
than what it does. These include performance, security, usability, and scalability.
  Types:
o Performance: Defines how fast the system should respond under certain
conditions (e.g., “The system should process 1000 transactions per
second”).
o Security: Describes how the system should protect data and maintain
privacy (e.g., “The system should use two-factor authentication”).
o Usability: Focuses on user experience and ease of use (e.g., “The
system should allow users to navigate between pages in under 3 clicks”).
o Reliability: Describes the system's availability and failure recovery (e.g.,
“The system should have 99.9% uptime”).
o Scalability: The system's ability to handle increased load (e.g., “The
system should scale to support 10,000 concurrent users”).
 Role in Model: Non-functional requirements shape how the system performs its
core functionality and ensure that it meets user expectations for quality. These
are often captured in:
o Quality attributes or metrics: Specific targets the system must achieve.
o System architecture decisions: To ensure the system can handle
performance, scalability, and security requirements.

3. Behavioral Requirements

 Definition: Behavioral requirements specify how the system reacts to specific

inputs or stimuli and describe its interaction with external entities. These
requirements are often modeled to visualize the dynamic behavior of the system.
 Role in Model: Behavioral requirements capture how the system should behave
in response to certain conditions or events. They help in understanding system
logic and workflows, often represented by:
o State Diagrams: Show how the system transitions from one state to
another based on certain events or inputs.
o Sequence Diagrams: Visualize how components of the system interact
with each other over time, illustrating the flow of messages or actions.
o Activity Diagrams: Represent the flow of control between different
system activities, often used to model workflows or processes.

Key Components Related to Behavioral Requirements:

 Triggers: Events that initiate specific behaviors in the system (e.g., a user
clicking a button).
 States: The various conditions the system can be in (e.g., “Logged in” or
“Logged out”).
 Transitions: The rules that govern the change from one state to another (e.g., "If
the user inputs correct credentials, transition from ‘Login Page’ to ‘Dashboard’").
 Actions: The system’s responses to specific events or triggers (e.g., “Send a
confirmation email when the user completes the registration form”).
Requirements validation

Requirements validation is a crucial step in the software development process that ensures the
requirements gathered for a system are correct, complete, and align with the needs of
stakeholders. It focuses on verifying that the requirements accurately represent what the
stakeholders want and expect before moving on to design, development, or further stages of the
project.

Purpose of Requirements Validation:

1. Accuracy: Ensures that the documented requirements match stakeholders'

expectations.
2. Completeness: Verifies that all necessary requirements have been captured.
3. Consistency: Confirms that requirements do not contradict each other.
4. Feasibility: Determines whether the requirements can be realistically implemented
within budget, time, and technology constraints.
5. Clarity: Ensures that the requirements are understandable and unambiguous to all
stakeholders.

Techniques Used for Validating Requirements:

1. Reviews (or Inspections):

o Requirements are examined by a group of stakeholders, including project
managers, business analysts, developers, and users, to ensure accuracy and
completeness.
o Structured reviews or inspections can identify inconsistencies, missing
requirements, or ambiguities.

2. Prototyping:
o Building a small, working model of the system (or parts of it) to demonstrate
functionality and gather feedback from stakeholders.
o Helps stakeholders visualize the final product and ensure their expectations are
being met.

3. Walkthroughs:
o An informal presentation of the requirements to stakeholders, where the author
explains each requirement and gathers feedback.
o Helps clarify uncertainties and gain consensus on the interpretation of
requirements.

4. Simulation:
o Simulating system operations based on requirements to observe behavior and
assess whether the system will meet expectations.
o Allows early identification of issues before full development begins.
 5. Test Case Generation:
o Writing test cases based on requirements to ensure they are testable.
o Helps verify whether the system can be validated and if the requirements are
clear and specific enough for testing.

6. Checklists:
o Using predefined lists of questions or criteria to ensure each requirement meets
certain standards (e.g., clarity, consistency, feasibility, testability).
o Ensures that common errors are avoided during the validation process.

7. Modeling:
o Using models like data flow diagrams (DFDs), entity-relationship diagrams
(ERDs), or Unified Modeling Language (UML) to visually represent the
requirements.
o Helps in validating the structure and behavior of the system, ensuring it aligns
with the needs of the business.

8. Stakeholder Interviews:
o Engaging stakeholders in direct discussions to confirm that the requirements
capture their needs accurately.
o Useful for resolving discrepancies between stakeholder expectations and
documented requirements.

9. Traceability Matrices:
o A document that links requirements to design, implementation, and testing to
ensure each requirement has been addressed throughout the development
lifecycle.
o Helps ensure that no requirement is overlooked and that each can be traced
back to its origin.

How Validation Ensures Requirements Meet Stakeholder Needs:

1. Early Detection of Errors: By validating requirements early in the development process,

misunderstandings, ambiguities, or errors can be identified before costly design or
development work begins.
2. Stakeholder Alignment: Validation brings stakeholders into the process early, ensuring
that the project aligns with their goals, expectations, and business objectives.
Misunderstandings between stakeholders and development teams are resolved upfront.
3. Improved Communication: Techniques such as walkthroughs, prototyping, and
interviews enhance communication between technical teams and non-technical
stakeholders, ensuring that everyone understands the requirements and their implications.
4. Feasibility Check: Validation ensures that the requirements are technically feasible and
practical, given constraints such as time, budget, and available resources. This prevents
unrealistic expectations from derailing the project later.
5. Testability Assurance: By generating test cases and ensuring requirements are testable,
validation confirms that the system can be effectively tested, ensuring that the final
product meets all the specified requirements.
6. Mitigating Risks: Validating requirements helps to identify and mitigate risks early, such
as scope creep or unrealistic expectations, by ensuring all necessary requirements are
captured and agreed upon.