Software Requirements Specification: guide + template (2024)

“Stop running in circles and ship work that matters” - from “Shape up” by Ryan Singer

To turn an idea into a tangible product you need to think it through clearly. The best way to do this is to write a Software Requirements Specification.

Having an SRS is the first step toward building your product. Without one, you’ll simply wander in the darkness and waste your time and resources. The main risk is that you can waste all your money before you produce a thing. This happens because no one knows for sure what should be made, or how to make it. As a result, there are endless arguments and reworks.

In this article, we will explain how to tame an SRS to make it work for you so you can launch your product on time and within budget.

What is an SRS?

A Software Requirements Specification (SRS) is a document that comprehensively describes the intended environment of the software and its purpose.

An SRS covers the technical side of how the system should function, as well as the business side of the project, including goals, business needs, and target audience. At Greenice, we also like to include how the plan will be implemented in the same document.

The creation of an SRS involves the client sharing ideas with the development team, and the team processing these ideas, and turning them into requirements with priorities. This allows us to see the full scope of the project, and estimate the cost and risks. As a result, it reduces the likelihood of project failure.

Why do you need an SRS?

An SRS is vital for the success of any project. Here are the main benefits of having an SRS document.

An SRS:

• creates the basis and the framework of the entire project
• gives every party involved in the project access to information about the development process, QA, and maintenance
• explains the tasks to developers eliminating the gap between business goals and the logic that developers are working on (misunderstanding often happens at this point)
• assures that you are working on the right product that solves the right problem
• makes sure that everyone is on the same page, and understands the idea in the same way
• gives project insights for designers, test case guidelines for testers, software explanations for end-users, and a system overview for investors
• provides structure for tasks, and helps solve problems efficiently optimizes the development process
• gives accurate estimates of the risk, time, and cost
• identifies the core functionality (MVP) for the initial and later releases.

Who is involved in writing the SRS?

Writing specifications requires the participation of the following people:

• Client (product owner) - a person with a vision and basic requirements who wants to create a product.
• Business analyst - a person who can turn a client’s ideas into a working plan of action.
• Team Lead - the team of technical specialists who can define what software is capable of and how to realize the solution.

It’s important to understand that every role above is vital. Unless the client is also a developer and business analyst himself, he can’t write an SRS on his own. The same goes for developers and analysts - they won’t be able to create a specification without a client.

There can also be additional participants like architects, UI/UX specialists, and many others. But these are not obligatory and small projects can do without them. Moreover, one person can have multiple roles ‒ for instance, a project manager can also be a business analyst. There’s nothing wrong with this as long as the person is qualified.

How to ‘gather’ requirements?

You don’t 'gather' or make up requirements. There are a number of things you need to do: Elicit - Express - Prioritize - Analyze - Manage.

Let’s see what each of them entails.

Eliciting

The difference between gathering and eliciting requirements is fundamental. Gathering implies that requirements are already out there and one only needs to collect them, while eliciting means a kind of co-creation with all the parties involved. You, as a client, have the product vision and some wants and needs, but only technical specialists can see how to tie everything into a product. Also, a good team should provide you with further ideas and tips about your product.

Negotiation between the client and the team turns ideas into a solid plan. The main task here is to distinguish “wants” from “needs.” ‘Wants’ are functions that are desired in a product. ‘Needs’ are core functions that are necessary so the product can solve the problem. Focusing on what you truly need will help you build the product successfully.

The client is the main source of requirements. But there are also additional ways to elicit them:

• interview end-users
• consult the user manual of a similar product
• research the competition
• conduct a feasibility study

Expressing

Expressing requirements presents needs in a usable form. It starts with simple, general notes which we turn into complete and explicit software specifications. To achieve this you can use the following techniques:

• use cases
• user stories
• storyboards
• wireframes (or sketches), etc.

Requirements can be expressed textually and graphically. They can be detailed or simplified. We will talk about it in detail below.

Prioritizing

At this step, you decide what requirements are the most important and what can be put off until later. To do this you can apply the MoSCoW technique and divide them into groups:

• what MUST be done - obligatory needs that the team have to satisfy first
• what SHOULD be done - sub-vital tasks but still important initiatives that add value to the product
• what COULD be done - optional things that have minimal value
• what WON’T be done right now - currently unimportant things that might be done later

Prioritization allows you to plan and estimate requirements according to their value and urgency. As a result, you will know which needs to be done urgently and which can be put off for a while.

Analyzing

You analyze requirements to see if they are:

• complete - the idea must be expressed fully and completely. The requirement conveys everything that is needed and includes stakeholders, goals, and constraints.
• clear - there must not be any ambiguity, confusion, or vague elements so it can be interpreted in only one way.
• consistent - the requirements must not contradict each other and they must remain applicable during the whole process of product development.

Checking if your requirements meet the client's needs and work well together ensures a great product.

Managing

