How to write a Software Requirements Specification (SRS) for a startup MVP?

We work in the app development business and every day we meet people who approach us to talk about their business ideas. And as you may expect, every entrepreneur has a different idea offering different values, trying to satisfy different customer needs. However, every time the same questions keep coming up: how long will it take to build the app? How much will it cost? When can you start work? These are the questions every team has to have an answer to before they get down to work.

What is a software requirement specification?

We like to think of the software requirements specification as a roadmap for product development. When you build a business, everybody tells you to have a business plan. It can be altered and changed along the way, but you need to have it in place to keep track of your progress and be able to plan for what lies ahead. 

And the same rule applies to your software. It’s supposed to be part of your general business plan, but the endeavor of developing your application is on a level of complexity that deserves its own plan. Going into development without one is like taking the helm of a ship with no map and a Klingonian-speaking crew on board.

How to write a software requirement specification?

3 new startups are founded every second, which makes it 11,000 an hour or 260,000 a day. It means that you are very likely to fall behind your new competition if you don’t develop fast enough. It is crucial to stay ahead of the market and a good plan (vide SRS) is what you need.

Choose the right tech stack

A specification sheet contains all the functional requirements of your future product. Having this information in place allows you to make the right choices in terms of which technology to use. You need to consider speed, scaling abilities, cost of future maintenance, and integrations to avoid unnecessarily complicating your app on one hand and to make sure it is ready for rapid growth on the other.

Choose the right team

A well-written software requirement specification allows you to clarify your needs in terms of tech stack and scale of the project, which in turn makes your recruitment needs crystal clear. Then, you can build a team whose competences will be a perfect match for the project. After all, before you find the right people for the job, you need to know what the job is, right?

Don’t go chasing waterfalls...

While searching ‘Project Specification Template’, ‘SRS example’, or ‘how to create SRS’ in Google, you will most likely encounter massive, confusing documents with several dozen pages of text and detailed descriptions. That doesn’t really fit into the ‘lean startup’ approach, does it? Those monstrous documents are usually relics of the ‘waterfall’ management approach. It required the project to be planned from A to Z at the very beginning. This led to an increased volume of documents that had to include all of the features, user profiles, etc. of the final product.

…please stick to the rivers

For a lean startup, the perfect solution is to prepare a ‘bare bones’ version of a software requirements specification document. The 20+ startups we have already worked with allowed us to establish a set of rules and best practices that work well for most software projects. These basic rules are listed below and following them should streamline the preparation of your software requirements specification document.

The best practices for writing a software requirement specification document

Invest time now, save later

Time is money, but make no mistake — diving into a project head-first without any preliminary work or planning is irresponsible. Being agile means adapting the plan to changing circumstances, not going full-YOLO, and see what happens. There has to be a plan. The lean approach requires us to act quickly and pivot easily when needed. Preparing a specification document may seem like a waste of time at first, but it is a necessary step that will save you tons of time in the development phase. Trust us — we’ve learned it the hard way. 

The requirements document is the main source of information for developers when designing your app, so you have to make sure it is of proper quality. If done right, it will allow the dev team to productively execute your idea without any unnecessary work. Your MVP will be more likely to be delivered on time and with all the required functionalities.

Be quick, but precise

A good time-saving trick is to prepare the first draft or your software specification document in 1–2 hours and gather feedback from your team as quickly as possible. Then, take another 1–2 hours to update the document with the received feedback and you’re all set. 

Our experience shows that the second version is usually good enough to start working with the development team. There is no point in wasting time coming up with unnecessary details at the very beginning. Your MVP needs to remain as basic as possible. And it is very likely that you will change the project along the way. Stick to the basics but make sure your idea is described clearly.

Get on the same page

Before starting any development work, you need to make sure that your team is working towards the same goal and that they share the same vision on the project. Therefore, planning before coding is the key to effectiveness. Everyone must understand the overall product, the features it requires, the views needed to be coded, and initial project goals.

Make it accessible

The spec is not to be written by the PM in seclusion and then brought to the team like an executive order. Make sure to share it so that your team has constant access to the latest version of the document. Share it in Google Docs or wherever you like, but let your team collaborate in real-time. That way everybody will be on the same page and a lot of problems will be avoided.

Be flexible

A very common mistake made by PMs is making the spec document too rigid and sticking to its first iteration at all costs. The lean approach requires flexibility and being able to move around, and the same rule applies to specs. From our experience, it is very common that the last 20% or more of the specs are completed during the development process. This allows teams to adapt their apps to new business needs by either removing or adding features to their MVP.

Get feedback

Make sure to show the first version of your SRS to several people. Ask both technical and non-technical friends to tell you what they think about the document. Is it clear? Is the scope right? Gather those remarks, implement them in your spec sheet and you’re good to go. Early-stage feedback is really important for startups — it will save you tons of time and money! Remember to remain open to suggestions and keep on improving the SRS along the way. Stay agile!

We launched our own Software Requirement Specification template! Tell us what you think about it! Drop us a line at hello@start-up.house.