How to Write a Mobile App Product

Requirements Document
6 July 2021

Kate Pismennaya

Content writer

Share

In this article, we’ll talk about the critical role of requirements in mobile app development.
What are the types of requirements and what’s the right way to develop them? Scroll down
and get a mobile app requirements document sample to help you get started.

Contents:

1. Why should you write a mobile app product requirements document

2. Types of requirements
 3. Business requirements
4. User requirements
5. System requirements
6. Ways to develop and manage requirements
7. Characteristics of a good mobile app development requirements document
8. A mobile app requirements document template

Why should you write a mobile app product requirements

document (PRD)?

To turn your idea into a shippable mobile app, you need a team of developers. But finding the
right team isn’t the hard part. The hard part is explaining your mobile app vision to
developers so clearly that they conceive it the way you do.

Writing a mobile app product requirements document (PRD) helps you facilitate a meeting
of minds between you and other stakeholders. Don’t balk at investing time in engineering
product requirements, because the potential payoff is clear.

 Increase your own certainty. Discussing requirements for your mobile app makes
everything clearer. Objectives, perspectives, features, constraints — your product
 vision starts to take shape. Determining product requirements moves you from fuzzy
statements to tangible tasks with thorough deadlines, budgets, and quality criteria.
 Make your ideas clear to developers. Clear product requirements reduce the
expectation gap between the mobile app you want and what developers deliver.
 Get prompt development and delivery. With documented mobile app requirements
in sight, your development team can better understand your project, set priorities, and
reduce rework.
 Make sure the final app meets your quality expectations. Thanks to the acceptance
criteria stated in a PRD, your team can easily determine whether you will be satisfied
with the delivered app.
 Reduce scope creep. A high-quality requirements specification prevents you from
developing unnecessary features, prevents your team of developers from working at
cross-purposes, and guards your whole development team from becoming overloaded.
 Spend less. Since well-thought-out requirements contribute to a focus on the
essentials, reduce rework, and speed up development, they save you money.

According to Boehm’s research, rework can cost about 40% to 50% of the total cost of all
software development. And a major part of rework is caused by requirements errors.

Another advantage of clear requirements is that they allow your team to detect defects shortly
after a product is created and fix them at a lower cost than in late development or after the
app is released. So take developing requirements not as a wasteful and frustrating matter but
as an investment in your project that will pay off in spades.

Types of requirements
When you get an idea to make an app, you need to ask yourself three main questions:

 Why? Why do you need a mobile app? To help people with your unique experience,
get an extra revenue stream, as an investment — what is your goal?
 Who? Who will use your app? Think of your target users’ pains, problems, needs,
and preferences. What solution do users expect to get from your app?
 How? How will you achieve your desired business outcomes and meet users’
expectations? Think of the functionality your app should provide.

Answers to these questions form three main levels of requirements for mobile app
development: business requirements, user requirements, and system requirements.

Each level also has an assortment of functional and non-functional requirements.

Functional requirements relate to your app’s operation and features you’re going to
implement.

Non-functional requirements define characteristics and constraints that aren’t connected to

functional requirements. In most cases, non-functional requirements relate to:

 Attributes of the developed product like performance, reliability, availability, and

usability.
 The development process, describing development methodologies, standards, coding
languages, time restraints, security, etc.
  The external environment, taking into account your app’s connection to other
systems and hardware components, alignment with corporate policy, government
regulations, and so on

If you’re concerned about how to write specifications for mobile app development, start from
eliciting your business requirements.

Business requirements

When writing your business requirements, focus on reasons why building a mobile
application is essential for your business, the changes the app will entail, and the outcomes
you expect it will deliver. To keep your product vision clear to your development company,
you should record your business requirements in a mobile app business requirements
document (BRD).

Note that although we use the term “document,” this doesn't have to be a printed piece of
paper or a Google Doc. You can store your requirements using diagrams, databases,
spreadsheets, or requirements management tools, or you can combine these with a traditional
text document.

Based on the vision and scope document proposed by Karl Wiegers in the third edition of
Software Requirements, we’ve prepared the following BRD structure:
 1. Business requirements
