You are on page 1of 11

FUNCTIONAL REQUIREMENTS

AND THEIR ROLE IN AGILE DEVELOPMENT

By Chris Grenard

CSC 614 – TERM PAPER

December 15th, 2008

Table of Contents

Abstract......................................................... ......................3

Current Approaches..................................... .........................4

Stakeholders.......................................... ..............................5

Use Cases......................................................................... ....5


Differing Complexities, Differing Requirements......................6

Responses to Changes in Plans/Requirements........................6

Risks of Bypassing Functional Requirements..........................7

Conclusions.................................................... ......................8

Endnotes....................................................... .....................10
Abstract
As modern development teams and systems analysts continue to evolve their

methodologies for gathering requirements and implementing systems it is important to

understand the role of Functional Requirements in the AGILE development process and

how these requirements will be collected, analyzed, and implemented in future products

and projects.

Where traditional Functional Requirements gathering has focused on assessing the

entire scope of the work and product before beginning development, Agile development

begins with just an understanding of the problem to be solved and work begins on

producing a product before all functional requirements are fully discovered. The idea is

that the trawling for requirements process can be done in parallel with development in

order to shorten release times for products and/or components.

The Agile approach to Requirements Gathering is very different from

traditional Requirements Gathering: “The way agile teams develop an

understanding of system requirements is radically different. The

primary artifacts are executable code and tests. Agile teams explore

requirements by talking with business people and then developing

software for their business customer to try out, in short cycles of weeks

(not months or years).” 1

Recent studies have indicated that although the work of collecting Functional

Requirements and Analysis of these requirements still occur, there is a significant trend

towards blending together different methodologies and techniques to create the right
product, as noted in a 2006 study2, which compiled data on which methodologies were

used most often in practice.

Current Approaches
In the current analysis development environment, a recent survey by Batra and

Satzinger3 states that “…of methodologies used in organizations for developing web-

based systems shows that the notion of methodology in the traditional systematic sense

seems to have been largely displaced by hybrid aggregations of techniques and other

method fragments…The survey reported that the use of methods is 23% for hybrid, 22%

for structured, 15% for Agile, 14% Tools, 13% for iterative/incremental, and 8% for

object-oriented”.

The use of techniques for analyzing requirements in this same study showed a 92%

adoption rate for Screen prototypes/Mockups, 95% for Flowcharts, 91% for 2-D site

mapping techniques, 85% for storyboards, 74% for Entity-Relationship diagrams, and

72% for Use-Case Diagrams/Scenarios, followed by 62%, 52%, 50% for Object Oriented

Class Diagrams, 3-D site mapping techniques an State Charts/State Diagrams,

respectively.

The results shown for the surveys above indicate there are no absolutes in terms of

modern Functional Requirements gathering and analysis. The Hybrid method seems to

best represent how current teams are performing their work.

A one-size fits all approach is no longer the norm, many tools are needed, many

different stakeholders are involved, and the requirements are sometimes too complex and

too lengthy to fully document and understand using a single methodology without

considering other alternatives for eliciting and implementing requirements in the final

product.
Stakeholders
The number stakeholders in today’s project typically exceed those of past projects, as

information systems have become more intertwined with the experiences of most workers

today. Where past projects looked no further than the boundaries of the company’s core

business processes, today’s projects seek to integrate the views and desires of external

actors who must interact with systems as much as they seek to provide the right solutions

to internal stakeholders.

Use Cases
Use cases remain an essential tool in the analyst’s toolbox. They help the analyst to

understand the process being analyzed in a graphical and simple way as well as convey to

the business stakeholder that their requirements are understood and conveyed back to

them in a simple and clear manner.

The level of detail in the initial use cases will not be as detailed as the use cases are

further defined and documented. This aspect of the Agile development process is where I

begin to see negative issues with the rapid pace of development before all of the

requirements are fully understood. What if a programmer was given a use-case that says

that “only internal users have access to product pricing”? Then the analyst gives this

requirement to the programmer to implement, which the programmer dutifully does.

