The Google Play Store hosts 3.3 million apps, as on September 2017, but not all apps are equal. Users rate a good number of these apps below par, and such apps have very few downloads.
Several factors contribute to the poor performance of an app. Some common causes include faulty design, poor user experience (UX), excessive bugs and lack of focus on functionality.
Another factor is that in many projects, the app owner and the developer are not on the same page.
Visualize yourself in a situation where you want to build an app. Next thing you would do is search for a developer who can build your app and describe your ideas to him. Despite thinking you were on the same page, when the developer unveils the app for the first time, it’s a far cry from what you actually wanted.
What went wrong? Vague, informal ideas could be the underlying reasons. When this happens, the developer may build the app in a way that the owner didn’t intend it to function. This disconnect can cause problems with the app as well.
As a developer, how can you pre-empt problem scenarios from happening?
Make sure all project requirements are crystal clear before you start any work. Preparing an app requirements document provides clarity on any new app, getting everyone on the same page in all aspects of the project. Share this document, which describes how you see the result of the development process, with the developer.
In this article, we will walk you through the most common approaches to writing requirements documents. We will help you with the basic steps of writing mobile application requirements and what a good requirements document looks like.
App Development for Beginners: The Basics
Developers need to seek clarity on six main components of a project before they start the actual task of application development:
- The text narrative or user story
- Project scope
- Technical specifications
- Sketches and wireframes
- Asset creation
- Putting everything together in a workflow document.
These six components constitute the core of an app requirements document. Developers need to hammer out consensus on all these components with the app owners before any code is written. Ideally, the project stakeholders, especially the developers, business owners, and managers, get together and reach consensus on each of the above-listed items.
An important point to keep in mind upfront is the fact there are no hard and fast rules, or any rigid format, for the app requirements document. This checklist covers the essential components included in most documents, but you can include additional information based on your own project’s needs. If you’re a new developer, you should find this checklist handy, so that you can develop the app requirements document in a structured way, without leaving anything out.
1. The Text Narrative or User Story
The user story is the first methodological step in the mobile app development process. It narrates what the app will provide for the intended users, and it also lists the target customers for the app.
The best user stories are a collaborative effort. The process of developing the text narrative involves the development team, business managers, and end user. These stakeholders get together to identify what problem the app would solve, or what aspect of company operations the app would improve. They prepare a specific list of features of functionality for the app.
A proper narrative pinpoints the core feature of the application. It goes into detail, leaving no scope for ambiguity. It lists the various possibilities with the app from the user’s perspective. Often, a large story is split into sub-stories, to focus on a specific user-case scenario.
The best user stories are simple and easy to understand. While the user story cannot, by itself, be the foundation for developing the app, it offers a good starting point.
2. The Project Scope
User stories are not a technical document, and do not come with any rigid format. The project scope extracts definite and technical requirements from the user story, to give a coherent shape to the purpose of the app. It also lists out all the components to be included in the app.
A good scope outline addresses the purpose of the app, in other words, the problems it would address or the process it would streamline. Writing the outline upfront gives a definite direction and goal for the app.
The project scope encompasses the business model of the app, as in whether the app is for the customer or internal employee, whether the app is for monetization, and so on. The structure of an app depends on the business model. For instance, an app aimed at monetization may require paywalls. An app meant for internal employees may be lean and minimalist in design. A customer-facing app, on the other hand, may require more assets such as images and banners.
The scope deals with the extent to which the app would leverage any assets already available to the company or the end user, and the new assets, which would be required to support the app. For instance, if a company launching a new mobile app for employees already has a BYOD (Bring Your Own Device) ecosystem running on Android phones, the app can be installed directly into those phones. On the other hand, if the company is launching a new highly-secure iOS app for top management, and the intended users do not have Apple iPhones, the new app would require the purchase of new smartphones.
The scope also lists out the constraints or limitations applying to the project. The most common limitations relate to budget and time. Other limitations relate to scope, risk tolerance, resource availability, and staffing. Clarity on such limitations makes sure the development team does not go overboard during the development process, and reconciles practical limitations to best practices.
Scope clarity is very important to plan out each feature and functionality. Each component of an app is interlinked, with one leading to another. A specific functionality may be tied to—or dependent on—another one, meaning that adding features and functionality at a later stage could lead to major chop-and-change to the entire code and architecture. Rework at a later stage subverts the project budget and timelines, and may take the wind out of the project’s sails.
3. Technical Specifications
The scope outline leads to framing the technical specifications of the project. Listing the technical specifications of the project in the app requirements document is essential to determine the practical budget of the app, and in identifying the amount of time and effort required for the project. It’s important for management and the people paying for the app to understand exactly what the project will require in terms of time and money so that they won’t be surprised later in the development process or ask for unreasonable changes.
A good list of technical specifications details the platforms on which the app runs, and the versions of the OS supported by the app. The app may be developed as a cross-platform one, or developed for Android, iOS, or Windows OS.
The list of technical specifications may contain profile, account, and platform credentials. The most essential credentials are Apple, Google, or other developer accounts. While such information may be sourced at a later stage as well, without affecting the development process, identifying such information upfront means that you won’t have to go back and gather information again later on in the process—and the app can be launched immediately when ready, without wasting further time on the account.
Another key inclusion in the list of technical specifications is a blueprint for the post-launch maintenance of the app. All apps require post-launch support. A good app requirements document lists out the extent of support the app will require, and at which times such support will be needed.
All apps will definitely require services documentation, so including these resources in the technical specification gives you a more comprehensive list.
All apps run on an ecosystem of third party software, servers, and databases. Apps also make use of dependency hardware to communicate, and in some cases, just to run. For example, beacons may power an IoT (Internet of Things) enabling app. An app designed to power a touch-screen kiosk would require the kiosk itself as dependent hardware.
The best technical specifications lists are comprehensive and detailed. However, at the same time, it does not go into the finer details, such as the color of a button. These finer details may safely be fixed at a later stage, without changing the scope or budget of the app.
4. Sketches and Wireframes
The UX makes or breaks an app. A good UX makes it easy for users to find what they seek, improving customer satisfaction. Wireframe sketching is a vital part of UX designing. Based on user requirements, the UX designers use a wireframe to define the hierarchy of items on the screen, and any possible functions.
Why are wireframes important during the mobile app development process?
No matter how competent you are, it’s impossible to go from an idea to immediately building it out without hashing out the details in between. Sketching out your idea before you build it is necessary for every designer.
Wireframe for mobile app development is what blueprint is for architecture. A wireframe is a visual concept of your future app or, say, the guidebook for the whole construction process. It may not give any idea about the design but helps in understanding how your future app will work. Sketches and wireframes make explicit the relationship between different features and functionality. They also illustrate the action-response sequence.
In this section we will guide on how to go ahead with the wireframe sketching.
Start with detailed screen sketches to render clarity to the requirements. A sketch is basic in nature, making explicit what the user will see on each screen. The screen design sketch illustrates the chain of sequence. Each new path, triggered by user action, represents a scenario, and ties back to the project scope. For example, a sketch might illustrate what happens when a user performs a swipe-down action.
Then create a wireframe, which refines the concept, making explicit in great detail how the app will work. The wireframe is usually prepared in pixelated grayscale widgets, and goes into the exact sizing, placement and order of elements.
Innovative designers translate user stories into wireframes that provide a comprehensive description of the proposed features, and how such features would appear on the app screen.
The best practice for creating a good user experience interface, especially if you are new at developing apps, is to proceed in the same sequence that a standard user would proceed in when using the app. The most common starting point is the onboarding screen and user registration. From there, you should cover all paths and eventualities in the user’s journey.
The success of an app depends on an awareness of what forms a good UX. A knowledge of standard navigation patterns, how to link different screens, and the relationship between various elements also helps. It’s important to create a document that covers all eventualities, such as how the app will behave when a user opens it with a push notification.
The development team may also include any necessary branding and design guidelines into the sketches and wireframes.
5. Create the Required Assets for the App
A well-written requirements document describes all the technical assets and information required for app store submission.
Though the app store information might vary depending on the app stores themselves, some of the assets information to be included are supported sizes of icons, supported sizes of splash screens, correct sizes for screen shots, app descriptions and keywords in required languages and a list of supported devices and OS versions.
The development team may choose to create such assets upfront and before coding, which would quicken the submission process when product is ready to go. They could also choose to wait and develop the assets at a later stage, and integrate it into the software at the end. Many developers choose to outsource such asset creation tasks, enabling simultaneous development.
6. Putting It All Together in the App Requirements Document
The mobile app requirements document outlines how the product or solution addresses the needs of the company or the users for whom the app is made. It compiles all the above-listed elements in one place and becomes the base reference document for the entire development team and other stakeholders.
The app requirement document leads from the narrative to the scope outline, and from the scope outline to the page design. It also lists out the technical specifications, and the list of assets connected with the app. The page design becomes the basis for co-opting documentation on graphics and video or audio files.
The best requirements documents are:
- Easy to read, with clear and concise language
- Precise and detailed, leaving no room for ambiguity
- Iterative; while the finer details may change, the basic requirements remain constant
- Collaborative, co-opting the views of all the stakeholders associated with the app.
The Template As a Guide
The above-mentioned steps to prepare a great mobile app requirements documents are a guide for you to use. The best practices are not set in stone.
There are several formats in vogue for the app requirements document. The most common methods include a functional specification document and storyboarding. The best method to document the requirements depends on the nature of the project. The best format depends on the project it is specific to.
However, regardless of the format, each of these key components is critical in the app development project process, especially if you’re a new developer.
The app requirements document constitutes the blueprint on what exactly goes into the app, and is, in a way, the technical agreement between the developer and the company or person who will own the app. Without it, the development process may end up chaotic, with ambiguities, follow-ups with different stakeholders for confirmation, and even scope creep, which can wreck a project.
| Published on Web Code Geeks with permission by Vinod Saratchandran, partner at our WCG program. See the original article here: The Beginner’s Guide to Mobile Application Requirements Documents Opinions expressed by Web Code Geeks contributors are their own. |
