4.1. Requirements for the system as a whole.

4.1.1. Requirements for the structure and functioning of the system.
4.1.2. Requirements for the number and qualifications of system personnel and their mode of operation.
4.1.3. Reliability requirements.
4.1.4. Safety requirements.
4.1.5. Requirements for ergonomics and technical aesthetics.
4.1.6. Operation and maintenance requirements.
4.1.7. Requirements for protecting information from unauthorized access;
4.1.8. Requirements for the safety of information in case of accidents.
4.1.9. Requirements for protection from external influences.
4.1.10. Requirements for patent purity.
4.1.11. Any additional requirements.

4.2. Requirements for functions (tasks) performed by the system.

(list of functions (tasks) to be automated; time schedule for the implementation of each function (task); requirements for the quality of implementation of each function (task), for the form of presentation of output information, for the accuracy and time of execution, for the reliability of the output of results; list and criteria for failures for each function (task) for which reliability requirements are defined)

4.3. Requirements for types of collateral.

4.3.1. Requirements for the software of the system.

(requirements for the composition, scope and methods of using mathematical methods and models in the system, standard algorithms and algorithms to be developed)

4.3.2. System information support requirements.

(requirements for the composition, structure and methods of organizing data in the system; for information exchange between system components; for information compatibility with related systems; for the use of database management systems; for the structure of the process of collecting, processing, transmitting data in the system and presenting data; to protecting data from destruction during accidents and system power failures; monitoring, storing, updating and restoring data)

4.3.3. Requirements for linguistic support of the system.

(requirements for the use of high-level programming languages, user interaction languages ​​and technical means of the system in the system, as well as requirements for data encoding and decoding, data input-output languages, data manipulation languages, means of describing the subject area (information modeling), methods organizing dialogues with the user, etc.)

4.3.4. System software requirements.

(list of licensed software products, the presence of which is necessary for the system to function normally)

4.3.5. Requirements for technical support.

(requirements for the types of technical means, software and hardware systems and other components allowed for use in the system; for the functional, design and operational characteristics of the system’s technical support means)

4.3.6. Requirements for organizational support.

(requirements for the structure and functions of departments involved in the operation of the system or providing operation; for the organization of the functioning of the system and the procedure for interaction of personnel of the automation facility; for protection against erroneous actions of system personnel)

G O S U D A R S T V E N N Y S T A N D A R T S O Y W A S S R

Date of introduction 01.01.90

This standard applies to automated systems (AS) used in various fields of activity (management, research, design, etc.), including their combination, and establishes the types, name, completeness and designation of documents developed at the stages of creating an AS established GOST 24.601.

An explanation of the terms used in this standard is given in Appendix 1.

1. TYPES AND NAMES OF DOCUMENTS

1.1. The composition of the types of documents developed at the stage “Research and justification for the creation of AS” is determined in accordance with Section. 3 GOST 24.601, based on the required results of this stage.

1.2. At the “Terms of Reference” stage, a Technical Specification (TOR) is developed for the creation of an automated system in accordance with the requirements of GOST 34.602.

It is allowed to develop private technical specifications for individual systems (subsystems, sets of tasks, software and hardware systems, components of hardware and software, etc.)

1.3. The types of documents developed at the stages “Sketch Design”, “Technical Design”, “Working Documentation” are given in Table. 1.

Table 1

1.3.1. The names of specific documents developed when designing the system as a whole or part of it are given in Table. 2.

table 2

(Changed edition, Amendment No. 1)

Notes:

• 1. The following designations are used in the table:
  • EP - preliminary design;
  • TP - technical design;
  • RD - working documentation;
  • OR - system-wide solutions;
  • OO - decisions on organizational support;
  • TO - solutions for technical support;
  • IO - solutions for information support;
  • Software - software solutions;
  • MO - software solutions.
• 2. The X sign indicates that it belongs to the design estimates or operational documentation.
• 3. The nomenclature of documents of the same name is established depending on the design decisions made during the creation of the system

1.3.2. Types of documents for software used to create the AS (its parts) - according to GOST 19.101.77.

1.3.3. Types of documents for technical means used in the creation of the NPP (its parts) - according to GOST 2.102 and according to GOST 2.601 in terms of operational documents.

