Compilation rules Software requirements specification
We all know how software is developed. We thought for 10 minutes and immediately went to code . The software creation cycle consists of many key points. These are such moments as planning, creating architecture, creating an SRS, creating a design, etc., etc.
SRS - Software Requirement Specification - special documentation for software which contains information about how the system should behave, what functions should be performed, what load should withstand and so on.
')
Everything is very simple. You use TK (bicycle), I use the SRS (machine). I hope the analogy was clear? :)
Below is the structure in English language in raw form. Below in the article we will look at each item in more detail.
And so we figured out the structure, now let's move on to the sections and what should be written in them.
Introduction \ Purpose
In this section, we describe the application or product, the functionality of which will be described in the SRS.
Introduction \ Document conventions
Here we describe all the obscure technical words or terms that are found in the SRS. Notice that the description of an incomprehensible word cannot contain another incomprehensible word. Try to paint as much as possible the term that you use is simple and clear in all languages. Do not save on this section because the more you sign out incomprehensible things, the easier it will be to design later.
Introduction \ References
In this section we write references to the literature in which you can find the basis of the technologies and facts used. Suppose you can insert RFC if you are writing an application that works with TCP / IP, insert references to documents to which you refer, and so on. Links and their description should be as complete as possible, in which case (the link simply died) it was possible to google this material.
Overall Description \ Product features
In this section, we describe 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 desirable to place a DFD-diagram which will show the general interaction of the system.
Overall Description \ Operating environment
As is clear from the title of the section here, we describe the environment in which the product will work. OS, compiler versions, databases, servers, software, hardware and other things that are necessary for the operation of your product.
Overall Description \ Design and implementation constraints
This section is vile :). It restricts the flight of a developer’s thought by imposing design 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 call the feature project and give it a unique identifier. For example, server.html.editor. A unique identifier is given so that later somewhere in your tickets you don’t write - “but this is the damn thing that allows you to edit html”
System features \ System feature X \ Description and priority
We describe in detail the feature of the product. What is she for? What should do? What is the priority of its implementation? .. From this section, a person who reads cpc should immediately understand 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, the HTML editor is displayed when the user clicks the menu link Open HTML editor
System features \ System feature X \ Functional requirements
Detailed and detailed description of the features. We describe everything: how it works, how it reacts to errors, what should check, how to display data, how and where it saves, and so on.
External interface requirements
A description of how the system will interact with the outer worlds. If it is of course. What API, how to get this or that data, and so on. Subsections are used to detail the requirements. What software interfaces, hardware interfaces, communication interfaces and so on.
Non functional requirements
Not functional requirements. There are requirements that can not 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 requests per second and so on. These requirements lead to a tremendous job of project optimization.
Non functional requirements \ Software quality attributes
Here we describe the requirements for the quality of the code. 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
Security Requirements If this is an HTML editor through which you can change something on the site, then it could be something like: you should not be able to put the shell on the server and etc. through the HTML editor
Appendix A: Glossary
Application. Sometimes in the 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. For this there is this section. Insert references for such explanations. Such a dictionary.
Appendix B: Analysis Models
The section defines which diagrams to use when writing an SRS. For example, DFD, some common diagrams of interaction and work
Appendix C: Issues list
This section is used for very formal SRS. Describes the items TBD (To Be Done) - what should be done in the future, but is not described here.
SRS is not mandatory, but can help in medium and large projects. Using SRS shows your professional level as a developer.
PS I beg you not to blame much - the first article of a more or less medium scale on the habr. Corrections in the syntax are welcome (I try to write correctly, but the 7th grade Russian language education leaves its mark.)
What is SRS?
SRS - Software Requirement Specification - special documentation for software which contains information about how the system should behave, what functions should be performed, what load should withstand and so on.
')
Why is it necessary?
Everything is very simple. You use TK (bicycle), I use the SRS (machine). I hope the analogy was clear? :)
SRS structure
Below is the structure in English language in raw form. Below in the article we will look at 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 units )
- Description and priority
- Stimulus / Response sequences
- Functional requirements
- System feature X ( there may be several such units )
- 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 figured out the structure, now let's move on to the sections and what should be written in them.
Basic requirements for all sections of the SRS
- Briefly, clearly. Describes everything extremely briefly and clearly. As much as possible.
- Without ambiguous descriptions. A person reading the SRS must understand exactly what is written, and not something else. Murphy's Law: If you can be misunderstood, you will be misunderstood. Avoid it
- Simplicity and readability. Do not use any too abstruse turns. Beauty in simplicity :)
- DFD diagrams . The specification can not be complete if we do not know what is at the entrance to the described software, and what is at the output. 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 information about the functional and what I have written does not cause me embarrassment, if the requirements are unambiguous and are not subject to any two-sided understanding, if the requirements describe the behavior of the functional sufficiently for me, then the SRS study can be considered complete
Explanation of each item of the SRS structure
Introduction \ Purpose
In this section, we describe the application or product, the functionality of which will be described in the SRS.
Introduction \ Document conventions
Here we describe all the obscure technical words or terms that are found in the SRS. Notice that the description of an incomprehensible word cannot contain another incomprehensible word. Try to paint as much as possible the term that you use is simple and clear in all languages. Do not save on this section because the more you sign out incomprehensible things, the easier it will be to design later.
Introduction \ References
In this section we write references to the literature in which you can find the basis of the technologies and facts used. Suppose you can insert RFC if you are writing an application that works with TCP / IP, insert references to documents to which you refer, and so on. Links and their description should be as complete as possible, in which case (the link simply died) it was possible to google this material.
Overall Description \ Product features
In this section, we describe 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 desirable to place a DFD-diagram which will show the general interaction of the system.
Overall Description \ Operating environment
As is clear from the title of the section here, we describe the environment in which the product will work. OS, compiler versions, databases, servers, software, hardware and other things that are necessary for the operation of your product.
Overall Description \ Design and implementation constraints
This section is vile :). It restricts the flight of a developer’s thought by imposing design 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 compatibility only with FF
- Restrictions 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 call the feature project and give it a unique identifier. For example, server.html.editor. A unique identifier is given so that later somewhere in your tickets you don’t write - “but this is the damn thing that allows you to edit html”
System features \ System feature X \ Description and priority
We describe in detail the feature of the product. What is she for? What should do? What is the priority of its implementation? .. From this section, a person who reads cpc should immediately understand 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, the HTML editor is displayed when the user clicks the menu link Open HTML editor
System features \ System feature X \ Functional requirements
Detailed and detailed description of the features. We describe everything: how it works, how it reacts to errors, what should check, how to display data, how and where it saves, and so on.
External interface requirements
A description of how the system will interact with the outer worlds. If it is of course. What API, how to get this or that data, and so on. Subsections are used to detail the requirements. What software interfaces, hardware interfaces, communication interfaces and so on.
Non functional requirements
Not functional requirements. There are requirements that can not 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 requests per second and so on. These requirements lead to a tremendous job of project optimization.
Non functional requirements \ Software quality attributes
Here we describe the requirements for the quality of the code. 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
Security Requirements If this is an HTML editor through which you can change something on the site, then it could be something like: you should not be able to put the shell on the server and etc. through the HTML editor
Appendix A: Glossary
Application. Sometimes in the 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. For this there is this section. Insert references for such explanations. Such a dictionary.
Appendix B: Analysis Models
The section defines which diagrams to use when writing an SRS. For example, DFD, some common diagrams of interaction and work
Appendix C: Issues list
This section is used for very formal SRS. Describes the items TBD (To Be Done) - what should be done in the future, but is not described here.
Conclusion
SRS is not mandatory, but can help in medium and large projects. Using SRS shows your professional level as a developer.
PS I beg you not to blame much - the first article of a more or less medium scale on the habr. Corrections in the syntax are welcome (I try to write correctly, but the 7th grade Russian language education leaves its mark.)
Source: https://habr.com/ru/post/52681/
All Articles