How to Write Software Requirement Specification (SRS) Doc

Main Thoughts

• Software requirements serve as the foundation for successful software development projects. They define the desired functionality, constraints, and objectives of the software.
• Requirements should be specific, measurable, achievable, relevant, and time-bound (SMART) to ensure that they are well-defined and can be effectively implemented.
• Requirements should be written from the perspective of the end-users and stakeholders. It is crucial to understand their needs, expectations, and goals to accurately capture the software’s functionalities and features.
• Involving stakeholders, developers, designers, and other relevant parties in the process helps ensure a comprehensive understanding of the software’s requirements.
• The use of various techniques, such as interviews, surveys, and workshops, can aid in eliciting requirements effectively.
• Requirements should be documented in a structured and organized manner.
• Regular review and validation of requirements are essential to identify and address any ambiguities, conflicts, or inconsistencies.
• Requirements may evolve and change over time as new insights are gained or project priorities shift. It is crucial to have a flexible approach and be open to refining and updating requirements as needed.

Introduction

Software Requirements Specification (SRS) is rightfully considered as one of the primary tools in custom software development that helps ensure positive project outcomes. When written the right way, SRS lays a solid foundation for the solution to be built. It serves to create a universally understandable vision of the future product.

In other words, SRS helps keep all the project actors on the same page as to the software functionality that needs to be developed. It makes it a lot easier to discuss and adjust this functionality and to avoid possible misunderstandings.

In this article, we’ll detail how one should properly write an SRS document. We’ll describe some of the related best practices, identify the priorities, and share some useful insights.

When and why do company executives need to know how to write a Software Requirements Specification?

SRS documents are typically written by custom software development companies, or, to be more precise, by their business analysts. However, it is still essential for the executives of a business organization that wants to outsource a software development project to knowledgeably control the process of creating their SRS document – this will help collect the software requirements for their future solution more fully.

Simultaneously, a vast number of companies still prefer to write software requirements specifications on their own. Why? This allows them to approach several software development companies. They can better find out these companies’ ability to implement the project as expected and pick the more suitable one of their software provider candidates.

In both the cases, it is imperative that you as the CEO, CTO, or CIO of the client company have a good understanding of how one should properly write Software Requirements. This includes the contents and structure of a SRS document and the best practices one should employ.

So what exactly is a Software Requirements Specification?

Software Requirements Specification is a document that describes in detail a future software solution and the environment in which its going to function.

More specifically, a SRS document provides an end-to-end description of the requirements for the functionality of the solution, the business goals that are to be reached by delivering the solution, and, in some instances, the ways to achieve the target project outcomes. Those SRS documents that describe the ways to implement the solution can also contain mockups, UI/UX designs and other relevant project artifacts.

Usually, an SRS document describes the features of a solution on several different levels that have different degrees of detail. For example, this can be the Module level, the Feature level, or the Solution level – depending on how important the described feature is.

Why is an SRS Document universally considered to be so important?

As we’ve already mentioned, creating an SRS document is a way to form a complete product vision. An SRS ensures that the client and their custom software provider mean the same in terms of the software functionality that needs to be developed. With an SRS document, you сan easily capture and formalize the full spectrum of your software requirements in any required detail, which would otherwise be simply impossible.

Kicking off a project without a detailed SRS document can easily result in your software provider delivering something seriously off the mark. This can happen both at some point during the development process, and already after the solution has gone live. Some part of the functionality may just appear to be at variance with your project requirements and have to be re-developed. For you, as the client, the consequences can include time and financial losses and missed deadlines. Your software provider is likely to incur some financial losses, if the arrangement they have with you is a Fixed-cost contract.

Creating an SRS document can eliminate all such risks. It can always serve as a mutually recognized reference point for settling any issues and misunderstandings that may arise in the course of the project.

Also, an SRS makes the project goals and the various project tasks clear and measurable for all the project actors involved. In other words, your business stakeholders can know the business impact your solution will make. Your software engineers will be able to optimally define the tech stack for your solution, while your QA engineers will be able to test your solution with much better quality.

Additionally, an SRS document can also facilitate the client’s dealings with their investors. It helps them highlight the advantages of their products and better show the ways in which these products can become a reality.

Overall, a Software Requirements Specification helps save the client’s project actors’ time, lessens the amount of communication-related churn, and enables a faster development speed for your engineering teams.

It may sometimes be useful to regard a Software Requirements Specification as a contract of sorts that safeguards both the client and their software provider against many unwanted scenarios.

What sections does an SRS document consist of?

The contents of SRS documents can vary depending on the project they are created for. They typically consist of all, or most of the following sections:

The purpose of the software being developed

This section of your Software Requirements Specification must clearly state the business needs your solution is intended to fulfill and the problems it is intended to solve.

