Writing software requirements for your messaging service

We can hardly imagine our everyday lives without messaging apps. They have become part of the daily routine, and it seems like these apps aren’t going anywhere. There are many messaging apps on the market already. But you can still build a successful product that will succeed.

What’s important before starting to develop a mobile messaging app is to prepare software requirements. Some development companies just skip this part, but that usually results in lost time and money. Without requirements, there’s a good chance that deadlines won’t be met and that the cost of messaging app development will increase.

Successful software development starts when you not only have described the app’s features but also have properly written requirements. We often work with clients who want to implement messaging features in their apps or develop a messaging app. Before beginning development, we always start by collecting and analyzing product requirements.

Read also: An Extensive Guide to Messaging App Development

There are different types of product requirements: business, functional, and non-functional. Business requirements typically answer how the product will address the needs of your company and its users. They also reveal the business model of the app and what problems it can solve. Functional requirements are about functionalities that will be implemented in the app. Non-functional requirements describe how these functionalities will be implemented.

In this article, we only focus on functional requirements. In simple words, functional requirements are not ideas of how to solve problems or which technologies to use but rather are descriptions of software functionality.

Deciding on the type of the app to develop

The first thing you should do before developing messaging software is to decide what kind of an app you want. To compete with commonly used messaging apps, you should focus on core features and on features that will distinguish your app on the market. Once you’ve prepared a list of problems your app aims to solve, you can start writing functional requirements. Your functional requirements document should provide clear and complete information about all the functionality you want in your software.

Supplying the necessary details for developers

Functional requirements provide information needed by designers, developers, quality assurance specialists, and project managers. When all team members know what the software requirements are, there’s little chance that your product will end up missing some necessary features or provide unwanted features instead.

Properly written requirements answer all of your developers’ key questions about your application so they know precisely what to build. At the same time, requirements allow you to be sure that you’ll get just what you want. Once software requirements are prepared, the functionality should be clear. Project documentation also states how the software will handle error states and provide explicit feedback to users.

Read also: Software Requirements Elicitation Best Practices

At Yalantis, our requirements analysts work on writing the requirements for all projects. These specialists interview clients to find out about the software they want to develop. The flow of creating messaging application requirements doesn’t differ much from the flow of creating requirements for other types of apps.

At the first stage, we:

• Research competitors’ apps
• Find design references
• Define key features
• Define types of users
• Write a draft product description of functional capabilities
• Draw sketches of screens

We then need to sort out all this information before writing the software requirements. It’s very important that you collaborate with our team to create accurate requirements for your chat application, as every detail means a lot in a software development project.

Requirements start with a high-level description, which is about brainstorming and rough estimation. This part of the software requirements is usually presented as a mind map. It starts with the main idea of your product, for example “instant messaging app.” This theme is then divided into sub-themes, which represent your app’s functionalities. While creating mind maps, we take all ideas into account. Mind maps are written in short and simple words, which helps us focus on ideas. They’re a great tool for explaining relationships among product features.

A mind map helps to organize ideas. Instead of keeping all the ideas in our heads, we visualize them on a mind map to see the whole picture. This stage is really about brainstorming. We start with generic topics, then go forward to sub-topics. That’s how the concept expands so that we can make a rough estimate. Usually, our clients work with their development team members to build the mind map for an application. Once the mind map is ready, we can start to estimate the project.

Having prepared a mind map of your project, you can move on to a more detailed description. Usually, this includes user stories, which describe how users will use your app’s features. Interactions are fundamental while developing apps. So requirements should explain how an application will work from the user’s perspective.

Software requirements may also consist of wireframes, prototypes, diagrams of functional relationships, or just lists of features. But writing stories is fundamental, as they show how users will use your app.

The development team starts writing user stories at the very start of an Agile project. Each team member participates, as it’s a principal stage of the development process. The main goal of user stories is to create a full description of the app’s functionality. A requirements analyst helps the team elicit, analyze, and document requirements. All requirements have to be defined before starting development.

But users stories aren’t just a list of features that you want in your app. For successful app development, a requirements analyst first collects information, defines user types and roles, and defines functional and non-functional requirements. Only then is it time for user stories.

User stories should be understandable both to developers and to you as the client, and should be written in simple words. The most popular way of writing a user story is with the following formula:

“As a <user type>, I want <goal> so that <reason>.”

This simple scheme for writing user stories is a great way to identify who does what and why. Each story describes one interaction. This may seem too simple. But what makes it so useful is combining user stories so that they cover all the functionality of an app.

A great benefit of writing user stories is that you can write them in different levels of detail. You can write simple stories. Or you can write user stories that cover a large part of the app’s functionality, in which case they’re called epics. Epics are large user stories that developers can’t usually complete in one iteration. So epics are split into smaller user stories.

To compete with successful and commonly used instant messaging platforms, your service has to offer great functionality. So first, let’s define the core features of a messaging app.

Among the core features of a messaging app are:

• Registration
• Adding contacts
• Sending messages and media to individuals
• Creating groups
• Sending messages and media to groups
• Viewing message history
• Calling (audio and/or video)

