A Matter Of Requirement

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 you to failure. The hardest part of
building a software system is deciding precisely what to build. Today, many
organizations recognize the fact that for an organization to carry out software
development effectively, it must understand what is to be built. Thus,
requirements management becomes an integral part of any product lifecycle.

Goals in Sight

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. 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.

To date, most organizations have a casual approach to
requirements engineering. 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.

In terms of cost-savings, organizations 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 such as 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.

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

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 stakeholders 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 the users can request
excessively complex systems. These requirement problems might slow the pace of
software development.

A requirements management tool that stores information in a
multi-user database provides a robust solution to these restrictions. These
tools let 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.

Requirements gathering and managing are critical factors in
the success of a software development project. 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, country manager,

Serena Software India