Describe the situation that led you to the idea of creating a mobile app, the
Background overall goal(s) for your project, and improvements you suppose it will bring
to your business.
Highlight strengths and advantages of your app compared to existing
Business
solutions on the market. Describe how your mobile app will keep up with
opportunity
market trends and ever-evolving technologies.
Summarize what benefits you expect to get from building a mobile app in a
quantitative and measurable way. Your objectives must be SMART
Business
(specific, measurable, achievable, relevant, and time-bound). An objective
objectives
may read like this: “I want to bring in $X in revenue and return Y% on
investment within Z months.”
Determine what indicators will help stakeholders understand that your
project has achieved success. For example, for an e-commerce app, to bring
Success metrics
in $X in revenue within Z months, a good goal could be getting two cross-
sales on 80% of orders.
You can describe your product vision using the following format:

 For (target users)

 Who (need or want to change something)
 The (your product name)
Vision statement  Is (a mobile app)
 That (will provide unique valuable functionality, key benefit)
 Unlike (current business model or competitors)
 My product (advantages that differentiate your app from competing
apps)

From the outset of your project development, define how your mobile app
Monetization
will generate revenue. You can check out possible monetization models for
model
mobile apps in our previous article.
Think of possible situations that can adversely affect your mobile app
development. For example, what will you do if you get too few downloads?
You need primarily to estimate the probability of this risk and how it will
Business risks
impact the whole project. Then plan actions to control, mitigate, or
eliminate the risk. Involve other stakeholders to join in the decision-
making.
Business assumptions reflect your observations of ways you can achieve
desired business objectives. Given the objective to bring in $X in revenue
Assumptions within Z months, your assumption can be that a new app will attract 100
and monthly active users who will spend on average $15 a month. Highlight
dependencies external factors that your mobile app development depends on, such as
third-party suppliers, partners, other business projects, industry standards,
or legislation.
2. Scope and limitations
Define what features your app must, should, could, and won’t provide
List of features based on your business objectives, time and financial resources, and
problems with existing business solutions, if any.
Scope of initial Define what features you should develop first. For help deciding, read our
release article about nine techniques to prioritize features for a mobile app.
 2. Scope and limitations
Scope of This section describes features that aren’t so critical to be developed first
subsequent because of their complexity, high cost, or low profitability. You can
releases implement them in future app releases.
Limitations and List features that you have to cut from the project scope. You can add
exclusions them to subsequent releases.
3. Business context
Create profiles of everyone somehow related to your project: those who
take an active part in mobile app development, who depend on its outcome,
Key stakeholders
and who impact its outcome. To get the ball rolling, you can start from
your corporate organizational chart.
Agree on features, quality, schedule, budget, and team size. Prioritize the
factors that lead to your project’s success and define constraints on project
Project priorities development. Discuss the degree of freedom you can grant your project
manager to accomplish tasks that lead to project success within the existing
constraints.
Describe possible improvements you want to make for your mobile
Deployment application to expand its market share. These can be extra features to reach
considerations audiences in other countries or new cloud data storage to make your app
more adaptive.

You can represent your project scope using different tools. The most comprehensive is a
lean canvas. It represents the segments of a business plan crucial for developing
documentation for all mobile applications: groups of users and their main problems, solutions
your app is going to provide along with a unique value proposition (UVP), and other
advantages. In the lean canvas model, you can describe the channels you’ll use to attract
target users and key metrics that will tell you how your business is doing. A lean canvas also
helps you determine the monetization model for your mobile app along with other potential
revenue streams.
Dive deeper: How to make a business model canvas for a mobile app
To foster clear communication among all project stakeholders, at Mind Studios, we
additionally use a mind map. This tool mirrors the logic of a mobile application and the
interconnections between its main components.

Here’s a simple example of a mind map for a meditation app like Headspace:

Read more about how to make a meditation app like Headspace.

Remember that drafting business requirements involves all project players. It is always a joint
effort.

User requirements

After identifying your business requirements, it’s time to focus on your users’ needs. You
need to outline potential aims with which users come to your app and the actions they will
take to meet these aims. But whose opinion should you consider when drafting user
requirements?

