Software requirements specification
We all know very well how software is developed. We thought for 10 minutes and immediately went to code . The software development cycle consists of many key points. These are such moments as planning, creating architecture, creating SRS, creating design, etc., etc.
SRS - Software Requirement Specification - a special documentation for software that contains information on how the system should behave, what functions should perform, what kind of load it must withstand, and so on.
Everything is extremely simple. You use TK (bike), I use SRS (car). I hope the analogy is clear? :)
Below is the structure in English in raw form. A little later in the article we will consider each item in more detail
And so we sorted out the structure, now let's move on to the sections and what we need to write in them.
Introduction \ Purpose
In this section, we describe an application or product whose functionality will be described in SRS.
Introduction \ Document conventions
Here we describe all obscure technical words or terms that are found in SRS. Note that the description of an incomprehensible word cannot contain another incomprehensible word. Try to describe in as much detail as possible the term that you use in a simple and understandable language. Do not save on this section because the more you write down obscure things, the easier it will be to design later.
Introduction \ References
In this section, we write links to literature in which you can find the basis of the technologies and facts used. Suppose you can embed RFC if you are writing an application that works with TCP / IP, insert links to documents to which you refer, and so on. Links and their description should be as complete as possible, in which case (the link died simply) it was possible to google this material.
Overall Description \ Product features
In this section, we describe the parts of the functionality at a high level. In more detail, each part of the functionality will be described in its section below. Here it is advisable to place a DFD diagram that shows the general interaction of the system.
Overall Description \ Operating environment
As is clear from the name of the section here, we describe the environment in which the product will work. OS, versions of compilers, databases, servers, software, hardware and other things that are necessary for your product to work.
Overall Description \ Design and implementation constraints
This section is vile :). It limits the flight of thought of the developer by imposing development standards. Such restrictions may be, for example, such things:
Overall Description \ User documentation We
describe what documentation is needed for users of this product. Perhaps this is a book on HTML if it is an HTML editor.
System features \ System feature X
We name the feature for the project and give it a unique identifier. For example, server.html.editor. A unique identifier is given in order not to write somewhere in your tickets - “but the shit that allows editing HTML”
System features \ System feature X \ Description and priority We
describe in detail the feature of the product. What is she for? What should i do? What is her execution priority? .. From this section, it should immediately become clear to the reader of the cms user why this functionality is present in the system.
System features \ System feature X \ Stimulus / Response sequences
Trigger trigger features. When does it start and how does it behave at startup? For example, an HTML editor is displayed when a user clicks on a menu link. Open HTML editor.
System features \ System feature X \ Functional requirements
Detailed and detailed description of the feature. We describe everything: how it works, how it reacts to errors, what it should check, how to display data, how and where it saves, etc.
External interface requirements
Description of how the system will interact with the external worlds. If it will be of course. What API, how to get this or that data, etc. Subsections are used to detail requirements. What software interfaces, hardware interfaces, communication interfaces, and more.
Non functional requirements
non-functional requirements. There are requirements that cannot be described as some kind of feature, for example, security requirements.
Non functional requirements \ Performance requirements Performance requirements
. This is not a feature, but imposes certain restrictions. Suppose a project database must withstand 1000 queries per second, and so on. These requirements lead to tremendous work to optimize the project.
Non functional requirements \ Software quality attributes
Here we describe the code quality requirements. What tests to use? What metrics to use to determine the quality of the code? How much code should be covered by tests?
Non functional requirements \ Security requirements
Safety requirements. If this is an HTML editor through which you can change something on the site, then 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
Application. Sometimes in SRS they try to insert a description of the protocols, etc., etc. This is not necessary. However, sometimes you need to clarify some kind of concept. There is this section for this. Insert links to such explanations. Such a dictionary.
Appendix B: Analysis Models This
section defines which diagrams should be used when writing SRS. For example, DFD, some general diagrams of interaction and work
Appendix C: Issues list
This section is used for very formal SRS. Describes the points TBD (To Be Done) - what in the future still needs to be done, but is not described here.
SRS is optional, but can help with medium to large projects. Using SRS shows your professional level as a developer.
PS I ask you not to blame much - the first article of a more or less average scale on a hub Corrections in the syntax are welcome (I try to write correctly, but a 7-grade education in the Russian language leaves its mark.)
What is SRS?
SRS - Software Requirement Specification - a special documentation for software that contains information on how the system should behave, what functions should perform, what kind of load it must withstand, and so on.
Why is it needed?
Everything is extremely simple. You use TK (bike), I use SRS (car). I hope the analogy is clear? :)
SRS structure
Below is the structure in English in raw form. A little later in the article we will consider each item in more detail
- Introduction
- Purpose
- Document conventions
- Intended Audience and Reading Suggestions
- Project scope
- References
- Overall description
- Product perspective
- Product features
- User classes and characteristics
- Operating environment
- Design and implementation constraints
- User documentation
- Assumptions and dependencies
- System features
- System feature X ( there may be several such blocks )
- Description and priority
- Stimulus / response sequences
- Functional requirements
- System feature X ( there may be several such blocks )
- External interface requirements
- User interfaces
- Software interfaces
- Hardware interfaces
- Communication interfaces
- Non functional requirements
- Performance requirements
- Safety requirements
- Software quality attributes
- Security requirements
- Other requirements
- Appendix A: Glossary
- Appendix B: Analysis Models
- Appendix C: Issues list
And so we sorted out the structure, now let's move on to the sections and what we need to write in them.
Basic requirements for all SRS sections
- Briefly, clearly. Describes everything extremely briefly and clearly. As much as possible.
- Without ambiguous descriptions. A person reading SRS should understand exactly what is written, and not something else. Murphy's Law: If you can be misunderstood, you will be misunderstood. Avoid this
- Simplicity and "readability". Do not use any too abstruse turns. Beauty is in simplicity :)
- DFD diagrams . The specification cannot 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 functional and what is written does not cause me any embarrassment, if the requirements are unambiguous and not subject to any double understanding, if the requirements sufficiently describe the behavior of the functional for me, then the development of SRS can be considered complete
Explanation of each clause of the SRS structure
Introduction \ Purpose
In this section, we describe an application or product whose functionality will be described in SRS.
Introduction \ Document conventions
Here we describe all obscure technical words or terms that are found in SRS. Note that the description of an incomprehensible word cannot contain another incomprehensible word. Try to describe in as much detail as possible the term that you use in a simple and understandable language. Do not save on this section because the more you write down obscure things, the easier it will be to design later.
Introduction \ References
In this section, we write links to literature in which you can find the basis of the technologies and facts used. Suppose you can embed RFC if you are writing an application that works with TCP / IP, insert links to documents to which you refer, and so on. Links and their description should be as complete as possible, in which case (the link died simply) it was possible to google this material.
Overall Description \ Product features
In this section, we describe the parts of the functionality at a high level. In more detail, each part of the functionality will be described in its section below. Here it is advisable to place a DFD diagram that shows the general interaction of the system.
Overall Description \ Operating environment
As is clear from the name of the section here, we describe the environment in which the product will work. OS, versions of compilers, databases, servers, software, hardware and other things that are necessary for your product to work.
Overall Description \ Design and implementation constraints
This section is vile :). It limits the flight of thought of the developer by imposing development standards. Such restrictions may be, for example, such things:
- Programming language database
- Coding standards
- Data Exchange Standards
- Restrictions imposed by Operational Enviroment, let's say only compatibility with FF
- Constraints that may be imposed by the business logic of the project
Overall Description \ User documentation We
describe what documentation is needed for users of this product. Perhaps this is a book on HTML if it is an HTML editor.
System features \ System feature X
We name the feature for the project and give it a unique identifier. For example, server.html.editor. A unique identifier is given in order not to write somewhere in your tickets - “but the shit that allows editing HTML”
System features \ System feature X \ Description and priority We
describe in detail the feature of the product. What is she for? What should i do? What is her execution priority? .. From this section, it should immediately become clear to the reader of the cms user why this functionality is present in the system.
System features \ System feature X \ Stimulus / Response sequences
Trigger trigger features. When does it start and how does it behave at startup? For example, an HTML editor is displayed when a user clicks on a menu link. Open HTML editor.
System features \ System feature X \ Functional requirements
Detailed and detailed description of the feature. We describe everything: how it works, how it reacts to errors, what it should check, how to display data, how and where it saves, etc.
External interface requirements
Description of how the system will interact with the external worlds. If it will be of course. What API, how to get this or that data, etc. Subsections are used to detail requirements. What software interfaces, hardware interfaces, communication interfaces, and more.
Non functional requirements
non-functional requirements. There are requirements that cannot be described as some kind of feature, for example, security requirements.
Non functional requirements \ Performance requirements Performance requirements
. This is not a feature, but imposes certain restrictions. Suppose a project database must withstand 1000 queries per second, and so on. These requirements lead to tremendous work to optimize the project.
Non functional requirements \ Software quality attributes
Here we describe the code quality requirements. What tests to use? What metrics to use to determine the quality of the code? How much code should be covered by tests?
Non functional requirements \ Security requirements
Safety requirements. If this is an HTML editor through which you can change something on the site, then 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
Application. Sometimes in SRS they try to insert a description of the protocols, etc., etc. This is not necessary. However, sometimes you need to clarify some kind of concept. There is this section for this. Insert links to such explanations. Such a dictionary.
Appendix B: Analysis Models This
section defines which diagrams should be used when writing SRS. For example, DFD, some general diagrams of interaction and work
Appendix C: Issues list
This section is used for very formal SRS. Describes the points TBD (To Be Done) - what in the future still needs to be done, but is not described here.
Conclusion
SRS is optional, but can help with medium to large projects. Using SRS shows your professional level as a developer.
PS I ask you not to blame much - the first article of a more or less average scale on a hub Corrections in the syntax are welcome (I try to write correctly, but a 7-grade education in the Russian language leaves its mark.)