lOMoARcPSD|50888207

UNIT -IV - Idegeg

Computer science (Malla Reddy Group of Institutions)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by NithishKumar K ([email protected])
 lOMoARcPSD|50888207

UNIT _IV:

I. Impact of Agile Processes in RE

Requirements engineering (RE) refers to the process of defining, documenting, and maintaining
requirements in the engineering design process. Requirement engineering provides the appropriate
mechanism to understand what the customer desires, analyzing the need, and assessing feasibility,
negotiating a reasonable solution, specifying the solution clearly, validating the specifications and
managing the requirements as they are transformed into a working system.

Agile Methodology includes many techniques and methods. Frequently used methods are Scrum,
Crystal, Dynamic Software Development Method (DSDM), Feature Driven Development (FDD),
Lean Software Development, and Extreme Programming (XP).

Agile modeling (AM) is a methodology for modeling and documenting software systems based on
best practices. It is a collection of values and principles that can be applied on an (agile) software
development project. Agile model driven development includes several best practices with are
pertinent to understanding how business analysis fits into an agile project.

 Active Stakeholder participation: Active

stakeholder interaction refers to the practice of engaging your product’s stakeholders in
reviewing the product as it is being developed and allowing them to provide timely
feedback. Traditionally, software development starts with active stakeholder engagement in
defining the product requirements. In many cases, teams create a “requirements contract”
with their customers before the project begins to ensure that they
 Prioritized Requirements :
On most projects of reasonable complexity, there is a limited budget and the budget must be
wisely targeted to maximize value and minimize costs. Prioritization provides transparency
to the business and allows them to make informed decisions when deciding on the scope of
the project.
 Requirements envisioning:
A common agile practice is to perform some high-level requirements envisioning early
in the initiative to help come to a common understanding as to the scope of what you’re
trying to accomplish. The goals at this point are to identify the business goals for the
effort, develop a common vision, and swiftly identify the initial requirements for the
system at a high-level. You do not need to write mounds of documentation at this point,
instead you will identify the details later during development cycles in model
storming sessions and via TDD. Very often this initial requirements modeling effort is
on the order of hours or days, not weeks or months as we see on traditional teams. This
article addresses several critical questions:

 Iteration model:
An Agile iteration is a short period of time during which a section of work is developed and
tested. Each iteration has a set completion date by which all its deliverables must be
achieved. As the Scaled Agile Framework puts it, iterations are the “basic building block of
agile development.”
 Model storming:

Downloaded by NithishKumar K ([email protected])

 lOMoARcPSD|50888207

Model storming is just in time (JIT) modeling: you identify an issue which you need to
resolve, you quickly grab a few team mates who can help you, the group explores the
issue, and then everyone continues on as before. It’s common on agile teams, Extreme
Programmers call it a stand-up design session or a customer Q&A session, and it’s
clearly common on traditional teams as well so we can find ways to get even better at it.

 Test Driven Development (TDD):

Test Driven Development (TDD) is a software development practice that focuses on

creating unit test cases before developing the actual code. It is an iterative approach
combining programming, unit test creation, and refactoring.

II. Current Agile Practices

Agile best practices for implementing each. You can even get an agile management
certification to learn professional skills. Some of the best agile practices used for creating an
effective team include:

Some more Agile practices for an effective team include -

1. Creating the sprint backlog during a planning meeting: The product owner presents
high-priority features at these sessions, and the team answers questions and develops
specific tasks for the sprint backlog.

3. Encouraging self-organizing teams: The ability to make decisions and adjust to shifting
demands is a benefit of self-organizing teams. Team members offer their services instead of
waiting for the team leader to assign work.
4. Maintain charts to monitor progress: Burn down charts can be kept up to date to monitor
development. A burn down chart plots the amount of work remaining against the amount of
time. When estimating and all of the work will be finished is quite helpful.

4. Sprint retrospectives to learn from the previous sprint: This meeting is held to review
the most recent sprint and decide what could be altered to make the following sprint more
fruitful.

5. Sprint reviews to present work: The team displays the product backlog items they
finished during the sprint during this meeting. A Power Point presentation or a
demonstration of fresh features could be used.

6. Release planning meeting to create a release plan: The primary goal of the release
planning meeting is for the development team to estimate the number of ideal
programming weeks needed to complete each user story. The customer then determines
which tale has the highest priority for completion and is the most important.

