If you’ve decided to create a mobile app or a web application, you are to write a Software Requirement Specification (SRS) for your project. It’s a document with a set of client’s requirements for the product. It includes features you want it to have, your design preferences and other basic information that describes the application that is to build.

What is the software requirements document for?

For communication: The spec will be used during communication with the application development company. It’s much easier for you and them to discuss the working process when you have this document at hand.

The more clear and detailed the specification is the better understanding of the project the development team will have. Hence the communication will be faster, especially at the first step of application development – requirements processing.
 
For you: You surely want to pay for the product you exactly want. However, the developers cannot read your mind and decide what to do unless you describe to them what you want clearly and in detail. It would be really confusing if you got an app that had elements and features that didn’t correspond to the picture you had in your head at the beginning.
 
For developers: Creativity is a part of a software developer’s work, but they are not artists. They like to follow instructions without guessing what you have in mind.

They may not think the way you think so try to avoid confusion so that they won’t have to make changes to the code when it is already written.
 

It should be admitted that to write a quality specification is rather difficult, but it will save you time, money and efforts later. And it will lead to a better final result. So, to help you do that, we provide some advice.

How to write?

Be specific: Try not to include any generic requirements such as just “small”, “slowly”, “clear”, try to be more specific. Programmers are engineers, not poets.

The more precisely you describe your requirements, the fewer questions from the team you will receive later.

Instead of describing features in a generic way, describe them quantitatively, for instance, use dp units to describe the size of an element.

The spec should be well thought-out and documented. Remember, that the more complex the application should be, the more precise and detailed specification you will need. However, don’t overdo it. Don’t include any unnecessary stuff into the spec.

It should be clear and concise. When you discuss your specification with the BA, he/she may suggest some noteworthy options and make meaningful recommendations, but try to make the spec as full as possible to reduce all further tedious tasks.

However, the SRS should be flexible, for you probably will change it later a little when you discuss it with the development project team.
 
SRS is not a discussion board: Don’t ask questions and don’t start discussions in the specification.

It is a document and if you want to ask dedicated development the team for their opinion later, write something like “to be determined”, not “what would be the better option?”
 
Get help: to write a really good specification you need to be a specialist in this field and no one expects that from you.

So, if you have any questions or need help, ask a professional. It can be either a technical specialist from your company or a specialist from the provider company.
 

These were some general tips. So here comes the question: what should you actually include into the specification requirements document?

What to write in a software requirements document?

Index. The index will include the names of all parts of your specification with the number of pages they are on. This will make search and discussion for the team much easier.
 
Idea and purpose. What is your product for? Why do you want to create your mobile or web app? For whom? Include the goals of the application, your ideas about what you want it to do and which challenges to solve.
 
User persona. Think of what your users should be like. Who are they? What are they age? What do they do? Are they university students, professors, entrepreneurs, drivers, doctors or someone else? What problems will your application solve for them? When will they use it? What for? How often?
 
Abbreviations and definitions. If you include any abbreviations and particular definitions that may not be clear to the people who will read your spec, explain them at the beginning of your SRS.
 
Devices, platforms, and OS. It’s crucial and necessary in custom mobile and web app development to know for which platform you build your product. There is a wide range of options.

You may choose native or hybrid application development or you may need another design for tablets that will differ from the one for smartphones.
 
Monetization. It’s important to know what the app monetization strategy will be. Will the users buy it from stores, will you include advertising, will it be a freemium model? How and where will the money be transferred? Find more about monetization strategies in one of our previous posts.
 
Deadlines and milestones. The team and you should be agreed on all the time frames. Determine dates on which every version of the app should be shown to you.
 
Budget. Write what budget you have for this app to avoid further confusions.
 
Your team. If you have people to provide from your side, include this information in your specification for more clarity.
 
Actions. Describe each interactive element on each screen as follows: gesture – animation – effect.
 
Design. It’s good practice to make different app design for tablets and smartphones as they have different sizes. Add wireframes for the tablet version if you want it to be different from the one for smartphones.
 
Features: There are specific features which must be described in the specification.
 
– Internet. If your app requires Internet, describe what should be done when there’s no connection with it. What data must be saved? How will a user get the information in this case?

– Social media integration. If your application will be connected to social media, describe what exactly it must do. Will it share data with other people, post something, add contacts?

– Sources of information. What information will come into your app? You may not know exactly what APIs are and that’s fine. Just describe what information should come from third-party providers.

– Geolocation. If the app will use GPS, what exactly will it do? What maps API will be used?

– Push notifications. In what cases will they be shown? Remember that they should be informative but not annoying.
 

Optional:

You don’t necessarily have to provide the team with this information. Wireframes can be created by the development project team according to your requirements, but it will make the preparation phase more clear if you give the visual representation of what you want your app to look like.

Flowchart. Include the arrangement of screens and navigation between them.

Screens. Add wireframes for all your screens. You don’t have to include every detail in the wireframe, since it the job of the designer, but make it easy for the team to understand what you want. Don’t forget such important screens as the ones for settings, menu, logging-in etc.

 
At Smartum Pro we have an experienced development project team that will help you decide on what features must be implemented in the app to meet your goals, solve your technical issues, and also will provide reasonable recommendations during custom mobile or web app development process if required.

