Over a million developers have joined DZone.

How Can Suppliers Help Customers Understand Their Requirements Better

DZone's Guide to

How Can Suppliers Help Customers Understand Their Requirements Better

· Agile Zone ·
Free Resource

Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap. Brought to you in partnership with Techtown.

In a previous post on the ReQtest blog, I listed the five worst requirements I have ever seen during my career and gave the reasons why these requirements and other like them are the curse of every tester.

This article is a follow-up of sorts.

Here, I intend to go into the ways how we as a supplier can help our customers achieve a better understanding of their requirements by making sure each statement is firmly anchored in the practical realities of the business process.

Understanding the dynamics of the requirements transfer process

First of all, let’s briefly mention the roles involved in the process where requirements are formulated and transferred.

The two main roles in this process are:

1.  The customer, the person or group of persons who are commissioning the project and decide the requirements that have to be implement in the final product; and

2.  The supplier, who produces a product for the customer on the basis of the requirements provided.

The user is natural third party to the exchange who often does not fully enter the process until later, but whose needs should be kept at the forefront of the other parties’minds at all times.

Linking customer and supplier are the written requirements

Written requirements are an essential tool used by suppliers to help customer formulate better requirements and delve more deeply into

1.  Helping software customers to accurately describe the practical outcomes they want to obtain from the product;

2.  Helping software suppliers to gain a better insight into their customers’business needs;

3.  Establishing an agreement between the customers and the suppliers on what the finished software product is to do;

4.  Providing a basis for estimating project costs and schedules.

Moreover, individuals working on implementing the requirements specified should utilise the below as a practical ‘guidebookwhich allows them to remember to:

1.  Write more effective test cases;

2.  Reduce development effort, as any omissions, misunderstanding or inconsistencies can be discovered early on in the project by reviewing carefully the document;


The key to creating a high quality document is directly linked with the quality of the communication and collaboration between customers and suppliers.

Requirements should be jointly prepared by both parties since, as the IEEE claims:

Neither the customer nor the supplier is qualified to write a good SRS alone.

Accepting this startling revelation, which positions both customers and suppliers on an equal footing: both are ignorant of each other’s needs even as they’re experts about their own, is an important step in the process.

The reasons why the customer and the supplier should work together are twofold:

1.  Customers usually do not understand the software design and development process well enough to provide adequate requirements.

2.  Suppliers usually do not understand the customer’s problem and field of endeavour well enough to specify requirements for a satisfactory system that meets their business needs.

What does a good requirement look like?

A good requirement documentation has eight important characteristics:

1.  Correct - every requirement stated in the document is one that the software shall meet;

2.  Unambiguous - every requirement stated in the document should have only one interpretation;

3.  Complete - full labels and references to all figures, tables, and diagrams in the document and definition of all terms and units of measurement used are given;

4.  Consistent - no individual requirement is in conflict with another ;

5.  Ranked for priority - each requirement has an identifier indicating its priority along a subjective scale (e.g. MoSCoW scale) ;

6.  Verifiable - every requirement stated in the document should be linked with a practical outcome that can be definitively assessed in real-life use.

7.  Modifiable - any changes to the requirements can be made easily, completely, and consistently while retaining the overall structure and style;

8.  Traceable - every requirement can be easily referenced for documentation pertaining to future development or enhancement.

In conclusion

Despite being a joint venture, suppliers still find themselves in a position where they have to coax the clients into participating fully in the process of documenting the requirements and needs.

There are many ways for suppliers to achieve this goal, from in-depth interviews to hands-on experience at the customer site.

In the latter case, business analysts immerse themselves in the business process of the client and gathers requirements by experience the business first-hand and any flaws in the current process can be more easily formulated.

Whilst time-consuming, this method yields accurate and detailed information that can help suppliers understand better their customers and develop better requirements that will produce greater savings in terms of money, time and effort later on.

About the author

Ulf Eriksson is one of the founders of ReQtest, an online bug tracking software hand-built and developed in Sweden. ReQtest is the culmination of Ulf’s decades of work in development and testing. Ulf is a huge fan of Agile and counts himself as an early adopter of the philosophy which he has abided to for a number of years in his professional life as well as in private.

Ulf’s goal is to life easier for everyone involved in testing and requirements management, and he works towards this goal in his role of Product Owner at ReQtest, where he strives to make ReQtest easy and logical for anyone to use, regardless of their technical knowledge or lack thereof.
The author of a number of white papers and articles, mostly on the world of software testing, Ulf is also slaving over a book, which will be compendium of his experiences in the industry. Ulf lives in Stockholm, Sweden.

Take Agile to the next level with DevOps. Learn practical tools and techniques in the three-day DevOps Implementation Boot Camp. Brought to you in partnership with Techtown.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}