1.3.4. Depending on the design methods used and the specifics of the speakers being created, the following is allowed:

• 1) develop group and basic documents in accordance with section. 1, 3, 4, 6 GOST 2.113;
• 2) issue documents in separate independent parts corresponding to sections of the main document;
• 3) expand the range of documents established by this standard.

1.4. At the stages “Manufacture of non-serial components of the automated control system” and “Commissioning” the following organizational and administrative documents are developed:

• 1) act of completion of work;
• 2) certificate of acceptance for trial operation;
• 3) certificate of acceptance for industrial operation;
• 4) work schedule;
• 5) order on the composition of the acceptance committee;
• 6) order to carry out work;
• 7) work program;
• 8) test report;
• 9) approval protocol.

2. COMPLETENESS OF DOCUMENTATION

2.1. The list of names of documents being developed and their completeness for the system and its parts must be determined in the technical specifications for the creation of an automated system (subsystem).

Note. The completeness of design and estimate documents is determined in accordance with the rules established by the system of design documentation for construction (SPDS).

2.2. A list of documents must be compiled for each set.

2.3. The completeness of the documentation ensuring the development, production, acceptance and installation of technical equipment is in accordance with GOST 2.102. The completeness of operational documentation for these means is in accordance with GOST 2.601.

2.4. The completeness of documentation for computer software is in accordance with GOST 19.101.77.

2.5. When independently developing part of the system, documents for it are completed in accordance with the requirements of this standard.

3. DOCUMENT SYMBOLS

3.1. Each document developed must be assigned an independent designation. A document executed on different data carriers must have the same designation. The letter “M” is added to the designation of documents made on computer media.

Borrowed documents retain the previously assigned designations.

3.2. These rules do not apply to documents whose designation rules are regulated by state standards of other documentation systems.

3.3. The document notation has the following structure:

Pre>___________
|___________|. XX. XX. X- X. M
System designation | | | | | |
(parts of the system) | | | | | |
Document code | | | | |
Serial number of one document | | | |
names | | | |
Document Revision Number | | |
Document part number | |
Sign of a document made by machine |
media |

3.3.1. The rules for designating a system (part of a system) are given in Appendix 2.

3.3.2. The document code consists of two alphanumeric characters. The code for documents defined by this standard is entered in accordance with column 3 of table. 2. The code of additional documents is formed as follows: the first character is a letter indicating the type of document according to table. 1, the second character is a number or letter indicating the serial number of a document of this type.

The document code is separated from the previous designation by a dot.

3.3.3. Serial numbers of documents of one name (2 characters) are assigned starting from the second and separated from the previous designation by a dot.

3.3.4. The document revision number is assigned starting from the second in ascending order from 2 to 9, and is separated from the previous value by a dot. The next edition number is assigned in cases where the previous edition is retained (not cancelled).

3.3.5. The document part number is separated from the previous designation by a hyphen. If the document consists of one part, then the hyphen is not inserted and the document part number is not assigned.

3.3.6. The attribute of a document executed on computer media is entered if necessary. The letter “M” is separated from the previous designation by a dot.

ANNEX 1
Information

EXPLANATION OF TERMS USED IN THIS STANDARD

Documentation for the automated system- a set of interrelated documents that fully describe all decisions on the creation and operation of the system, as well as documents confirming the system’s compliance with the requirements of the technical specifications and its readiness for operation (functioning).

Design and estimate documentation for the NPP- part of the NPP documentation developed to carry out construction and installation work related to the creation of the NPP.

Working documentation for the speakers- part of the documentation for the NPP necessary for the manufacture, construction, installation and commissioning of the automated system as a whole, as well as the software and hardware, software and methodological complexes and components of technical, software and information support included in the system.

RULES FOR NAMING SYSTEMS AND THEIR PARTS

1. The structure of the designation of an automated system or its part has the form:

2. The developer organization code is assigned in accordance with the All-Union Classifier of Enterprises, Institutions and Organizations (OKPO) or according to the rules established by industry normative and technical documentation.

3. The code of the classification characteristic of the system or its part (subsystem, complex, component) is assigned in accordance with the rules established in the industry on the basis of subclass 425 of the All-Union classifier of products and / or the All-Union classifier of subsystems and complexes of tasks of automated control systems - 1 84 154.