If you’ve decided to create a mobile app or a web application, you are to write a Software Requirement Specification (SRS) for your project. It’s a document with a set of client’s requirements for the product. It includes features you want it to have, your design preferences and other basic information that describes the application that is to build.

What is the software requirements document for?

For communication. The spec will be used during communication with the application development company. It’s much easier for you and them to discuss the working process when you have this document at hand. The more clear and detailed the specification is, the better understanding of the project the development team will have. Hence the communication will be faster, especially at the first step of application development – requirements processing.

For you. You surely want to pay for the product you exactly want. However the developers cannot read your mind and decide what to do unless you describe to them what you want clearly and in detail. It would be really confusing if you got an app that had elements and features that didn’t correspond to the picture you had in your head at the beginning.

For developers. Creativity is a part of a software developer’s work, but they are not artists. They like to follow instructions without guessing what you have in mind. They may not think the way you think so try to avoid confusion, so that they won’t have to make changes to the code when it is already written.

It should be admitted that to write a quality specification is rather difficult, but it will save you time, money and efforts later. And it will lead to a better final result. So, to help you do that, we provide some advice.

How to write?

Be specific. Try not to include any generic requirements such as just “small”, “slowly”, “clear”, try to be more specific. Programmers are engineers, not poets. The more precisely you describe your requirements, the less questions from the team you will receive later. Instead of describing features in generic way, describe them quantitatively, for instance use dp units to describe the size of an element.

The spec should be well thought-out and documented. Remember, that the more complex the application should be, the more precise and detailed specification you will need. However don’t overdo it. Don’t include any unnecessary stuff into the spec. It should be clear and concise. When you discuss your specification with the BA, he/she may suggest some noteworthy options and make meaningful recommendations, but try to make the spec as full as possible to reduce all further tedious tasks. However the SRS should be flexible, for you probably will change it later a little when you discuss it with the development project team.

SRS is not a discussion board. Don’t ask questions and don’t start discussions in the specification. It is a document and if you want to ask dedicated development the team for their opinion later, write something like “to be determined”, not “what would be the better option?”

Get help. To write a really good specification you need to be a specialist in this field and no one expects that from you. So if you have any questions or need help, ask a professional. It can be either a technical specialist from your company or a specialist from the provider company.

These were some general tips. So here comes the question: what should you actually include into the specification?

What to write in software requirements document?

Index. Index will include the names of all parts of your specification with the number of pages they are on. This will make search and discussion for the team much easier.

Idea and purpose. What is your product for? Why do you want to create your mobile or web app? For whom? Include goals of the application, your ideas about what you want it to do and which challenges to solve.

User persona. Think of what your users should be like. Who are they? What are they age? What do they do? Are they university students, professors, entrepreneurs, drivers, doctors or someone else? What problems will your application solve for them? When will they use it? What for? How often?

Abbreviations and definitions. If you include any abbreviations and particular definitions that may not be clear to the people who will read your spec, explain them at the beginning of your software requirements document.

Devices, platforms and OS. It’s crucial and necessary in custom web and mobile app development to know for which platform you build your product. There is a wide range of options. You may choose native or hybrid application development or you may need another design for tablets that will differ from the one for smartphones.

Monetization It’s important to know what the app monetization strategy will be. Will the users buy it from stores, will you include advertising, will it be a freemium model? How and where will the money be transferred?  Find more about monetization strategies in one of our previous posts.

Deadlines and milestones. The team and you should be agreed on all the time frames. Determine dates on which every version of the app should be shown to you.

Budget. Write what budget you have for this app to avoid further confusions.

Your team. If you have people to provide from your side, include this information into your specification for more clarity.

Actions. Describe each interactive element on each screen as follows: gesture – animation – effect.

Design. It’s good practice to make different app design for tablets and smartphones as they have different sizes. Add wireframes for the tablet version if you want it to be different from the one for smartphones.
 

Features: there are specific features which must be described in the specification.

– Internet. If your app requires Internet, describe what should be done when there’s no connection with it. What data must be saved? How will a user get the information in this case?

– Social media integration. If your application will be connected to social media, describe what exactly it must do. Will it share data with other people, post something, add contacts?

– Sources of information. What information will come into your app? You may not know exactly what APIs are and that’s fine. Just describe what information should come from third-party providers.

– Geolocation. If the app will use GPS, what exactly will it do? What maps API will be used?

– Push notifications. In what cases will they be shown? Remember that they should be informative but not annoying.

Optional:

You don’t necessarily have to provide the team with this information. Wireframes can be created by the development project team according to your requirements, but it will make the preparation phase more clear if you give visual representation of what you want your app to look like.

Flowchart. Include the arrangement of screens and navigation between them.

Screens. Add wireframes for all your screens. You don’t have to include every detail into the wireframe, since it the job of the designer, but make it easy for the team to understand what you want. Don’t forget such important screens as the ones for settings, menu, logging-in etc.

At Smartum Pro we have an experienced development project team that will help you decide on what features must be implemented in the app to meet your goals, solve your technical issues, and also will provide reasonable recommendations during custom mobile or web app development process if required.