IJCA Special Issue on “Computational Science - New Dimensions & Perspectives”

NCCSE, 2011

Requirement Gathering for small Projects using Agile

Methods

Kavitha C.R Sunitha Mary Thomas

Dept of Computer Applications
Dept of Computer Applications
SNGIST
Christ Knowledge City
N Parur
Airapuram

ABSTRACT Agile Methods

Gathering, understanding and managing requirements is a key The agile methodologies are also known as the lightweight
factor to the success of a software development effort. methodologies. These methodologies consist of development
Requirement engineering is a critical task in all development techniques designed to deliver products on time, on budget, and
methods including the agile development method. with high quality and customer satisfaction. There are different
There are several requirement techniques available for agile methodologies available today. The most popular flavours
requirement gathering which can be used with agile development include:
methods. These techniques concentrates on a continuous Extreme Programming (XP)
interaction with the customer to address the evolution of Adaptive Software Development (ASD)
requirements, changing requirements, prioritizing requirements Dynamic Systems Development Method (DSDM)
and delivers the most important functionalities first. Feature Driven Development (FDD)
Scrum
This article presents an overview of agile software development The Agile Manifesto
methods and a best requirement elicitation technique used for The Agile Manifesto is a statement of the principles that
requirement capturing. We present an application case of underpin agile software development. It was drafted from 11 to
requirement gathering process by using User stories for web- 13 February 2001, at The Lodge at the Snowbird ski resort in the
based, cost-effective and efficient software (ISODTA- ISO Wasatch Range of mountains in Utah, where representatives of
documentation teaching automation) which automates the ISO various new methodologies (such as Extreme Programming,
documentation of teaching process at the institution SNGIST Scrum, DSDM, Adaptive Software Development, Crystal,
using SCRUM, an agile software development methodology. Feature Driven Development, and Pragmatic programming) met
to discuss the need for lighter alternatives to the traditional
Keywords heavyweight methodologies.
Agile methodologies, Scrum, requirement elicitation, user ―We are uncovering better ways of developing software by doing
stories, story index card it and helping others do it. Through this work we have come to
value:
1. INTRODUCTION
Individuals and interactions over processes and tools
Agile development methodology is an approach used in
software development which has become more popular during
Working software over comprehensive documentation
the last few years. Agile software development is iterative and
incremental development where you do development in small
Customer collaboration over contract negotiation
iterations. It attempts to provide many opportunities to assess the
different stages of a project throughout the software development
Responding to change over following a plan
life cycle. These methods aim to deliver software faster and
ensure that the software meets customer’s changing needs and That is, while there is value in the items on the right, we value
expectations. Agile methodologies focus on skills, the items on the left more‖.
communication and community clarifying the roles of customers,
managers and developers for more satisfying and productive
relationship.

122
 IJCA Special Issue on “Computational Science - New Dimensions & Perspectives”
NCCSE, 2011

Agile Methods (AMs) Vs Traditional Methods (TMs). - empowers your developers to confidently respond to
changing customer requirements, even late in the life cycle
TABLE 1. AMS VS TMS
- emphasizes teamwork. Managers, customers, and
Traditional Agile Methodologies developers are all equal partners in a collaborative team
Methodologies(TMs) (AMs) - solve the problem efficiently
- follow simple rules
Focused on processes, Focused on people
sequence of processes XP improves a software project in five essential ways;
and useful tools communication, simplicity, feedback, respect, and courage.
Extreme Programmers constantly communicate with their
Flexible only in the Emphasizes the customers and fellow programmers. They keep their design
beginning of project communication, simple and clean. They get feedback by testing their software
collaboration, rapid starting on day one. They deliver the system to the customers
exchange of as early as possible and implement changes as suggested.
information, team work
and the functioning
software and flexibility 2.2.2 Core Practices
Help deliver projects on Uncertain budgets and There are twelve core practices that define Extreme
time and budget but not unclear milestones Programming. The practices can be described as a cycle of
suitable when you are activities. The inner circle describes the tight cycle of the
moving to a new Programmers. The outer loop describes the planning cycle
technology or for that occurs between the Customers and Programmers. The
changing requirements middle loop shows practices that help the team communicate
and coordinate the delivery of quality software.
Use single model (like Involves a lot of
waterfall model) different methods that
work in a similar way.

