http://gallop.net/

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.

Gallop’s 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