UNIT-IV

IMPACT OF AGILE PROCESSES IN REQUIREMENTS ENGINEERING.

Agile processes have had a significant impact on requirements engineering, which is the process
of eliciting, analyzing, documenting, validating, and managing software requirements. The
following are some ways in which Agile processes have impacted requirements engineering:
1. User involvement: Agile processes emphasize user involvement throughout the software
development process. This means that requirements are often elicited directly from users or
stakeholders, and are continuously refined and validated throughout the development process.
This helps ensure that the final product meets the needs of the user.
2. Collaboration: Agile processes encourage collaboration and communication between team
members and stakeholders. This helps ensure that everyone has a clear understanding of the
requirements and the development process, and helps to identify and address potential issues or
risks early on.
3. Flexibility: Agile processes are designed to be flexible and adaptable to changing requirements
or priorities. This means that requirements can be adjusted or refined as needed throughout the
development process, in response to feedback from users or changes in the market or business
environment.
4. Iterative development: Agile processes are based on iterative and incremental development.
This means that requirements are developed and delivered in small, manageable increments,
rather than in a single, large release. This approach allows for continuous feedback and
validation of requirements, and ensures that the product is developed in a timely and efficient
manner.
5. Emphasis on value: Agile processes emphasize delivering value to the customer. This means
that requirements are prioritized based on their value to the user or customer, and features or
requirements that do not add value are eliminated or postponed. This helps ensure that the final
product is focused on meeting the needs of the user or customer, and is not burdened by
unnecessary features or requirements.
In summary, Agile processes have had a significant impact on requirements engineering, by
emphasizing user involvement, collaboration, flexibility, iterative development, and value. These
principles help ensure that requirements are developed and delivered in a timely and efficient
manner, and that the final product meets the needs of the user or customer.

1
 CURRENT AGILE PRACTICES

As of my last knowledge update in September 2021, Agile practices in Requirements

Engineering (RE) were evolving and adapting to meet the changing needs of software
development. However, please note that practices may have continued to evolve since then. Here
are some of the common Agile practices in Requirements Engineering:

1. User Stories: Agile teams typically use user stories as a primary means of capturing
requirements. User stories are short, user-centric descriptions of functionality that provide
context to developers and help prioritize work based on customer needs.
2. Backlog Management: Agile teams maintain a product backlog, which is a prioritized list of
user stories and other work items. The backlog is continually refined, with items added,
removed, or reprioritized based on changing requirements and feedback.
3. Product Owner Role: The product owner plays a crucial role in Agile development. They are
responsible for representing the customer or stakeholder interests, prioritizing the backlog, and
ensuring the team is working on the most valuable features.
4. Iterative Development: Agile projects are organized into iterations or sprints, typically lasting
two to four weeks. During each iteration, a subset of user stories is selected for implementation,
allowing for regular delivery of working software.
5. Continuous Feedback: Agile emphasizes continuous feedback from stakeholders. This includes
regular demos of working software, user acceptance testing, and the incorporation of feedback
into future iterations.
6. Acceptance Criteria: Each user story includes acceptance criteria, which define the conditions
that must be met for the story to be considered complete. This helps ensure a shared
understanding of what's expected.
7. Refinement Meetings: Agile teams hold regular refinement meetings to clarify and add detail to
user stories. This helps in breaking down large stories into smaller, actionable tasks and ensures
that the team has a shared understanding of the requirements.
8. Cross-functional Teams: Agile teams are typically cross-functional, including developers,
testers, designers, and other roles. This ensures that all aspects of a user story, including
technical and usability considerations, are addressed.