The trouble is, there’s no single type of app user. On the contrary, there are many types of
users asking for different things: investors, business owners, end users, developers,
distributors, regulators, marketing staff, and others. Your task is to hear everyone and find
the balance between the needs of different user groups.
When it comes to user requirements, it’s sensible to start with these three steps:

Step 1 — Classify users. Group all stakeholders into user classes. You can sort them
according to the following criteria:

 Access level (guest, regular user, paying user, provider, administrator)

 Tasks they perform (find, view, read, select, buy, share, comment)
 App features they use (searching, mapping, sorting, comparing, paying, etc.)
 Frequency of visits (daily, monthly)
 Platforms used (iOS or Android)
 Native language (or other demographics like location, gender, education, and family
status.)

Read more about how to find the target audience for your mobile app.

Step 2 — Identify product champions. Choose individuals who can represent each group of
users and communicate user requirements to your project manager. Being a good product
champion means having a clear vision of the benefits your app will bring to users. In turn,
product champions must be actual users to perfectly understand users’ pains and urgent
needs.

Step 3 — Agree on the requirements decision-makers for your project. Agree on

representatives of each group of users with stakeholders. Be careful not to overlook any
stakeholder to avoid complaints that the final app doesn’t meet a stakeholder’s expectations.

After identifying eligible user representatives, get their input on two types of user
requirements.

User requirements
Outline tasks users want to perform within your mobile app and list
Functional user possible user–app interactions. Based on this data, you can derive the
requirements core functionality your app must provide to enable these interactions to
happen.
Non-functional user Gather users’ expectations related to your mobile app’s level of
requirements performance, security, usability, and so forth.
Describe possible improvements you want to make for your mobile
Deployment application to expand its market share. These can be extra features to
considerations reach audiences in other countries or new cloud data storage to make
your app more adaptive.

Record feedback from users in a user requirements document (URD). To do this, you can
use the following techniques:

A user persona is a useful tool that allows you to visualize your target users. For each user
persona, choose a name and a photo, then list the user’s needs, wants, and aims. Write key
reasons why the persona will use your app. Here is an example of a user persona we made for
a social media app like LinkedIn:
User stories. Itemize actions users will perform within your app to meet their goals. Then
arrange these actions in a natural sequence to determine a typical user journey through your
app. Depending on your project’s scope, you can primarily outline epics — intricate user
actions that you can decompose into smaller steps users will take while using your app. Epics
are user stories that tend to be written as follows: As a <type of user>, I want <some goal> so
that <some reason>.

In Agile development, user stories are often put into a product backlog. While negotiating the
scope of software development for the first and subsequent releases, you and your
development team will consider user stories from the backlog and select the most relevant.
By arranging user stories, you can form a product roadmap that clearly defines what app
features you should implement and when. The example below is related to the two most
common basic epics for any mobile app:
System requirements
A complete product requirements document for a mobile app should contain requirements on
how your app must operate. Resist the lure of hastily writing system requirements based only
on users’ wants and business needs. Talk to developers. They’ll give you feedback on
whether it’s technically possible to realize your original plans for the app’s functionality. In
talking to developers, you’ll reveal potential threats to your project development and can
collectively establish a plan B to sidestep them.

After constructive dialogue with your team, write down the agreed requirements in a
software requirements specification (SRS) that contains the following blocks:

System requirements
List the features developers can build to enable users to complete tasks
according to your business requirements. To do this, use existing mind maps
Functional
or user stories. After defining what your app will do, assign a unique name
requirements
and number to every functional requirement along with a short description,
rationale, and status.
Describe requirements for your mobile app from the perspective of software
Subsystem and hardware subsystems. For example, if you’re going to build a fitness
requirements activity tracking app, you’ll need to write requirements for wearable trackers
that will synchronize with the app.
Business rules Since every business is subject to laws, policies, and industry standards,
these will be obvious sources of requirements for an SRS. Here’s a shortlist
of requirement sources:
 System requirements

 Corporate policy
 Government regulations
 Industry standards
 User roles and permission ratings
 If-then models of user behavior
 Computational algorithms, if any