7. Cross training: The project's progress may be slowed down if only one member of your
team is capable of working in a particular area and that individual decides to quit or simply

Downloaded by NithishKumar K ([email protected])

 lOMoARcPSD|50888207

has too much to accomplish. Cross-training makes your team more adaptable and helps to
avoid this problem.

8. Creating an ideal Agile workspace where the team enjoys working:

The following elements should be present in the ideal agile workspace:

 large, readable charts (a visual reminder of the current state of the project)
 the opportunity to observe each team member (everyone should be visible in the team
workspace)
 massive whiteboards (at least one where developers may share problems and seek solutions)
 a calm and intimate setting (for relaxing, working alone or private calls)

9. Setting a sustainable pace: A manageable pace assists the team in planning releases and
iterations and prevents overtime.

10. Estimating the projected velocity: Project velocity's major goal is to assist teams in
estimating how much work they can complete in a specific amount of time based on how
quickly earlier iterations of the same task were finished.

11. Always having the customer available: The consumer must be accessible at all times. It
is preferable to designate a customer or clients to the development team.

12. Creating spike solutions to reduce risks: Very basic software to investigate potential
solutions is called a spike solution. It aids in finding solutions to challenging technical or
design issues.

13. Work together with the client: When needs and wishes are met, expectations are met,
and requirements are satisfied, the consumer is happy. Software engineers have devised
several methods, short of mindreading, to ascertain what the customer wants and provide
it. At one end of the funnel, teams often record user needs before delivering the product
at the other end with little to no client engagement in between. An agile team keeps in
close contact with the client to clarify expectations, work on fixes, and present
possibilities that hadn't been thought of before.

14. Build projects around motivated people: To push through a demanding development
cycle and complete the work correctly, one needs motivation. Agile teams are committed
to their job, laser-focused on the collective objective, and collegial. Agile teams create a
fast-paced, predictable rhythm to their work when there is mutual trust and respect among
the team members. It's challenging to create an environment where this can occur.

15. Transmit information in person: Agile team members like in-person interactions,
whether discussing a challenging issue with a coworker or reporting on the day's
accomplishments during a daily meeting. Progress is slowed down or blocked by
information lost in a busy email box or voice mail queue. The daily meeting is the only
time the complete staff gets together to discuss any problems that can result in delays.

Downloaded by NithishKumar K ([email protected])

 lOMoARcPSD|50888207

III. Variance
Sprint effort variance represents the comparison of the planned amongst the actual efforts within a
sprint.

X axis -15 sprints.

Y axis - Hour

1. If the Spent Hours is less than the Estimated Hours, then Effort Variance will be positive.

2. If the Spent Hours is more than the Estimated Hours, then Effort Variance will be negative. If the
Variance is positive then the indicator will be in green and spiked up. If the variance is negative
then the indicator will be in red and spiked down.

3. Positive Variance represents that the team member has spent less time (in Hours) in comparison
of their Estimation (in Hours) within a sprint.

4. Negative Variance represents that the team member has spent more time (in Hours) in
comparison of their Estimation (in Hours) within a sprint.

5. Orange Bar – Total Hours of work estimated by the Team members (in Hours) with in a sprint.

6. Green Bar – Total Hours of time spent by Team members (in Hours) with in a sprint.

7. Green Trend line – It will show total available hours of all the sprints within a sprint.

Downloaded by NithishKumar K ([email protected])

 lOMoARcPSD|50888207

8. Variance is based on total hours that are spent more/ less in comparison of your estimated hours.
(Sprint Effort Variance = Estimation Hours – Spent Hours).

IV. Overview of RE using Agile

Elicitation: An elicitation technique is any of a number of data collection techniques used

in anthropology, cognitive science, counseling, education, knowledge engineering, linguistics,
management, philosophy, psychology, or other fields to gather knowledge or information from
people. Elicitation technique or elicitation procedure, any of various data collection techniques in
social sciences or other fields to gather knowledge or information from people.

Validation: The validation activity is a process constantly in progress, with the main objective of
making sure documented requirements are describing the wanted properties and describing them in
the right way. Validation tries to answer the following questions

• Do all parts match and is everything included?

• Are the stakeholders happy?

• Is the specification consistent with product goals? A good requirements specification should fulfill
a number of quality criteria:

• Each requirement should be correct and reflect a customer need or expectation.

Requirements Management:

Requirements Management is the process of managing, organizing, and controlling all requirements
of a project. This process involves collecting and analyzing stakeholders’ requirements,
documenting them in a Requirements Management Plan (RMP), evaluating the impact of changes
in those requirements, and ensuring that the right stakeholders are involved in decision-making
throughout the project. It also includes tracking progress against established requirements and
addressing any issues associated with meeting those objectives. Requirements Management ensures
that projects are completed efficiently and effectively while meeting stakeholder expectations.
Additionally, it helps to avoid costly rework due to misunderstandings or incorrect assumptions
about what is required for the successful completion of a project.

Sprint planning meeting goals:

 Look for holidays within the sprint.

 Find out the mandatory pieces of training for each team member.
 Work out how many hours do we need to reserve for regular meetings.
 Find out the planned leaves from the team.
 Finalize the available capacity for sprint work.
 Have a walkthrough of what has not been completed in the previous sprint but just give only
a few minutes as you already know enough about these stories.
 Decide if the spillovers need to go to sprint backlog for planning or product backlog.

Downloaded by NithishKumar K ([email protected])

 lOMoARcPSD|50888207

Project Backlog:

A project backlog is a prioritized and structured list of deliverables that are a part of the scope of a
project. It is often a complete list that breaks down work that needs to be completed. The project
backlog helps structure scope and identifies business priorities before teams spend too much time
planning the details.

For longer projects, teams may not keep the entire work breakdown structure in the project backlog.
Instead, it may only focus on what needs to be done during a specific time period.

Project backlogs contain ideas that focus on a specific project. These backlogs are usually handled
by a project owner in charge of a single team. Projects can be part of larger products managed by a
product backlog. For example, an organization may deliver customer implementation projects as
part of a larger product backlog. Or a game development company might manage each generation
of a game as a project with a fixed delivery date.

Sprints:
A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work.
Sprints are at the very heart of scrum and agile methodologies, and getting sprints right will help
your agile team ship better software with fewer headaches.

“With scrum, a product is built in a series of iterations called sprints that break down big, complex
projects into bite-sized pieces," said Megan Cook, Group Product Manager for Jira Software at
Alsatian.

Stand-up
The daily stand-up is a short, daily meeting to discuss progress and identify blockers. The reason
it’s called a “stand-up” is because if attendees participate while standing, the meeting should be
kept short.

For software teams, a stand-up is like a sports team’s huddle. Like (American) football and rugby,
the team huddles before each play. The huddle is strategic: it keeps the team informed, connected,
and calibrated throughout the game. For software teams, the stand-up is like the team’s huddle. It’s
even commonly known as the daily scrum, and reinforces “we” to keep everyone aware of the
team’s landscape and progress.

Here’s a daily stand-up template to get you started.

Said another way, a stand-up is a daily meeting that involves the core team: product owners,
developers, and the scrum master. This meeting’s flavor is unique to each team, but at Atlassian we
use three simple questions to generate structure:

Downloaded by NithishKumar K ([email protected])

 lOMoARcPSD|50888207

 What did I work on yesterday?

 What am I working on today?
 What issues are blocking me?

These questions highlight progress and help flag team blockers. Also, it strengthens the team when
everyone shares the progress they’re contributing to the team. The daily reinforcement of sharing
individual successes and plans keeps everyone excited about the team’s overall contribution to the
organization.

Sprint Review Meeting

Each sprint is required to deliver a potentially shippable product increment. This means that at the
end of each sprint, the team has produced a coded, tested and usable piece of software. So at the
end of each sprint, a sprint review meeting is held. During this meeting, the Scrum team shows what
they accomplished during the sprint. Typically this takes the form of a demo of the new features.

The sprint review meeting is intentionally kept very informal, typically with rules forbidding
the use of PowerPoint slides and allowing no more than two hours of preparation time for the
meeting. A sprint review meeting should not become a distraction or significant detour for the team;
rather, it should be a natural result of the sprint.

V. Managing Unstable Requirements