2
9. Continuous Integration and Testing: Agile teams practice continuous integration, where code
changes are integrated frequently into a shared repository, and automated testing is run to ensure
that new features don't introduce defects.
10. Documentation as Code: Instead of extensive upfront documentation, Agile teams often
emphasize documenting requirements as code, using tools like living documentation frameworks
and generating documentation from code comments.
11. Retrospectives: Agile teams regularly hold retrospectives at the end of each iteration to reflect
on what went well and what could be improved. This includes examining the requirements
process for ways to enhance it.
12. Adaptive Planning: Agile embraces change, and teams are open to adapting requirements based
on evolving customer needs or market conditions. This flexibility allows for a more responsive
development process.
13. Minimum Viable Product (MVP): Agile teams often start with an MVP, a minimal version of
the product that includes only the most essential features. This allows for quicker delivery and
feedback while keeping the focus on value.

Keep in mind that the specific Agile practices used in Requirements Engineering can vary
depending on the organization, project, and team. The Agile framework chosen (e.g., Scrum,
Kanban, etc.) can also influence the practices employed. It's essential to stay updated with the
latest Agile trends and adapt practices to fit the needs of your specific project and organization.

VARIANCE
1. Scope Variance: This occurs when the project's scope changes during the development process.
Agile methodologies, such as Scrum, often deal with scope variance through mechanisms like
the product backlog. New requirements or changes in priorities can be added to the backlog and
prioritized for future sprints. This allows the team to adapt to changing business needs while
maintaining control over scope.
2. Velocity Variance In Agile, velocity is a measure of the team's capacity to complete work in a
sprint. If the team consistently completes fewer or more story points in a sprint than initially
planned, there is a velocity variance. Teams should monitor velocity closely to adjust their sprint
planning and commitments accordingly.

3
3. Schedule Variance: Agile projects are time-boxed into iterations (e.g., sprints in Scrum).
Schedule variance can occur when the team doesn't complete all planned work within a sprint.
Agile teams address this by reviewing their velocity (the amount of work they can complete in a
sprint) and adjusting future sprint planning accordingly. Retrospectives are also used to identify
and address issues that may be causing schedule variance.
4. Burnup/Burndown Chart Variance: Agile teams often use burnup and burndown charts to
track progress during a sprint or release. Variance in these charts can indicate whether the team
is ahead or behind schedule. Teams should regularly update and analyze these charts to make
informed decisions
5. Cost Variance: Agile projects are often seen as providing more predictable costs compared to
traditional project management approaches. However, cost variance can still occur if teams
underestimate the effort required for certain tasks. Agile teams can address cost variance by
monitoring project spending and adjusting future plans based on actual costs and team velocity.
6. Quality Variance: Variance in the quality of deliverables can arise if the team doesn't adhere to
Agile principles such as continuous testing and refactoring. To address quality variance, Agile
teams prioritize and allocate time for quality assurance and testing within each sprint. They also
focus on delivering a potentially shippable product increment at the end of each sprint, which
should meet the defined quality standards.
7. Risk Variance: Agile projects inherently embrace change, which can introduce risks. Risk
variance occurs when unexpected issues or challenges arise during development. Agile teams
mitigate risk variance by identifying and addressing risks early in the project, maintaining open
communication with stakeholders, and adapting plans as necessary.
8. Resource Variance: Agile teams are typically cross-functional, which means that team
members have a mix of skills. Variance in resource availability or skill sets can affect project
progress. Agile teams address resource variance by maintaining a balanced team with a mix of
skills and by cross-training team members when necessary.
9. Customer Satisfaction Variance: Ultimately, Agile development is customer-centric. Variance
in customer satisfaction can occur if the product does not meet customer expectations. Agile
teams continuously seek feedback from customers and stakeholders, which helps in addressing
variance in customer satisfaction by making necessary adjustments to the product backlog and
development priorities.

4
 In Agile, the key to addressing variances effectively is to embrace change, regularly inspect and
adapt, and maintain strong collaboration among team members and stakeholders. Agile
methodologies provide a framework for managing and responding to variance in a way that
allows teams to deliver value incrementally and respond to changing circumstances.

To address variance effectively in Agile:

 Regular Monitoring: Agile teams should regularly review their progress and metrics, such as
