13

2008
Agile Methodology in
Requirements Engineering
By Sujoy Bose, Manish Kurhekar and Joydip Ghoshal
Agile methodology looks at RE in an innovative
manner for its orientation towards delivering
value to the customer
I
ncreasing competition and complex
business processes are pushing IT rms gain
competitive advantage by squeezing delivery
timelines. IT rms are thus increasingly seeking
ways to become more responsive in their
methodology and requirements.
This paper attempts at highlighting
a modied Requirements Engineering (RE)
technique which when adopted using Agile
methodology can help develop quality
software products faster even while stamping
out problems associated with traditional RE
technique.
OVERVIEW OF RE USING AGILE
Agile software processes provide very efcient
RE in that they narrow the gap between
customers needs and the software product being
developed. The main aspects of Agile are:
On-site and Co-located Customer: This
principle suggests that at least one person from
the customers group physically joins the team





of developers for the predominant part of the
project. She selects and sorts the requirements
to implement and sets priorities by doing so.
Development is therefore driven by business
interests that help dene what is useful to the
customer.

Frequent Short Releases: Frequently releasing
pieces of software product provides the ability
to deliver faster and expected results to the
clients. Also, shorter delivery cycle means
sharper crystallization of clients needs. During
the incipient stages of the project, clients are
usually clueless on the systems requirements.
Short releases help them form a mental map of
how the future system would look like. Also,
each release takes into account the experiences of
previous releases, thus leading to a continuous
improvement in the subsequent releases.
Facilitating Extraction: High level (abstract) and
detailed level (concrete) end-user requirements
can be extracted using Agile.
14
User stories or use-cases form the high level
requirement. Usually clients write user-stories
because they know best about the desired
functionality. Each user-story is written in a
language that enables the customer to prioritize
such stories according to their business value.
One of the rst things one wants to decide on is
how much detail to include in the requirements
artifacts. Table 1 lists factors that may be
considered to decide what level of requirements
should be extracted using Agile.
Table 1: Factors to Consider when Extracting
Requirements using Agile
Source: www.searchsoftwarequality.techtarget.com
Acceptance Test Criteria During RE: Clients
write acceptance tests that are transformed into
unit tests by the developers before any other
development activity. The system has to pass
all acceptance tests on every release. Acceptance
test descriptions are also very suitable as a
contractual base.
The above aspects allow for a lot of
knowledge to be transferred from customer
to developer in a very short time with few
bureaucratic overheads.
AGILE VS. WATERFALL MODEL
Agile methods grew out of the real-life project
experiences of leading software professionals
who had experienced the challenges and
Figure 1: Traditional Model vs. Agile Model
Source: Infosys Research
limitations of traditional Waterfall model on
various projects. By delivering working, tested,
deployable software on an incremental basis,
Agile methodology delivers increased value,
visibility and adaptability much earlier in the
lifecycle, signicantly reducing project risk.
Figure 1 depicts the difference between
traditional model and Agile model. In traditional
Waterfall project, we release version 1 (i.e., RL1)
to meet the business target as shown in Figure
1. But with time the value of that software/
product decreases. This is expected because of
the changing business environment. Thus, the
software is not in sync with the pace of change
as every new release in Waterfall model involves
planning, design, development, testing and
deployment -- a rather time consuming process.
Above all, second and subsequent release(s)
most often fall short of meeting the business
goal or in other words, the gap between business
need and value that the software delivers is not
fully recovered. In most cases, the software fails
to deliver to the business requirements.







