How to Write a Specification For A Mobile App Development Project 

Specifications are great tools for making sure everything will run smoothly on a development project.

Mobile app dev projects are no exception to this golden rule.

Let’s see why specifications are so important and how to write them in the best way!

 

The logic behind project specifications

 

I will start with a simple fact: each mobile application development project should aim to help users solve their problems.

If the app does not meet the needs of the customers it was created for, the development project could result in total failure and heavy financial losses.

This concept is pretty obvious, but not so straightforward to implement …

In fact, according to PMI’s in-depth Pulse of the Profession report, approximately 47% of all unsuccessful projects fail to achieve their goals due to poor requirements management.

 

Approximately 47% of all unsuccessful projects failed to achieve their goals due to poor requirements management.

 

A great project specification is the best answer

For any mobile app development company, the best way to overcome these problems is to set a good mobile app project specification.

This tool helps cover the following points:

• Being on the same page
• Easily negotiating any changes
• Being sure that the requirements are relevant to the business objectives
• Getting rid of any doubts that something essential has been lost

 

Why should you write a good project specification?

The “iron triangle” project management model shows the interconnections between different project variables: cost, scope, time, and quality.

This model also claims that the PM is able to trade off between these four features. But these parameters are impossible to control properly if your mobile app has no specifications.

Think about a customer who wants to add some new features during the development process.

 

As a result…

The scope increases but the PM has no written evidence that the requirements were not previously included.

So the only two ways a manager can keep the cost stable is to reduce quality or increase development time.

OUCH!

That’s why a specification is so important: it helps both you and your partners to set in writing the mobile app requirements and avoid misunderstandings.

 

  

What is a good mobile app specification?

The document with mobile app development requirements consists of more than just requirements.

One of the best models is the software requirements specification (SRS) created by Karl Wiegers.

Below you can find out what’s usually in this SRS document.

Keep in mind that the names, contents, and order can be substantially different: it depends on the author.

 

1. Introduction

Purpose: it identifies 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 brief description of the software features related to business needs.

References: all 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 characteristics that will be implemented in the app in a short table view.

User roles and rights: the description of user classes in a brief table view.

Operating environment: hardware and software platforms, other products that need to be considered.

Design and Implementation Constraints: Anything that marginalizes the outside-the-box thinking 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 anything that is still not clear to classify in the current stage.

 

3. System features

Here are all the functional requirements in the form of the main services provided by the app. For each one it should contain:

Description and priority: detailed description and purpose.

Stimulus / Response Sequences: A trigger that initiates the feature.

Functional Requirements (Use Cases, User Stories): The user of a scenario interacts with the functionality from start to finish, including alternate scenarios and exceptions.

 

4. External interfaces

Here we describe all the interfaces involved in the project.

User interfaces: prototype and description of all app screens and view sections. Screens (tabs) must 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 the hardware. Device models, use of physical controls, communication protocols, and so on.

Software Interfaces: APIs, cross-platform compatibility and operating systems, databases, third-party software tools, and integrated components.

In this section, you should clarify if your mobile app needs to be integrated with social media.

You should also specify the ability to configure your mobile app to send data to/from an external server and provide a general description of the server part.

Other adjustable parameters include print availability, in-app purchases availability, support of geographic data functionality, and push notifications.

Communication interfaces: e-mail, browser, server exchange protocols, the definition of message formatting.

 

5. Any doubts / questions / concerns

Performance: measurable parameters relating to working speed, productivity, etc.

Safety: all precautions that must be taken into account to avoid possible injury.

Security: All required standards and provisions implemented to avoid data breaches.

Software Quality Attributes: Everything about your app’s quality measures.

 

6. Other requirements

Any other requirement that is not placed elsewhere.

Appendix A – Glossary: It contains links to definitions that facilitate proper interpretation of the SRS.

Appendix B – Analysis Models: Here you can put your diagrams and other visual modeling results. The DFD is required.

Appendix C – List of problems: A place for all that is still unfinished. Use the TBD (To Be Determined) note for these cases.

 

Should my mobile app requirements be so bulky?

