Table of Contents
Why write a software requirement specification at all? Perhaps the right answer is that we are writing specifications in order to competently manage risks. After all, the implementation scheme over time can simply be forgotten, a key employee can go rogue taking knowledge about the project with him, a newcomer who comes to replace him will howl due to the prospect of collecting information bits manually and from the words of colleagues, and finally, team members can just understand the same workflow in different ways.
To make long story short, the software requirement specification is a very useful thing, but how to write it correctly? Moreover, how to write it so that it can later be read by living people? In fact, the secret is simple - you just need to understand the subject well, because if you can’t explain something in simple words, then you don’t fully understand this. Or vice versa, you are so smart that the intricate constructions generously flavored with professional vocabulary is a dull daily routine for you and, well, how can they not understand basic things. Just keep in mind that the second option, in the first place, happens extremely rarely, mainly among world-renowned scientists, and secondly, think about your grandmother. Would she be pleased to read such a messy software requirement specification? How would you look into her eyes? Would you dare to say that she is simply not smart enough for such complex things? Yeah, that’s it.
In fact, there is no secret here. To write a high-quality and understandable software requirement specification, you just need to clearly understand what it is written for, why these or those sections are needed, and also follow several rules. And of course, keep in mind that the final recipient of the information will still be a living person who most likely doesn’t want to supplement what you have written with its own guesses and assumptions (as a client-oriented company we are pretty sure about this). Now let's get every software requirement specification duck in a nice row.
What is software requirement specification?
What is the specification for?
.1 You can get an accurate estimate of the cost, risk, and time spent.
.2 The client will be able to more clearly draw their own vision of the project.
.3 Customer and Contractor will have the same idea of the product.
.4 It will help to identify the optimal set of functions.
.5 It serves as the basis for the formation of other technical documentation.
.6 The development process will be optimized - time spent minimized.
.7 No duplication of tasks.
.8 Allows you to structure problems in order to solve them easier and faster.
.9 It helps to understand which results are considered optimal when testing.
Problems encountered during the development of a project without software requirement specifications
- It will not be possible to obtain an accurate estimate of the cost, risk, and time spent.
- Customer and Contractor may have a completely different idea of the product.
- Developers cannot be sure that the software they create fully meets customer requirements.
- It will be very difficult to write a user guide.
- It is likely that you will need to redo parts of the project again.
SRS structure
Are you ready? Just don’t panic.
An embarrassment of riches, as they say. But don’t be scared. In fact, everything becomes somewhat easier if you try to delve into the goal of each item.
- Introduction\Purpose
This section is intended to describe the application or product whose functionality will be described in the document.
- Introduction\Document conventions
If you have any obscure technical words or terms that will be used in the future in SRS, then you need to describe them here. But there are a couple of conditions! Firstly, the description of an incomprehensible word cannot contain another incomprehensible word. The term that you use should be described in detail, in a simple and understandable language. The worst thing you can do is to fool around in this section and not to list everything in detail. There is no doubt that, the more obscure things you describe, the easier it will be to design the application later.
- Introduction\References
This section is needed for references to literature in which you can find the basis of the technologies and facts used. Here you can embed RFC, if you are writing an application that works with TCP/IP, insert links to documents, etc. Write the most complete links and its descriptions in case the website has kicked the bucket. This way one can quickly google this issue.
- Overall Description\Product features
This section is needed to describe part of the functionality at a higher level. A detailed description of each part of the functionality will be in the corresponding section below. In this part, it is desirable to place a DFD diagram that illustrates the overall interaction of the system.
- Overall Description\Operating environment
As comes from the name of the section, we describe the environment in which the product will work. Operating system, version of compilers, database, server, software, hardware and other things that are crucial for your product.
- Overall Description\Design and implementation constraints
This section is quite vicious:). It limits the freedom of developers’ thought by imposing development standards. Such restrictions may be, for example:
- Programming language database;
- Coding standards;
- Data Exchange Standards;
- Limitations imposed by the operational environment;
- Limitations that may be imposed by the business logic of the project.
- Overall Description\User documentation
Here we describe what documentation is needed for users of this product.
- System features\System feature X
Here we call the features of the project and give it a unique identifier. A unique identifier is given in order not to write somewhere in your tickets - “the thing that does that task”.
- System functions\System function X\Description and priority
Here we should describe in details the product’s features. What is it for? What should it do? What part of this task should it perform?
- System Functions\System Function X\Stimulus/Response Sequences
Trigger of a feature. When does it start working?
- System Functions\System Functions X\Functional Requirements
Detailed description of features. Everything should be checked for errors.
- External interface requirements
Interaction with the outside world. If there will be one of course. What are APIs, how to get this or that data, etc. Subsections are used to detail requirements.
- Non functional requirements
Non functional requirements, such as security requirements.
- Non-functional requirements\Performance requirements
Performance requirements. This is not a feature, but it may impose certain restrictions. Let’s assume a project database must withstand 2000 queries per second. Further work on project optimization depends on these requirements.
- Non-functional requirements\Software quality attributes
Here the quality requirements of the code are described. What tests and metrics are used to determine the quality of the code? How much code should the tests cover?
- Non-functional requirements\Security requirements
Requirements for safety. For example if speaking of HTML editor, it can be something like: through an HTML editor it should not be possible to put a shell on the server, etc.
- Appendix A: Glossary
Simply an application. Sometimes in SRS there is a protocol description. This is not crucial. However, sometimes you need to clarify one concept or another. This is what this section for. Insert links to such explanations. Serves as a kind of a dictionary.
- Appendix B. Analytical Models
List of SRS diagrams. This can be DFD or some general interaction and work diagrams.
- Appendix C: List of Issues
This section is used in very formal SRS. Describes To be done items.
Well, did it become clearer? We hope that at least you no longer feel like a student who does not know how to start writing scientific work. You might think that we were a little deceiving by promising specific tips in the heading, while actually we simply sticked to explaining the sections, but again, there is no secret here, you just have to sit down and do it. And then re-read it. And then re-read it a couple of times more. Then postpone the document for a couple of days and re-read it again, and give it to your colleagues. And keep in mind the image of your grandmother throughout the whole process. If you clearly understand what you are doing and why, you will succeed. However, just in case, here's a couple more general recommendations.
Basic requirements for all SRS sections
- Be brief and be clear. Describe everything very briefly and clearly. As much as possible.
- No ambiguous descriptions. A person reading SRS should understand exactly what is written. Murphy's Law: If you can be misunderstood, you will be misunderstood.
- Simplicity and readability. Do not use any too abstruse constructions. Beauty in simplicity!
- DFD diagrams (data flow diagram, DFD) is one of the main tools for structural analysis and design of information systems that existed before the widespread use of UML. This is a methodology that describes data sources and destinations external to the system, logical functions, data streams, and data warehouses that are accessed. The specification may not be complete if we do not know what is at the entrance to the described software and what is at the exit. Everything should be clearly drawn.
- The degree of detail. This is a heuristic parameter. It can be defined as follows: if I can freely state the information about the functions and what is written doesn’t cause me any embarrassment, if the requirements are unambiguous and cannot be doubly understood, if the requirements sufficiently describe the behavior of the functional for me, then the development of SRS can be considered complete.
Trump card in the sleeve - IT consulting
If you are a business owner, not a developer, then it may seem to you that everything written above is not your concern. After all, the writing of software requirement specification should be done by an IT specialist who is thoroughly versed in the matter. However, it’s too early to relax, as in this process you are a key figure. The success of a further enterprise depends on how clearly and in detail you state your requirements and wishes. No doubt, it will be a shame if in the process (or even on the release) it turns out that you and the contractor misunderstood each other.
In order to minimize such misunderstandings, there is an IT consulting service. IT consulting is a whole range of consulting activities, during which you can discuss in detail each requirement, every little thing and every wish for a future project. We strongly recommend that you use this service, if there such an option, as when real professionals come to work, they will not only help you figure out the situation, but will also offer your ideas and comments.
***
To summarize, in order to write a software requirements specification, you need to pick yourself up, sit down and write a software requirements specification, instead of procrastinating by reading articles on how to do it. On the other hand, there is still enough time, you figured out the principle of solving the problem, so why not pour some more tea and read a couple more articles. Here's an interesting one Searching for Startup Financing: Top Options for Small Business.
