Geekly Articles each Day
📜 ⬆️ ⬇️

Standards and templates for software development specifications

Introduction


Recently I was approached to advise standards for writing technical specifications (TK) for the development of automated systems (AS) and software (SW). Here I think, now I’ll go to Yandex , find a suitable article and send it. But it was not there! I did not find one article listing the standards for TK, including templates and examples of finished documents. You'll have to make such an article yourself ...

And so, the basic standards, methodologies and knowledge sets where TK or SRS (Software (or System) Requirements Specification) is mentioned:

• GOST 34
• GOST 19
• IEEE STD 830-1998
• ISO / IEC / IEEE 29148-2011
• RUP
• SWEBOK, BABOK, etc.

GOST 34


GOST 34.602-89 Terms of Reference for the creation of an automated system regulates the structure of the TOR for the creation of the SYSTEM, which includes software, hardware, people who work with software, and automated processes.
')
According to GOST 34, the terms of reference should include the following sections:

1. General information
2. Purpose and objectives of the creation (development) of the system
3. Characteristics of automation objects
4. System requirements
5. The composition and content of work on the creation of the system
6. The order of control and acceptance of the system
7. Requirements for the composition and content of work on the preparation of the automation object for the commissioning of the system
8. Documentation Requirements
9. Sources of development

When developing TK for state projects, Customers, as a rule, require compliance with this particular standard.

GOST 19


“GOST 19.xxx Unified Program Documentation System (ESPD)” is a set of state standards that establish interrelated rules for the development, design and circulation of programs (or software) and program documentation. Those. This standard refers to the development of software.
According to GOST 19.201-78 Terms of Reference, the requirements for the content and design of the terms of reference should include the following sections:

1. Introduction;
2. Reasons for the development;
3. The purpose of the development;
4. Requirements for the program or software product;
5. Requirements for software documentation;
6. Technical and economic indicators;
7. Stages and stages of development;
8. The order of control and acceptance;
9. Applications.

Naturally GOST 34 (and 19) are already outdated, and I do not like to use them, but with the correct interpretation of the standards, you can get a good TK, see Conclusion.

IEEE STD 830-1998


A fairly good definition of the standard 830-1998 - IEEE Recommended Practice for Software Requirements Specifications is given in its description itself:

It describes the content and quality characteristics of a well-designed software requirement specification (SRS) and provides several SRS templates. This recommended technique is intended to establish requirements for the software being developed, but it can also be used to assist in the selection of own and commercial software products.

According to the standard, the terms of reference should include the following sections:

1. Introduction

2. General description

3. Detailed requirements (can be arranged in different ways, for example, so)

4. Applications
5. Alphabetical Index

In fact, it is quite difficult for a beginner to understand what should be contained in these sections according to the above structure (as is the case with GOST), so you need to read the standard itself, which is easy to find on the Internet . As examples , however, in English. language.

I also prefer the adapted Karl Wigs template that I use when developing TK for commercial companies. In general, grandfather Vigers provides many useful recommendations on how to work with requirements (where money goes when you buy these recommendations, read in the beginning in red). Well, and you have already read his book several times, I hope.

ISO / IEC / IEEE 29148-2011


The IEEE Standard 29148-2011 provides a single interpretation of the processes and products used in the development of requirements throughout the life cycle of systems and software. It replaces the IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998 standards.

This standard contains two requirements specification templates:

• System requirements specification (SyRS)
• Software requirements specification (SRS)

The System Requirements Specification (SyRS) defines the technical requirements for the selected system and the convenience of interaction between the intended system and the person. It defines the high-level system requirements from the point of view of the subject area, as well as information on the overall goal of the system, its target environment and constraints, assumptions and non-functional requirements. It may include conceptual models designed to illustrate the content of the system, usage scenarios, basic domain entities, data, information and workflows. From the definition it follows that this is an analogue of the TZ described in GOST 34.

SyRS may contain the following sections:

1. Introduction


2. References

3. System requirements


4. Testing and verification (list of required acceptance tests, which mirror section 3)

5. Applications


SRS is a specification of requirements for a specific software product, program, or set of programs (product) that perform specific functions in a particular environment. From the definition it follows that this is an analogue of the TZ described in GOST 19, and in its structure it is very similar to SRS from the IEEE 830 standard.

SRS may contain the following sections:

1. Introduction


2. References

3. Detailed requirements


4. Testing and verification (list of required acceptance tests, which mirror section 3)

5. Applications


This standard is quite difficult to find in clear form on the Internet, but you can try, and again only in English.

RUP


The SRS structure in RUP (Rational Unified Process) is a document in which it is necessary to describe the artifacts obtained in the process of specifying requirements.

The SRS template in RUP is adapted from the IEEE STD 830 standard and contains two options:

• The traditional SRS pattern with structured functional requirements for the System functions, is as close as possible to the 830 standard.
• Simplified SRS template with structured functional requirements in the form of use cases (use cases):

1. Introduction.


2. System Overview


3. Detailed requirements


4. Auxiliary information.

Naturally, on the Internet you can find a template and examples of SRS from RUP .

SWEBOK, BABOK, etc.


SWEBOK , BABOK , as well as many other software development methodologies and knowledge sets when referring to SRS refer to the above-mentioned foreign standards.

It is also worth mentioning that other types of documents are used to describe the requirements for the AU and software, each cat calls differently: FRD (Functional Requirements Document), RD (Requirements Document), PZ (Task Statement or Explanatory Note), etc. But this all derivative documents from the aforementioned standards that do not have industry standardization, although, in some cases, already with established terminology.

What about Agile?


I will say one phrase from the Agile Manifesto : “Working software over comprehensive documentation”. Therefore, very little space is allocated in the Agile documentation.

My belief is that it is possible to develop NPPs without TK (using Agile techniques / recommendations), but it is impossible to accompany them in the future. So immediately think about how you will write TK and other documentation when developing software for Agile.

Conclusion


As they say, each project has its own technical task. With proper use of any of the above standards, you can take these templates for writing TK, naturally adapting them for themselves.

But the main thing is that TK does not turn into HZ, and, namely, the content (content) in TK is the most important thing! But that's another story ... If you are interested, you can take an online course Developing and Managing Software Requirements .

Well, who read to the end is a bonus: an example of TZ, which I wrote many years ago (now I’m just not working as an analyst for a long time, and other more successful examples prohibits opening it for public viewing NDA).

Also I recommend to get acquainted with the following materials:

Source: https://habr.com/ru/post/328822/

More articles:


All Articles