When developing a mobile app, you need to create, store, modify, display,
delete, process, and use massive amounts of data. To manage data flows, you
need to:

Data  outline a logical model of data entity interactions

requirements  define entities in the data dictionary
 specify how the system must enforce data analysis, retention, or
disposal
 choose types of data reports (spreadsheets, charts, dashboards, etc.)

Writing clear quality criteria ensures that developers will meet your
expectations with the end product. You need to consider quality attributes
that are important to:

 your business and users, such as usability, performance, and security

(external attributes)
 developers, such as efficiency, modifiability, and portability
Quality
(internal attributes)
attributes
Discuss what attributes are critical to your app’s success with other
stakeholders and prioritize them. Write specific expectations for each
attribute using fit criteria — a quantification of the requirement that
describes the standard your app must reach. Translate quality attributes into
technical specifications and write acceptance tests for your team to enable
them to check results.
External This part of a functional requirements document for a mobile application is
interfaces needed to ensure that your app will communicate properly with users and
external hardware or software systems. In an SRS, you need to write down
requirements for:

 User interfaces. Specify the design of your mobile app’s screens

(standards for fonts, icons, color schemes, images, screen size, layout,
resolution, and so forth)
 Software interfaces. Describe interactions between your app and
other software components including other apps, websites, libraries,
databases, and tools.
 Hardware interfaces. Outline each of the supported device types,
data and control interactions between software and hardware, and
communication protocols to be used.
 System requirements
 Communications interfaces. In an SRS for your mobile app, state
requirements for any communications functions your app will use,
including in-app messages, push notifications, emails, and network
protocols.

Record constraints that restrict your mobile app’s design, operation, and
implementation. First of all, check whether your mobile app requirements
specification aligns with Apple App Store and Google Play Store
Constraints
requirements. Additionally, specify other system constraints imposed, for
instance, by the programming language used or rules of using third-party
APIs or content.
If you want your app to be used in countries, cultures, and geographic
locations that differ from those in which it was created, then you should set
requirements for changing:

 Currency
 Date, number, address, and telephone number formats
Localization  Language (including national spelling conventions, local dialects,
requirements directions)
 Functionality to comply with regulations and laws
 Content in consideration of cultural and political issues
 Time zones
 Weights and measures
 Other variables

Let’s take a closer look at the tools you can use for representing system requirements in your
software requirements specification for a mobile app.
Spreadsheets offer a traditional presentation in rows and columns of app functionality you
intend to build. Let’s review a fragment of the functional requirements spreadsheet we
drafted as part of a real estate mobile application development document:
You might be interested in: How to make a real estate app like Zillow.

An entity-relationship diagram (ERD) represents how data entities relate to each other
within a system and connections between elements within those entities. The following is an
example of a diagram we used in a requirement specification document for a food delivery
mobile application:
Learn more about building a food delivery app like Postmates
Ways to develop and manage requirements

As your project evolves, changes to software requirements for your mobile application are
inevitable. New requirements can come from anywhere: Your investors can insist on getting a
return on investment faster than you planned; users can go to a competitor’s app because your
app doesn’t provide a feature they like; subsequent software updates can impose extra
restrictions on your mobile app development.

It’s tempting to outline software requirements for mobile application development once and
for all, but doing this can lead you to project failure. Let’s figure out why requirements
development is an iterative process.

Drafting requirements for your mobile app project is commonly about performing four
activities:

1. Elicitation, or asking what users expect from a new product, listening to what they
say, and watching what they do
2. Analysis, or processing user feedback to understand, classify, and relate this
information to possible mobile app requirements
3. Specification gathering, which involves turning vague user input into thoughtful,
structured, written requirements documents with visual illustrations
4. Validation, which is about drawing confirmation from stakeholders that the
requirements specification you’ve created is accurate and complete
While conducting analysis, you can realize some inaccuracies that turn you back to
elicitation. And while writing a mobile app product requirements document, you can bump
into some gaps that require you to conduct more analysis. If stakeholders point out errors in
your requirements document, you will have to rewrite some statements, conduct a re-analysis,
or even conduct a follow-up poll. Only by interweaving and iterating these activities can
you provide stakeholders with relevant mobile app requirements through the whole
development cycle.