15
On the other hand Agile project delivers
quick initial release that may be an interim
release too, when it achieves less value than is
delivered by Waterfall project in its rst release.
This is because a vertical integrated version of
the software is delivered with fewer features.
But in this case, the depreciation between the
second release and the rst is so small that one
is able to provide extra value in the second
release.
Also, client feedback can be incorporated
quickly in subsequent releases to ll up any
further depreciation of the software solution.
The value delivered by Agile project
is therefore expected to be much higher than
the value delivered by Waterfall project over
this whole period of time [see Annexure 1 for
traditional vs. agile evaluation checklist]. The
benets of Agile methodology can be identied
as:
Higher Visibility on Project Progress:
In Agile methodology, measuring and
evaluating the status based on the
working and testing software provides
much more accurate visibility into the
actual progress of projects. In traditional
projects, the visibility is high during the
requirements gathering phase but the
customer remains almost in dark post
the requirements gathering phase till the
implementation.
Higher Adaptability to Changes: In the
course of building business software
requirements, changes are the norm.
A late change in requirement is often a
competitive advantage for the customer.
As one cannot avoid it, the question
is what can one do about it. Waterfall
method is a predictable methodology







and using a predictable process in an
unpredictable environment almost
always leads to trouble.
RE with Agile enables the customer
to include latest changes needed to be
incorporated in the requirement that adds
to the market advantage of the customer.
As a result of the planning and feedback
loop, teams are able to continuously
align the delivered software with desired
business needs, easily adapting to changing
requirements throughout the process.
Lower Overall Risk: Agile methodology
maintains a focus on the rapid delivery of
business benet. As a result of this focus
and its associated benets, organizations
are capable of signicantly reducing the
overall risk associated with software
development.
Effective Requirement Elicitation by
Feedback Method: It is often difcult for
customers to clearly articulate what they
need, in the rst go. At times they are
far from having a complete, concise and
unambiguous model in mind that has to
be transferred to the developer. Seeing and
feeling the running system, in iterations in
Agile, enables the customers to provide
requirements in iterative feedbacks.
GUIDELINES TO IMPROVE RE USING
AGILE METHODOLOGY
Agile focuses very strongly on customer
interaction. However, most of this interaction is
done by prototyping. It is sometimes not possible
to have all the requirements from just one person.
So there is still the need to consider elicitation as a
process to gather requirements from viewpoints
of different business stakeholders.
16
The project using Agile should also learn
from various interviewing techniques that have
been in use in the RE of Waterfall model. The
importance of context-free questions, open
questions and meta-questions is also valid in
an Agile environment. If there are conicts
between stakeholder requirements, the use of
Joint Application Development (JAD) can help
promote the use of a professional facilitator who
can help resolve conicts.
Agile methods rely on the use of validation
(testing), not only as a way of achieving quality
by getting rid of errors, but also as a way of
identifying requirements. Agile processes do not
address aspects of verication and they would
benet if they additionally include verication
together with validation. Simple tools to check
early requirements descriptions associated with
effective management practices for applying
inspections can improve the quality of Agile
processes.
Sometimes, software systems fail to
deliver the intended objective due to the lack of
consideration of non-functional requirements
(NFRs). As Agile considers non-functional
requirements at implementation level, it may
cause some problems. There is a need for Agile
methods to include techniques that make it
possible to identify non-functional requirements
early and describe them in a manner to
indicate that an analysis may happen before
implementation.
Since Agile develops software in small
releases and uses refactoring as a frequent
practice, change is intrinsic to Agile methods.
Agile methods should not rely only on
conguration management practices but also
adapt the requirements management practices
to provide traceability from customers needs to
actual implementation.
In the rst release of the project using


