How to Build a Mobile App Requirements Document

A mobile app requirements document (PRD), also known as a product specifications document, acts as the foundation of your product, outlining the business logic, listing the technical specifications, and ultimately guiding your team from early concepting stages to the final sprint.

Product teams use the PRD to guide the development of the mobile app so that they understand what is required to build the product. The purpose of the product requirements document is to build a compelling product which means you need to gather a lot of research on your competitors, users, technologies, and your team’s capabilities.

Quality products start with a need that it is trying to address. The product requirements document will help your team have a clear understanding of what the need is, and how your product addresses it. While there are different ways of organizing what this document looks like, we find it beneficial to include both Business Requirements and Product/Technical Requirements, as well as a few other considerations that will help best prepare your engineering team to get your product to market. Here’s how to build an effective mobile app requirements document.

Business Requirements

Business requirements are criteria that are necessary to meet organizational objectives. Typically they outline how the product or solution will address the needs of the company and/or its users.

These considerations are commonly included when mapping out business requirements for a mobile app requirements document:

• What is the purpose of the app or product? What are you trying to accomplish?
• What is the current problem(s) it will solve?
• How will it streamline or improve the current process or facilitate a new process?
• What is the product vision?
• What aspects are already in place? What needs to be added? Will the app need to be started from scratch or can you leverage existing assets?
• What should the app be able to do (ie. functionality)?
• What features will it need?
• What is the monetization or business model?
• Are there branding and design guidelines that need to be followed?
• Is the ask feasible?

Product & Technical Requirements

Source: Jordan Goms via Slideshare

Product and technical requirements outline the systemic and technical needs in order for the product to achieve the desired features and functionalities.

The following should be determined within the product/technical specifications for your mobile app requirements document:

• What platforms will the app be built for (iOS, Android, etc)?
• What should operating system versions support it?
• What are your current services, servers, databases?
• What are your maintenance needs? Do you need to support it for the future?
• How long should the app function before an overhaul is needed?
• Do you have current API/services documentation?
• Do you have current Apple, Google, or other developer accounts/credentials?
• Do you have existing provisioning profiles?
• Are there other credentials that are needed or already exist (analytics systems, platforms, etc.)?

Dependencies

Dependencies are any aspect that the product or product team relies on in order to meet objectives. These may include:

• Hardware that the app will run on/communicate with (for example, beacons)
• Service/API documentation
• Profile/account/platform credentials
• Any third-party software your app relies on
• Any flowcharts, documents, or information related to the product

Assumptions

Source: Lean Startup 101 via Slideshare

In the early stages of a project, there are assumptions about the product that we believe to be true based on knowledge, experience, or current information. Typically, these include:

• Assumptions about the user (for example, X% of users will see enough value in the product to become regular users)
• Technical assumptions (for example, technical requirement A will work on the latest operating system)
• Business assumptions (for example, we can develop the product in proposed time frame)

Constraints

Constraints are the limitations that teams must work within, typically scope, budget, and time. However, they may also include aspects like risk tolerance, resources/staff, and quality requirements.

Submission

Your mobile app requirements document should include all technical assets and information required for app store submission. Defining these requirements early will significantly expedite the submission process when the product is ready for release. While these will vary depending on the app stores being submitted to, below are the assets and information to include for Apple App Store and Google Play.

General Assets

• Icons of supported sizes (iOS: @1x @2x @3x images | Android: mdpi, hdpi, xhdpi, xxhdpi)
• Splash screens of supported sizes (iOS: @1x @2x @3x images | Android: mdpi, hdpi, xhdpi, xxhdpi)
• Screenshots in correct sizes, in required languages
• App descriptions in required languages
• Search keywords in required languages
• List of supported devices and OS versions

Apple App Store

• iTunes Connect Account access
• Company/Entity Name
• Search keywords
• Bundle id / SKU
• Demo account for reviewers
• Description
• Support URL
• Marketing URL
• Privacy policy
• App category
• Copyright information
• Contact information
• App icon (1024×1024)
• App Store distribution code signing identity
• Screenshots (correct sizes based on devices)

Google Play

• Google Play Developer access
• Store listing name
• Paid/free
• Short description
• Full description
• App icon (512×512)
• Feature Graphic (1024×500)
• App type
• App category
• Content Rating
• Contact Email
• Privacy Policy
• Screenshots (correct sizes based on devices)

Things to Keep in Mind For Your Product Requirements Document

Above we’ve gone through some of the aspects to include for your mobile app requirements document. When you’re crafting your requirements, you’ll also want to keep the following tips and considerations top of mind:

• Requirements documents can (and probably should) be high-level, as it’s likely the product will change and evolve as new information and learnings become available
• Be wary of too much detail. While this may seem counter-intuitive, you want to ensure that your product requirements document allows for a degree of flexibility. Intricately detailed documents that are drawn out before engineering begins will most likely need to be changed as the project progresses, which results in wasted time and resources
• Also be wary of too little detail. A product requirements document shouldn’t be underspecified. Make sure that all important areas are covered. Run the document by the development team to ensure that nothing is overlooked
• Don’t build your requirements without input. Your team has a variety of experience and insight; take advantage of it

The ultimate goal of creating a mobile app requirements document is to provide a foundation for a successful product. Mapping out business and technical requirements, dependencies, constraints, assumptions, and submission assets will give your team the ammunition needed to get your project off the ground. During development, questions are bound to come up, even with the most thorough PRDs. If questions are not answered in the document, make sure you add them in order to avoid any miscommunication.

During the process of defining the product, it is important to always focus on delivering superior value to the marketplace. It is easy to get distracted by competitors, vocal customers, and architectural issues, and you do need to understand those needs, but in defining a good product, always remember to focus on the value.

Source

How to Build a Mobile App Requirements Document