4. The serial registration number of the system (part of the system) is assigned by the service of the developer's organization, which is responsible for maintaining a file cabinet and accounting for designations. Registration numbers are assigned from 001 to 999 for each registration characteristic code.

INFORMATION DATA

1. DEVELOPED AND INTRODUCED
USSR State Committee for Standards
USSR Ministry of Instrumentation, Automation and Control Systems

PERFORMERS
I.P. Vakhlakov; Ya.G. Vilenchik; N.M. Vitsyn, Ph.D. tech. sciences; F.R. Otter, Ph.D. tech. sciences; S.V. Garshina; B.A. Dyukov; L.M. Seidenberg, Ph.D. tech. sciences; A.P. Igoshin, Ph.D. tech. sciences; Yu.B. Irz, Ph.D. tech. Sciences (topic leader); V.Yu. Korolev; I.A. Koroteeva; E.S. Krankov, Ph.D. tech. sciences; IN AND. Makhnach, Doctor of Engineering. sciences; I.S. Mityaev; A.M. Mustafina; E.I. Nekrylov, Ph.D. tech. sciences; V.F. Popov; E.G. Savina; N.V. Stepanchikova; VC. Chistov, Ph.D. tech. sciences; P.A. Shalaev, Ph.D. tech. Sciences

2. APPROVED AND INTRODUCED BY Decree of the USSR State Committee for Standards dated March 24, 1989 No. 664

3. Inspection period - 1999; inspection frequency - 10 years

4. INSTEAD OF GOST 24.101-80, GOST 24.102-80, RD 50-617-86

5. REFERENCE REGULATIVE AND TECHNICAL DOCUMENTS

Amendments No. 1, (Approved and put into effect by the Decree of the USSR State Committee for Product Quality Management and Standards dated December 29, 1990 No. 3468, date of introduction July 1, 91) were introduced.

GOST 19.101-77

Group T55

INTERSTATE STANDARD

Unified system of program documentation

TYPES OF PROGRAMS AND PROGRAM DOCUMENTS

Unified system for program documentation. Types of programs and program documents

MKS 35.080

Date of introduction 1980-01-01

By the Decree of the State Committee of Standards of the Council of Ministers of the USSR dated May 20, 1977 N 1268, the introduction date was set to 01.01.80

EDITION (January 2010) with Amendment No. 1 approved in June 1981 (IUS 9-81).


This standard establishes the types of programs and software documents for computers, complexes and systems, regardless of their purpose and scope.

The standard fully complies with ST SEV 1626-79.

(Changed edition, Amendment No. 1).

1. TYPES OF PROGRAMS

1. TYPES OF PROGRAMS

1.1. The program (according to GOST 19781-90) can be identified and used independently and (or) as part of other programs.

1.2. Programs are divided into types shown in Table 1.

Table 1

1.3. The documentation developed for the program can be used for the implementation and transfer of the program on storage media, as well as for the manufacture of a software product.

1.2, 1.3. (Changed edition, Amendment No. 1).

2. TYPES OF PROGRAM DOCUMENTS

2.1. Software documents include documents containing information necessary for the development, production, maintenance and operation of programs.

2.2. Types of program documents and their content are given in Table 2.

table 2

2.3. Types of operational documents and their content are given in Table 3.

Table 3

2.4. Depending on the method of implementation and the nature of application, program documents are divided into original, duplicate and copy (GOST 2.102-68), intended for the development, maintenance and operation of the program.

2.5. The types of program documents developed at different stages and their codes are given in Table 4.

Table 4

Legend:

- the document is mandatory;

- the document is mandatory for components that have independent use;

- the need to draw up a document is determined at the stage of development and approval of the technical specifications;

- - the document is not drawn up.

2.2-2.5. (Changed edition, Amendment No. 1).

2.6. It is allowed to combine certain types of operational documents (with the exception of the list of operational documents and the form). The need to combine these documents is indicated in the technical specifications. The merged document is assigned the name and designation of one of the merged documents.

Merged documents must specify the information that must be included in each document being merged.

2.7. At the stage of development and approval of the technical specifications, the need to draw up technical specifications containing requirements for the production, control and acceptance of the program is determined.

Technical specifications are developed at the “Detailed Design” stage.