2. AGILE SOFTWARE DEVELOPMENT

AND REQUIREMENT HANDLING
2.1 Introduction
Agile development works in a different manner. Instead of
specifying everything before you start developing, one need to
take a small portion of the most important features and only
specify and implement those. Requirement gathering is different
for different methods, for. E.g. in SCRUM & XP, user stories are
used. Requirement specification is an iterative process that
continues until the customer is satisfied with the product. By
using this method, it is easier to react to changes and can have a
Figure 1. XP Practices and the Circle of Life from [8]
better estimate and better control on the development leading to
a better quality product and customer satisfaction.
Since Agile development is a fairly new technique there is 2.3 Adaptive Software Development (ASD)
no good answers on how to handle requirements and researches
are being undertaken in this area. Adaptive Software Development (ASD) was developed in 2000
by Jim Highsmith which has grown out of the Rapid Application
2.2 Extreme Programming Development (RAD). Like other agile methodologies, ASD aims
to increase a software organization’s responsiveness while
Extreme Programming abbreviated as XP, was invented by
decreasing development overhead. It embodies the belief that
Kent Beck which addresses the specific needs of software
continuous adaptation of the process to the work at hand is the
development conducted by small teams in the face of vague
normal state of affairs.
or changing requirements
ASD replaces the traditional waterfall cycle with a repeating
2.2.1 Advantages of XP: series of speculate, collaborate, and learn cycles. This dynamic
cycle provides for continuous learning and adaptation to the
- it stresses customer satisfaction emergent state of the project. The characteristics of an ASD life

123
 IJCA Special Issue on “Computational Science - New Dimensions & Perspectives”
NCCSE, 2011

cycle are that it is mission focused, feature based, iterative, time 2.4.3.1 Stage1A: The Feasibility Study, where the feasibility
boxed, risk driven, and change tolerant. of the project for the use of DSDM is examined.

The word ―speculate‖ refers to the paradox of planning – it is Stage1B: The Business Study, which examines the influenced
more likely to assume that all stakeholders are comparably wrong business processes, user groups involved and their respective
for certain aspects of the project’s mission, while trying to define needs and wishes.
it. Collaboration refers to the efforts for balancing the work
based on predictable parts of the environment (planning and 2.4.3.2 Stage2: Functional Model Iteration, where the
guiding them) and adapting to the uncertain surrounding mix of requirements that have been identified in the previous stages are
changes caused by various factors – technology, requirements, converted to a functional model.
stakeholders, software vendors, etc. The learning cycles,
challenging all stakeholders, are based on the short iterations 2.4.3.3 Stage3: Design and Build Iteration, integrates he
with design, build and testing. During these iterations the functional components from the previous phase into one system
knowledge is gathered by making small mistakes based on false that satisfies user needs.
assumptions and correcting those mistakes, thus leading to 2.4.3.4 Stage4: Implementation, where the tested system
greater experience and eventually mastery in the problem including user documentation is delivered to the users and
domain. training of future users is realized.
2.4 Dynamic Systems Development Method
(DSDM)
2.4.1 Introduction
Dynamic Systems Development Method (DSDM) developed in
the United Kingdom in the 1990s by the DSDM Consortium, an
association of vendors and experts in the field of software
engineering created with the objective of "jointly developing and
promoting an independent RAD framework" by combining their
best practice experiences. It is a software development
methodology originally based upon the Rapid Application
Development methodology. DSDM is an iterative and
incremental approach that emphasizes continuous user Figure 2. Project Life Cycle from [9]
involvement.

Its goal is to deliver software systems on time and on budget

