There’s many steps between an IDEA and a final product. That’s why in this article we’ll focus on making the very first step in which we create Software Requirements Specification. A document that starts it all.
What is Software Requirements Specification?
Software Requirements Specification is a document that describes the whole scope of a project. It consists of a number of different aspects of a product like its features, targeted personas, business model and more.
“Software Requirements Specification is a single most important document in the whole software development process. The more effort is put into it, the bigger the chance of a successful project.”
This document or set of documents is the best way to make sure everyone involved is on the same page. We’re talking about development team, stakeholders etc.
Why do we need Software Requirements Specification?
There’s often a misunderstanding of what Agile software development means. Some people say:
Why do you need requirements specification? Aren’t you supposed to be agile?
Agile programming focuses on developing the best product possible thanks to adaptive planning, early delivery and continual improvement. However, it doesn’t mean that there’s no documentation needed. It’s not going to be as detailed as a documentation for waterfall programming but it’s definitely necessary to have it as a base of every project.
It allows us to have the same perspective on what the final product should look like while being agile in a way it’s being developed.
We also need it for:
- Estimation of cost and time needed to develop the product
- Understanding a business logic and business value of a product
- Prioritizing features based on products key market preposition
- Better understanding of problems and how to solve them
- Predicting most probable scenarios to act quicker in a moment of uncertainty
- Better task management and quicker deployment
What Should SRS consists of?
Software Requirement Specification can consist of many different informations. However, there’s a few key elements that are always a part of SRS.
-
Project Scope
Usually documentation starts with a basic description of a product to create a general understanding of next points. For example, it often mentions the goal for the project and what is the purpose for it.
-
Problem statement / Product Value
In order to develop a successful project we need to create a value for that product. It can be a problem solution or a completely new market value. Either way, it’s important to conclude it in the SRS. In case of unpredicted changes it is clear what the main focus for the project is. It prevents from losing this value.
-
Glossary
It’s a good idea to create a glossary, dictionary with definitions of unusual phrases, product names etc. to create ubiquitous language. Moreover, it helps the reader to better understand not only documentation but also your business.
-
Personas / Users
Some Software Requirement Specifications consist of product personas. It’s a description of a main user target. A project usually has between 1-3 personas per product. It describes the age, gender, average earnings, hobbies, profession and more of a persona. Depending of the product they can inform about things like whether or not this person uses social media etc. Product Owners create personas to help understand what our targeted user might look for in our product and how to reach them.
-
User stories / Functionalities
User stories are a form of describing features for a product. We create a scenario of what we want the user to do on our app. It usually looks something like this:
As a < type of user >, I want < goal > so that < reason >.
Some features are too big to develop them within one sprint and they’re called epics. They’re being presented as a number of smaller user stories that eventually come together as a feature from epic.
Here’s an example of an epic based on Spotify app:
- As a user, I want to have a playlist of my favorite songs so I can find them easily.
This user story needs a few other user stories to develop this feature. Here’s how we could create smaller user stories:
- As a user, I want to be able to save a song that I like so I can listen to it later.
- As a user, I want to be able to view my saved songs so I can choose which one I want to listen to.
And here’s an example of tasks that would be needed to develop this feature:
- Add “Save to favorites” button next to every song.
- Create folder of favorite songs of a user.
- Create “Shuffle play” button in a folder.
These user stories are a part of product backlog and inform developers on what features need to be developed.
-
Operating environment
When we’re developing an application we need to have information on operating environment that the product needs to cooperate with. For example, those are usually informations about operating system, type of hardware etc.
-
System Architecture
System architecture is a description of the overall system. Which means that its purpose is to show the overall business structure of individual components and how it will cooperate with the product. Moreover, system architecture shows relations between elements and life-cycle processes.
-
External interfaces requirements
This point specifies each element and component of the system: user interface, hardware, software and communication interfaces. Information about user interface often consist of UI mockups, resolution requirements, functions, menus, navigation links etc. Hardware Interfaces focus on supported device types, communication protocols between software and hardware etc. Software Interfaces specify databases, libraries, external components. It might also mention web browsers etc.
-
Nonfunctional requirements
Last but not least, depending on the type of the project there might be other requirements that have nothing to do with the functionality of the application itself. For example, there might be a certain level of security needed. This is a place where you can be introduced to some criteria, behavior etc.
Useful Tips
Now that you know what does Software Requirements Specification consists of, it’s time for some special tips for you that will make your documentation even better.
- Remember that the person reading it most probably has never heard of your company, is not familiar with your business logic and won’t know more than what is written in SRS.
- Don’t be overly descriptive. Find balance and avoid explaining irrelevant things.
- Using graphs, graphics, diagrams and other visuals is very appreciated. It’s the most effective way to describe requirements, processes etc.
Now there’s nothing left to do than start writing THE PERFECT Software Requirements Specification!