The Iterative Waterfall model was very popular for completing a project. But nowadays,
developers face various problems while using it to develop software. The main difficulties
included handling customer change requests during project development and the high cost and
time required to incorporate these changes. To overcome these drawbacks of the Waterfall model,
in the mid-1990s the Agile Software Development model was proposed.
The Agile model was primarily designed to help a project adapt quickly to change requests. So,
the main aim of the agile model is to facilitate quick project completion. To accomplish this task,
agility is required. Agility is achieved by fitting the process to the project and removing activities
that may not be essential for a specific project. Also, anything that is a waste of time and effort is
avoided. The agile model refers to a group of development processes. These processes share some
basic characteristics but do have certain subtle differences among themselves.

Agile SDLC models / Methods:-

 Crystal: Crystal Agile methodology places a strong emphasis on fostering effective

communication and collaboration among team members, as well as taking into account the

Downloaded by NithishKumar K ([email protected])

 lOMoARcPSD|50888207

human elements that are crucial for a successful development process. This methodology is
particularly beneficial for projects with a high degree of uncertainty, where requirements tend to
change frequently.
 Atern: This methodology is tailored for projects with moderate to high uncertainty where
requirements are prone to change frequently. Its clear-cut roles and responsibilities focus on
delivering working software in short time frames. Governance practices set it apart and make it
an effective approach for teams and projects.
 Feature-driven development: This approach is implemented by utilizing a series of techniques,
like creating feature lists, conducting model evaluations, and implementing a design-by-feature
method, to meet its goal. This methodology is particularly effective in ensuring that the end
product is delivered on time and that it aligns with the requirements of the customer.
 Scrum: This methodology serves as a framework for tackling complex projects and ensuring
their successful completion. It is led by a Scrum Master, who oversees the process, and a Product
Owner, who establishes the priorities. The Development Team, accountable for delivering the
software, is another key player.
 Extreme programming (XP): It uses specific practices like pair programming, continuous
integration, and test-driven development to achieve these goals. Extreme programming is ideal
for projects that have high levels of uncertainty and require frequent changes, as it allows for
quick adaptation to new requirements and feedback.
 Lean development: It is rooted in the principles of lean manufacturing and aims to streamline
the process by identifying and removing unnecessary steps and activities. This is achieved
through practices such as continuous improvement, visual management, and value stream
mapping, which helps in identifying areas of improvement and implementing changes
accordingly.
 Unified Process: Unified Process is a methodology that can be tailored to the specific needs of
any given project. It combines elements of both waterfall and Agile methodologies, allowing for
an iterative and incremental approach to development. This means that the UP is characterized
by a series of iterations, each of which results in a working product increment, allowing for
continuous improvement and the delivery of value to the customer.

The agile model is a combination of iterative and incremental process models. The steps
involve in agile SDLC models are:

1. Requirement Gathering:- In this step, development team must gather the requirements, by
interaction with the customer. Development team should plan the time and effort needed to
build the project. Based on this information you can evaluate technical and economical
feasibility.
2. Design the Requirements:- In this step, development team will use user-flow-diagram or high
level UML diagrams to show the working of the new features and show how it will apply to
the existing software. Wire framing and designing user interfaces are done in this phase.
3. Construction / Iteration: In this step, development team members start working on their
project, which aims to deploy a working product.
4. Testing / Quality Assurance: Testing involves unit testing, Integration testing, system
testing. Brief introduction of these three testing are as follows:
5. Deployment: In this step, development team will deploy the working project to end users.
6. Feedback: This is the last step of Agile Model. In this, team receives feedback about the
product and works on correcting bugs based on feedback provided by the customer.

Downloaded by NithishKumar K ([email protected])

 lOMoARcPSD|50888207

VI. Requirements Elicitation & Analysis

It’s a process of interacting with customers and end-users to find out about the domain requirements,
what services the system should provide, and the other constraints. Domain requirements reflect the
environment in which the system operates so, when we talk about an application domain we mean
environments such as train operation, medical records, e-commerce etc.

It may also involve different kinds of stockholders; end-users, managers, system

engineers, test engineers, maintenance engineers, etc. A stakeholder is anyone who has direct or
indirect influence on the requirements.

The requirements elicitation process

We typically start by gathering the requirements, this could be done through a general discussion or
interviews with your stakeholders, also it may involve some graphical notation. Then you organize
the related requirements into sub-components and prioritize them, and finally, you refine them by
removing any ambiguous requirements that may arise from some conflicts.

Here are the 4 main processes of requirements elicitation and analysis

1. Requirements Discovery

