How to Write Software Requirements Specification (and Why You Need It)
Table of content
  1. What Is a Software Requirements Specification (SRS) Document?
  2. Why you need Software Requirements Specification (SRS) Documentation
  3. How Software Requirements Specification can help you choose the best software developer
  4. How to write a Software Requirement Specification Document
  5. A text editor or dedicated software – what to use
  6. How do you know you’ve written an excellent Software Requirement Specification Document?
  7. Is it safe to share the SRS document before signing the contract?
  8. Should you sign a non-disclosure agreement?

Would you entrust your app development to anyone based just on meetings and meeting notes? I bet you wouldn’t. It may result in a poor quality product that doesn’t fulfil your business expectations and doesn’t suit users’ needs. It’s easy to guess that such a project is doomed to failure from the very beginning.

To make your app successful and avoid this scenario, there must be a mutual understanding between you and your software developer. You need to write down every expectation and assumption about the app and development process. It makes communication easier and based on facts rather than guesswork.

A good example of misunderstanding was NASA’s Mars Climate Orbiter failure. The problem was in measurements. One team used the metric system (millimetres and meters), while the second used imperial metrics (inches, feet, and pounds). Something such prosaic decided on the vast space program failure. NASA could easily avoid such a spectacular setback simply by specifying expectations.

They needed a software requirements specification (SRS document).

So are you.

What Is a Software Requirements Specification (SRS) Document?

The software requirements specification document provides a complete picture of your app and its functionality. After reading it, one should understand the purpose and architecture of the app and be able to describe what specific requirements are.

According to PMI’s Pulse of Profession report, inaccurate requirements gathering is the third most common reason for failures and happens in 35% of all cases. The most common ones are only changes in organisations’ priorities and objectives (ranging from 37% to 39%).

That report shows that you need to gather and write down all requirements, but you have to do it properly. That’s my job here – to explain to you what you need to include and why.

Why you need Software Requirements Specification (SRS) Documentation

There are a few personas who benefit from such a document. You’re one of them. I bet you’ve conceptualised the app-to-be quite well if you are looking for a contractor. But did you think about all aspects of the app? Will you get exactly what you have in your head?

When you’re writing an SRS document, keep in mind that it’s for you in the first place. It’s your checklist, and it helps you in requirements management. If you are searching for investors, the SRS document may benefit from an app overview.

You need to define who app users are, what problems they have and how your app can help solve them. Don’t rely just on your impressions. Check the competition to figure out what features the app should have. Check how you can differ from competitors, too. Those are parts of the go-to-market strategy and if you need some details, check …

Then you need to specify what technologies you want to choose, when the app has to be launched and how much you can pay for it. Those are key points that help you shorten the list of potential contractors.

When it comes to software engineering itself, the SRS document gives the chosen contractor a better understanding of your project, which is one of the key factors of success. Remember that developers don’t read your mind. They will do exactly what is specified. A well-written document helps developers save time (and therefore your money) needed for reaching the goal. The document is also helpful when planning the software development process and further development because it helps manage requirements. It is a base for testers to create test cases and technical writers to make software documentation and user manuals.

Having such a document helps you avoid misunderstandings, bugs and errors and decrease development costs (removing time-consuming consultations at every stage).

How Software Requirements Specification can help you choose the best software developer

Having the SRS document is extremely helpful when gathering offers from the market. You are sure that all potential contractors are based on the exact specification, so estimations are comparable.

When choosing a software development company, the critical factor in many cases is the price. When there are a few options under consideration, it’s pretty understandable. Without a document that each company can base on while preparing an estimation, you may compare offers containing different work scopes. Technology, features or solutions are just a few examples that can be misunderstood when relying on discussions instead of documentation. A straightforward software requirements specification document is the best way to gather comparable offers from potential contractors.

Estimations based on the SRS document are also more accurate. That means you’ll receive a more realistic estimation, so you know how to manage your budget.

Choosing the contractor depends on how the first contact goes – how they reply to your message or what they say on the call. Talking with a few companies, you may miss some points during one call or specify more details on another. That may result in different scopes of work from other companies. Incomparable!

How to write a Software Requirement Specification Document

Writing an SRS document is not as hard as it may seem.

Introduction

Intended use of the document

Your document must be helpful, so you need to specify who will be the audience that will have access to it. You should mention all co-workers: the developers, project managers, and stakeholders from various departments (including sales and marketing).

Having this point conceptualised, you will be able to address all aspects of software development.

