How Harmful can be Ambiguous Software Requirements

Software Project managers have realized that ambiguity in software requirements can
create greater harm than ambiguity or defects in any other stage of software
development. Yet, unfortunately, most software projects, still fail to understand the
importance of validating requirement specifications, thanks to the pressure of releasing
products faster to the market. What is overlooked often creates ambiguity and thus has
far-flung implications as the development cycle kick starts. The irony is, even when we
know the perils of not doing something, we consciously ignore it, hoping everything
should go fine.

Let us understand why ambiguity creeps into requirements. First, business users create
requirements they define the requirements from the user perspective and how they
want the system to finally behave. They are unaware of the technology details on how
this ideal system is to be developed. System analysts & architects transform these
requirements into technical requirements. Development teams work on this version and
QA validates the application to ensure business requirements are met. This all sounds
fine but ambiguity creeps in when perception of the requirements at each stage is not
thoroughly checked. Ambiguity results from unclear or incomplete/inadequate critical
information in the requirements or in their interpretation. Discovered later in the

http://gallop.net/

development cycle, this spirals into a vicious cycle of defects, delays and more defects
and further delays, finally hurting the project budget, timelines and often translates to
going live with a half-baked first version of the product with limited functionality,
limiting the business advantages further. Research reveals, it is 100 times more costly to
fix a defect in UAT/Production than during the requirements stage.

There might be ambiguity with respect to boundary conditions, negative requirements,

abbreviations, functionalities, and/or many more. Elimination of ambiguities is the first
step towards driving a testable requirement through a review process which is known as
ambiguity review. The practice of performing ambiguity reviews on the requirements
document is very important to detect issues early on in the requirements stage. And, it
is extremely critical to review all ambiguous requirements at an early phase to reduce
costs and delays in timelines and to create valid test cases and build good quality
software.

Apart from achieving testable requirements, the Requirements Ambiguity Reviews

additionally help in multiple ways:
Improving requirements and reducing future defects in software
Designing & Mapping the right tests ensuring 100% code coverage
Evaluating quality attributes & ensuring compliance specifying the differences
between poor and testable requirements

It is important for the requirements to be precise, such that the objective is clear and
effective communication is delivered. Now, let us see some of the important
approaches through which ambiguous software requirements can be identified, verified,
and modified, at the source itself.

1. Usage of Effective Requirements Gathering Techniques: While gathering

requirements, the business analyst or the user involved should clearly understand, elicit,
and gather data through various methods such that ambiguous requirements can be
identified along with any hidden requirements. Some of the methods include
conducting elaborate interviews, preparing follow-up questionnaires, drafting open
ended questions and others. Offer effective feedback and periodic summaries so that

http://gallop.net/

the interviewee knows you are listening and understands what was said. Finally get an
understanding from the facts and analyze the collected data.
2. Engage Developers & Testers in the Requirements Definition Process: It is
important to involve both the developers and testers in the requirements definition
process as they are involved in the actual development & testing of the software. They
can understand and analyze any ambiguous requirements if they are involved early in
the requirements definition phase.
3. Practice Dual Track Agile process to keep the requirements in check: The Agile
coach, Aaron Sanders, coined a new term Dual track development wherein early
fixation of false assumptions is a process before the actual development begins. This
process helps check ambiguous requirements with respect to certain project
assumptions. Moreover, dual track agile development refers to repeated testing process
to confirm that the right requirements are met by releasing code and conducting focus
group meetings.

Gallops proprietary Requirements Testing Framework (RTF) helps eliminate

ambiguities in the requirement phase of the STLC and prevents the defects from
propagating to the subsequent phases of the STLC. This framework performs a holistic
analysis of requirements across 4 parameters: Consistency, Clarity, Completeness and
Testability. Contact Gallops team of Software Testing Experts today for a requirements
validation.
Are your requirements error-free?
Tags: Ambiguous software requirements, Gallop Solutions, qa validations, requirements testing
framework, Software Testing, software testing life cycle, software testing requirements

http://gallop.net/