Requirement-Driven Application Lifecycle

They form the basis of the initial estimates and
plans; they also form the basis on which any software product is built and
validated.

It has been said that if you don't know where you are going, any road will
get you there. This optimistic perspective on life has a devastating impact on
many software projects.

In the software realm 'not knowing where you are going' can lead to
failure. But at the same time, the hardest part of building a software system is
deciding precisely what to build.

Today, several solution providers are getting into software development for
deploying these applications on their client's backend. But they often work in
a very ad-hoc manner.

Quite
a few of them recognize the fact that to carry out their software development
effectively, they must understand what is to be built. And this is where
requirement-driven application creation and management comes into play. This is
a pertinent part of any product lifecycle.

Building the foundation

Requirements are the foundation for all subsequent software development and
project management activities. They form the basis of the initial estimates and
plans; they also form the basis on which any software product is built and
validated.

The goal of requirements development is to deduce, capture, and agree upon a
set of functional requirements and product characteristics that will achieve the
stated business objectives. Requirements management is an often underutilized
discipline in software development.

Unfortunately, poorly defined and misunderstood requirements continue to
cause projects problems. Nevertheless, many solution providers still practice
ineffective methods for this essential project activity. The typical outcome is
an expectation gap - a difference between what developers think they are
supposed to build and what customers really need.

Many software problems arise from shortcomings in the ways that people
acquire, document, agree on, and modify the product's requirements. Typical
problem areas include informal information gathering, implied functionality,
inadequately defined requirements, and a casual change process.

Get serious about it

To date most organizations have a casual approach to requirements
engineering. Year after year, lack of user input, incomplete requirements, and
changing requirements are the major reasons why so many information technology
projects fail to deliver all of their planned functionality on schedule and
within budget.

Good requirements processes ensure that the functionality built enables users
to perform essential business tasks. Well-specified requirements also define
achievable quality expectations, letting the team implement both the
capabilities and the characteristics that will make the users happy. It is
frustrating for any development team to release a product only to find that
essential functionality is missing and that other capabilities are included
which are not likely to be used.

In terms of cost-savings, solution providers must realize that it costs far
more to correct a defect that is found later in the project in comparison to
fixing it shortly after it was created. Organizations always find the time,
money, and resources needed to fix a flawed product. But if more time is spent
on requirements engineering in the early stages of a project, it not only
reduces the error margin, but has other benefits like lowered development costs,
faster development and better products that delight customers.

Though typical projects spend perhaps 10% of their effort on requirements,
one thing that needs to be understood at this point is that requirements
management should not only be restricted to the initial phase of product
development but should be threaded throughout the entire project lifecycle.

Allocation of resources

Not all of the requirements development effort should be allocated to the
beginning of the project. Requirements will change because initial elicitation
activities are imperfect, because business needs evolve, and because customer
expectations change once they see the product beginning to take shape. Therefore
the heart of requirements management is dealing with requirements changes.

Developing and managing requirements is not an easy task. One of the biggest
problems with requirements is ambiguity. Ambiguity results when a requirement
can be interpreted in multiple ways.

Tools and activities that let end-users compare their understanding of the
requirements can reveal these ambiguities. Developers might add unnecessary
features they think the users will like.

At the same time, even users can request excessively complex systems. These
requirement problems might slow the pace of software development.

The traditional requirements approach is to create documents that contain
business, user, functional, and nonfunctional requirements written in natural
language, preferably using the organization's standard templates. But this
approach has its own limitations.

Simple tasks like keeping the documents updated and synchronized, tracking
the status of individual requirements, communicating changes to all affected
team members, tracking rejected requirements, becomes a real cumbersome process.

Creating a robust solution

A requirements management tool that stores information in a multi-user
database provides a robust solution to these restrictions. This tools lets users
create various classes of requirements information and define unique sets of
attribute values for each requirement class. Users can import requirements from
source documents, filter and display the database contents, and export
requirements in various formats.

Connecting the requirements into product lifecycle processes creates a
proactive requirements environment that allows you to avoid problems and make
better product decisions. Beyond the product development teams, connected
requirements help other participants in the product lifecycle answer the
critical questions that can take weeks or months to answer.

In conclusion, requirements gathering and managing are critical factors in
the success of a software development project. For a globally dispersed team, it
becomes even more complex since requirements need to be gathered from the client
and translated to all the teams, taking into account cultural, linguistic and
contextual differences between them.

It is also crucial to establish a standard requirement management process so
that every fragment of the development team works within the scope of the
project, strictly adhering to the stated requirements. Getting the requirements
right will pave the way for successful performance in the development, analysis
and implementation stages of the software application lifecycle.

Keshav Prakash is Country Manager of Serena Software India