It’s the process of interacting with, and gathering the requirements from, the stakeholders about the
required system and the existing system (if exists). It can be done using some techniques, like
interviews, scenarios, prototypes, etc, which help the stockholders to understand what the system
will be like.

Downloaded by NithishKumar K ([email protected])

 lOMoARcPSD|50888207

Gathering and understanding the requirements is a difficult process

That’s because stakeholders may not know what exactly they want the software to do, or they may
give unrealistic requirements. They may give different requirements, which will result in conflict
between the requirements, so we have to discover and resolve these conflicts.

Also, there might be some factors that influence the stakeholder’s decision, like, for example,
managers at a company or professors at the university want to take full control over the management
system.

2. Requirements Classification & Organization

It’s very important to organize the overall structure of the system. Putting related requirements
together, and decomposing the system into sub-components of related requirements. Then, we define
the relationship between these components. What we do here will help us in the decision of
identifying the most suitable architectural design patterns.

3. Requirements Prioritization & Negotiation

We previously explained why eliciting and understanding the requirements is not an easy process.
One of the reasons is the conflicts that may arise as a result of having different stakeholders
involved. it’s hard to satisfy all parties if it’s not impossible. This activity is concerned with
prioritizing requirements and finding and resolving requirements conflicts through negotiations until
you reach a situation where some of the stakeholders can compromise.

We shouldn’t reach a situation where a stakeholder is not satisfied because his requirements are not
taken into consideration. Prioritizing your requirements will help you later to focus on the essentials
and core features of the system, so you can meet the user expectations. It can be achieved by giving
every piece of function a priority level. So, functions with higher priorities need higher attention and
focus.

4. Requirements Specification

The requirements are then documented. We’ll discuss requirements specifications in more detail in
“Requirements Engineering Requirements Specification”.

Requirements Elicitation Techniques

Factors, such as the customer's profile and organizational structure, as well as the project type,
should be considered by the business analysis team before adopting a requirements elicitation
technique or a combination of techniques. There are many requirements elicitation techniques for
obtaining critical information from Subject Matter Experts and stakeholders. The most popular ones
are listed below.

Downloaded by NithishKumar K ([email protected])

 lOMoARcPSD|50888207

Brainstorming

The requirements elicitation process begins with brainstorming. To facilitate focused and fruitful
brainstorming sessions, business analysts should set up a team with representatives of all
stakeholders for capturing new ideas. Suggestions coming out of brainstorming sessions should be
properly documented in order to draft the plan of action.

Document Analysis
During this step of the requirements elicitation process, business analysts review existing
documentation at hand, with the intent of identifying requirements for changes or improvements.
Examples of document analysis sources include pre-existing project plans, system specifications,
process documentation, market research dossiers, customer feedback, meeting minutes, and user
manuals. Document analysis is performed before scheduling more in-depth requirements elicitation

Interviews

A great way to extract critical data is via interviews. Business analysts engage in group or one-to-
one interviews in an informal or formal setting to elicit project requirements through questions
directed at Subject Matter Experts, stakeholders, and end-users. By exploring diverse opinions,
business analysts gain in-depth knowledge of the requirements.

Observation

Also referred to as job shadowing, observation is an excellent elicitation technique that helps
understand requirements based on observations related to process flows and work environments of
stakeholders. Practical insights into actual workflows serve as the basis for modifications and
enhancements. The observation approach allows business analysts to elicit real-world data that
other requirements elicitation methods cannot capture.

Prototyping
One of the most important phases of the requirements elicitation process, prototyping enables
business owners and end-users to visualize realistic models of applications before they are finally
developed. Prototyping helps generate early feedback, and it boosts stakeholder participation in
requirements elicitation.

Workshops

For multi-stakeholder, complex projects, workshops are one of the most resource-efficient methods
to elicit requirements. Intense, focused, and highly productive workshops have a key role to play in
getting all parties onto the same page. Workshop events help Subject Matter Experts and
Stakeholders to collaborate, resolve conflicts, and come to an agreement.

Survey

When multiple Subject Matter Experts and stakeholders are involved in a project, business analysts
conduct a survey for the elicitation of requirements. Everyone involved is given a questionnaire to

Downloaded by NithishKumar K ([email protected])

 lOMoARcPSD|50888207

fill out. Subsequently, the responses are analyzed to refine the requirements. Surveys are less
expensive than other requirements elicitation techniques, easy to administer, and can produce both
qualitative and quantitative results.