velocity, burndown charts, and budget vs. actuals, to identify and address variances promptly.
 Adaptability: Agile principles encourage adaptability to change. When variances are detected,
teams should be open to adjusting their plans and strategies to stay aligned with project goals.
 Collaboration: Collaborative communication within the Agile team and with stakeholders is
crucial. Variances should be communicated transparently to ensure everyone is aware of the
current project status.
 Continuous Improvement: Agile promotes a culture of continuous improvement. Teams should
use variance analysis as an opportunity to learn and make necessary improvements in their
processes and practices.
 Prioritization: When faced with scope or resource variances, Agile teams should prioritize work
items based on their value to the project and customer needs..
OVERVIEW OF RE USING AGILE

Requirements engineering (RE) is a critical phase in software development that focuses on

gathering, documenting, and managing the requirements for a software system. Agile
methodologies, such as Scrum and Kanban, have gained popularity in recent years for their
flexibility and customer-centric approach to software development. When incorporating
requirements engineering into an agile framework, several key principles and practices should be
considered:

1. User Stories: In agile development, requirements are often expressed as user stories. These are
short, simple descriptions of a feature or functionality from an end-user's perspective. User
stories are typically written on index cards or digitally, and they serve as a lightweight way to
capture and prioritize requirements.

5
2. Product Backlog: Agile teams maintain a product backlog, which is a dynamic list of user
stories and other requirements. The backlog is prioritized based on business value and can be
adjusted as new information becomes available. The most important requirements are at the top
of the backlog.
3. Iterative Development: Agile development is iterative and incremental. Instead of trying to
gather all requirements upfront, agile teams work in short development cycles (sprints in Scrum)
and continuously refine and add to the requirements as they go. This allows for flexibility and
the ability to respond to changing business needs.
4. Continuous Stakeholder Engagement: Agile encourages regular interaction with stakeholders,
including customers and end-users. This ongoing collaboration helps to clarify requirements,
validate assumptions, and ensure that the software being developed meets the users' needs.
5. Acceptance Criteria: Each user story should have clear acceptance criteria that define when the
story is considered complete and meets the user's expectations. These criteria serve as a basis for
testing and validation.
6. Prioritization: Agile teams work with stakeholders to prioritize requirements based on business
value. This ensures that the most valuable features are developed first, allowing for early
delivery of value to the customer.
7. Change Management: Agile recognizes that requirements can change throughout the project.
Instead of resisting change, agile methodologies embrace it and have processes in place for
managing changes to requirements without disrupting the project's progress.
8. Documentation: While agile values working software over comprehensive documentation, some
level of documentation is still necessary. Agile teams often use lightweight documentation
techniques, such as user story cards and digital tools, to capture and share requirements.
9. Feedback Loops: Agile encourages frequent feedback from users and stakeholders. This
feedback helps in refining and updating requirements to ensure they align with the evolving
needs of the project.
10. Continuous Improvement: Agile teams regularly reflect on their processes and seek ways to
improve. This includes reviewing and adapting their requirements engineering practices to
enhance efficiency and effectiveness.

6
In summary, requirements engineering within an agile framework emphasizes collaboration,
flexibility, and adaptability. It involves continuously refining and evolving requirements based
on stakeholder feedback and changing business conditions, ultimately leading to the
development of software that better meets the needs of users and customers.

MANAGING UNSTABLE REQUIREMENTS AND REQUIREMENTS ELICITATION.