2.8. The need to draw up technical specifications for components not intended for independent use, and complexes included in other complexes, is determined by agreement with the customer.

(Introduced additionally, Amendment No. 1).



Electronic document text
prepared by Kodeks JSC and verified against:
official publication
Unified software system
documentation: Sat. GOST. -
M.: Standartinform, 2010

USE OF GOST 19 AND 34 SERIES REQUIREMENTS WHEN PREPARING DOCUMENTATION IN IT PROJECTS FOR GOVERNMENT STRUCTURES

Introduction

It is impossible to imagine the modern world without automation tools, which are being implemented everywhere at a rapid pace in commercial and government structures, which ensures more efficient operation of business and the public sector. The implementation of certain automation tools, as a rule, involves the development of documentation at various stages, such as: developing requirements for the information system; at the technical design stage; stage of development of working documentation.

At the same time, there are situations when documentation developers and the customer do not always have the same idea about the number, structure and content of the documents being developed. This leads to the fact that the results of the work do not satisfy the customer, and additional resources have to be spent on finalizing the documents. Using GOST requirements when developing documentation allows you to avoid such situations, because Despite the prevailing opinion that standards lag behind modern technologies, GOST provides a clear structure for the documentation being developed, has the properties of completeness and consistency, and also removes controversial issues between the contractor and the customer regarding the results of the work. Moreover, in most government organizations, the development of documentation in accordance with GOST is a prerequisite. Next, we will try to understand the intricacies of developing documentation according to GOST requirements.

When developing automated systems (AS) in accordance with GOST 34 in IT projects for government agencies, the question often arises: what GOST standards should we use to draw up documentation? GOST 34 does not contain explicit instructions on what standards to draw up specific documents developed as part of the creation of an AS, except for the requirements for the preparation of technical specifications. Let's try to find out which GOSTs are used when preparing documents in the absence of precise instructions in a government contract or competitive technical specification (TOR). This material is primarily intended for IT specialists who want to understand how documents are drawn up in IT projects in accordance with GOST requirements.

Defining documentation standards

The preparation of documents in GOST 34 depends on the type of document (design or software) and the stage of creation of the AS at which the document is prepared.

The list of documents developed at various stages of the creation of automated systems is given in GOST 34.201-89 “Types, completeness and designation of documents when creating automated systems.” It contains the following requirements:

• At the “Technical specifications” stage, technical specifications for the creation of an automated system are developed in accordance with GOST 34.602-89 “Technical specifications for the creation of an automated system”;
• Kinds program documents GOST 19.101-77“Unified system of program documentation. Types of programs and program documents.” These include various manuals, such as the user manual.
• Kinds design documents, developed at various stages of the creation of AS are determined by GOST 2.102-2013“Unified system of design documentation. Types and completeness of design documents." For example, these include statements of preliminary and technical designs, statements of purchased products, explanatory notes to preliminary and technical designs.

Now let's take a closer look at how to determine design standards in various projects.

Registration of technical specifications

Everything is quite clear with the technical specifications: GOST 34.602-89 provides the standard for its design: clause 3.2. states that “The technical specifications for the speakers are drawn up in accordance with the requirements of GOST 2.105 on A4 sheets in accordance with GOST 2.301 without a frame, main inscription and additional columns to it.”

Preparation of program documentation

With program documents developed as part of an IT project, there is also a clear indication to use GOST 19 series in terms of design: the above GOST 19.101-77 is part of the GOST 19 series “Unified System of Program Documentation” (USPD). ESPD is a set of state standards of the Russian Federation that establish interrelated rules for the development, execution and circulation of programs and program documentation.

Documentation in the ESPD is drawn up in accordance with GOST 19.104-78 “Unified system of program documentation. Basic inscriptions", GOST 19.105-78 "Unified system of program documentation. General requirements for program documents”, GOST 19.106-78 “Unified system of program documentation. Requirements for printed program documents."

Preparation of design documentation

Now let's look at GOST 2.102-2013. This standard is part of the GOST series 2 “Unified System of Design Documentation” (ESKD). ESKD is an interstate set of standards that establish interrelated norms and rules for the development, execution and circulation of design documentation developed and applied at all stages of the product life cycle (during design, manufacturing, operation, repair, etc.)