VII. Agile Requirements Abstraction model

The Agile Requirements Abstraction Model was developed based on RAM in close
collaboration with an industrial partner, Tactile. The goal was to integrate traditional requirements
engineering in a scrum environment, and still be agile throughout the software development
process.

Initial Agile Requirements Modeling:

Initial requirements envisioning is particularly important for scaling agile software

development techniques to larger, more complex, or globally distributed development efforts.
The goal is to understand the requirements at a high-level, it isn’t to create detailed
requirements specification early in the lifecycle, a traditional practice referred to as “Big
Requirements Up Front” which proves to be very risky in practice

Downloaded by NithishKumar K ([email protected])

 lOMoARcPSD|50888207

Usage Model

Usage models enable you to explore how users will work with your system, which is
absolutely critical if you’re to understand what they need. Your usage model may be a
collection of features for a Feature Driven Development (FDD) team, or a collection of user
stories for an Scrum team. I generally prefer either user stories or use cases although my actual
choice in practice will be driven by the software process (XP, FDD) the team is following.

Whiteboard sketch of a UML Use-Case Diagram.

Use Cases & Scenarios

The use cases and scenarios are two different techniques, but, usually, they are used together. Use
cases identify interactions between the system and its users or even other external systems (using
graphical notations), while a scenario is a textual description of one or more of these interactions.
Use case involves some symbols to describe the system:

Downloaded by NithishKumar K ([email protected])

 lOMoARcPSD|50888207

1. Actors: Are those who interact with the system; human or other systems
2. Interaction (Use Case): It denotes the name of the interaction (verb). It’s represented as a named
ellipse.
3. Connection: Lines that link between the actors and the interactions.
4. Include Relationship: It denotes a connection between two interactions when an interaction is
invoked by another. As an example, splitting a large interaction into several interactions.
5. Exclude Relationship: It denotes a connection between two interactions when you want to
extend an interaction by adding an optional behavior, but you can use the main interaction on its
own without the extending interaction.

Scenario:

1. A description of the initial situation.

2. A description of the flow of the events or interactions with the system
3. A description of the exceptions, or in other words, what can go wrong, and how it can be
handled.
4. Any concurrent activities should be mentioned
5. A description of the final state.

Downloaded by NithishKumar K ([email protected])

 lOMoARcPSD|50888207

Domain Model

Part of your initial modeling efforts, particularly for a business application, will likely include
the development of a conceptual domain model. This model should be very slim, capturing the
main business entities and the relationships between them. As you see in Figure 4, your model
doesn’t need to be complete, it just needs to cover enough information to make you
comfortable with the primary business concepts.

User Interface Model(s)

The user interface (UI) is the portion of software with which a user directly interacts. For most
stakeholders the UI is the system so it is crucial to the initial success of your t eam to ensure that you
understand what stakeholders expect of the UI. One way to explore the requirements for the UI is to
create what are called essential UI prototypes, also known as an abstract prototypes or paper
prototype.

Downloaded by NithishKumar K ([email protected])

 lOMoARcPSD|50888207

VIII. Requirements Management in Agile Environment

Requirements Management is the process of managing, organizing, and controlling all requirements
of a project. This process involves collecting and analyzing stakeholders’ requirements,
documenting them in a Requirements Management Plan (RMP), evaluating the impact of changes
in those requirements, and ensuring that the right stakeholders are involved in decision-making
throughout the project. It also includes tracking progress against established requirements and
addressing any issues associated with meeting those objectives. Requirements Management ensures
that projects are completed efficiently and effectively while meeting stakeholder expectations.
Additionally, it helps to avoid costly rework due to misunderstandings or incorrect assumptions
about what is required for the successful completion of a project.

 Review Requirements Collaboration:

Requirements collaboration is a systematic approach that involves engagement with key
stakeholders and the project team. This process enables team members of any user level to collaborate
and participate in real-time topics and discussion across projects.
The main purpose of the requirements collaboration process is to ensure that the requirements are
complete, precise, clear, and that all stakeholders are on the same page. Requirements authoring is a
monotonous and complex process, making it inevitable that errors may occur at some stage. That's why
it's important to have a requirements collaboration process merged to a requirements review process in
place to identify areas that require modifications, corrections, and clarifications.

Downloaded by NithishKumar K ([email protected])