Heads up: An updated and more detailed version of this article with actual Steps on how to Create a requirements document for your Mobile app (with tips, step wise details) is also published on our blog.

Chances are you will be using a mobile app development company to whom you’ll have to explain your vision and idea.
Doesn’t seem complicated, does it? Almost trivial ? After all, you’ve thought about that idea day in and out. You’ve considered all the aspects to it.

And what could be simpler than putting your thoughts on a piece of paper …. or well … your laptop.

But hold on a sec – What if you’ve missed some important features?

What if you didn’t explain a feature right?

Or what if, the features and look and feel of the app have been written down according to you – but not the average actual user?

This is why you need a proper Requirements Document for your Mobile application before working with any development company. Before you start creating a Requirements Document (Specifications of your App) or what is technically called a RFP / SRS – let’s see what it contains. To be precise, a RFP or Request for Proposal is what is created first. After that, once your development partner is selected, the requirements may further need to be elaborated and a new Requirements Document may emerge.

However for the sake of simplicity and considering practical constraints , lets assume here – and as happens at times, the RFP gets evolved / modified into a Requirement Specification Document. We’ll be using these terms interchangeably.

Steps to take before making a Requirement Document or Specifications Sheet for your Mobile app.

1. Study competitor or similar apps – Download from Google Play Store and study their navigation and flow.
2. Study Apps which have features similar to the one you are planning to offer. Install, check the flow and save screenshots on your phone itself. These screenshots can be referenced in future documentation when explaining something.
3. Talk to friends, family , colleagues who are similar to the possible users of the app and understand how they make use of a specific App.

Creating your Mobile App Requirement Document the right way

What should the Requirement Document / RFP for your Mobile App Cover?

1. It should cover all the Features of the App in detail.
2. You should also provide mock-ups of screens, or wire-frames (need not provide at RFP stage)
3. It should cover Performance requirements of the app , Future needs, Security and User Assumptions
4. Questions should be put to the development team in the RFP on how they plan achieve the features required. The team should be encouraged to provide suggestions wherever they feel necessary, of a better way of achieving any specific functionality / end objective than is mentioned in the RFP.

Typical Sections in a Mobile App Requirement Document / RFP Document

1. Introduction and Functional Requirements
The introduction section should talk about the objective of the app and it’s target audience. It should also cover your preferred technology platform (if any) and what all devices or OS are being targeted by the app.

The Functional Requirements will be at the core of your Mobile Application’s requirement specs. These will answer the questions: Who, What, When and Where. (for any specific feature). These cover the main user flow and can also be in the form of ‘User stories.’ A User Story is a less formal but more intuitive way of describing a functionality. It describes the usage of a specific feature or the app’s usage in a specific situation (like logging in, finding service providers etc.) in the user’s voice in first or second person.

Example of a Functional Specification: Let’s say we are talking about a car servicing and cleaning app. So one of the key user flows is when an existing customer places an order for car servicing. So your requirement spec can mention: “The app will allow an existing and logged in customer to go to the order screen and search for car servicing stations near his location. He should be able to filter them by distance, price etc. He will see the service station profile image, name of the business, distance from his home location, user rating, service types in the list which shows on the screen.” As you can see this example appears to answer the who, what, when , where which is generally required in every requirement specification.

2. Assumptions & Constraints
Constraints and assumptions are examples of special requirements which apart from being features also specify special considerations that the developers have to keep in mind.
Example: Let’s say if you are making a logistics app using location services , a constraint could be that it should work on Low Power setting of Location services as well. Now this is a feature, but is also a limitation which the app developer has to keep in mind.
Another example: of assumption could be related to the users of the app. For example let’s say the App is a Social app and we’re launching it where the chances of it’s users being offline are next to zero – then the Assumption could be: The app will be available only for those who are connected to the internet but should show a proper error message if they aren’t.

