How I Gather Technical Requirements before Building Systems

There’s so much to think about when gathering the requirements of the software you will be building. Questions that need to be answered and factors that need to be put in place, in other to design and deliver high-quality software.

In this article, you will learn about how I gather technical requirements for the systems I build. Let’s get right into it.

I was recently approached by a client who wanted a chat application; what separated this client from other clients that have approached me in the past was his technical knowledge of the product he wanted. He was well-informed, answering every question that I threw at him.

Now, he wanted a chat application with low messaging latency. When I saw his message and the kind of application he wanted, I laughed inside me. I have been approached by clients that wanted me to build the exact copy of Reddit and even YouTube which is so ridiculous. When I ask these clients to further explain the necessary features they wish to have in the MVP, I am shocked that they don’t even know what the word “MVP” means.

What? You don’t know what an MVP is, yet, you are trying to compete with a very stable platform like YouTube? Before the end of our conversation, I tell them that I am no longer interested and wish them the best of luck.

Back to this technical client of mine, he listed all the features he needed the MVP to have.

I will be listing the most generic of them:

• push notifications

• voice chat/call

• media upload

• formal chat groups

  
  

Push Notification

I believe that this is one of the most popular features to include when building a mobile application. A push notification is a message that pops up on a mobile device, it serves as a quick communication channel enabling companies to convey offers, alerts, or some other information to their users (or customers). An example of a push notification is when you get a notification from Twitter that says “X is now following you“.

The first question I asked the client was, “Can you provide more information about the expected number of users and the expected usage patterns for the application?”.

His reply was, “Yes, the expected number of users and expected usage pattern is as follows:

• 10k users (peak usage)

• 1-2k users (moderate usage)

• 100 least (minimum usage)”

  
  

Isn’t that a beautiful reply? Moving forward, I created a google document and recorded his answer.

Voice Call

This is an interesting feature. A voice call/chat is the ability to converse with people in real-time with a mobile phone. He wanted users using the chat application to be able to contact and converse with each other, chat through voice, and save the time and labor of typing.

I asked the client, “Are there any specific requirements for the voice call feature, such as support for specific codecs or call quality standards?”. A codec is an algorithm that is used to compress audio and video, allowing high-quality media content to be transmitted over the internet.

His reply was, “One with provide good call quality”. He further went on to say that it is an extra feature to the application and has no business value whatsoever. I agree with him.

Media Upload

Another interesting feature was to grant users the ability to upload images, and documents and share them amongst themselves. He mentioned that the feature is critical and one of the most important one of them all.

Formal Chat Groups

This is another main feature of the application. A chat group is used for sharing information, usually in text with a group of users.

I asked the client two questions; “How do you envision the formal chat groups to work, and what level of access control and management will be required?” And “What is the desired message latency?”.

His reply was; “So basically, the group will be like every other chat group with an administrative/moderation role and members.” and “The desired message latency is to be of high speed like that of WhatsApp.”

I understand that he, like every other client, wants a message latency like that of WhatsApp. But in other to achieve that kind of scale, I hope you are ready to bear the cost that comes with it.

Summary

My conversation with him was very interesting. He kept asking a lot of technical questions; like the choice of tech stacks, why them, and the kind of architecture that will be used to build the application. In other to get a clear vision of the product your client wants, you must ask questions.