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

Michał Merchelski
27 August 2018

Different ideas, same problems: Software requirement specification as the solution

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 the work? These are the questions every team has to have an answer to before they get down to work.

It’s like a business plan, but different

We like to think of the software requirements specification as a roadmap for development. When you build a business, everybody tells you to have a business plan. It can be altered and changed along the way, sure, 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 endeavour of developing your application is on a level of complexity which 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.

 

Keep up the pace

3 new startups are founded every second, that 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 under your belt.

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 SRS allows you to clarify your needs in terms of technology stack and scale of the project, which in turn makes your recruitment needs crystal clear. Then, you can build a team whose competence will be a perfect match for the project and make sure that your product is delivered. 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 increased volume of the document which 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 which 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.

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. 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 which 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 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 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 rendering your previous work useless. So 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 elastic

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 spec is 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 SRS template: start-up.house/srs. Tell us what you think about it! 

Any comment you want to share with us? Drop us a line: hello@start-up.house

Read more...

You may also like...

About us

5 ½ Recruitment Tips

We all know recruitment processes can be... tricky, to say the least. Even for some of you ‘Coding Ninjas’, ‘Rockstar Developers’ and other ‘magical creatur...

Sandra Morgan
23 September 2019
Startups

The keys to successfully plan product development

You have an idea. You have confronted it in the market and achieved a real problem-solution fit. You have mapped your ecosystem and drafted a business plan to achieve a product-market fit.&...

Thibaut Bardout
09 September 2019