Agile, environment setup should not be mixed
with the actual product development. Even
though rst release is small in Agile, environment
set up should be made ready before the release.
Also, projects using Agile should have similar
detailed project planning for each release like
that of projects using Waterfall model
CONCLUSION
Agile effectively manages requirements and
focuses on generating value for the customer
by reducing irrelevant elements. Therefore, the
involvement of the customer is of paramount
importance to achieve this goal. Also, as
customers give continuous feedback throughout
the lifecycle of the project, any late changes
become easy to incorporate. Agile is a valuable
approach to software development for some
types of projects, but their limits are not well
dened yet. Since these methods are new, the
subject is still evolving and many techniques are
under investigation.
REFERENCES
1. Armin Eberlein and Julio Cesar Sampaio
do Prado Leite, Agile Requirements
Denition: A View from Requirements
Engineering, 2002. Available at http://
www-di.inf.puc-rio.br/~julio/tcre-site/
p4.pdf
2. Martin Fowler, The New Methodology,
2000. Available at http://martinfowler.
com/articles/newMethodology.html
3. Rolf Goetz, How Agile Processes Can
Help in Time-Constrained Requirements
Engineering. Available at http://enel.
ucalgary.ca/tcre02/papers/Goetz.PDF
4. Martin Crisp, Approaches to Dening
Requirements within Agile Teams,
April 2008. Available at http://
searchsoftwarequality.techtarget.com/
17
tip/0,289483,sid92_gci1310960,00.html
5. Simon Baker, User Stories Part 1: What
is a User Story and Who Writes Them?
Available at http://www.think-box.
co.uk/blog/2006/02/user-stories-part-
1-what-is-user-story.html.
ANNEXURE: AGILE VS TRADITIONAL METHOD
Annexure 1 shows the checklist containing list of questions to be answered by various IT
professionals (project managers, business analysts, quality professionals, etc.) to decide whether
to use Agile or traditional methodology.
Section I: Project Type
Tip: Traditional is best suited for projects that plan to execute a full project lifecycle including
analysis, design, development and testing. Projects that have analysis, data, system maintenance,
infrastructure or QES as individual process are not suitable.
Agile is best suited for projects where software products/services need to be launched
within short time.
1. Will this project span
a full development
lifecycle including
analysis, design,
development and
testing?
2. Do any of the
following statements
apply:
a- This project is quality
assurance/control only
(i.e., no development)
b- This project is system
maintenance only
c- This project is analysis
only
d- This project is data
only
e- This project is
infrastructure only
Agile is best suited for projects where
development lifecycle is executed
concurrently with requirement gathering/
analysis in order to have quick smaller
releases, incorporating the feedback on the
product of prior release from stake holders.
Traditional methodology is applicable if
the project is a new or enhanced business
application. It is neither application
maintenance nor an infrastructure project.
Whereas Agile can be applied to similar
projects.
Yes Traditional
Yes Agile
Criteria

Evaluation
Traditional
Points to Consider
or Agile?
18
3. Can the project scope
be fully dened as part of
the current Requirement
gat her i ng/anal ys i s
activity?
4. Is the duration of the
project estimated to be
one year or less?
Are the
requirements expected
to remain stable
throughout the duration
of the project?
5. Is the business
amenable to having the
project developed and
deployed as multiple
releases?
6. Is the business able
to dene and prioritize
The project should be entirely dened
including reason for development, fully
dened scope and well dened goals in
order to apply traditional method. Baselined
requirements should not be expected to
change signicantly.
Agile is suitable when a sponsor
organization does not have a clear
understanding of its business needs initially.
After the rst release is based on initial
requirement, subsequent requirements get
evolved, based on the feedback of end-users,
business and other stakeholders.
Projects longer than one year may experience
more requirements changes than shorter
projects due to regulatory and legal shifts or
other business direction shifts. With traditional
projects that are required to complete all
requirements upfront prior to start, signicant
requirement changes are not auspicable.
Whereas Agile is best suited
for long term projects because one of
the goals of Agile is to embrace changes
in the requirement and make necessary
enhancements on the software to keep pace
with changing business environment.
Sometimes based on the nature of software
product and services, it is imperative to
launch the complete product and services in
one go instead of having multiple releases.
No further enhancement after rst release
is allowed.
Agile is suitable for businesses that are not
clear about their needs initially. Business
No Agile
No Agile
No Agile
No Traditional
Criteria

Evaluation
Traditional
Points to Consider
or Agile?
Section II: Scope and Delivery Approach
19
the Expanded Business
Needs and associated
functional business
requirements?
7. Is it feasible for the
project team to dene
and document all
requirements (high
level and detailed) for
all releases before the
start of design and
development?
needs evolve based on the feedback of the
product after rst release.
Traditional projects are allowed a longer
Requirement gathering phase due to
the fact that phase is accommodating the
requirements for the entire project. Consider
also whether all requirements are presently
known at the detailed level to complete use
cases and functional requirements for all
releases upfront.
No Agile
Criteria