You will need to group and organize your requirements after you have collected and analyzed them. The easiest way to do this is to give the requirements numbers and group them according to their purpose: for example ‒ business or functional. Another benefit of organizing requirements is that you will be able to revise them at any time, or even reuse them for different products.

Types of requirements

You can group and organize requirements in several different ways. For example, divide them according to their purpose or project area. Here are the main types of requirements:

• Business - define the purpose of the project, and how the product brings tangible and quantifiable business value. Example: The client needs to reduce order errors by 25% this year to increase revenue by $10,000. Business requirements are also connected to business rules that define how the product functions and if it can be successful. Business rules include a privacy policy, governmental regulations, brand uniformity requirements, and conditional routing documents.
• User - describe what users can do with the software and what functionality must be developed. User requirements can be expressed through use cases or user stories. Example: Users can log in to their account by entering their password.
• Functional - describe what behavior the product must support. It can be expressed through inputs and outputs. An information flow diagram may help represent these requirements by showing the context for individual components. Example: After the customer uses a credit card for a purchase, the credit card information is verified and then a receipt is generated.
• Non-functional - explain how well the product must perform. Here are some non-functional requirements: accuracy dependability security usability efficiency performance maintainability Example: Users receive a confirmation email 2 hours after their purchase.

Additional requirements:

• External interface - explain the logical placement of the product among entities outside the product. This shows how the product relates to anything in the system. You can identify it with a data flow diagram. Example: An app for retrieving information from a remote database and showing it to users sits between database entities and the end-user.
• Physical setting - show how to design the product according to the physical environment. Here you must be sure that your team is able to produce the product. Example: The product must be waterproof as it will be used underwater.
• Development constraints - refer to the technologies, conventions, and documentation that the team uses. This also includes supported devices, memory volume, bandwidth, etc. But this aspect is specified later in the process to avoid strict limitations while working on the product. Be sure to remember that technologies evolve and by the time you reach the development stage, the limitations might be out of date. Example: System runs on Linux. System exports financial data to a financial data management program X.

Who will use your product?

Unless you are going to be the only user of your product, you have to know and understand your users. We distinguish users (those who use the software) and stakeholders (those who are affected by the success of the product). The latter can include clients, managers, system administrators and investors. Users can be classified as:

• Primary - the ones who use the product directly
• Secondary - the ones who use the product occasionally
• Tertiary - the ones who are affected by the product

Knowing your primary users helps you design a product according to users’ needs. The key point is that while users usually know what they don’t like, they can’t tell you exactly what they need. In addition, they are unfamiliar with new technologies, so they rely on old ones. That’s why the development team should create a user-friendly and intuitive interface. With this, users will be able to use the software even without technical know-how.

Just be sure that the team doesn't make the product incomprehensible to potential users. Be aware that their way of thinking may be different from ordinary users.

Keep in mind these human limitations:

• perceptual - limitations of our 5 senses (e.g. color blindness)
• physical - limitations of user physical interactions with the product (e.g. left-handed people)
• cognitive - memory-based limitations (e.g. preference for familiar elements)
• cultural - cultural differences (e.g. meaning of symbols)

How to express requirements

It might be problematic to visualize requirements and present them in a logical way. This is probably even harder for those who didn’t create them (e.g. investors, users). Luckily, you have a few useful techniques to do this.

Use cases - a list of actions that defines how an actor (customer, staff member) interacts with the system to achieve a goal. Use cases consist of:

• name
• participating actors
• the goal
• the triggers
• pre- and post-conditions
• basic flow
• exceptions
• qualities

Use cases focus on the actor's point of view. They shouldn’t depend on specific technologies or particular UI platforms.

You can use a technique called a use case diagram to identify actors and their use cases. This helps visually represent product tasks.

User stories - description of features from the user’s perspective. User stories are easy to write, understand and evaluate. They have a certain structure: “As a [stakeholder], I want to [task or function], so that [reason].” In that manner, user stories specify “who” is doing “what” and “why” without too much detail. Usually, stories are written on index cards or sticky notes and can be easily reorganized if requirements change.

Good user story follows INVEST principles:

• Independent - is developed separately from other user stories. Otherwise, it can lead to problems with prioritization and planning.
• Negotiable - brief and not too defined. It allows the client and the team to agree on requirements.
• Valuable - brings value to the client. It explains the reason to build a certain feature and gives clarity to the client.
• Estimable - allows to estimate implementation time because the team has a story of the proper length, and also has domain and technical knowledge.
• Small - can be built within the allotted time. Otherwise, it will be too hard to manage and may turn into an epic (vague and unachievable requirement).
• Testable - can be verified with the help of acceptance tests with measurable criteria.

Storyboards - shows in the form of a story how the end user interacts with the product. There are 2 ways to build a storyboard. The first looks like a comic book. You create a sequence to illustrate every way the actors can interact with the feature. The second is a combination of wireframes and basic flow from use cases. It shows a sequence of interactions between users and the product. The storyboard is not a necessary element of an SRS, but it allows the creator to group user stories in a visual manner to see how they work together and if anything is missing.