Now, the analyst speaks to the Marketing liaison to the IT group and learns that there has

been a mailing sent out informing select customers that it has decided to post pricing on

the company’s website, after the customer signs in with a special code. Now that the

analyst has learned this new piece of important information he must modify his use-case

diagram and go back to the programming team to inform them of the change. Now new
methods must be written, security procedures identified and implemented, and access to

the website must be made available for product price data. If all of this information had

been known to the analyst before the project implementation began, there may have been

considerable time saved if the programming team knew that internal and external

customers would need access to the company’s pricing data.

Differing Complexities, Differing Requirements

When considering which methodologies and techniques to use to create the Functional

Requirements for a project, the complexity of the project being considered must be

factored into the decision about how to go about the Requirements gathering process.

Interviews will still be conducted with relevant stakeholders, use-cases will be created,

and Functional Requirements will be written. It is the level of detail needed to capture the

business process that determines its complexity. For extremely complex projects, the

Agile method must fully document all requirements in advance of application

development.
Responses to Changes in Plans/Requirements

The Agile method is well suited to accommodating rapidly changing requirements.

Because less time is spent on producing documentation and more time is spent

programming the opportunity to respond quickly to change exists, as the requirements are

recognized as being fluid and subject to change. In my opinion, for projects intended for

rapid-release this approach will most likely produce a timely and satisfactory solution.

For projects with longer release cycles and more complexity, the introduction of radical

change in design or requirements will cause delays when the additional functionality has

to be added in places where it may have never been envisioned being used.

As an answer to the risk of additional complexity, Adrian Marchis argues that: “In

complex products, a good approach is to exploit one of Agile’s greatest strengths: the

imperative to reduce risk and increase learning as soon as possible. By building a small

slice of the product and getting feedback on it immediately, teams quickly and

inexpensively expose technical unknowns, while customers discover and explore true

needs (requirements). “4
Risks of Bypassing Functional Requirements

Back to the example of building a house without a blueprint, no software project

should begin in earnest until the problem domain is understood, the project boundaries

are clear, and specifications, at least an initial set, are written.

“Programmers and software engineers who dive into code without writing a spec tend

to think they're cool gunslingers, shooting from the hip. They're not. They are terribly

unproductive. They write bad code and produce shoddy software, and they threaten their

projects by taking giant risks which are completely uncalled for.”5

I agree with the author on this point, because a programmer can only build what s/he

conceives the end product (or result) to be. If there is incomplete information they waste

time by dedicating resources to solving the wrong problem or trying to solve a problem

that is not completely defined.

Conclusions

When we examine what exactly Functional Requirements are supposed to provide,

which is a product that performs the tasks the user expects the product to perform and

does so without hindering the ability of the user to perform any other tasks essential to

their work using the product. Systems that do not meet the Functional Requirements are

failures – a waste of time and resources that could have been used to create the right

product the first time.


The future of application development will continue to rely on requirements and

analysis in order to understand the problem that needs to be solved. The methods and

techniques used to elicit these requirements will most likely continue to evolve, and a

mixed/hybrid approach to requirements gathering and analysis will provide programming

teams and database administrators the correct information to build the right system.
Endnotes
1Rachel Davies, “Agile Requirements”, Methods and Tools, ISSN 1661-402X, Fall 2005, (Volume 13
–number 3)

2Lang, M. “New Branches, Old Roots: A Study of Methods and Techniques in Web/Hypermedia
Design”, Information Systems Management 2006

3Dinesh Batra, Florida International University, John W. Satzinger, Missouri State University,
“Contemporary Approaches and Techniques for the Systems Analyst”, Journal of Information
Systems Education, Vol. 17(3), pp. 258

4Adrian Marchis, “Agile Requirements, In Context”, ModernAnalyst.com,

http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/430/A
gile-Requirements-in-Context.aspx, June 2008

5Joel Spolsky, “Painless Functional Specifications”, ModernAnalyst.com,

http://www.joelonsoftware.com/articles/fog0000000036.htm, October 2000