At Mind Studios, we define and agree upon initial product requirements at the discovery and
idea validation stage by taking the following steps:

Define business requirements

Identify stakeholder groups
Select requirements decision-makers
Analyze the target audience by conducting:

 focus groups
 interviews
 questionnaires
Elicitation
 workshops
 search queries
 social media analysis
 forums research

Perform document analysis

Examine problems with previous solutions
Identify user requirements
Conduct SWOT analysis of competitors
Analyze idea feasibility
Flesh out requirements
Analysis Prioritize requirements
Derive functional requirements
Make sketches and mock-ups
Create a glossary
Adopt a requirements document template
Record business rules
Specifications
Specify non-functional requirements
Document requirements using diagrams, spreadsheets, and wireframes
Create prototypes
Test requirements
Validation
Correct requirements
Define acceptance criteria

Read more Mobile app development process for launching successful apps.

In the name of your project’s success, you need to rein in requirement volatility with sound
management. A project manager and/or a business analyst can take on this responsibility.
Project managers and business analysts have different requirements management tools to:
  Track the need for changing requirements
 Perform impact analysis to determine what these changes will bring to project
development
 Trace requirements maintenance
 Track the status of each requirement
 Track requirements issues
 Maintain a history of requirements changes

Characteristics of a good mobile app development

requirements document

Since nowhere more than in product requirements do the interests of all stakeholders
intersect, you need to be sure your requirements are equally clear and understandable to
investors, users, and developers. How to build a mobile app requirements document to meet
everyone’s needs? Not only the contents of a requirements document but the tone of voice
can help you with this.

Go above and beyond to get a high-quality product requirements document. Discuss the level
of detail, representation techniques, and writing style that are best for stakeholders.

In a perfect world, your mobile app requirements stated in a PRD should be:
  Complete. For example, each functional requirement should contain enough
information for developers to be able to implement it correctly. If you have some
gaps, mark them as TBD (to be determined) and follow up on them later.
 Correct. You and your development team should both verify the correctness of your
mobile app’s product requirements document. You can consider requirements correct
if they conform to technical specifications, business rules, industry standards, and
relevant laws.
 Consistent. This means no requirements in a PRD should contradict other
requirements in the same PRD.
 Feasible. It must be possible to realize each product requirement within the operating
environment on hand, given the known staff capabilities, time, and budget. The Agile
development methodology and proof of concept prototypes help you evaluate
requirement feasibility.
 Prioritized. Each requirement, be it a functional requirement or a user requirement,
must be ranked for importance to be implemented for a particular release.
 Modifiable. Since requirements can change during development, your product
requirements document structure needs to be flexible.
 Verifiable. Product requirements must be measurable and specific so that testers can
check them with tests and determine whether a particular requirement is properly
implemented.
 Unambiguous. One of the main reasons to write a mobile app product requirement
document is to reduce miscommunication. You need to write every requirement so it
can only be interpreted in one possible way.

We strongly recommend creating a glossary of terms from the outset of development. The
fact is that developers aren’t familiar with your business speak, and probably you aren’t
proficient in programming. A lack of understanding of terms can lead to rework, missed
deadlines, cost overruns, and unnecessary debates.

A mobile app requirements document template

Some businesses demand a detailed list of requirements backed by a well-thought-out
technical specification, while others are content with a shallow approach. No matter what
group you belong to, you have to start somewhere.

As guidance to develop initial requirements, you can fill in our mobile app product
requirements template. It provides enough core information to ease and accelerate a
developers’ entry into your project and, therefore, to save you time and money.

Mobile app product requirements document brief made by Mind Studios

Introduction

Briefly outline what industry your business is in, the idea behind your mobile app (What
made you think of building an app?), and how you expect the app will improve your business.

Business requirements

1. Why did you decide to create a mobile app?

 o To share your unique experience
