How to Write a Specification For A Mobile App Development Project
Each mobile application development starts with a concept.
But how can you be sure that the concept is aligning with the needs of users, helping them to solve their real issues?
Moreover, an implementation of the concept should meet the needs of the business it’s gonna build up, otherwise, it may provoke project failure or heavy financial losses.
According to PMI’s Pulse of the Profession in-depth report, about 47% of all unsuccessful projects failed to meet goals due to poor requirements management.
…about 47% of all unsuccessful projects failed to meet goals due to poor requirements management.
For every mobile app development company, the best way to overcome these issues is to develop a good specification for mobile.
It helps to get the following points covered:
- To be on the same page here;
- To negotiate changes easily;
- To be sure that the requirements are relevant to the business goals;
- And get rid of doubts that something essential was missed.
Why Is It So Critical to Write a Good App Spec for Your Project?
The project management triangle model shows dependencies between the different project constraints – cost, scope, time and quality.
This model also states that PM is able to trade between these features.
These parameters are impossible to control given your mobile app comes with no specs.
For example, a customer wants to add some new features somewhen in the middle of the development process.
As a result, the scope increases but PM has no evidence that the requirements weren’t previously included.
So the only two ways for a manager to keep the cost stable is to either reduce quality or to increase the timescale.
Sad but true.
One more reason to write mobile app requirements is that it is the most efficient way to coordinate the scope in writing.
It is rather helpful for both you and your mobile app development partner.
What are the Specifications for Mobile Development?
The mobile app development requirements sheet document is made up of far more than just requirements.
One of the best practices is a Software Requirements Specification created by Karl Wiegers.
Below you can find out what’s typically in the document named SRS.
Keep in mind that names, contents, and order may be substantially different, it’s up to an author.
Purpose – identify the purpose of the document in a few sentences.
Document conventions – terms and definitions in the document.
Intended audience – descriptions of the different types of readers the document is intended for.
Project scope – a short description of the software features related to business needs.
References – all the external links required.
2. Overall Description
Product perspective – the description of the context and origin of the product prepared in a special form.
Product features – all the features that will be implemented in the app in a short table view.
Users roles and rights – the description of the user classes in a short table view.
Operating environment – hardware and software platforms, other products that must be taken into account.
Design and implementation constraints – everything that marginalizes the thinking-outside-the-box of developers and designers.
User documents – a list of user-related documents that will be released along with the app.
Assumptions and dependencies – here you can place everything that is unclear to classify at the current stage.
3. System Features
Here are all the functional requirements in the form of the major services provided by the app. For each one it should contain:
- Description and priority – a detailed description and purpose.
- Stimulus/Response sequences – a trigger that launches the feature.
- Functional requirements (Use Cases, User Stories) – a scenario user interacts with the feature, from the beginning till the end, including alternate scenarios and exceptions.
4. External Interfaces
Here is a place for any interfaces involved in the project.
- User interfaces – prototype and description of all the app screens and display sections. Screens (tabs) should be presented separately, with images, presentations, and all other visual materials available.
- Hardware interfaces – logical and physical characteristics of the interfaces between the app and hardware. Device models, physical controls usage, communication protocols engaged.
- Software interfaces – APIs, cross-platform compatibility and operation systems, databases, third-party software tools, and integrated components.
Clarify if your mobile app should be integrated with social media.Here is the option of setting up your mobile app to send any data from/to an external server and providing some general description of the server part.Other tunable parameters include printing availability, in-app purchases availability, geo-data functionality support and push notifications.
- Communications interfaces – e-mail, browsers, server exchange protocols, message formatting definition.
5. Concerns / Queries / Doubts if any:
- Performance – measurable parameters relating to the speed of work, productivity, etc.
- Safety – any cautions that must be taken into account to avoid possible injury.
- Security – all the required standards and arrangement must be implemented to dodge data breaches.
- Software quality attributes – anything related to the quality measures of your app.
6. Other Requirements
Any other requirements that aren’t placed elsewhere.
- Appendix A: Glossary
Contains links to the definitions without which make it easy to interpret the SRS correctly.
- Appendix B: Analysis Models
Place here diagrams and other visual modeling results. The DFD is necessary.
- Appendix C: Issues List
A placement for everything that is unfinished yet. Use the TBD (To Be Determined) note for such cases.
Should My Mobile App Requirements Be Such a Bulky?
There is no need to copy the provided structure in full. If a project is simple enough, it’ll be better to exclude all unnecessary parts.
The most essential rule is to cover as many requirements as possible.
Keep in mind that elective requirement in the specifications for mobile is much better than missed but necessary one. Of course, it doesn’t mean adding new useless features.
As we said before, there are three major categories of stakeholders, each with its own layer of requirements: business requirements at the top, user requirements in the middle, and technical requirements at the bottom.
All the three types of requirements must be traceable in between.
How to Approach the Writing?
Although writing specifications is quite big and time-taking, this is no big deal.
If you understand what an app should look like, all you need is just flowing from simple to complicated.
Describe your idea.
Say a few words about its main features, specify, for whom the app is intended.
Don’t forget to add as much context details as you can, e.g. say something about its closest competitors or about an unoccupied niche.
Then conduct a kind of research to specify the most relevant technologies and tools to implement your idea.
Now you have a ready-made text for a Product perspective section.
Determine basic navigation patterns.
Use your imagination to come up with all possible actions users will take while using the app.
Point out everything that users do, as well as each and every answer the system gives you out. Then analyze the actions to find out which ones were missing, and write them down too.
Once the list of actions is full, analyze each action and search for alternative scenarios and possible exceptions.
Usually, scenarios are pretty similar to ping-pong: actions of the user and the system constantly interleave each other.
Pick up market information.
The requirements specification document isn’t really a place where in-depth marketing research should be placed.
Add some details of your targeted audience – whether they prefer iOS or Android phones, which sex is prevailing, what’s an average age, income level or geography?
Choose what features an application should have.
Return to your feature list to validate and prioritize all of them. Maybe some features look redundant while others might be shorter?
Use a simple analysis method called “MoSCoW”.
It means that all the features can be divided into four groups – must, should, could and won’t (I hope you don’t need a further explanation).
Update the features: there must remain only those that correlate with your business goals.
Prepare functional specification.
For most people, this section looks much more complex than all the previous ones.
At a first glance it is, but it’s really not. We’ll walk you through. For starters, use your validated scenarios to make a table with the users’ roles.
Then create a table with your product features. After that, it’ll be quite easy to finish the System features section.
There are many other tables to go, but all of them are way too short. Moreover, after a little review, you should learn two things.
The first one is that you don’t need half of non-functional requirements.
The second one is that you can find all the data for the rest of the tables, using Google search.
Way to go!
Provide wireframes to complement the text.
The last stage is the most time-consuming. You don’t need to draw every last screen of your app, but all the features described before must be covered by the wireframes.