For more details about the must-have functionality of a messaging app, read our other article. The above-mentioned list of features would not be enough for a development team to start the process of building a successful app. Lots of questions appear after reading over the functionality of your messenger. To be sure that all team members know what features are to be implemented, we write user stories.

First of all, think of the way users will register. Users may register with their phone numbers. Or they may register via social media accounts, such as Facebook. Can users choose how to register, or is there only one method of registration? Using phone numbers to register in a messaging app is what users are most familiar with. It’s the most common method of registration, and it’s quite safe. So the registration feature may seem obvious, but there are lots of issues to be solved. That’s how requirements and user stories in particular help define the details of an app’s functionality. Here are some example user stories related to registration:

“As an unregistered user, I want to tap “sign up” so that I can see the registration form.”

“As an unregistered user, I want to use my phone number to register so that my account is tied to my phone number.”

“As an unregistered user, I want to add a username so that other users can find my account not only by my phone number.”

“As an unregistered user, I want to receive the registration confirmation via SMS so that I can activate my account.”

These are just a few examples that show why you can’t just add “registration feature” to your messaging app requirements. You should include explicit details so that your development team can estimate the feature and decide how to build your real-time messaging app.

Let’s take a look at another example. Registered users can send text messages. That’s also not a requirement, but a feature. Here we have user stories describing this feature:

“As a registered user, I want to send a text message so that another user gets a notification and sees my message.”

“As a user, I want to see the status of a sent message so that I know if it’s been seen.”

It takes lots of user stories to describe the functionality of an app. But by developing user stories, you can be sure that you’re on the same page as your development team.

Read also: Implementing Push Notifications into Your iOS or Android App

Let’s say you have an idea to implement a brand-new feature in your messaging app. If it’s innovative, you can’t simply tell your development team, “We need a feature like WhatsApp has.” In this case, software requirements play a major role. To avoid misunderstandings and tons of corrections while developing the app, requirements analysts describe the features that you want in detail.

So having a good idea isn’t enough. It needs to be written properly so that you and your development team can be sure they’re on the same page and that the estimate is correct. We’re going to take a look at some messenger features to see how we can elaborate an idea into user stories.

Telegram encryption feature

Security is one of the main advantages of Telegram. We won’t explain in detail how its protocol works. Here, we’ll focus on secure messaging. Telegram chats aren’t encrypted by default, but a user can start a private chat with end-to-end encryption. By default, chats in Telegram are encrypted server-to-client. Secret chats are special because they’re encrypted client-to-client. So messages aren’t stored on servers and stay only on users’ devices. A user can start a secret chat only with users from their contact list.

We can start writing user stories for Telegram with this:

“As a registered user, I want to start secret chats with users from my contact list so that we can send messages that stay only on our devices.”

What’s important is that these secret chats are device-specific. Once you’ve started a discussion from your phone, for example, you won’t see it when you switch to desktop or tablet versions of Telegram. That means you can’t sync secret chats with other devices.

“As a registered user, I want my secret chats to be device-specific so that I can see a secret chat only on the device that I used to start this chat.”

We can’t say that we provide secure communication if users can forward secret messages or take screenshots of them. So we should provide user stories to prevent the sharing of secret messages.

“As a member of a secret chat, I want my secret messages to be protected from forwarding so that secret messages stay in secret chats.”

“As a member of a secret chat, I want to get a notification when another member of the secret chat takes a screenshot of it.”

We would need many more user stories to describe the functionality of a secure messaging app. After that, developers would work on the technology stack and estimate the project.

Snapchat deleted messages

Snapchat is quite a unique messaging app. Its defining feature is the ability to send multimedia messages that disappear seconds after the recipient sees them. This feature has made Snapchat extremely popular, especially among teenagers. Let’s try to write user stories to describe the idea of Snapchat’s self-destructing messages.

“As a registered user, I want to set a timer for up to 10 seconds so that the recipient of my message will be able to see this message only for the exact number of seconds I’ve selected.”

Self-destructing messages put into action an idea not to save but to share multimedia messages. That’s why it would be useful to get notified if the recipient takes a screenshot of a message you’ve sent.

“As a registered user, I want to get a notification if a recipient takes a screenshot of my multimedia message, so that the notification appears in my list of Snap messaging activity beside the recipient’s name.”

Voxer, the push-to-talk app

Voxer’s core feature is delivering voice messages live. So this live chat platform is commonly known as a walkie-talkie. Users can send voice messages to individuals or to groups. If your friend’s phone is turned on and the Voxer app is running, when you send a message it will be played instantly through their phone’s speakers. If your friend isn’t online, the message will be received and recorded as a voicemail. Voxer is a great tool for communicating quickly, as messages can be listened to immediately.

“As a registered user, I want to send voice messages live so that a recipient can listen to them in real time when their phone is running the app.”

“As a registered user, I want to receive voice messages when Voxer isn’t running so that I can listen to them when I open the app. “

These user stories no longer seem innovative. But they show how your ideas can be developed into requirements. Once a requirements analyst has prepared the software requirements for your app, it multiplies the chance of successful app development.

Another benefit of having correctly written software requirements is that in case the development team changes, other developers can save time when joining the project as the software requirements provide all necessary information about the app’s functionality.