Evaluation
Traditional
Points to Consider
or Agile?
8. Can dedicated and
empowered business
SME(s) be committed
to the Joint Application
Design (JAD) sessions?
9. Can small, core teams
of 7-10 people be used?
Joint Application Design (JAD) is a facilitated
workshop including all the stakeholders,
including users, business experts, business
analysts, architects, application developers,
and deployment personnel. The participants
are empowered to make decisions in the
room without having to involve others who
are not in the JAD session.
Rapid, accurate communication is essential
for a project team to make decisions rapidly
and for producing a solution that meets
business and quality objectives in short time
in Agile. Working in small teams lowers the
number of separate interactions from team
member to team member. Core dedicated
project team members are assigned to only
one project at a time, enabling them to focus
on one assignment for long periods of time
and increasing their productivity.
Tip: Agile is best suited for small and fully dedicated project teams. JAD sessions are recommended
for High and Detailed level requirements discovery. Full commitment to those JAD sessions (average 5
days) is key especially for business resources.
No Traditional
No Traditional
Section III: Team Structure
20
There should not be more than two
designated business stakeholders or an
identied complex stakeholder relationship
involving the business, development,
operations and/or support to apply
Agile. The stakeholder relationship needs
to be collaborative, not confrontational.
For long duration project, when there is a
better chance of staff turnover, it is benecial
to use Agile; as in case of Waterfall, the
new team members may not understand
the original project scope or may have
never been fully integrated when coming
onboard. After a certain period of time
(in Waterfall) in a long project, even the
original team members may have difculty
maintaining a clear view of project goals,
no matter how well they were articulated
at the onset of the project. Benets of using
Agile include increased project awareness
for new team members and restored
condence in the original project concept.
No Agile
Criteria

Evaluation
Traditional
Points to Consider
or Agile?
10. Is there a single,
dened business owner
who has collaborative
relationships with the
other stakeholders?
11. Is there a better
chance of staff
turnover for a long
duration project?
No Traditional
For information on obtaining additional copies, reprinting or translating articles, and all other correspondence,
please contact:
Telephone : 91-80-41173871
Email: SetlabsBriengs@infosys.com
SETLabs 2008, Infosys Technologies Limited.
Infosys acknowledges the proprietary rights of the trademarks and product names of the other
companies mentioned in this issue of SETLabs Briengs. The information provided in this document
is intended for the sole use of the recipient and for educational purposes only. Infosys makes no
express or implied warranties relating to the information contained in this document or to any
derived results obtained by the recipient from the use of the information in the document. Infosys
further does not guarantee the sequence, timeliness, accuracy or completeness of the information and
will not be liable in any way to the recipient for any delays, inaccuracies, errors in, or omissions of,
any of the information or in the transmission thereof, or for any damages arising there from. Opinions
and forecasts constitute our judgment at the time of release and are subject to change without notice.
This document does not contain information provided to us in condence by our clients.
Authors Profile
JOYDIP GHOSHAL
Joydip Ghoshal is a Programmer Analyst at Infosys Technologies Limited. He has an experience on software
development projects for more than 7 years. He has an experience on Business Analysis activities for over 3 years.
He can be contacted at joydip_ghoshal@infosys.com.
MANISH KURHEKAR
Manish Kurhekar is a Programmer Analyst at Infosys Technologies Limited. He has an experience on software
development projects for more than 6 years. He has an experience on Business Analysis activities for close to 3
years. He can be contacted at manish_kurhekar@infosys.com.
SUJOY BOSE
Sujoy Bose is a Project Manager at Infosys Technologies Limited. He has an experience on software development
projects for 8 years. He has an experience on Business Analysis activities for over 4 years. He can be contacted
at sujoy_bose@infosys.com.