How to write a software requirement document for a mobile App?

This is a great question on which multiple books have been written. I’ll outline in this answer the strategy I use to write such a spec today.

It is different from the way I use to do it at Microsoft as I found Microsoft spec to have a  fatal flaw. They lacked the context of the feature/product.

When you first start this process it is likely that each section will contain more questions than answers. That's ok, it helps you keep track of the unknowns.

What problem are you solving?

Too many times, as the design of the app is moving forward the original problem to solve gets lost. 

Then features unrelated to the original problem are added to the product because someone thought it was a good idea. The app ends up losing focus and becomes less attractive to the users. 

So making sure to document the problem at hand is very useful.

Here is an example from an app I'm working on:

"I am helping expat wife cook recipes from home by providing a quick and beautiful way to convert cooking measurements to local units"

Who are you creating this for?

You have to remember that you don't create apps for yourself. You are creating an application for someone else that may have a different need than you, different computer skills, different culture and more.
So make sure you have a clear persona you are designing your app for. Actually when you first create your app, having a single person for whom you are creating this app might be the best option.

For my app:

"Maria moved to the United States from Spain two years ago. When she first moved to the united states, she bought measuring cups and measuring spoons to cook as this was all she could find. She can easily cook local recipes, but whenever she looks up a Spanish recipe online, she has to convert the Kg and Liters into cups. She has found a website to do so, but it is a pain to use."

During the design process, you I can ask yourself: "How would Maria like to convert all those measurements?" 

Differentiating factors?

The AppStore and PlayStore have a staggering number of apps today. So rest assured that most likely your great app idea has been done before. 

So what is your differentiating factor? Be specific.

For example, if you look at the unit conversion on the AppStore, you'll get a long list of generic unit converters and currency converters.

If you do a little bit of digging, they are all doing the same thing: providing as many unit conversion options as possible: They are all doing the same thing. There is no differentiation.
Maria does not care to convert Celsius degrees to Kelvin degrees. Her oven only displays Fahrenheit anyway.

Also, now that I know I'm creating an app for cooking, this helps me tremendously to focus my app and for the visual design.

What are your business goals?

What is it that you are trying to achieve. Are you looking to replace Facebook? Are you looking to create an app that allows you to live a comfortable life? Is this application a loss leader for a larger service? Is this a complementary service to something your user already bought? 
Be clear on this, because that will help you answer a lot of questions that will come later in the design phase.

Going back to the unit conversion app, my goals are not to get rich out of this app. My goal is to create an app my wife could use (we are expats) and that I can use in my design portfolio.

Important dates

A project never happens in a vacuum. You might be trying to be ready for a specific annual convention to be able to announce your product there. 

You might have to hit a certain date so that another team can complete their part of the project in time.

You might know that your main competitor will release at a certain date and you want to beat them to market.

RATs (Risky assumptions to test)

When you create an app you are never sure if this is going to be successful or not. And this is fine. Though you should list what are the things which have not been validated yet. Next list how you will validate those. This way you can make sure that you have all you need to validate as soon as possible. An early alpha version of the app can be sent to early users, for example, to see if they use it.

User stories/Scenarios

Remember Maria from our audience. What is she trying to do with your app? What do you want to empower her to do with your app?


User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a <type of user>, I want <some goal> so that <some reason>. 
User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

So make a list of those stories and prioritize them. 

My user stories for my unit conversion app are all along the line of:

Maria is cooking a new recipe she found on a Spanish reciepe site. She wants to convert the 500 grams of butter she needs to something she can actually measure with her American measuring cups.


Each scenario will require a certain set of feature to allow your user to complete those. The main reason why I include all the context above is that, for one user scenario, there is a lot of different ways to implement it. So you'll want to use that context (business goals, user profile, budget, problem solved) to pick the right feature set.

Here is my feature set for the scenario I listed above

- sliding ruler to convert grams to cups
- control to select ingredient (convert mass to volume can be tricky)

Another feature I thought of for a future version which solves the same scenario:

- Perform OCR on recipe and convert all the measurement from a picture

Notice how those two sets of features are different yet they solve the same scenario. The latter one will take a lot longer to implement, so I'm keeping it for later.

Use your business goals, your user profile, your target dates and your budget to decide on your feature set.

OS supported

Depending on your audience (and your budget), you might decide that you only want to support the latest version of the iOS. Or you might find out that your audience has not updated their phone in the last 4 years, so you should support 1 or 2 previous version and expect your app to run on smaller screens (and forget about ARKit).

For my project, given that this is a pet project, I'm only going to support the latest version of iOS and make my life simple. It also helps that iOS user update their phone pretty fast.


Not every application requires a backend, but if you do, then you have a whole lot to document. I'll keep that for another time though.

Third-party services

In today's app, you always have some third party services. There are some things that are best left to others. Here is a typical list that I have for mobile apps:

  • Analytics service: to keep track about what your users are doing
  • Error logging service: to know when your users are encountering errors so you can fix them
  • Crash reporting service: So you know when your application crashed so you can fix it
  • Payment platform: which paiment platform are you going to use
  • In-app messaging: Don't create a messaging platform from scratch in your app, use a prebuilt one


This is something that is frequently left out of specs and I think this might be one of the most important sections. List all the things that you can think of that could go sideways and what is your mitigation plan for each of them. It is much easier to figure out a solution when you are not under pressure and have to find a solution to that security breach that nobody saw coming.

This is usually where the spec ends. From there, you're heading into the UX design of the application. I have included the three design parts which are the most important but don't usually go in the spec.

Application information architecture

What is going to be the structure of your app? How will the information be grouped?


With the information architecture in place, you can start to layout each screen and show how the functionality is represented. Keep it simple, no need for fancy graphics yet. But do keep in mind screen transition so you can get a good idea of how the application will behave.

Visual design

Time to create a great visual design. Use what you know about your target audience to create a visual design that will resonate with them. 
Depending on your project, you might simply reuse the base control of the OS, or you might create custom controls for everything.
If you go the custom control route and your project is fairly large, I highly recommend creating a visual design book that defines:

  • colors to use throughout the app
  • text styles to use throughout the app
  • The visual style for the controls (with animation)

The goal here is to have a single place where reusable components are documented. This way your developer can easily make a consistent user experience by knowing that all those controls are the same. This will save you time down the road.