Wireframes - also called mockups, a basic visualization of the product that explains to every team member and client how it works. Wireframes must be simple and contain basic functions and end-user tasks. They help to understand the problem that the product solves and the tasks that users expect to be able to do with the product. Wireframes can be created on paper or on a computer. Every sign is a placeholder for future elements, e.g. a shaded box is used for text.

What makes a good SRS?

Specification is like a map - you follow it to arrive at the right destination. Writing this document might look like a challenge, but there are ways to create a functional SRS that will provide huge benefits. Here are the best practices:

• be specific - it should be clear to every stakeholder and team member what the document is about.
• keep it organized - group requirements in order to easily find them, e.g. divide them into functional and non-functional, and/or give them numbers.
• give access to the team and stakeholders - this way, everyone will know what they need to know while not having unnecessary information.
• use authentic sources - check the basis of requirements and all the information.
• create measurable requirements - to know if they are fulfilled. This means it must be possible to test if requirements are done correctly, e.g. “the user is locked out if they enter the incorrect password 3 times”
• avoid epics - epics are unstructured and vague requirements that can’t be accomplished in time. They are most likely to appear at the beginning of the process before there is a clear vision.
• communicate with the team in the right way - remain assertive and helpful by answering all questions and providing maximum information. Avoid settling on the first version of the solution, as it may turn out to be unsatisfying. Explore enough ideas and find a compromise between the client's opinion and the developers’ capabilities.
• keep it modifiable - the SRS is not set in stone. Requirements might change during the process of development and it’s normal practice when using the Agile approach. Just be ready to alter them. It’s impossible to get everything right from the start. The team and client should maintain clear and open channels of communication. After seeing the prototype, preferences will be more clear, and everyone will understand what else needs to be done.

An SRS can be an integral part of an Agile approach to software development. That’s why the principle of staying open to changes is so important. Changes are endemic, but if the team is rigid - the project will fail. Adapt to existing circumstances and make requirements as agile as possible.

How to write an SRS document?

There are a lot of different ways to write a specification. We at Greenice usually follow the structure below, adjusting it slightly to suit every project:

1. Project Overview
2. User roles and permissions
3. Software Requirements
   • Business
   • User
   • Non-functional
   • Wireframes
4. Technology Stack
5. Development Plan

Now, let’s see what each section includes.

1. Project overview

The overview describes a general idea of what is needed. It tells us the vision, and the goal of the product. In a nutshell, you write a synopsis of what the whole project is about.

2. User roles and permissions

You need to decide who will use the software (roles) and who can do what (permissions). Permissions are defined in the context of a particular community. For example, here are basic user roles for the online marketplace:

• Administrator - person with the highest level of permissions. S/he can perform any activity and has access to every part of the system. This role is given only to highly trusted individuals. Administrators can define constraints to other user roles. Seller - a user who registers his business within the platform and offers his products to buyers.
• Sellers can manage their accounts, interact with buyers, and watch statistics, but their capabilities are defined by the administrator.
• Buyer - a user who can buy products from sellers. Usually, s\he needs to create an account to do this, but many platforms offer the ability to buy something without registration.

3. Software Requirements

List all types of requirements for your product:

• Business - define why the product is needed
• User - what tasks users can do with your product
• Functional - what functionality is expected, what features the product will have
• Non-functional - specify what you expect from your software in terms of qualities like performance, speed, and security
• Wireframes - a draft of what the user interfaces will look like

4. Technology Stack

List the tools and platforms that are needed to create the project. The technology stack consists of the backend (how it works) and frontend (how it looks).

Backend technologies examples:

• Programming languages - Python, PHP
• Databases - MySQL, GraphSQL
• Web servers - Apache, NGINX, Frameworks - Laravel, Django

Frontend technologies examples:

• Programming languages - HTML, JavaScript
• Frameworks - React.js, Vue.js

Additionally, your project may require some integrations. For example, it can be a payment system like Stripe or integration like REST API.

Every project requires an individual set of technologies. To know exactly what you need, you should consult an experienced development team. These items are the most important:

• project size and complexity
• time to market
• security
• features of the project

5. Development Plan

Here you work on describing steps to build the project. Divide the work into milestones and tasks, and decide in what order they will be done. Include design, development, and marketing from the start to create a quality product without gaps. It’s a good idea to focus on creating an MVP and then add features.

SRS document example

Here is a template to help you write your own specification.

Conclusion

Starting a new business is always hard and risky. The secret is to have the right product that is done right and managed well. A proper SRS will help you get there.

A software requirements specification outlines the project details. This document describes every aspect: business goals, stakeholders, users, technology stack, etc. It helps find an understanding between the team and the client.

With the right approach toward writing the SRS, you will be able to build a viable product and not waste your resources. The most important thing is to remain agile and be always ready to adapt to changes. You’ll end up with something fantastic!