Clearly stating the purpose of the product creates more understanding and motivation for your development teams. Besides, it also helps add more value to the product, as those involved in implementing the project are then better aware of your end goals and can use their previous experience more proactively.

An overall description of the product

This section of your SRS document must provide a high-level overview of your software product.

This high-level description must state what the solution is intended for. It must describe the solution’s target audience, the problems it aims to solve, and the ways in which the product is different from, or superior over other, similar solutions.

The functionality of the software and what it is supposed to do

The high-level overview of your product must be followed by a detailed description of the functions it provides. One must describe all the features of the solution and the ways they interact with one another.

To do so, it is better to employ the module-by-module approach, and use a Web-based wiki. The latter allows one to better capture and reflect the hierarchy of the system’s functionality.

A Description of the System Requirements

This is the section of your SRS document that provides a detailed description of all the requirements for the system to be developed. These requirements fall into Functional Requirements and Non-Functional Requirements.

The Difference between Functional and Non-functional Requirements

Functional requirements are those system requirements that relate directly to the functionality of the solution, the way the different parts of this functionality technically interact with one another, and the results of these interactions. Functional requirements can also include some UI/UX-related requirements.

Non-functional requirements have to do with the technical properties that the system must have either on a permanent basis, or under certain circumstances.

Non-functional requirements detail the system’s operational capabilities and related constraints and represent an attempt to determine the more optimal variation of the system’s functionality. They outline how well the system will perform across a range of indicators, including processing speed, security, reliability, data integrity, and more.

Functional Requirements

Functional Requirements can include the following types of system requirements:

• User Authentication requirements
• Authorization Hierarchy requirements
• Legal Compliance requirements
• Transaction processing requirements
• Business Rules-related requirements
• Reporting requirements,

and more.

As you start writing the Functional Requirements for your solution-to-be, it is imperative that you take a need-centric approach. 

This means that one should first identify the client’s business need that must be addressed and then the business process and features that will address this business need.

Next, one should identify the actors/users who will participate in this business process and use the corresponding features to fulfill their needs. These needs of the user and the related user requirements serve as the starting point for creating functional requirements.

Note: Quite often, the client incorrectly formulates the business need the solution is intended to solve. As the CIO or CTO of the client, you should see to it that the business analysts of your software development company receive all the information on your business situation, so that they can correctly identify the business needs your solution must solve. 

Note: The client does not always have a clear idea about the business needs of their B2B customers. If you think that this is at least partially the case, you should encourage the Business Analysts working on your SRS to research this matter at greater depth (perhaps, by working on site).

Basically, there are two very similar ways to describe functional system requirements: User Story and Use Case. Of these two, Use Case is a higher-level description. If the functional requirements you are working on are related to more or less complex software functionality, it is recommended that you use the User Story format.

As an example, if you need to allow users to register in the system, you should first formulate this need. Then you should define the user roles (user personas) that will face this need (your internal users, B2C clients, B2B clients, and so on).

Next, you should define the needs of each of the user roles/user personas (for example, the need for B2B customers to indicate not only their name and surname, but also their title and the business entity they represent).

The next step is to create a User Story for each of the user roles/user personas involved, indicating the steps they perform and the outcomes of each of the user actions.

In writing User Stories, one should adhere to the following best practices: 

• Always write any User Story from the end user’s perspective.
• Don’t pile up too many tech details at the start of your User Story.
• Keep your User Story reasonably brief.
• Done create too many acceptance criteria for your User Story (3-4 should normally be enough).

All your User Stories and Use Cases must necessarily be validated using two criteria – Definition of Ready and Definition of Done. 

In the case of Definition of Ready, one juxtaposes a User Story with the various project artifacts that are related to the workflow it describes, like, for example, the solution’s data model, diagrams, validation requirements, and so on.

In the case of Definition of Done, one considers a User Story from the point of view of whether it reasonably covers all the related requirements.

This section of your Software Requirements Specification should also contain links to any documents, illustrations, or artifacts that can help better understand the nature of the requirements it contains.

Important: The Functional Requirements you create must necessarily prioritize all the functional capabilities they describe. This helps optimize your solution’s time-to-market. One should prioritize the features based on their business value and importance. Your development team should implement them in strict compliance with the defined priorities.

All the User Stories you create must also be in compliance with the INVEST Quality Model, where:

I (Independent) – a User Story must be completely independent of any of the rest of your User Stories.

N (Negotiable) – a User Story cannot be “carved in stone” – it can be discussed and adjusted as required. Consequently, a User Story cannot constitute or be regarded as a contractual obligation.

V (Valuable) – a User Story must clearly state the value of the corresponding action and be disposed of, if this value cannot be clearly defined.