2.5 Feature Driven Development (FDD)
while adjusting for changing requirements along the development 2.5.1 Introduction
process. Feature Driven Development (FDD) was initially developed by
Jeff De Luca, which is an iterative and incremental software
2.4.2 Phases of DSDM development process. FDD blends a number of industry-
recognized best practices into a cohesive whole. These practices
The DSDM framework consists of three sequential phases: are all driven from a client-valued functionality (feature)
perspective. Its main purpose is to deliver tangible, working
Phase 1 - The Pre-Project phase where candidate projects are software repeatedly in a timely manner.
identified, project funding is realized and project commitment is
2.5.2 Best practices
ensured.
Feature-Driven Development is built around a core set of
Phase 2 - The Project life-cycle phase include five stages to industry-recognized best practices, derived from software
create an information system. engineering. These practices are all driven from a client-valued
feature perspective. It is the combination of these practices and
Phase 3 - Post-project phase ensures the system operating techniques that makes FDD so compelling. The best practices
effectively and efficiently. that make up FDD are shortly described below.

Domain Object Modeling, explores and explains the domain

of the problem to be solved. The resulting domain object
2.4.3 Four stages of the Project life-cycle
model provides an overall framework in which to add
features.

Developing by Feature. Any function that is too complex to

be implemented within two weeks is further decomposed into
smaller functions until each sub-problem is small enough to

124
 IJCA Special Issue on “Computational Science - New Dimensions & Perspectives”
NCCSE, 2011