It is not necessary to fully copy the structure provided. If a project is simple enough, it will be best to exclude all unnecessary parts.

The most essential rule is to cover as many requirements as possible.

 

Better something more than something less

But keep in mind that putting additional (and non-essential) requirements into the mobile app development specification is much better than missing out on something necessary.

Of course, it doesn’t mean randomly adding tons of unnecessary new features.

As we said before, there are three main categories of stakeholders, each with their own level of requirements: business requirements at the top, user requirements at the center, and technical requirements at the bottom.

All three types of requirements should be found in a good specification.

 

How to approach specification writing

While writing specs is quite lengthy and time-consuming, it’s not a big deal!

If you understand what an app should look like, all you need to do is simply go from simple to complicated.

 

1. Describe your idea

Say a few words about its main features and specify who the app is for.

Don’t forget to add as many contextual details as possible. For example, say something about its closest competitors or an unoccupied niche.

Then conduct some sort of research to specify the most relevant technologies and tools to implement your idea.

You now have a text ready for a Product Perspective section.

 

2. Determine basic navigation patterns

Use your imagination to devise all possible actions that users will take while using the app.

Point out everything users do, as well as any response the system gives you. Then analyze the actions to find out which ones were missing and write them down too.

Once the list of actions is complete, analyze each action and look for alternative scenarios and possible exceptions.

Usually, the scenarios are quite similar to ping-pong: user and system actions constantly alternate.

 

3. Collect market information

The requirements specification document isn’t really a place where thorough marketing research should be placed.

All you need to do is investigate your main competitors: platforms on which their products work (iOS, Android, or both), roughly estimated popularity, etc.

Add some details of your target audience: if they prefer iOS or Android phones, which gender is prevalent, what is the average age, income level, or region…

 

4. Choose what features an application should have

Go back to the list of features to validate and prioritize some of them. Maybe you’ll notice that some features seem redundant while others might be shorter.

For this purpose, it is possible to use a simple analysis method called “MoSCoW”.

According to this method, all the features can be divided into four groups: must, should, could, and won’t (give a check to the link above for further explanation).

After updating the features, only those strictly related to your business goals should remain. 

 

5. Prepare a functional specification

For most people, this section seems much more complex than all the previous ones, but it really isn’t.

To get started, use your validated scenarios to create a table with user roles.

Then create a table with the characteristics of your product. After that, it will be quite easy to finish the System Features section.

There are many other tables to complete, but all are too short. Also, after a little review, you should learn two things.

The first is that half of the non-functional requirements are unnecessary. The second is that you can find all the data for the rest of the tables by using Google search.

Cool!

 

6. Provide wireframes to complement the text.

The last stage is the one that takes the longest. You don’t need to draw up to the last screen of your app, but all the features described above need to be covered by wireframes.

Need more details about it? Go on reading.

What tools and techniques to use for wireframing?

Here are some of the tools that make the prototyping process quite simple and relatively fast: Axure RP (Windows, Mac), Balsamiq (Windows, Mac, web, Google Drive), Figma (Windows, Mac, Linux), Sketch (Mac), and others.

Also, you can use old-fashioned Photoshop or one of the online visual layout tools, e.g. Webflow.

• Axure RP (Windows, Mac)
• Balsamiq (Windows, Mac, web, Google Drive)
• Figma (Windows, Mac, Linux)
• Sketch (Mac) and others

The UI design rules

The common rules of UI design are pretty simple:

• Place items from top to bottom and left to right
• Use only the elements relevant to the situation and some UI-only display sections
• Make the textual content of the right length to make sure your interface can contain it
• Do not place the elements too close to each other
• Check the actual iOS and Android guidelines before starting

 

Conclusion

Developing mobile apps without a specification can be a real hassle!

Sure, the software specifications require an investment early on, but they help to avoid higher expenses in the later stages of the project.

If a potential mobile app development partner offers you to kickstart a dev process without the above, there’s a good chance you’re dealing with newbies.

So… you should seek out someone more skilled and experienced.

Someone like APRO Software professionals, for example. 😉