Software requirements specifications – the first step to successful development
It's no secret that ordinary people and programmers speak different languages. But despite this, business needs automation, and managers need to negotiate with IT industry representatives.
One of the key factors ensuring the successful cooperation of the customer and the executor is the software requirements specifications (SRS) – a document that contains the customer's requirements. The final acceptance of developed information system is made on the basis of this document, so its importance can hardly be overestimated. For instance, the stage of writing and harmonization of SRS can take up to 30% of the total time of all works on large projects.
In this article, we will not address the issue of writing requirements specifications for websites, because this topic deserves a separate discussion. Instead, we will focus on the SRS for the automated information system (or part thereof) and will try to reveal the main points that this document should contain.
There are GOST standards (regional standards) for writing the SRS documents, which are used in Russian Federation: GOST 34.602.89 "Technical directions for automated system making" and GOST 19.201-78 "Technical specifications for development. Requirements to contents and form of presentation". Of course they are different from IEEE standards, but the structure of the final document is not so dissimilar. Nevertheless, we will mainly look at GOST standards, which describes following structure:
- general information about the system;
- the purpose of the system;
- functional and non-functional requirements;
- documentation requirements;
- conditions for acceptance;
- development stages.
The last point is not included in IEEE standards.
General Information About the System contains information about the customer, the developer, time limits, other documents references (for example, internal enterprise standards), a list of terms and abbreviations. Often Terminology/Glossary/Definitions list is a separate section of the document.
Filling in the section The Purpose of the System will allow you to state the purpose of the system and formalize the goals that will be achieved through the development of an information system.
The most voluminous is usually the Functional and Non-functional requirements section. It contains detailed and explicit description of system features. Nonfunctional requirements mean requirements for reliability, security, privacy , and other parameters of the system.
Documentation Requirements section defines which documents, such as project documentation and user documentation, should be provided in the kit with the system.
Conditions for Acceptance section contains documents or description which allow to determine if the result of development corresponds to the contract.
Typically, the development process is divided into several stages. Their description should be in the Development Stages section. Each stage may have its own time limits and cost, as well as the functional requirements.
Summarizing, software requirements specifications is not just a document, it is the transition from design to implementation. To avoid wasting valuable resources on multiple remaking the half finished system, it is necessary to achieve the maximum possible understanding on the analytical stage. Of course, we have presented the very rough structure of the document, but it contains the key points that will allow you to get an idea of what you need to prepare before looking for an IT company and developing an information system.
