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 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
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 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.
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.
- 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
- App Store app listing name
- Search keywords
- Bundle id / SKU
- Demo account for reviewers
- Support URL
- Marketing URL
- App category
- Copyright information
- Contact information
- App icon (1024×1024)
- App Store distribution provision profile
- App Store distribution code signing identity
- Screenshots (correct sizes based on devices)
- Google Play Developer access
- Store listing name
- Short description
- Full description
- App icon (512×512)
- Feature Graphic (1024×500)
- App type
- App category
- Content Rating
- Contact Email
- Screenshots (correct sizes based on devices)
Things to Keep in Mind
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.