Business Overview

Business context

A business context introduction is helpful for your company’s internal use and for a software provider to understand your business.

Business goal/purpose

Define what you expect to achieve developing the app. You should list the business benefits that the app should have and the objectives you want to fulfil while building it. Those should be high-level business goals understandable for contractors, e.g. software development companies.

You can ask yourself the following questions to define the project’s goal: What do we want to improve or reach by developing this product? What measurable outcomes do we expect to achieve?

Risk management

In writing a software requirements specification document, you should consider possible risks and investigate what can go wrong. You should be preventive and prepared to deal with all issues expected. Try to write down all the obstacles the project might face, define what will be the bottleneck for the product, and try to figure out how these risks can be managed.

Assumptions and dependencies

Everyone assumes something, but you should make it clear when it comes to software development. Would assumptions be accurate? Are you assuming what technology stack should be used? Are functionalities assumed (not tested yet with the target group)?

You should also outline if the project depends on external elements. Do you need to use some parts of the old solution? Do you need to integrate the app with software that may be outdated soon? All those dependencies need to be described.

Describe your assumed technology stack and development methodology. Having those here doesn’t mean you can’t change them. Quite the opposite, don’t stick to them if a software developer suggests a different one.

General limitations

You may specify all regulations your software has to comply with or any other limitations or restrictions here. Ensure you’ve included all relevant information because the software developer of your choice will rely on it.

Project details

This section needs to specify all the required information for a software development company.

Budget

It can be a controversial point, but necessary. By defining the budget, you help a software developer estimate whether the project is doable within the budget or if some adjustments are needed at the very beginning. You will have a chance to change the project initially before spending more money you can afford (or even suspending the project, wasting money invested).

Don’t be afraid of increasing the estimation knowing your budget (if it’s high). You can prevent this tactic by collecting and comparing at least a few offers from the market. Time estimations won’t be exact but they should be quite similar.

Comparing estimations, you should take into consideration solutions that different companies propose. They may affect pricing.

Remember that a reliable development partner won’t increase the hourly rates knowing your budget. Choose the right partner wisely and carefully. Check my previous article on how to choose the best software development company. I’m sure it will help you make the right choice.

Timeline and starting point

A specified timeline is beneficial not only for a contractor but also for you. You know when the deadline is, so you may decide on resigning from the company of your first choice if it’s unable to deliver the solution on time.

Sometimes the critical point is when to start the project. Many companies running projects might be unable to start a new one immediately simply because of developers’ schedules.

Give yourself some time to choose a company, and don’t start completely new projects in a hurry (the ongoing ones have their own rules).

The current stage of development

Inform potential contractors whether it’s the very first app to be developed or you have one already.

If you are going to redevelop the app from scratch, inform the developer what was wrong and what you need to change.

Covering another channel (e.g. developing a mobile app for an existing web app), share your impressions with the contractor on what to avoid and what is needed from your customers’ point of view.

If you need to develop an add-on to an existing product, share all documentation of the original solution.

All those information may help software development companies prepare accurate estimations (and plan the time needed for your project).

Previous experience (have you been using any other solutions for that purpose?)

If you’ve already used software that address needs addressing by your app, share your observations and conclusions. Maybe there’s something worth implementing in your app-to-be? Potential partners should know that at the early stage.

Similar systems

You can also indicate other software made by your competitors (it can be just an overall description). It will help you when creating a go-to-market strategy, but it’s also beneficial in the software development process.

Knowing competitors and their solutions, you can indicate weak points or lacking features of your app-to-be. Knowing competitive systems, the software developer of your choice may support you with establishing features as well.

It’s not apparent, but a great software developer will contribute to developing ideas and conceptualising key features to make your app successful.

Monetisation model

The monetisation model is how you will make money using the app. It’s essential not only for you (I know, it’s a key) but also for potential development partners. Knowing the model, a developer can define what features to implement (payments, paid ad slots, recommendation system, etc.).

General description

The software developer of your choice has to understand the app-to-be value and its end-users. The overall description providing knowledge of the points listed below can help designers and front-end developers create the user-oriented final product more easily.

The purpose of the software you want to develop

Each app has its purpose. It may make communication easier, content-sharing more straightforward, or search for products intuitive. Is it caused by some sort of void in the market? Are you filling the niche with your app’s functionality?

The core value an app is meant to bring to end-user

If you’re a startup, you probably start with an MVP. That means you need to define the core value of the product you want to deliver to end-users. It’s the core feature. Something that your app would not exist without – a non-retractable functionality.

