How to Effectively Gather Requirements from a Non-Technical Client

Effective communication with a client is absolutely critical in any industry. Especially, in IT industry, it is very critical at all levels, either it is the initial phase of requirements gathering, software development process, change requests, testing, UAT or explaining the complicated functions of a software. It is important to get the things done right to avoid any misinterpretation of conversation between the company and the customer.

In IT industry, we have to deal with different types of clients. In the context of this blog, we’d like to categorize them mainly into two types: Technical Client and Non-technical Client.

1.  Technical Client
A technical client has sound knowledge of various software development technologies and platforms. They might be experts in one or more technical areas and understand the concepts of web, network, database, domain, hosting, etc. as they may have experience working in such areas, hence very well accustomed to IT operations. Dealing with such technical clients is sometimes easy, as they’ll easily understand what we are talking.

2.  Non-technical Client
A Non-technical client is the one having lesser or no technical knowledge. Either they have never dealt with technical areas or have inadequate knowledge to understand the IT systems. They might know the importance of computerized automated systems very well to help their business flourish, save time and money, but they have no idea on how actually a software application really works.

Communication is a big problem faced by the technical and non-technical people. According to the non-technical clients, most of the terms that we IT people use are Jargons. So, in this blog, we would like to share few important things to remember while communicating with a client which is based on our experience of working with our non-technical clients.

Requirement Gathering – Develop or Not to Develop
Requirement Gathering is an important phase of software development process. It includes a detailed discussion between the client and software development team. Most of the time it is conducted by Business Analysts. As we know that the client on the other side is non-technical, therefore we must take care of everything, that is what to develop as well as what not to develop!

Let us understand this with the help of some examples of client interactions:

Example 1
A client explained his requirement: “If my job has an issue, I need an area in the system where I can add the issue.”

Now, in terms of database, interpreting the words literally makes us understand that ‘Job’ has a one-to-one relationship with ‘Issue’ and we usually handle this by adding required column in ‘Job’ table for the ‘Issue’. But, the reality is quite different in this case.

Here, we need to explicitly ask the client: “Do you have more than one issue for a job?”  If “Yes”, then the answer straightaway changes the database structure. We now need 2 tables, i.e. ‘Job’ and ‘Issue’. ‘Issue’ is holding a foreign key reference to ‘Job’ for a one-to-many relationship. This seems to be a simple iteration, however, only a software developer can imagine the pain for such things that are discovered only after all development code and testing are already done. Moreover, you cannot even give an explanation to the customer about the problem as he will not understand anything.

Example 2
Let’s look at another example. We have gathered the following requirements from the customer to build a ‘swing’:

• Back support required? – No
• Safety lock required? – No
• Color of swing – Red (color can be changed according to client’s requirement)
• Height of swing from the ground – 1 m

Based on the above requirements and discussions, here is the solution that was delivered.

After the delivery, here are is the client feedback:

• Can you please change “Red” color to “Matte black” please? (Oops, we didn’t mention that matte shades are way costlier than normal shades!)
• Why did you make the swing out of fiber?  I want it to be made out of steel. (Oops again! We didn’t confirm the material that’ll be used to make the swing. Loss again!.)

Now we realized that we didn’t ask the right questions to the clients. Ideally, we could have gathered requirements as below:

• Back support required? – No
• Safety lock required? – No
• Color of swing – Red (we can have any color you want, matte shades will cost higher by 20%)
• Height of swing from the ground – 1 m
• Material to be used: Fiber (Metal option available at higher cos)

From the above example, we learned that clearly mentioning what a client will not get at a particular rate is equally important.

Give Examples Before Solution
Before concluding to a solution, firstly, explain the things to the clients with examples. It is best if you can create those examples in the context of his own business.

For e.g., a customer wants a system that he can use for his staff within the office as well as out on the field. The office staff has a lot more things to do and a web application cannot suffice as it needs to leverage the benefits of a desktop application and software. The people onsite cannot use the software on the computer and they need a web-based solution to fulfill their needs. So, here we need to develop two applications with a common back end.

What generally others do:

The above image will make no sense to the client as he has no knowledge about the database, and so it will become hard to convince him why we need two separate applications. A better explanation can be given as shown in the below image.

What we should do:

How Applications should be designed:

• The applications should be designed in a way that the user interface provides a certain flow to the areas.
• Divide the areas into relevant blocks, separate the blocks using different colors and layouts.
• Numbers can be a good way to indicate a step by step process of using a certain screen, therefore, by giving numbers to separate blocks it becomes easier for the non-technical people to understand the screen, as all they need to know is follow the numbers!
• Study their day-to-day operations properly and maintain the same sequence in your user interface as well. It gets a lot easier for them to relate.
• Also, study the users who are going to use the application. Understand and consider their preferences, likes, dislikes, etc., and get application designed accordingly.

Clear and Concise Communication

• Try to understand client’s perception of relevant things.
• Adapt to his communication preferences.
• Try to think like him, get his vision and it gets easier to realize what he actually wants.
• Avoid long conversations, queries, explanations and any technical stuff in emails. Talk direct instead.

Build Customer Trust

• While dealing with a technical client, even though a mutual rapport is not yet built, the client will understand the justification of estimated time, efforts, price, etc.
• But the same thing is not true while dealing with a non-technical client. Such clients are mostly businessmen and deal with a lot of people of a different kind. They surely know how to analyze the other person. So, be ethical and honest, understand your professional limits, remain calm and confident and gradually they’ll start trusting you. Their trust on you will make things a lot easier!

Conclusion:

TatvaSoft, being a CMMi 3 and Microsoft solutions certified company, strictly adheres to guidelines of software development life cycle. We differentiate ourselves on the basis of the software development processes we follow and the close interactions with clients. We ensure an in-depth understanding of customers’ requirements and challenges before we start development. While other software companies have a little coupling with clients because specifications are thrown over the wall, our software development model is interactive and is based on a global team concept where few team members or client IT staff works with end customer to define requirements, review prototypes and manage scope changes.