• Managing Unstable Requirements: Managing unstable requirements refers to the process of
dealing with requirements that are likely to change or evolve over the course of a software
development project. This can occur for a number of reasons, such as changes in the business
environment, shifting user needs or priorities, or evolving technology.
• Managing unstable requirements requires a flexible and adaptive approach to software
development, in which requirements are continuously refined and validated throughout the
development process. This can be achieved through iterative and incremental development,
continuous user involvement and feedback, and a focus on delivering value to the customer.
• By managing unstable requirements effectively, software development teams can ensure that
the final product meets the needs of the user or customer, even in the face of changing
requirements or priorities.
• Requirements Elicitation: Requirements elicitation refers to the process of identifying,
gathering, and documenting the requirements for a software
system.
• This involves working with stakeholders such as users, customers, and business analysts to
understand their needs and expectations for the system.
Requirements elicitation may involve a variety of techniques, such as interviews, surveys, focus
groups, and observation. The goal of requirements elicitation is to ensure that all relevant
requirements are identified and documented, and that they are clearly and accurately
communicated to the development team.
• This helps to ensure that the final product meets the needs of the user or customer, and that it is
delivered in a timely and efficient manner. Requirements elicitation is a critical component of the
software development process, as it forms the basis for all subsequent development activities,
including design, implementation, and testing.

AGILE REQUIREMENTS ABSTRACTION MODEL

7
Ans: The Agile Requirements Abstraction Model (ARAM) is a framework for managing and
prioritizing requirements in Agile software development projects. It is designed to help
development teams identify and prioritize requirements based on their impact on the overall
project goals and objectives, as well as on their level of complexity and effort required for
implementation.
The ARAM framework consists of five levels of abstraction, each of which represents a
different level of detail and complexity:
1. Vision: At the highest level of abstraction, the vision represents the overall goals and
objectives of the project. The vision provides a high-level view of what the software system
should accomplish, and serves as a guide for prioritizing requirements and making development
decisions.
2. Themes: Themes are a set of high-level categories or areas of functionality that are important
to achieving the project vision. Themes help to organize requirements into logical groups, and
provide a way to prioritize requirements based on their alignment with the overall project goals.
3. Epics: Epics are large, high-level requirements that are typically broken down into smaller,
more manageable pieces. Epics represent major areas of functionality or user needs, and are used
to guide development efforts and prioritize requirements.
4. User Stories: User stories are specific, detailed requirements that describe the needs and
expectations of the end user. User stories are typically written from the perspective of the user,
and focus on the desired outcome or functionality, rather than on technical details.
5. Tasks: Tasks are specific development activities or actions that are required to implement a
user story. Tasks are typically assigned to individual team members, and are used to track
progress and ensure that development efforts are aligned with the overall project goals.
The ARAM framework is designed to provide a structured approach to requirements
management in Agile software development projects. By breaking requirements down into
manageable pieces and prioritizing them based on their alignment with the overall project goals
and objectives, the ARAM framework helps development teams to stay focused on delivering
value to the customer, while also ensuring that development efforts are aligned with the overall
project vision.
REQUIREMENTS MANAGEMENT IN AGILE ENVIRONMENT.

8
Requirements management in an Agile environment is the process of identifying, prioritizing,
and tracking requirements throughout the software development lifecycle. In an Agile
environment, requirements are managed in a flexible and iterative manner, with an emphasis on
collaboration, continuous feedback, and rapid adaptation to changing requirements.
The following are some of the key aspects of requirements management in an Agile
environment:

User involvement: Agile development places a strong emphasis on involving the end user in the
requirements management process. User involvement helps to ensure that the requirements are
aligned with the needs and expectations of the end user, and that the final product meets their
needs and provides value.
2. Continuous feedback: In an Agile environment, requirements are continuously refined and
validated through ongoing feedback from stakeholders, including users, customers, and other
members of the development team. This feedback helps to ensure that the requirements remain
relevant and that the development efforts are aligned with the overall project goals and
objectives.
3. Prioritization: In an Agile environment, requirements are prioritized based on their alignment
with the overall project goals and objectives, as well as on their level of complexity and effort
required for implementation. Prioritization helps to ensure that development efforts are focused
on delivering value to the customer and that the team is working on the most important and
relevant requirements.
4. Iterative and incremental development: In an Agile environment, development is carried out in
small, iterative cycles, with each cycle focused on delivering a specific set of requirements. This
approach allows for rapid adaptation to changing requirements and ensures that the final product
is aligned with the needs and expectations of the end user.
5. Continuous improvement: Agile development emphasizes continuous improvement and
learning throughout the development process. This includes ongoing evaluation of the
requirements management process, with a focus on identifying areas for improvement and
implementing changes to improve the process and deliver better results.
Overall, requirements management in an Agile environment is focused on delivering value to the
customer through a flexible, iterative, and collaborative approach To software development. By
continuously refining and validating requirements, prioritizing development efforts, and focusing