Documentation in ESKD is drawn up according to several standards. The most frequently used of them (in relation to the IT sector) are GOST 2.105-95 “Unified system of design documentation. General requirements for text documents" and GOST 2.106-96 "Unified system of design documentation. Text documents."

At first glance, it is not clear from the GOST 34 series how to draw up documentation for the AU. Often, within the framework of an IT project, especially for government customers, the technical specifications contain requirements for the preparation of documentation in accordance with GOST 2.105-95 and GOST 2.106-96. But should documents be drawn up in accordance with these GOSTs if there are no explicit requirements for registration?

How to apply correctly?

GOST 2nd series contains requirements for the purpose of each standard and indicates the industry of its application: GOST 2.102-2013 - the standard establishes the types and completeness of design documents for products of all industries.

If GOST 2.102-2013 applies to products of all industries, including the IT sector, let's see, what is a design document?

According to GOST 2.001-2013 “Unified system for design documentation (ESKD). General provisions":

A) "3.1.2 design document: A document that, individually or in combination with other documents, determines the design of the product and has a substantive and requisite part, including established signatures.

B) "3.1.5 design documentation: A set of design documents containing data necessary for the design (development), manufacture, control, acceptance, delivery, operation, repair, modernization, disposal of the product"

This could have been stopped by logically comparing the requirements for the composition of the documents of our IT project with the provisions given above, and determining whether each of the documents refers to design or not and completing the design according to GOST 2 series standards.

Main GOSTs of the 2nd series for an IT project in terms of design

Now let's look at the main GOSTs of the 2nd series, which are most often used for paperwork in an IT project. As a rule, in terms of design they use:

GOST 2.105-95 - the standard establishes general requirements for the execution of text documents for engineering products, instrumentation and construction;

GOST 2.106-96 - the standard establishes the forms and rules for the implementation of design documents for engineering and instrumentation products.

The reader may have a question: can we use these GOSTs for speakers if they are intended for mechanical engineering and instrument making products?

According to the definition of the Great Soviet Encyclopedia, “Instrument making is a branch of mechanical engineering that produces means for measuring, analyzing, processing and presenting information, control devices, automatic and automated control systems; the field of science and technology that develops automation and control systems, that is, everything that is needed on our topic of modern information technology.

In addition, if you look at GOST 34.003-90 “Automated systems. Terms and definitions", this standard defines the AU as "a system consisting of personnel and a set of means for automating its activities, implementing information technology for performing established functions."

Thus, the AU belongs to the instrument-making industry and, therefore, the design documents of the AU are drawn up in accordance with GOST 2.105-95 and GOST 2.106-96.

Now let's look at the main points of designing project documentation in accordance with GOST 2.105-95 and GOST 2.106-96.

Highlights in the design in accordance with GOST 2. 105

Consider the main design parameters according to GOST 2nd series.

According to GOST 2.105-95, the distance from the form frame to the text boundaries at the beginning and at the end of lines must be at least 3 mm. The distance from the top or bottom line of text to the top or bottom frame must be at least 10 mm. Paragraphs in the text begin with an indent equal to five strokes of a typewriter (15 - 17 mm).

GOST 2.105-95 does not define parameters for formatting text in electronic form: font name, font height, line spacing. Therefore, the parameters for processing documents in electronic form are, as a rule, the subject of an agreement with the customer.

At the beginning of the electronic formatting work, formatting parameters are determined:

• Text paragraph format – font used, font height, line spacing;
• Format for each heading by levels (1, 2, 3) – font used, font height, indentation in cm, line spacing size;

Table - text font used, line spacing, table border thickness, table width, cell indent, title placed above the table. The Table title is formatted in the same way as the main text of the document. According to GOST 2.105-95, the height of the table rows must be at least 8 mm. The font height of the table rows can also be agreed with the customer.

Illustrations in the document should be centered. The title is placed directly below the illustration. Title formatting is the same as the text of the document.

Table design rules

The table, depending on its size, is placed under the text in which a link to it is first given, or on the next page, and, if necessary, in an appendix to the document.

Tables, with the exception of appendix tables, are numbered with Arabic numerals and continuous numbering. For example: "Table 1".

The tables of each application are designated by separate numbering in Arabic numerals with the addition of the application designation before the number. For example: “Table B.1”.