Description of end-users

Understanding the target audience is crucial when developing an app. It’s the intended audience for your app. Any app is created for users, and they will decide on its success. Your success.

Let’s say you’re about to develop a flight booking app. At first glance, your customer could be anyone who wants to book a flight. Really? Think carefully about who will use the app – younger or older people? How likely elderly will use their mobile phones to book (and pay for) a flight? How likely are they to travel long distances? Even if they are, are they booking their tickets? Or ask their children or grandchildren for help? All those you have to know when thinking about developing an app. You have to point out who the target group is.

Defining groups of users specify the demographics (age, sex, location), interests, social profile (family, friends, social networks) and job description. In creating buyer personas, remember to describe problems users cope with (and which your app is going to resolve) and their motivations (e.g. users can design houses of their dreams, and for that reason, they use a house configurator). If you need more information on how to create buyer personas, check …

These findings will affect the final app, so they have to be included in the SRS document.

A user problem and needs

Describe the end-user problem and specify how the app should resolve it. It gives you better insight into intended audience intentions and helps build better software.

Specify all needs users may have using your app. Remember that users need to solve the problem, so the app should have all the required features (it’s the starting point, actually).

Don’t guess. Trust the data. If you don’t have relevant data on user requirements, conduct your research. You may use thousands of existing data sources (like social media, websites or forums) or conduct a survey. You may use both approaches, quantitative and qualitative. To learn more about market research, read…

User stories – how to fulfil the need

User stories anticipate and decode users’ needs that your app should fulfil. If we want to create a dream house, we need an interactive configurator that will show us what it will look like and make buying easier.

Let’s get back to our flight booking app example. At this stage, we are considering the ones who will use the app, not those who gain benefits. Think carefully about what they need – do they need to share the ticket with their parents (for whom they were bought)? Do they need a straightforward payment service included? Maybe they need to have a few profiles of people for whom they will be able to buy a ticket (and automatic ticket sending to the right person)?

Features and requirements specification

Functional requirements: how the app should behave

To address defined needs, your app should behave in some way. When you know what the user needs and what he intends to do in your app (user stories), you may prepare use cases to make their journey understandable. By collecting use cases, you define what users can do on the website (it will help you design the functional requirements of your project).

Defining use cases, you should notice different entering points (especially on a website) because not everyone will land on the same page. Let’s go back to the example of the booking system in its website version. You may expect users to come through blog pages or particular flights and look for scheduling and pricing. You have to anticipate what they want to do and prepare clear and straightforward patches for each use case.

The more use cases, the better understanding of the app (but don’t go overboard). Remember, however, to prepare use cases for every persona you’ve described. Various groups may use the app differently.

Having use cases, you can create workflows. It’s about how users can navigate the app to reach the goal defined in a particular use case. Describe system responses to users’ actions (including data inputs). You will notice whether the app is appropriately designed to go through it smoothly when you do workflows.

When determining functional requirements, you should think about what functions should the app have. Searching for the product’s functionality, ask what functions something provides and how it may help users with their tasks.

You can define system outputs to users’ data inputs and describe business processes here.

Features are functional requirements, that indicate what is strictly necessary for the system to work.

A business analyst is the one who gathers users’ feedback and makes changes to the SRS document.

External interfaces

This group defines specific types of functional requirements and indicates how the final product will interact with other software, systems, interfaces and components (including hardware).

Describe here user interfaces, software interfaces, hardware interfaces and communication interfaces.

Nonfunctional requirements

Nonfunctional requirements define necessities that don’t have any function but are crucial for the app. They are about how the system will deliver features.

Nonfunctional requirements can describe quality, security, safety, performance, scalability, reliability, compatibility, availability, maintainability or usability.

The catalogue of those may differ depending on the industry – healthcare companies may consider security and data safety essential.

Other requirements

Here you can mention all individual requirements that you could possibly think of.

Design constraints

Your app may need to fulfil some regulations or be adjusted for a specific target group. Let’s say you will develop a companion app for the elderly who may have worse hearing. Let’s assume your app’s goal is to read aloud all messages to its users.

Such an app must be appropriately designed so that older people can customise and navigate through it easily. All findings you’ll find during conceptualisation should be attached here so the development team knows them.

Implementation constraints

If there are any limitations to implementing the new app, you should mention all of those here. If you need to use some part of the old system or existing infrastructure, the developer should be aware of it.

