SMS? BTS? CMS? SRS!
Software requirements specification is a document with requirements for an app. The SRS document includes functionality and performance requirements and limitations. SRS is compiled to facilitate transparent interaction between a client and a contractor.
SRS is written in the client language based on their opinion. To start cooperation, a contractor should know what clients want, and understand their desires and business goals. Based on information gathered during several calls, contractors make an SRS document.
The SRS document has several features.
Structure
Looks scary. On the one hand, having a template for every project is convenient, on the other hand, there is a risk of putting yourself in the box and losing product individuality.
SRS structure includes a detailed description of each part of the future app. The problem is that 90% of the information there is useless. Only design examples and explanations of complicated work algorithms are valuable. If Tinder had SRS, there would be a matching algorithm. And 37 useless pages.
The typical structure of software specifications looks like this:
- Introduction:
1. Goals
2. Terminology conventions
3. Target audience and consistency of perception
4. Project scope
5. Links to sources
- General description
1. Product vision
2. Product functionality
3. Classes and characteristics of users
4. Product operating environment (operating environment)
5. Scope, restrictions, rules and standards
6. User documentation
7. Assumptions and dependencies
- System functionality
1. Functional block X (there can be several such blocks)
2. Description and Priority
3. Causal relationships, algorithms (movement of processes, workflows)
4. Functional requirements
- Requirements for external interfaces
1. User interfaces (UX)
2. Programming interfaces
3. Equipment interfaces
4. Communication and communication interfaces
- Non-functional requirements
1. Performance requirements
2. Security (data) requirements
3. Software quality criteria
4. System security requirements
- Other requirements
Appendix A: Glossary
Appendix B: Domain Process Models and Other Diagrams
Appendix B: List of Key Tasks
Relevance
As much as we would like to talk about the advantages of the company or ideas that came to mind already during the development process, it is prohibited to do so in the SRS document. The document has a clear purpose and must have clear content. SRS always reflects the functionality and technical characteristics of a product.
Transparency
This is about terms and language. Use the client language, but don’t oversimplify, or go overboard with euphemisms and literary tricks. It would help if you didn’t write about the magic work of code masters and the ingenious inventions of picture masters. It’s better to be overly specific than ambiguous. The software requirements specification is not a masterpiece of world classics, so even the most rudimentary stylistic rules can be ignored in the name of clarity.
Accuracy
Abbreviations, names — should not differ in the document. At first glance, this is a trifle, but since the document is official by nature, you should not make mistakes in such moments. This is how it should and should not be:
Priority rating
If it takes a long time to fulfill a requirement, it is worth giving it a high priority. In general, ranking requirements by importance and stability is a good idea. By stability, we mean how accurately we set the task, and whether we will have to change something during execution.
Changes
Although the SRS is a highly regulated document, it can and should be systematically changed. True, this is not as easy as it seems — the SRS document is far from flexible. Startups suffer the most from this: MVP applications often need to be changed in the process, and everyone forgets to update the software requirements specification. Even in large companies that love paperwork and bureaucracy, you can often find Confluence with 5-year-old documentation. Why was it even done? Of course, for the show!
SRS in Russia and abroad
Over seven years of work, we have noticed that the attitude towards SRS documents in Russia and abroad is significantly different. We are trying to understand why Russia is so fond of paperwork, and how to ‘sell a design concept at the SRS price.’
| Russia | Abroad |
| Russian clients often ask us to make an SRS. It is customary to make big reports on everything that happens around, so even the modern IT sphere can’t live without red tape.
Sometimes, we are forced to make such documents because the client is a large government entity, where, as you know, people can do nothing without reports. For one of such clients, we wrote the case ‘Big Brother is real.’ Tap the link below to read more 👇 |
However, foreign clients rarely require SRS. They willingly accept our rules and agree on a flexible working model. There are, of course, principal clients too. Once, a client insisted on drawing up an SRS document because he wanted to request development from another contractor. We ‘rebuilt’ it: we made a hybrid of the SRS and our standard design description and added illustrations. He liked it and stayed with us! |
5 reasons to give up on SRS
At Purrweb, we don’t do SRS documents. This is a principled position, from which we retreated only a couple of times — we remind you that the number of our projects has exceeded 250. We don’t waste time on paperwork and bureaucracy and save clients’ resources. We highlighted five main reasons why you don’t need the SRS.
Time
SRS will gobble up your time and won’t choke on the bones of sales managers. How long will it take to complete the document? We asked our COO to rate this task. The numbers speak for themselves:
It’s all about the high detail of the SRS document. Collecting the necessary information can take a long time — business analysts must approach designers, developers, QA engineers, and team leads. There are many technical issues inside the software requirements specification that are hard to comprehend for a person far from development. During the time spent on SRS, we managed to complete one sprint and come to the client with the first results. We are sure — this is better than a piece of paper.
Non-effectivity
It doesn’t matter how good managers write the requirements at the start of the project. EVERYTHING can go wrong at ANY moment. So, the time and money you spent on the SRS, to put it mildly, don’t pay off. Your business analysts will probably feel useless. The client needs only 15-20% of the whole document they spend 80 work hours on.
All the rest of the SRS document is bureaucracy bullshit. Such documents are drawn up in large companies for the effect of ‘creating turbulent activity’ and a report for the sake of a report, which in 9 out of 10 cases will not even be opened.
Anti-agile
SRS is not compatible with agile development. It is impossible to look at a blank screen and see the future application down to a button. However, the methodology for drafting the SRS document states the opposite: you must draw up a detailed action plan with a detailed description of each step before the team starts working.
This approach matches the Waterfall model well. The peculiarity of waterfall is that all stages of project creation are in order. First, they do the whole design, then the entire development, and they test everything. If they find bugs, they fix it in the already-finished application. There is no return to the previous step, so it is important to do each step ‘perfectly.’ In our opinion, it is an extremely romantic model. No SRS will save you from bugs or urgent tasks that the software requirements specification does not provide.
So, companies that use agile and SCRUM methodologies reject SRS documents. There (and here) they work in sprints. Testing takes place at the end of a two-week iteration, so bugs are found immediately. This way developers don’t have to go through all the code to find a breakdown.
This model is convenient not only for the development company but also for the client. With the agile approach, you are always in touch with the project manager, which means you always have up-to-date information on the project. You do not have to constantly refer to the SRS document, as the data may become outdated at the very first iteration.
At Purrweb, we keep in touch with each client, especially if the project has specific conditions. For example, in the Headcount case, the client had a limited time frame, so he was heavily involved in the development process and micromanaged all our steps. Read more about high-speed application development for the fintech industry here 👇
Dev companies don’t need SRS
Let’s reveal a terrible secret: we would not use the SRS, even if a client insisted on preparing it. The document would be dead weight on the developers’ desktops. When we were first asked to draw up an SRS document, we simply downloaded a template from the Internet and customized it for the client. Spoiler alert: the startupper didn’t even notice. We don’t think he opened it. And we didn’t open it either.
…And startups too
‘What’s wrong with a startup?’ — the owner of the startup asks. The startup is fine, but the SRS document is still a nuisance. While another contractor will draw up a document with a detailed description of the functionality of the future application, we will already make the first version of the design and show it to the client.
Purrweb chooses this approach based on the target audience — we have startups that come for MVP (Minimum Viable Product). Instead of wasting the client’s time and money and our human resources on an ugly SRS, we offer the client the opportunity to save money and start the design right away.
At Purrweb, we start the work after a call with an account manager. There, we discuss the project idea and promise the client several deliverables: concept, user stories, and database structure. We don't even suggest making an SRS.
Next, we’ll tell you why design is first.
Instead of a thousand words: alternative to SRS
Instead of thousands of words and dozens of pages with unnecessary information, we offer our clients a design-first approach. This means that immediately after we confirm cooperation, the design team begins to work. Do not be afraid, the designers will not design ‘what is needed and not needed’ — the account manager and the client discuss all the details on the calls, and the business analyst estimates the project’s cost. We receive anti-references from the client and sometimes, design solutions — so there is always something to start from.
Why is it good to start with design?
Because design is part of the future product, and the SRS document is just a collection of words put together in a strict structure.
Not a single technical assignment or SRS can prescribe everything at once. During the project, everything can change (and 100% will change) — no one will return to the technical task to fix or update something.
How we do it: instead of large documents, we write user stories. Based on user stories, we do design, based on design, we evaluate the development, then we do the architecture and database structure. And only at the development stage we make a small document — describe how the logic on the backend or some complex algorithm works. Important: this is not an official document. We may not even show it to the client, but do it ‘for ourselves’ and store it in the readme file in the repository.
With this approach, it is easy to make changes at any stage. Even if by the end of development, for example, the admin panel which was done in the middle of the project, falls off, the developer does not need to go back and ‘raise’ everything. Most importantly — there are no complicated documents, red tape, bureaucracy, and other terrible things in the world of reports.
No SRS?
We are loyal to any wishes of the customer: want a custom chat, calendar, and video calls? Yes, please! Like to follow every development step? No problem, we will call you more often. But when it comes to the specification of software requirements, we will offer the client alternative solutions to the last.
The SRS document is not in line with the values of the agile approach, does not benefit the client, and takes away both our and their resources. At Purrweb, we have been doing everything differently for a long time: we work according to Scrum, and we do not fill our clients’ heads with nonsense like huge technical specifications, but we develop simple interfaces with a convenient design.
Want to order an app from Purrweb? Below is a form for your e-mail 👇