be called a feature. This makes it easier to deliver correct The Scrum methodology really works is due to a set of roles,
functions and to extend or modify the system. responsibilities, and meetings that never change. If Scrum’s
capacity for adaption and flexibility makes it an appealing
Individual Class (Code) Ownership. It means that distinct option, the stability of its practices give teams something to lean
pieces or grouping of code are assigned to a single owner who on when development gets chaotic.
is responsible for the consistency, performance, and
conceptual integrity of the class. 2.6.3 The Roles of Scrum
Scrum has three fundamental roles: Product Owner,
Feature Teams. It is a small, dynamically formed team that ScrumMaster, and team member.
develops a small activity. By doing so, multiple minds are
always applied to each design decision and also multiple Product Owner: In Scrum, the Product Owner is responsible
design options are always evaluated before one is chosen. for communicating the vision of the product to the
development team. He or she must also represent the
Inspections. Inspections are carried out to ensure good customer’s interests through requirements and prioritization.
quality design and code, primarily by detection of defects. Because the Product Owner has the most authority of the three
roles and also has the greatest responsibility. In other words,
Configuration Management. It helps with identifying the the Product Owner is the single individual who must face the
source code for all features that have been completed to date trouble when a project goes awry and also must answer
and to maintain a history of changes to classes as feature questions from the team.
teams enhance them.
ScrumMaster: The ScrumMaster acts as a liaison between
Regular Builds. It ensures there is always an up to date the Product Owner and the team. The ScrumMaster does not
system that can be demonstrated to the client and helps manage the team. Instead, he or she works to remove any
highlighting integration errors of source code for the features impediments that are obstructing the team from achieving its
early. sprint goals. Scrummaster helps the team to remain creative
and productive and makes sure of its successes visible to the
Visibility of progress and results. By frequent, appropriate, Product Owner. The ScrumMaster also works to advise the
and accurate progress reporting at all levels inside and Product Owner about how to maximize return over investment
outside the project, based on completed work, managers are for the team.
helped at steering a project well.
Team Member: In the Scrum methodology, the team is
2.6 Scrum responsible for completing work. Ideally, teams consist of
2.6.1 Introduction seven cross-functional members, plus or minus two
individuals. For software projects, a typical team includes a
Scrum is an agile approach to software development. It has been
mix of software engineers, architects, programmers, analysts,
found out that Scrum is very beneficial when applied to small
Quality Assurance experts, testers, and User Interface
and medium projects. Rather than a full process or methodology,
designers. Each sprint, the team is responsible for
it is a framework which instead of providing complete, detailed
determining how it will accomplish the work to be
descriptions of how everything is to be done on the project, much
completed. This grants teams a great deal of autonomy, but,
is left up to the team, because the team will know best how to
solve its problem. For e.g., in a sprint planning meeting is similar to the Product Owner’s situation, that freedom is
accompanied by a responsibility to meet the goals of the
described in terms of the desired outcome (a commitment to set
sprint.
of features to be developed in the next sprint. Scrum relies on a
self-organizing, cross-functional team. There is no team leader in
Scrum projects make progress in a series of sprints, which are
a scrum team who decides which person will do which task or
time boxed iterations no more than a month long. At the start of a
how a problem will be solved.
sprint, team members commit to delivering some number of
2.6.2 Unique about Scrum features that were listed on the project’s product backlog. At the
end of the sprint, these features are done--they are coded, tested,
Of all the agile methodologies, Scrum is unique because it and integrated into the evolving product or system. At the end of
introduced the idea of ―empirical process control.‖ That is, the sprint a sprint review is conducted during which the team
Scrum uses the real-world progress of a project — not a best demonstrates the new functionality to the product owner and
guess or uninformed forecast — to plan and schedule releases. In other interested stakeholders who provide feedback that could
Scrum, projects are divided into succinct work cadences, known influence the next sprint.
as sprints, which are typically one week, two weeks, or three
weeks in duration. At the end of each sprint, stakeholders and
team members meet to assess the progress of a project and plan
its next steps. This allows a project’s direction to be adjusted or
reoriented based on completed work, not speculation or
predictions.

125
 IJCA Special Issue on “Computational Science - New Dimensions & Perspectives”
NCCSE, 2011

3. USER STORIES
3.1 Introduction
User stories are used in agile software development
methodologies like XP and Scrum. A user story is a very high-
level definition of a requirement, containing just enough
information so that the developers can produce a reasonable
estimate of the effort to implement it. It describes all those
functionalities that are valuable to a stakeholder. It is a reminder
to have a conversation with the customer. In short, user stories
are very slim and high-level requirements artefacts. It shifts the
Figure 3. Scrum Process from [10] focus from writing to talking. It supports and encourages iterative
development.
In agile software development methodology, there will be a
―potentially shippable product increment" at the end of each The basic components of a User Story includes
iteration/sprint. During each iteration, the Scrum Master
(SM) should ensure that the work the team committed to do Cards (physical medium)
during that sprint is what the team actually delivers.
Conversation (discussion surrounding stories)
The SM should ensure that the team understands the
user stories and provides accurate estimates. Confirmation (tests and validation that verify story
completion).
Once the team commits to a unit of work (and is in a
sprint), the SM should make sure that the team is User stories are often written on 3’’X 5’’ index cards which
focused only on the user stories that are within the are very easy to work with. Simple index cards can be used
current sprint. to write the user stories and a small index card box can be
used to store these cards arranged by priority. One has to try
During the sprint, the SM should also ensure that the to keep the user stories short and to the point. During the
team is focused on the sprint work (and only the sprint sprint planning sessions, cards can be re-prioritized if
work). He/she should eliminate any impediments that needed.
might be blocking the team’s progress.
Project Name: Story Card ID:
The SM should maintain the task burndown chart and
story burnup charts, along with the team’s velocity
calculations.

2.6.4 Requirement Gathering in SCRUM

Priority: Estimation:
In Scrum, user stories can be used to capture a project’s ever
changing requirements. Because project needs fluctuate, Scrum Front side of the index card
doesn’t consider requirements gathering to be a one-time task.
Instead, Scrum focuses on the incremental unfolding of
requirements. The work is decomposed and captured at different
Acceptance Test:
levels in varying levels of detail during the project. At each level,
the work is broken down into smaller, more manageable pieces
1. ………….
of work.
2. …………
Product backlog (PB): High-level capabilities and features are 3. ………..
captured as user stories. The PB is the repository of all the work
that needs to happen during the project.
Back Side of the index card
Sprint backlog: The team identifies the user stories that will be
worked on during the current iteration, or sprint. Each user story
is decomposed further into tasks. Figure: 4, Story Index Card

User stories should be validation-centric. The team needs to

identify and write down the validation conditions for each
user story. The story should not be closed until these
validation conditions are met satisfactorily.

126
 IJCA Special Issue on “Computational Science - New Dimensions & Perspectives”
NCCSE, 2011

3.2 INVEST Model In this project of requirements gathering, since the customers are
present onsite, user stories has been used for requirement
A well-written user story follows the INVEST model. . A user gathering on story cards. Like in XP, user stories can be applied
story should be: in SCRUM to capture requirements. SCRUM treats the
requirements like a prioritized task. It freezes the requirements
Independent: A good story should stand on its own. for the current iteration to provide a level of stability for the
A good story is negotiable. It is not an explicit developers. In Scrum, work is expressed in the backlog as user
contract for features; rather, details are co-created stories. User stories document requirements with particular
Negotiable: by the customer and programmer during attention to the end user’s point of view. By using user stories,
development. A good story captures the essence, one would be able to focus on exactly what the user need/want
not the details. without going into details on how this should be done. A team
may write its user stories in a number of ways as long as they are
Valuable: A user story should be valuable to the business. written from the perspective of the end user.
The team should be able to gauge the size of a User stories generally follow the following template:
Estimable:
story. As a … (role or actor) (Who)
A good rule of thumb is that a user story should not I want … (what capability or feature do they need) (What)
Small:
be more than eight to sixteen hours of effort.
so that … (why is it of business value or benefit) (Why)
Testable: The story should include validation criteria.

Well-written User Stories are cornerstones for Agile "As a type of user I want capability or feature so that business
Development. They should be independent of each other; the value or benefit”
details should be negotiated between the users and the
developers; the stories should be of value to the users; they
should be clear enough for developers to be able to estimate The ―Who‖ and ―What‖ are essential to the story, but the ―Why‖
them; they should be small; and they should be testable through only helps with clarity and sets up the acceptance test.
the use of pre-defined test cases.When writing individual,
detailed tasks under each user story, teams should focus on
writing SMART tasks. 4.2 Applying User Stories in the Case Study
Stories help you ask the right questions about the context and
Specific reason for the request from the prospective of the person
Measurable requesting the feature.
Achievable
Relevant Here are some examples of User Stories for the web based
ISODTA software:
Time-boxed
• As a new faculty to SNGIST, I want to register myself to get a
4. OUR CASE STUDY username and password so that I can use ISODTA.
4.1 Introduction • As a faculty, I want to select the names of the students from the
database so that I can make them as a batch of some particular
ISO 9000 provides a framework that can be used by any size or class which I am going to handle.
type of organization to develop a quality system. Today, ISO
9000 standards are rapidly being implemented in many service • As a faculty, I want to mark the attendance of the students of
industries such as educational institutions in particular. Benefits my class so that I can calculate the monthly attendance and
from implementing ISO 9000 standards can be divided into four monthly attendance percentage
different parts as benefits to system, faculty, students and • As a faculty, I want to enter the marks of series exam, model
external benefits to the organizations. Today, customers expect exam, assignments, presentations, project and seminar of the
quality in all aspects of life. The customer wants to be assured students so that I can calculate the internal marks of the students.
that educational institutions provide quality service. This is an
• As a faculty, I want to prepare the lesson plan so that the course
era of competition and globalization of knowledge much
can be completed within the stipulated time.
importance is given to the quality. As a result educational
institutions have started implementing ISO. • As a faculty, I want to record the shortfall topics so that I can
take the corrective action.
Quality and accountability in higher education are inevitably
going to be the principal themes in the higher education policy. • As a faculty, I want to generate reports on the absentees so that
The objective of ISO documentation is mainly to provide the I can take suitable actions.
service continuously as before even though the Institution decides • As a faculty, I want to record the details of the assignment,
to replace personnel all together. The control of documentation is seminars, case study, group discussion etc.
the critical element to retain the ISO registration. So, good
customized software is required to do the documentation process • As a faculty, I want to conduct the result analysis of internal
efficiently and effectively. examination so that I can find out the performance of the class.

127
 IJCA Special Issue on “Computational Science - New Dimensions & Perspectives”
NCCSE, 2011

• As a faculty, I want to analyze the University exam result so 5. CONCLUSION

that I can get an idea about the results of my subject for a few
years. Developing software that meets the customers or stakeholders’
needs and expectation is the ultimate goal of the software
• As a faculty, I want to mark the subject hours in the time table. development methodology. To meet their need we have to
• As a batch coordinator, I want to prepare the time table for my perform requirement engineering which helps to identify and
class. structure requirements. In many cases it is risky or very difficult
and not economical to produce a complete, verifiable set of
• As a batch coordinator, I want to prepare the test plan so that
requirements. Traditional software development has a problem to
all the exams can be planned and conducted within schedule. deal with requirement change after careful analysis and
 As a batch coordinator, I want to prepare the weekly report so negotiation.
that shortfalls of different subjects can be found out
Generally customers have rarely a general picture of the
 As a batch coordinator, I want to prepare the monthly
requirements or system in their mind which leads problems
attendance statement so that attendance shortage of students can
related to requirements like requirements conflicts, missing
be traced for each subject.
requirements, and ambiguous requirements etc, and does not
 As a batch coordinator, I want to prepare the series exam and
address non-functional requirements from exploration phase.
model exam marks statement.
This problem is well tackled by SCRUM as SCRUM
recommends an on-site customer to represents their requirements
through user stories on story cards. Scrum places a high value on
4.3 Acceptance Test/Criteria for User Stories customer interaction and satisfaction. User stories, which are
As a vital part of the planning our project, user stories define concise often, dwelling within the boundaries of the index card,
what we are going to build in our project. User stories are are considered the best method for explaining requirements when
prioritized to indicate which are most important for the system using the scrum approach.
and are broken down into software engineering tasks and
estimated by the development team. When we implement a user 6. REFERENCES
story a more formal acceptance test will be written to ensure that [1] Pressman, R. S. (2005), Software Engineering: A
the goals of the story are fulfilled. Acceptance tests are created
Practitioner’s Approach, Sixth Edition, McGraw-Hill
from user stories.
International Edition.
Acceptance criteria are specified indicators or measures
[2] Alford M. W, A requirements engineering methodology for
employed in assessing the ability of a component, structure or
realtime process requirement, IEEE transactions on software
system to perform its intended function. They are the
engineering volume 3
expectations of the product owner on what will be delivered.
Acceptance criteria can include functionality that the system will [3] Cohn, M (2009), Succeeding with Agile: Software
perform, interface look and feel and necessary documentation. Development using Scrum

These are high-level tests to test the completeness of a user story [4] Cohn, M (2003) User stories applied for Agile Software
or stories 'played' during any sprint/iteration. These tests are Development 2003 Addison-Wesley
created ideally through collaboration between business [5] The agile manifesto http://WWW.agilemanifesto.org/ (cited
customers, business analysts, testers and developers; however the 2010-07-21)
business customers (product owners) are the primary owners of
[6] Extreme Programming- a gentle introduction
these tests. As the user stories pass their acceptance criteria, the
http://WWW.extremeprogramming.or/ (cited 2010-08-03)
business owners can be sure of the fact that the developers are
progressing in the right direction about how the application was [7] Kishore S, Naik R, Software Requirements and Estimation
envisaged to work and so it's essential that these tests include
[8] http://gannman.x10hosting.com/Portfolio/ExtremeProg.pdf
both business logic tests as well as User Interface validation
(cited 2010-09-11)
elements (if need be).
[9] http://en.wikipedia.org/wiki/DSDM (cited 2010-09-23)
Acceptance test cards are ideally created during sprint planning
[10] http://en.wikipedia.org/wiki/Scrum_(development) (cited
or iteration planning meeting, before development begins so that
2010-09-24)
the developers have a clear idea of what to develop.
[11] http://en.wikipedia.org/wiki/INVEST_(mnemonic) (cited
During iteration the user stories selected during the iteration
2010-10-12)
planning meeting will be translated into acceptance tests. A story
can have one or many acceptance tests, whatever it takes to [13] Scrum (development) http://en.wikipedia.org/wiki/
ensure the functionality works 100%. Each acceptance test Scrum_%28development%29 (cited 2010-09-11).
represents some expected result from the system. We must verify
the correctness of the acceptance tests and reviewing test scores
to decide which failed tests are of highest priority. A user story is
not considered complete until it has passed its acceptance tests.

128