It is allowed to number tables within a section. In this case, the table number consists of the section number and the table sequence number, separated by a dot. For example, in section 4 the number would be “Table 4.3”.

The title of the table should reflect its content, be accurate, and concise. The name consists of the word “Table”, table number and text. GOST 2.105-95 does not define the use of a hyphen or dash in the table name. In practice, a dash can be used, similar to the use of a dash in the title of a picture. For example, “Table 5 – Work performed, content and deadlines.” There is no period at the end of the title. The title is placed above the table on the left.

GOST 2.105-95 in clause 4.4.3 contains the following requirement: “All tables of the document must be referenced in the text of the document; when referring, the word “table” should be written indicating its number.” In practice, the word “table” is declined in the text according to the rules of the Russian language. For example: “A brief description of the purpose and main characteristics of the second-stage IP IC subsystems is presented in Table 1.”

If your table spans multiple pages, you should display its title at the beginning of each page.

GOST 2.105-95 has an optional requirement in clause 4.4.7: “if the table is interrupted at the end of the page and its continuation will be on the next page, in the first part of the table the lower horizontal line limiting the table may not be drawn.” In practice, the lower horizontal line is drawn, since its absence impairs the user’s perception of the table.

Rules for the design of illustrations

Illustrations include graphic images (diagrams, graphs, photographs, drawings).

Illustrations, with the exception of illustrations of applications, are numbered in Arabic numerals, and the numbering is continuous. For example: "Figure 3".

The illustrations of each application are designated by a separate numbering in Arabic numerals with the addition of the application designation before the number. For example: “Figure B.6.”

It is allowed to number illustrations within the section. In this case, the illustration number consists of the section number and the number of the illustration, separated by a dot. For example, in section 5 the number would be "Figure 5.2".

It is allowed not to number small illustrations (small drawings) placed directly in the text and to which there are no further references in the text.

GOST 2.105-95 requirements for location: "illustrations can be located both in the text of the document (possibly closer to the corresponding parts of the text), and at the end of it."

GOST 2.105-95 in clause 4.3.1 states the following: “when referring to illustrations, one should write "... in accordance with Figure 2" for continuous numbering and "... in accordance with Figure 1.2" for numbering within the section ".

The name is written under the illustration in the format "Figure 1 - Instrument details".

An interesting fact: if you cover up an error in a paper document and write a correction in black ink on top, it will be in accordance with GOST. GOST 2.105-95 allows corrections of documents in paper form. This is stated in clause 3.7: “Misprints, typos and graphic inaccuracies discovered during the execution of the document can be corrected by erasing or painting over with white paint and applying the corrected text (graphic) in the same place in typewritten way or in black ink, paste or ink in handwritten way . Damage to sheets of text documents, blots and traces of incompletely removed previous text (graphics) are not allowed.”

That is, if you printed something and found an error, you can correct it manually using the above method.

Registration according to GOST 2. 106-96

GOST 2.106-96 establishes the forms and rules for the execution of design documents. For each type of document, GOST 2.106-96 provides a template for designing the document framework.

GOST 2.106-96 defines not only the shape of the frames, but also the main inscription in the frame. Example from GOST 2.106-96: “PZs are drawn up on forms 9 and 9a of Appendix A, and the necessary diagrams, tables and drawings in paper form can be made on sheets of any format established by GOST 2.301, while the main inscription and additional columns to it are made in in accordance with the requirements of GOST 2.104 (form 2a)”.

Summary

In addition to the above, we can say that when developing AS in accordance with GOST 34 in IT projects for government agencies, in the absence of precise instructions in the government contract or competitive technical specifications, software and design documentation must be drawn up in accordance with the following GOSTs:

• Program documents developed at various stages of AS creation are drawn up in accordance with GOST 19.104-78, GOST 19.105-78, GOST 19.106-78;
• Design documents developed at various stages of NPP creation are drawn up in accordance with GOST 2.105-95 and GOST 2.106-96. In this case, the content requirements are regulated by RD 50.34-698-90.

It is necessary to check GOSTs for relevance and use the latest edition of the standards, since they, although rarely, are still updated. I hope the article will help you better navigate the GOST requirements, and if necessary, you can always