E (Estimable) one must be able to estimate a User Story for prioritization purposes, for example, by comparing the business value it brings with the required development time and cost.

S (Small) – a User Story must be implementable with a reasonably small time period. For example, for Agile projects, this time period should not exceed 3-4 days.

T (Testable) – a User Story must be testable in order to be considered as “done.” In other words, it must allow one to immediately come up with the appropriate testing criteria, easily create a test case, and test the User Story by using this test case.

Well-defined Functional Requirements not only allow one to build an efficient and well-performing product, but they also make it a great deal easier for Project Managers, BAs, and Product Managers to create tasks for the developers. It also becomes a lot easier to test the solution.

Non-Functional Requirements

The Non-Functional Requirements are quite diverse. Not all of them may need to be present in a specific SRS document.

These software requirements can include:

• Performance requirements
• Security requirements
• Simplicity requirements
• Usability requirements
• Reliability requirements
• Scalability requirements
• Maintainability requirements
• Operational system-related requirements
• Device Coverage requirements

Let’s look at the more complex and frequently used types of non-functional requirements.

Performance requirements – define the way the system must perform under different circumstances and scenarios, as well as a result of certain user actions.

For instance, they can include the requirement that any of the application’s pages take not more than 1 sec. or 0,5 sec. to open.

It is possible to indicate the permissible uptime for the system (for example, 99,9%), the required processing speed (for example, not more than 100 ms to display widget content), and the peak load (the largest possible number of concurrent users) the system must be able to sustain, while retaining its normal processing speed. Besides, Performance software requirements can include response times, data transfer rates, browsers support, resolutions-related metrics, and more.

Please note, that Performance software requirements can also include some more generic requirements. For instance, a requirement that some calculation-intensive operations be performed in the background beforehand, and not when the user is accessing the corresponding functionality.

Security requirements – can include any software requirements that can help secure your solution in any way.

For example, you can make a requirement to use a certain tech stack, use only http: hosting for all the login and payment-related pages, implement a certain type of security (for example, two-factor or multi-factor authentication), or employ some specific advanced type of Identity Verification that is used for Fraud Detection purposes.

Scalability requirements – these software requirements state for how long one must be able to scale your software solution without any negative impact on its performance.

Reliability requirements – these software requirements indicate the time period, during which your software application must run without failure.

In writing a Software Requirement Specification, it is best to use a well-thought-out SRS template. However, one should regard it as a document that can be adjusted in accordance with the needs of a specific project.

Some of the best practices in Writing Software Requirements

While describing software requirements, it’s better to follow several best practices that usually make them more readable and better understandable to all the project actors:

• Use passive voice to describe actions more often than you do elsewhere.
• Use only the terminology that is accepted in this industry, and not any other one.
• Keep the style and language simple.
• Focus on the business processes – the numerous technicalities should be described in the Technical Design document.
• The SRS document and the rest of the documentation package created for a specific client must be styled similarly.

Your Software Requirements document must necessarily indicate the project stakeholder on the client’s side, who is authorized to approve this document. The document must have this project stakeholder’s written approval on it before your solution starts being developed.

External interfaces (APIs), and other interactions of the solution with external software applications

Your Software Requirements Specification must describe the Applied Programming Interfaces (APIs) that your solution will use to connect to other software systems (for example, Google Maps or shipping services). Additionally, your SRS document must also describe the APIs external systems will use to connect to your system.

The API descriptions must clearly state the purpose of an API and the value the corresponding integration brings.

Notably, this section of your SRS should include not only regular APIs, but also a description of any manual export and import operations that involve external systems. For example, if you need to retrieve a file from your system and submit it to an external software system, you need to describe this process and the related UIs.

Design constraints and the limitations of the environment, in which the software will work

This section of your SRS document must describe the environment the solution can function in and any other usage-related constraints. As an example, one can indicate that the solution can run only on machines of some specific type, can be deployed only in AWS or in Google Cloud, or cannot use any calculation facilities that are based in a certain geography.

The section can also contain instructions to find out how compatible your solution will be with the proposed technical environments, and if these proposed technical environments will allow reaching the project goals.

How to tell a good SRS Document?

You can use the following points as a checklist in order to determine whether your SRS document is up to par:

1. The SRS document is well-structured (or contains all the sections we’ve recommended here).
2. The SRS document has a reasonably sufficient number of user stories.
3. The SRS document describes the Functional Requirements for your future solution in great detail.
4. The Functional Requirements in the SRS document include many illustrations, for example, user-flow diagrams and mind maps.

Although it is probably a lot more effective and productive to entrust the writing of your SRS document to your software development company, knowing how one should write software requirements helps maximize the effect in this case too.