9
 on delivering value to the customer, Agile development teams can ensure that the final product
meets the needs and expectations of the end user and provides value to the organization.
AGILE REQUIREMENT PRIORITIZATION

Agile requirement prioritization is a critical aspect of Agile software development methodologies

such as Scrum and Kanban. It involves determining which features, user stories, or tasks should
be worked on first based on their importance, value, and dependencies. Prioritizing requirements
in an Agile context helps teams focus their efforts on delivering the most valuable and impactful
features early in the development process. Here are some common approaches and best practices
for prioritizing requirements in Agile:

1. Product Backlog: In Scrum, the Product Backlog is a prioritized list of all the requirements,
features, and user stories that need to be developed. The Product Owner is responsible for
maintaining this list and ensuring that the most valuable items are at the top.
2. User Stories: Agile teams often break down requirements into smaller, manageable units called
user stories. These stories should be prioritized based on their business value, customer needs,
and dependencies. The team can estimate the effort required for each story, which can also factor
into prioritization.
3. Value-Based Prioritization: Prioritize requirements based on the value they deliver to the
customer or the business. The Product Owner should work closely with stakeholders to
determine which features or user stories will have the most significant impact on achieving
project goals or meeting customer needs.
4. MoSCoW Method: This method categorizes requirements into four categories: Must-haves
(critical), Should-haves (important but not critical), Could-haves (nice to have but not essential),
and Won't-haves (features that won't be addressed in the current release). This approach helps in
making clear decisions about what to work on first.
5. Weighted Shortest Job First (WSJF): WSJF is a framework from the Scaled Agile Framework
(SAFe) that assigns a weight to each requirement based on factors like cost of delay, business
value, and time criticality. The highest WSJF score indicates the highest priority.
6. Kano Model: This model classifies requirements into different categories, including basic needs,
performance needs, and delighters. Prioritize based on whether a requirement falls into a
category that will satisfy or delight the customer.

10
7. Dependency Analysis: Consider dependencies between requirements. Sometimes, you may need
to prioritize a requirement lower if it's dependent on another requirement that hasn't been
implemented yet.
8. Continuous Refinement: Prioritization is not a one-time task. Agile teams should continuously
review and refine their priorities as they gain more information, feedback, and insights
throughout the project.
9. Regular Backlog Grooming: Schedule regular backlog grooming sessions to reevaluate and
adjust priorities. This keeps the backlog up-to-date and ensures that the team is always working
on the most valuable items.
10. Collaboration and Feedback: Prioritization should be a collaborative effort involving the entire
Agile team, including developers, testers, and stakeholders. Encourage open communication and
gather feedback to make informed decisions.

Remember that Agile prioritization is flexible and responsive to change. It's essential to adapt
and reprioritize as the project evolves and as you learn more about customer needs and market
conditions. The goal is to maximize the value delivered to the customer and the business
throughout the development process.

AGILE REQUIREMENTS MODELLING AND GENERATION.