3. Error Handling
Error handling is a very important aspect of any requirements document. If you notice in any Mobile App: Error Handling is done with a uniform look and feel through dialog / popups / toasts etc. More importantly, the error handling sub-section should indicate when and where the system will alert the user of any error. This would typically be a subsection for every user story / feature.
Example: If Login has failed due to incorrect credentials, the App should display this error in the login screen itself through a toast. However, If user does not exist, app should specify this separately.

4. Security and Privacy Requirements
Any mobile app would have some security and privacy requirements. Even if it is open to all public without a login, even that should be mentioned specifically. If it requires Login , then it should be mentioned how a person will login, logout, and which functionalities are accessible after login. If login is via third party authentication such as Twitter / Facebook, this needs to be mentioned.
There are other ramifications which are somewhat technical. When your app calls the server it would need to authenticate itself and this should be documented. It need not be very technical but questions can be asked from the development company through the RFP (and later elaborated in the Requirement document) how they plan to handle security.

5. Interface and Compatibility Requirements
During the requirement study and design , the apps external interface should be mentioned. If your app is dependent on a third party app or interfaces with it, this should be mentioned wherever relevant.

Example: Social Auth Login is an external interface, Google Maps for Location is another external interface.
You need not go very deep or write the exact name of the interface, the idea is just to give the mobile development company a hint about external interfaces.
The Other important use of this section is to mention your apps scope and compatibility . Android apps for instance are made defining a minimum API (as users across the world don’t all have the same android version in their device). So mentioning the minimum, maximum, targeted API version , other platform constraints (should not use closed source back-end programming ) should be mentioned clearly.

6. Performance Requirements
This is an often ignored but a crucial section. You need to have a benchmark, and a best guess estimate of how your app will grow and what kind of performance is expected. For example, how many users should be simultaneously able to login / chat? What should be the latency of critical features /tasks in the app?
Both now, and in the near term future.

Example: The app should be able to handle up to 50 concurrent chats initially and capable of scaling this to 500 concurrent chats over 6 months.

7. Requirements of the Backend Admin System
Let’s not forget that most apps will need a backend administrative interface available generally via the web to manage functions such as User management, order management, other settings and limits etc. So some details about this administrative interface should also be included in your RFP / Requirements Document.

8. Design Requirement
You can talk in brief here about the design requirements. You can provide the full set of wireframes of the App if you have an NDA signed from the prospective app development team – but it is not mandatory. There are many UI wire-framing tools such as Balsamiq available which can be used and even Microsoft Visio or MS word drawing objects would work.
You certainly should provide example of apps which excite you with their look or feel and even point specific screens whose kind of look you would like in your mobile application.

Requirements Document for your Mobile App – How to know it is Exhaustive?

Once all the above is said and done, a nagging thought may probably have entered to your mind.

Is my requirement document complete and ready to go ?

Well, this is a subjective question and best answered by putting yourself in the shoes of the companies who will be responding to your inquiry. The information should be enough for them to provide a fairly accurate quote estimate and time estimate for your project.
IT need NOT contain all the wire-frames, proprietary or crucial information – but If you cover the above sections, you should have a pretty complete requirements document ready.

Protecting your Mobile Application Idea. Practical Considerations when Sharing Information

Most app development companies have standard NDA templates.

As you may note: the above Requirements Document / RFP / Technical Spec (or whatever else name used) sections are pretty detailed. And you may have valid concerns as to what level of detail you wish to disclose to a bunch of companies of which only 1 you may end up hiring.

So, as I have mentioned above, disclose to the level what is necessary. Make 2 versions of the document if required. One which is fully elaborate and will be used for further discussion with the hired company – and one which has the information removed / deleted which is not necessary at this stage.
Moreover , feel free to get an NDA signed for the company. Like many companies, our mobile app development company based in Delhi, India – provides standard NDA for clients. For your reference here is an example Non Disclosure agreement we provide to client’s on request.

By the way, Here is another list of Things to do before choosing your Mobile application Development provider.

And feel free to be in contact if you have an App idea and need that initial consultation. We’ll be happy to provide a no obligation initial consultation and advice.