Acceptance criteria

This section lists the criteria that have to be met for you to accept the project outcome. It is important for you to think this through thoroughly and make a detailed list of requirements.

Approval

Consult project requirements with all stakeholders and get their approval. Until you have all of them, you should not start the project, otherwise, there’s a risk the app won’t suit all needs or those additional adjustments will be needed.

A text editor or dedicated software – what to use

There’s no need to use dedicated software if you have a good software requirements specification document template.

The aim is to have all things mentioned above written so that you can share them with potential developers.

If you need a hand, you can download the existing SRS template.

How do you know you’ve written an excellent Software Requirement Specification Document?

It’s explicit

The document you create must be easily understood with no room for interpretation (also by developers). Very handy are visuals like diagrams, schemes, models or mind maps. They can explain some points straight away just because they are shown instead of imagined.

Using those visual elements, you can also easily outline critical points of your project and show connections or dependencies. It makes the app concept more accessible.

Measurable

Make sure you can validate and verify the final app with the requirements defined in the SRS document. It’s extremely important in software engineering when the development process is ongoing. It is helpful in requirements traceability.

Complete

Provide your software development team with all information needed to design, code and validate the final solution, so it meets users’ needs in a bug-free manner.

Viable

Rely on the technologies and possibilities you have now and don’t wait for breakthroughs. Make sure you have the budget needed and the timeline specified.

Flexible

You need an app that will grow with your business and be flexible enough to further the development process and updates.

Verifiable

Requirements should be described precisely, and in detail, so there should be no need to ask for additional explanation. It allows precise requirements traceability, too.

Consistent

All the software requirements should be consistent and complement each other with no conflicts. The document should be written using understood terms, the same terms throughout the whole text. Avoid synonyms or any fuzzy words. It’s not a writing competition. Your document doesn’t have to use blossom words. It must be as specific and understandable as possible.

Precise

All requirements should be precisely defined. Some notes can be confusing if not specified how to read them. Let’s say you want to trigger some event when a customer will do one of a few things – describe precisely how the system should behave. Whether it’s the OR (at least one from mentioned) or XOR (the only one from mentioned) logic gate? Explain.

Prioritisation

You should indicate priorities in the software requirements specification document. It’s extremely useful when planning tasks. Prioritisation helps your dedicated project manager plan each development stage properly according to your needs.

Not too detailed

Avoid too detailed requirements – you need to strike a balance. Don’t describe a functionality from every angle, leave the obvious out. Do not repeat yourself, be brief but comprehensive enough.

Is it safe to share the SRS document before signing the contract?

Basically, yes. Experienced decision-makers don’t feel afraid to share such documents with potential contractors. There are two main reasons.

You know your process like anyone else, so it’s impossible for someone to build your app quicker and better than you will.

The second reason refers to the development process itself. You receive a more reliable and precise estimation when you share the doc with potential partners. Having information, the development company can estimate what resources will be needed, how much time it will take and, therefore, how much it will cost. Furthermore, you’ll be able to observe at the earliest stage whether a potential partner understands your business and the app itself.

Should you sign a non-disclosure agreement?

The software development requirements specification document contains all essential information about your future project. It’s not surprising you may be wondering whether you need to sign NDA before sharing.

If you have any doubts, insist on signing the non-disclosure agreement. A reliable development partner won’t refuse. That could be the first step for contractor evaluation.

Lead Project Manager at TeaCode

Gabriela is a lead project manager and keeps in mind that the crucial thing in project management is always seeing the business objectives. She takes care of clients' business outcomes, and that's why clients usually give her a lot of independence.

As a web developer, she understands teammates, which is an asset in project management. UX designer background is handy when clients ask her for advice or consult their app ideas. Having this knowledge, she can address their confusedness or curiosity.

Data analysis and research have no secrets from her as she's a physicist. She knows how to discover data patterns and dependencies, which brings additional value to her everyday work.

Gabriela Jarzębska
Gabriela Jarzębska

Gabriela is a lead project manager and keeps in mind that the crucial thing in project management is always seeing the business objectives. She takes care of clients' business outcomes, and that's why clients usually give her a lot of independence. As a web developer, she understands teammates, which is an asset in project management. UX designer background is handy when clients ask her for advice or consult their app ideas. Having this knowledge, she can address their confusedness or curiosity. Data analysis and research have no secrets from her as she's a physicist. She knows how to discover data patterns and dependencies, which brings additional value to her everyday work.