• Agile requirements modeling and generation are two key processes in Agile software
development that help teams to identify, prioritize, and track requirements throughout the
development lifecycle.
• Agile requirements modeling involves creating a visual representation of the requirements
using diagrams, flowcharts, or other modeling techniques. The goal of requirements modeling is
to create a shared understanding of the requirements among all stakeholders, including the
development team, end
users, and customers. Agile requirements modeling emphasizes collaboration and feedback, with
the goal of continuously refining and validating the requirements throughout the development
process.
• Agile requirements generation is the process of creating new requirements based on the
evolving needs of the project. Requirements generation is an iterative process, with new

11
requirements identified and prioritized based on their alignment with the overall project goals
and objectives. Agile requirements generation is typically driven by user feedback, market
research, and changes in business or technical requirements.
There are several key techniques and tools that can be used for Agile requirements
modeling and generation, including:
1. User stories: User stories are a key tool in Agile requirements modeling and generation. User
stories are brief, written descriptions of a specific user need or requirement, written from the
perspective of the end user.
2. Story mapping: Story mapping is a visual technique for Agile requirements modeling that
involves creating a visual map of the user stories and their relationships. Story mapping helps to
identify gaps in the requirements and prioritize development efforts based on the most important
user needs.
3. Agile personas: Agile personas are fictional characters that represent the different types of end
users or customers. Agile personas help to create a shared understanding of the users' needs and
expectations, and can be used to guide the development of user stories and other requirements.
4. Acceptance criteria: Acceptance criteria are specific, measurable criteria that must be met for a
user story or requirement to be considered complete. Acceptance criteria help to ensure that the
requirements are aligned with the overall project goals and objectives, and provide a way to track
progress and measure success.
Overall, Agile requirements modeling and generation are critical processes in Agile software
development, helping teams to identify, prioritize, and track
requirements throughout the development lifecycle. By emphasizing collaboration, feedback, and
rapid adaptation to changing requirements, Agile requirements modeling and generation can help
teams to deliver value to the customer and achieve the overall project goals and objectives.
CONCURRENCY IN AGILE REQUIREMENTS GENERATION
• Concurrency in Agile requirements generation refers to the practice of developing requirements
in parallel with other aspects of the software development process, such as design, coding, and
testing. Concurrency is a key feature of Agile development, as it allows teams to rapidly iterate
and adapt to changing requirements, without sacrificing quality or speed. • In Agile
development, concurrency is achieved through the use of cross-functional teams, which include
members from different disciplines, such as development, design, testing, and project

12
management. These teams work together to identify, prioritize, and develop requirements in
parallel with other aspects of the development process. This approach allows teams to rapidly
respond to changes in requirements and market conditions, without having to wait for all
requirements to be fully defined and documented.
1. Faster time-to-market: Concurrency allows teams to rapidly develop and release software,
without having to wait for all requirements to be fully defined and documented. This allows
teams to respond quickly to changing market conditions and customer needs, and to deliver value
to the customer more quickly.
2. Better collaboration: Concurrency encourages collaboration and communication among team
members, as they work together to develop requirements in parallel with other aspects of the
development process. This can lead to better alignment and understanding of the requirements,
and can help to avoid misunderstandings and miscommunications.
3. More flexibility: Concurrency allows teams to rapidly iterate and adapt to changing
requirements, without sacrificing quality or speed. This allows teams to experiment with new
ideas and approaches, and to quickly pivot if a particular requirement or feature is not working as
expected.
However, there are also some potential drawbacks to concurrency in Agile requirements
generation, including:
1. Lack of clarity: When requirements are developed in parallel with other aspects of the
development process, there is a risk that the requirements may not be fully defined or
documented, which can lead to misunderstandings or miscommunications.
2. Complexity: Concurrency can make the development process more complex, as teams must
coordinate their efforts and ensure that all aspects of the development process are aligned with
the overall project goals and objectives. Overall, concurrency is an important aspect of Agile
requirements generation, as it allows teams to rapidly iterate and adapt to changing requirements,
while maintaining quality and speed. By encouraging collaboration, communication, and
flexibility, concurrency can help teams to deliver value to the customer more quickly, and to
achieve the overall project goals and objectives.

13