How to write Software Requirements Document for Custom Mobile and Web App Development?

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 the client’s requirements for the product. It includes the product’s features, design preferences and other basic information that describes the application that is to be built.

What is the software requirements document for?

1. 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 ready. 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 the application development – requirements processing;
2. For you: You surely want to pay to get 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 your SRS document. It will be really confusing if you get an app that has elements and features that don’t correspond to the picture you have had in your head at the beginning;
3. 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 do so try to avoid confusion and misunderstanding so that they don’t have to make changes to the code when it is already written;

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

How to write software requirements?

1. Be specific: Try not to include any generic requirements such as just “small”, “slow”, “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.
2. SRS is not a discussion board: Don’t ask questions and don’t start discussions in the software requirements specification. It is a document and if you want to ask the team for their opinion later, write something like “to be determined” and not “what would be the better option?”.
3. Get help: To write a really good specification you need to be a specialist in this field and no one expects this 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’s company.

These are some general tips on how to write business requirements documents. So here comes the question: what should you actually include into the specification requirements document?

What to write in a software requirements document?

1. Index. The index will include names of all the parts of your specification with their page numbers. This will make search and discussion for the team much easier;
2. Idea and purpose. What is your product for? Why do you want to create your mobile or web app? For who? Include the goals of the application, your ideas about what you want it to do and what challenges to solve;
3. User persona. Think of what your users should be like. Who are they? What is their 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?
4. 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;
5. Devices, platforms, and OS. It’s crucial and necessary in custom mobile and web app development to know which platforms you build your product for. There is a wide range of options. You may choose native, hybrid or cross-platform application development or you may need another design for tablets that will differ from the one for smartphones;
6. 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;
7. 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;
8. Budget. Write what budget you have for this app to avoid further confusion;
9. Your team. If you have people to provide from your side, include this information in your specification for more clarity;
10. Actions. Describe each interactive element on each screen as follows: gesture – animation – effect;
11. Design. It’s a 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;
12. Features. There are specific features that must be described in the software requirements specification.
    1. Internet. If your app requires Internet, describe what should be done when there’s no connection to it. What data must be saved? How will a user get the information in this case?
    2. Social media integration. If your application will be connected to social media, describe exactly what it must do. Will it share data with other people, post something, add contacts?
    3. 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;
    4. Geolocation. If the app will use GPS, what exactly will it do? What maps API will be used?
    5. Push notifications. In what cases will they be shown? Remember that they should be informative but not annoying.
13. Optional. You don’t necessarily have to provide the team with this information in your mobile app requirements document (or web):
    1. Flowchart. Include the arrangement of screens and navigation between them.
    2. Screens. Add wireframes for all your screens. You don’t have to include every detail in the wireframe since it’s 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 Smartym Pro we have an experienced project development 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.