o To create an extra revenue stream
o To improve current business processes
o To get a return on investment
o Another reason
2. What is the main purpose of your project?
o To launch a new business, product, or service in a new market
o To enhance brand awareness apart from the website
o To make improvements to, redesign, or create a new version of the current app
o Something else
3. What category does your app belong to?
o Gaming
o Entertainment
o E-commerce
o Education
o Lifestyle
o Utility
o Travel
o Other
4. What are your financial and nonfinancial business objectives?
o Financial objectives: I want to capture an X% market share within Y months.
o Nonfinancial objectives: I want to be rated as the top mobile app in its
category in the Apple App Store and Google Play Store by a specific date.
5. What do you expect your app will do?
o Describe core functionality
o Offer a unique value proposition
6. Who are your direct and indirect competitors?
o List three to five main competitors in your niche (along with links)
o State features you like and dislike in your competitors’ products
7. What is your product vision?
o For (your target users) who (need to or want to change something), (name of
your mobile app) is a mobile app that will provide (a killer feature). Unlike
(current business model or competitors), my app will provide (main
advantages).
8. Choose your monetization model:
o Paid advertising
o In-app purchases
o Freemium subscription
o Premium subscription
o Something else

User requirements

1. Describe the user roles in your app:

o Guest / regular user / paying user
o Buyer / seller
o Customer / executor
o Student / teacher
o Provider / administrator
 o Your classification
2. Based on user roles, create up to three possible user personas considering the
following criteria:
o Demographics (age, gender, family status, education level, job type, location)
o Psychographics (pain points, aims, needs, vital problems, attitudes,
motivations, opinions)
o In-market behavior (apps used, sorts of services/goods bought, reasons for
using the app or buying the product or service, solvency)
3. Determine your target users’ preferences in terms of:
o Device type: smartphone, tablet, desktop, smartwatch, smart TV
o Platform: iOS, Android, cross-platform
4. Describe the user journey:
o Sketch a typical path your users will take within your app to get desired results
o Add links to sketches of possible app interfaces

System requirements

1. Describe the features you want your app to provide users with:
o List up to three must-have features
o Add links, if any, to examples of how a particular feature needs to look
2. What type of content would you like to add to your app?
o Videos
o Audio
o Animations
o Images
o RSS feeds
o Other
3. What current services, servers, and databases do you use?
4. What third-party applications, services, and databases do you need your app to be
integrated with? (payment gateways, social media, etc.)
5. What operating system versions should your app be compatible with?
6. Describe your UI requirements:
o Mobile app style
o Color scheme
o Logo
o Icons
o Buttons
o Images
o Fonts
o Link to brand guidelines the team needs to follow
7. Do you have current provisioning profiles in the Apple App Store and/or Google Play
Store?
8. What hardware does your app need to synchronize with? (wearable devices, drones,
etc.)
9. Describe your app’s quality criteria regarding:
o Usability
o Performance
o Security
o Safety
 o Other quality attributes
10. What languages should your app be translated into?

Other requirements

1. What are the constraints and limitations within which the team must work?
o Business rules
o Industry standards
o Government legislation
o Other possible constraints
2. What is your project timeline and budget?
o When do you expect to start and finish the project?
o What is the approximate budget (USD) you can allocate to the project?
3. What services would you like to request from your software development team?
o Full-cycle mobile app development
o Website development
o Continued support and maintenance
o Promotion and marketing
o Interface design
o IT consulting
o Additional services

After you complete this brief, email it to us and one of our managers will respond promptly.
This brief will provide a solid basis for creating a detailed mobile app product requirements
document with the help of our team.

Have any questions about your mobile app project? Drop us a line.

Final word
Even for the smallest projects, it’s critical to have a shared understanding of initial
requirements. In some cases, ready-made product requirements document templates can help
you out. But more often, they’re only illustrative. Since no two apps are alike, there’s no
chance that someone else’s PRD will suit your project.

To perfectly meet your specific tasks, you need to create an original mobile app
requirements document, which can be a time-consuming and tedious process. The good
news is that you can leave it to experts. Especially since they’re just one call away.