Development of technical specifications according to GOST 34 is easy and simple

Often you hear the opinion that the preparation of a Technical Specification in accordance with GOST 34 (TZ) is not only laborious, but also extremely annoying, because you have to write a lot of nonsense and water. But think about it: the whole scientific research institutes were engaged in the development of this GOST, it was a project at the state level, the experience of hundreds of automation projects, complex projects was summarized. Could they write nonsense?

In fact, with the right approach, GOST is very helpful not only in the development of the TZ, but during the implementation of the automation project as a whole (and not only in government contracts, but also for commercial development). Literate people wrote it. But in order to take advantage of the fruits of their labors, it is necessary to understand a little the idea of ​​not only TK, but also GOST 34 as a whole.

In this article, we will analyze all the requirements of GOST, point by point, and try to make the development of TZ in accordance with GOST 34 not a burden, but a great help in the project.

1. What is the article about?

Often you hear the opinion that the preparation of a Technical Specification in accordance with GOST 34 (TZ) is not only laborious, but also extremely annoying, because you have to write a lot of nonsense and water. But think about it: the whole scientific research institutes were engaged in the development of this GOST, it was a project at the state level, the experience of hundreds of automation projects and complex projects was generalized. Could they write nonsense?

In fact, with the right approach, GOST is very helpful not only in the development of the TZ, but during the implementation of the automation project as a whole (and not only in government contracts, but also for commercial development). Literate people wrote it. But in order to take advantage of the fruits of their labors, it is necessary to understand a little the idea of ​​not only TK, but also GOST 34 as a whole.

By the way, TK is not the first document that is being developed during the automation project. This is explicitly stated in clause 1.5. GOST 34.602-89: “TK at the NPP is developed on the basis of the initial data, including the stage“ Research and justification of the NP creation ”contained in the final documentation”. For details, see. In my article Pre-survey the development of the information system .

ATTENTION: THE PURPOSE OF THIS ARTICLE IS NOT TO REPLACE GOST, AND TO EXPLAIN SOME OF ITS PROVISIONS.

2. Characteristics of the Terms of Reference according to GOST 34

2.1. What is the standard for TK?

The full name of the standard for TZ in accordance with GOST 34 is as follows: GOST 34.602-89 “Information Technology (IT). Set of standards for automated systems. Terms of Reference for the creation of an automated system.

The standard itself is printed on only 15 pages (yes, quite a bit). The language is Russian, really Russian, and not an alien planted in Cyrillic. That is, if you don’t drive into your head in advance that neither the GOST texts, nor federal laws, or dissertations are easy to understand for a mere mortal, then it is quite possible to read and understand, although often not the first time.

Indeed, the standard uses many obscure terms. What, for example, is meant by linguistic software? For clarification of the concepts used, refer to GOST 34.003-90 “Information Technology (IT). Set of standards for automated systems. Automated systems. Terms and Definitions".

2.2. Why do we need GOST for the technical task?

Probably, when you need to create a new document for you, you are looking for a template for such a document on the Internet or ask your colleagues. So, ANY standard for documents or processes is a template. Moreover, the template greatly simplifies the development of a document: the structure and content have already been thought out for you, moreover, such a template takes into account such moments that you would not have remembered.

2.3. What is the role of the technical task in the project?

According to clause 1.7 of the standard RD 50-682-89, "the technical task is the main document, in accordance with which the creation of the AU is carried out and accepted by the customer." And this is really the main document. It should describe everything that is necessary for the development and implementation of the system.

The TOR establishes the overall appearance of the system, the scope of work (development framework), as well as the order of development and acceptance. Everything starts with TK and everything ends with it. This document is ideal for your customer to understand the importance and complexity of the task and for what he pays the money.

Moreover, TK is drawn up for both the contractor and the customer, since the automation project is carried out by teams from both sides. In any IT project there is a huge number of organizational measures, the implementation of which without the active participation of the customer is impossible. Explain it to customers at every opportunity, otherwise they get the impression that they only have to pay the money and sit straight: the hired guys will do everything. And then the project fails and disassembly begins. In general, without a real team from that side, it is not worth starting a project.

Do not make TK formally. If you don’t know what to write, then it’s too early to develop TZ, you don’t have an understanding of the system, the automation process itself, the automation object, is not yet clear. You should create a System Concept., we talked about this at the very beginning of the article.

2.4. How old is GOST 34.602-89 and are there newer standards?

Neither how old is it. I almost could not find any irrelevant things. And no one who declares the obsolescence of GOST 34 can cite a single example (probably, just did not have enough qualifications to read it?) The fact is that GOST describes a general approach to the automation project, there is no talk of programming, GOST 34 is not about that.

Well, if we talk about comparison with other standards, then there’s really nothing to compare with. GOST 34 represents such a broad view of the automation project that the rest of the standards cannot hold a candle (in my opinion). Yes, they are simpler (and therefore more popular), but the depth is not the same. Here is a list of standards that would be worthwhile when developing your own standards for an automation project:

• IEEE 830-1998. The methodology for the preparation of specifications of software requirements.
• GOST R ISO / IEC 12207-2010. Information technology. System and software engineering. Software life cycle processes.
• ISO / IEC / IEEE 29148-2011. Systems and software engineering - Life cycle processes - Requirements engineering.
• GOST R 54869-2011. Project Management. Project management requirements.
• Well and GOSTs of a series 34.

3. General principles for the preparation of TZ according to GOST 34

3.1. Which specialist should make a technical task according to GOST 34?

Often, developers strongly swear in the preparation of TZ according to GOST 34. Why? Yes, because it is not a matter of programmers. The technical task in accordance with GOST 34 is generally possible for programmers not to show. For this there are technical project documents. The technical task is a document that is agreed with the customer, who is constantly on the table with the project manager. TK answers two questions: WHAT the system should do, and HOW it should be created. The technical project answers the question: HOW the requirements of the TOR should be met. For example, in TK you prescribe that there should be authorization by login and password, and in TP, you bring interface layouts, scripts, database structure. Why there is a division into different stages and why you should not immediately do the task for programmers, see my articlesSecrets of successful design of IP (information system) on the example of the construction of the hospital and pre-project examination in the development of information systems .

The terms of reference must be compiled by the business analyst because he is the “translator” between the customer and the development team. The task of the business analyst is to figure out what the customer needs and express it in such a way that the team understands. And express it in the form of technical specifications. Moreover, the business analyst is required not only to listen to the customer and his staff, but to find out what they did not say (and this is usually more than 50%). Therefore, the analyst should be well aware of the processes being automated and, at the expense of his knowledge, fill in the gaps that remained from the survey results.

3.2. Which side should make the technical task?

Basically the technical task is made by the performer? Why?

Not only because it is recommended in Annex 1 to GOST 34-602-89. In fact, the customer, as a rule, lacks the relevant specialists. But the TZ is necessarily worked out and agreed by the customer. And here it is necessary to ensure that the agreement is not formal. I always try to insist that we together with the customer disassemble each item in detail. Your goal is to involve the customer in the project. Otherwise, he will not form his expectations of the system, which means, firstly, he will be dissatisfied with any result, and, secondly, he will not be able to carry out the necessary organizational measures.

3.3. How far can you go from GOST 34?

Any template also has a significant drawback - this is a template. That is, a step to the right and to the left is the highest measure of social protection (this is how the death penalty was used to be called).

In fact, everything is not so. Any process standard (that is, a standard not for sausage, but for any activity) gives only general instructions, an outline. It was created to help not to forget something important, to pass on to you the experience of generations, and not to drive past the flags.

Do not believe? Then read clause 2.2 of GOST 34.602-89 (by the way, the digits after the hyphen - the year of publication of the standard or its edition): “Depending on the type, purpose, specific features of the automation object and the conditions of the system’s operation, it is allowed to issue TOR sections in the form of applications, introduce additional exclude or merge subdivisions of TZ ". Also in paragraph 1.2. RD 34.698-90 states: “The content of the documents is common to all types of speakers and, if necessary, may be supplemented by the developer of the documents, depending on the characteristics of the created speakers. It is allowed to include additional sections and information in documents, to merge and exclude sections. ”

Generally, if it turns out to bring only common phrases, for all the good, against all the bad, - do not write anything. Otherwise, the specialist reading the document, having met such passages, will cease to take the document seriously, and important provisions will be missed. Do not read the document torture!

3.4. Why in the TK, according to GOST 34, are there so many requirements that are not directly related to the functions of the system?

Indeed, in the TK of 30 pages, only 7-10 pages can be devoted to functions. This has an explanation. The fact is that the developers of GOST 34 looked at the automation project in a completely different way than we did. And they looked more correctly, more complex.

First , in the first half of the TZ, it’s not just that the general information about the system and general requirements are presented. It is necessary to understand why the system is being created, what processes it automates, what needs to be done to make the system work, what kind of system the system has. It seems to be banal things, but without them, team members will understand the purpose of the work and the means of achieving the goal in different ways. It is very important for us to make sure that all participants are set to the same wave, and not like a swan, a crab and a pike.

SecondlyThe compilers of GOST 34 saw the system primarily as people, and then as a software and hardware complex. This is how GOST 34.003-90 defines an automated system: “A system consisting of personnel and a complex of automation equipment for its activities, implementing information technology for performing the established functions”. Thus, an information system is trained personnel, software and hardware, all together. And indeed, take away computers from accountants, they can hardly but be able to do their work, even with paper registries. But 1C without an accountant will not work independently. From here and many sections of TZ devoted to organizational measures. As they say, the IT system by 20% is IT, all the rest is organizational measures. That is, TK is a document

Thirdly , pay attention to the name of GOST 34.602-89: “Technical task for the creation of an automated system”. TK is not on the system, but on the creation of the system. What's the Difference? The difference is that TK sets not only the requirements for the system itself, but also regulates the process of its creation, that is, the document sets out the requirements for all organizational measures that are necessary to achieve the result. Indeed, when implementing an automation project, it is often necessary to restructure a number of processes, train personnel, and prepare the hardware.

Fourth, TK is a document on which you can put a tick: we took into account this requirement or not. Maybe you will put 10 ticks clean automatically, because it will be standard solutions. But tick number 11 will reveal a very big problem, and if this problem is now missed, it will pop up somewhere in the implementation process, when all the deadlines and budgets have been defined.

Fifth , as we have said above, unnecessary subsections can be excluded, it is allowed. For example, if you know for sure that there can be nothing patented in your developments, then why bring out patent clearance requirements? This is not the case when without water and not tudes, and not syudy.

3.5. Why in different sections says the same thing?

Indeed, there are subsections in TK, which largely repeat the content of other subsections. For example, there are requirements for organizational support and for the number and qualifications of personnel. In both paragraphs we are talking about staff. But in the first case, we provide information about the organizational structure: what should be the departments, how should be established interaction with other departments. Agree, this is not at all the same as simply the requirements for the number and qualifications of personnel.

But for small systems, only one or two administrators and a couple of moderators are required. In this case, we simply have nothing to describe in as many as two subsections. Then omit one section, and in the other please provide a full statement of requirements.

3.6. Do I need to make out a quality specification?

Although the requirements for the design of TZ are given in paragraph 3 of GOST 34.602-89, let's say a few words about this aspect.

Of course, the main content. But, firstly, they are met by clothes, and, secondly, it is difficult to read illiterately written text with a jumping font. Readers will be distracted by poor-quality design and it will be more difficult for them to penetrate into the content. Therefore, the technical documents adopted strict content and limited terminology, without colorful expressions: the reader should focus on the essence, not on artistic turns.

We give a few wishes for the design of large documents like TK.

First of all, in a large document it is necessary to use styles and, except for underlining or highlighting inside a paragraph, do not change the font and paragraph settings for only one fragment. If you change, the style.

Secondly , we must not forget about such mandatory elements as auto-selectable table of contents, a list of terms and abbreviations (well, there is no joy to guess what this means by this or that abbreviation), the title page. It is also advisable to provide a list of versions of the document, a list of changes: it is very easy to track down later on which dates a particular version was sent.

Fourth, each individual requirement should be set forth in a separate numbered paragraph. If in one fragment there are 2-3 requirements, then only the first is read, and our brain skips the rest. TK is a document in which in front of each paragraph you can tick whether the requirement is fulfilled or not.

Fifth , do not skimp on the placement of links. Sometimes you read a paragraph where some function or requirement is mentioned, and you do not understand, this is from the same document or from another. If from this, then in what section. Therefore, try to refer to other sections if they are mentioned in the current text. Naturally, links should be automatic.

Note that, according to strict rules, the TK is issued without a frame (this is stated in paragraph 3), but the rest of the documents are framed. This is set in GOST 24.301-80 "System of technical documentation for automated control systems. General requirements for the implementation of text documents (with Amendments No. 1, 2) ". This standard establishes the rules for the design of all documents except TK and documents created at pre-project stages. Although I personally do not like the frame in any documents.

4. Section 1. "General Information" / p. 2.3 GOST 34.602-89 /

Most of the information in this section does not need to be commented, so we will focus only on some subsections.

So, under the "list of documents on the basis of which the system is created" means laws, orders or an agreement. Also, such a document may be another TK, if we develop TK for the subsystem. In general, there are several sections in the TK, in which a list of documents is provided, and it is necessary to very clearly understand the differences between the purpose of these parts of the technical task.

In the subsection "The order of registration and presentation to the customer of the results of work on the creation of the system (its parts), on the manufacture and commissioning of individual tools (technical, software, information) and software and hardware (software and methodical) systems complexes" provides general information about the acceptance of work. For example, the fact that we transfer documentation and conduct a series of system tests. Here we only mention the procedure for transferring the results of work, and below, in other sections, this topic is disclosed in detail.

5. Section 2. "Purpose and objectives of the creation (development) of the system" / p. 2.4 GOST 34.602-89 /

Here we need to understand the difference between the purpose and the purpose of creating a system. Very often, these concepts are mixed. For example, they write that the purpose of the system is to automate a personal account, and the goal is to create a personal account. Oil oily. In some cases, these concepts really match, then write only the appointment.

With the appointment, everything is clear: we present exactly the type (s) of automated activity. For example, if we create a system for production accounting, then it is worthwhile to give automated types of accounting, automated operations, as well as objects whose automation is expected.

With a view, everything is different. The goal is for what we are projecting. You can call it business goals. I highlight the following possible goals for automation projects:

1. Fulfillment of external requirements (requirements of law, standard, etc.)
2. Ensuring the work of a new technological process (for example, we create an online store, we organize a new department, a new business).
3. Decrease in operating expenses (decrease in the number of personnel, increase in output when using the same capacity, increase in efficiency).
4. Improving the quality of work: reducing the number of errors, accelerating decision-making.
5. Reduced risk, increased reliability. This applies not only to the technical side, but also to the exclusion of danger in the event of illness or dismissal of key, “indispensable” employees.

The GOST also says that it is necessary to provide criteria for assessing the achievement of a goal, that is, specific indicators. For example, we have 3 people collect only 20 orders per day. And after the introduction of the system, we want everyone to collect 20 orders, that is, three times more. If there such indicators are known, we give them in this paragraph.

6. Section 3. "Characteristics of the automation object" / p. 2.5 GOST 34.602-89 /

A very important, and often often formally described section. Although, in my opinion, this is the most important section of the TK, without it we simply do not understand what the system is all about.

Let's first define what an “automation object” is. If we automate a warehouse or plant, an accounting department, then everything is clear. And if, for example, we create a new social network, then there is no object, as it were. But in fact, the object rather means automated processes. And even in the case of a warehouse, we do not automate the warehouse itself (how can you automate the storage of boxes?), But warehouse processes.

If this section is carried out formally, it will be very similar to the description of the purpose of the system, and another lake of water will appear in the TOR, but it will not be clear what the system should do.

In this section should be given:

1. Description of the customer: the activities of the customer, the number of branches, employees. Of course, it is necessary to characterize the customer in the part that directly relates to the system being created.
2. Information about users of the system: types of users, what role the system plays for different users.
3. Description of objects to be automated. For example, if we automate a warehouse, we must describe how large it is, how many passes, what width of passes, what racks, whether there is a separate assembly area, how many people work and what their duties are. Then we will understand what we specifically automate, how the warehouse process should look, and what equipment is used.
4. Description of automated processes. Of course, it is not necessary to paint the processes in detail in the technical specifications. But to bring common scenarios - necessarily. Only then it becomes clear to us what functions should be available.
5. A list of documents that provide a detailed description of the automation object.

I have had occasions when the description of this section took more than half of the development time of TK, because it takes a long time and scrupulously to collect various information, analyze them and carefully describe.

7. Section 4 “System Requirements”

In TK, according to GOST 34, there is one giant section: Section 4, System Requirements. It has three subsections:

• System requirements in general.
• Requirements for functions (tasks) performed by the system.
• Requirements for types of collateral.

These subsections, we consider separately.

7.1. Subsection 4.1. "Requirements for the system as a whole" / p. 2.6.1 GOST 34.602-89 /

In subsection 4.1, “Requirements for the system as a whole,” the so-called non-functional, general, requirements that describe the system being created from different sides are given.

By the way, as we mentioned, subsections can be added and omitted. Therefore, the numbering given here is approximate and serves for orientation within the article.

7.1.1. Clause 4.1.1. "Requirements for the structure and functioning of the system" / p. 2.6.1.1 GOST 34.602-89 /

This item is quite extensive, it should give a general idea of ​​the system architecture. Let us examine these requirements in more detail.

1. The list of subsystems, their purpose and basic characteristics, the requirements for the number of hierarchy levels and the degree of centralization of the system.

At this point, I usually quote:

• internal structure (application server, data storage module, thick client in the form of a native application, public web application, administration panel, mobile applications, report server) and external adjacent systems (other customer systems, SMTP mail server, SMS sending service) acquiring bank, online cash desk, map service, address service, email address verification service, etc.);
• requirements for the elements of the structure.

If you are planning a microservice architecture, then it makes sense to list and describe the functionality of the services.

For clarity, it is desirable to attach a block diagram of the system with the designation of its parts and adjacent systems, as shown in the examples below.



... or so:



2. Requirements for methods and means of communication for information exchange between system components.

3. Requirements for the characteristics of the relationship of the system being created with adjacent systems, requirements for its compatibility, including instructions on how to exchange information (automatically, sending documents, by phone, etc.)

In modern conditions, most of the interactions are performed using the HTTP (S) protocol. It seems, besides this, there is nothing to write. However, these items can be so large that they are placed in the application. They should include the following information:

• a list of information transmitted, at least a general description, in order to understand why we integrate with a particular system;
• a description of the protocols (or references to the description), especially in the case of connecting devices;
• structure of local networks;
• required data transfer rate;
• the use of mobile Internet or WiFi;
• description of manual data transfer methods.

4. Requirements for the modes of operation of the system.
Modes of operation may have several classifications:

• on operational readiness: regular mode, emergency mode, maintenance mode (for example, a site screensaver must be present in the emergency mode, the load is transferred to another server, special messages are displayed when accessing this system via API, in the maintenance mode some functions can be available);
• on the readiness for operation of parts of the system: how the system should function, for example, if one of the external or internal services is not available;
• according to the work schedule: 24/7 or five days (at least the work of technical support depends on it);
• whenever possible data changes: view or edit mode;
• by the level of access to data and system operations: authorized user mode, administrator mode, guest mode (for unauthorized users);
• on the means of accessing the system: through a web application, through a thick client, through a mobile application (agree that the functionality may be slightly different, these limitations can be described here);
• by type of interaction: conversational (via interface), interaction by changing settings in configuration files or otherwise, non-automated (for example, information is transmitted to another employee who enters data into the system, manual readings are performed);
• according to the degree of automation: automatic or semi-automatic mode, “advisor mode”;
• by application visibility: interactive or background mode;
• on possible effects on the system: regular, training, test modes.

5. Requirements for system diagnostics.

Requirements for permanent or periodic diagnostics should be made to systems based on microservice (distributed) architecture, systems that include equipment: sensors, control systems, terminals, etc. Of course, if only software is developed that runs on one server, these requirements are unnecessary: ​​and so you will find out if something stops working.

6. Prospects for the development and modernization of the system.

It seems that the prospects for the development of the system are related to the subsection “Requirements for the structure and functioning of the system” But imagine, now you are creating an alpha version for 100 people, and in a year you want to get more than a million simultaneous users in different parts of the world. Then you are at the stage of creation immediately need to provide a cluster architecture.

Or now you are working from the same organization, and after six months there will be several of them, it means you must foresee the possibility of expansion.

In other words, in this section, you can write down all the prospects for modernization, but especially those that accurately affect the architecture.

7.1.2. Clause 4.1.2. "Requirements for the number and qualifications of staff" / p. 2.6.1.2 GOST 34.602-89 /

As we mentioned earlier, any automated system consists of “personnel and a set of automation equipment for its activities”. Therefore, the requirements for staff and their qualifications are specified in the TOR.

If you automate a specific production line, then the number of personnel is known to you. But in many cases it depends on the amount of work done. Therefore, indicate the positions, work schedule, activity description (for assigning access rights) and an approximate qualification. At a minimum, you will need a system administrator and operator, quite often - a moderator. It is possible that we will have to provide several types of operators with different levels of access.

It is clear that the requirements for staff are often set by the customer, why should they be brought then? But, first, we have already said that the TOR is compiled for both parties, and secondly, the contractor will be protected: the recruitment condition is not fulfilled, what does the customer want if the system is not implemented?

7.1.3. Clause 4.1.3. "Requirements for the performance indicators" / p. 2.6.1.3 GOST 34.602-89 /

In this subsection, it is often written what your heart desires, since the list of possible indicators is not in the text of the GOST, and it is almost impossible to find them in open sources. Please note that the “degree of adaptability”, “modernization limits” and “probabilistic-temporal characteristics” given in GOST are, firstly, indicated for the ACS (automated control system) and, secondly, they are rather difficult to measure. Thus, these characteristics are not always suitable.

However, in the text itself, “assignment indicators” are defined as “parameters characterizing the degree of compliance of the system with its purpose”. In modern computer systems, the quantitative values ​​characterizing this system mainly relate to the performance and amount of data storage.

The indicators of appointment include:

• the number of users simultaneously working in the system;
• the number of simultaneous requests to the server;
• the number of transactions (recorded) per unit of time;
• response time with a different number of one-time queries and working users, with a different amount of data processed (especially when searching and aggregating in reports);
• the amount of stored data (in particular, images and video);
• connection time additional computing power when the maximum load is reached;
• connection time for additional capacity with a significant increase in the amount of stored data.

All these characteristics affect the choice of server hardware, application server architecture and DBMS, relational or non-relational DBMS, microservices, etc.

7.1.4. Clause 4.1.4. "Requirements for reliability" / p. 2.6.1.4 GOST 34.602-89 /

The text of the GOST describes in some detail what is necessary to specify in the requirements for reliability. However, to understand the approach to ensuring the reliability laid down in this standard, GOSTs of the series 27 should be examined. First you should familiarize yourself with the terminology: this will be enough to understand the very concept of reliability, how it is measured and what it provides. Therefore, refer to GOST 27.002-89. “Reliability in technology. Basic concepts. Terms and Definitions".

The basic concept that can be applied to automated systems is the availability ratio: 99%, 99.9%, 99.99%. Each number of "nines" is provided by certain measures.

Which technical solutions may affect these requirements? This includes the number of reserve capacities (they are different), the presence of technical personnel in the field, the use of not only uninterruptible power supplies, but also diesel generators, as well as connection from two independent sources (connection to power grids in I or II reliability category).

7.1.5. Clause 4.1.5. "Security Requirements" / p. 2.6.1.5 GOST 34.602-89 /

This subsection describes safety requirements for handling equipment (installation, commissioning and operation). Now these requirements are called labor protection and are contained in the State Standards of the 12th series (SSBT - the system of labor safety standards). In TZ, it is enough to give a list of these sections, again, if someone is going to seriously engage in security.

7.1.6. Clause 4.1.6. "Requirements for ergonomics and technical aesthetics" / p. 2.6.1.6 GOST 34.602-89 /

Here are the requirements of GOST: “The requirements for ergonomics and technical aesthetics include indicators of the AU, setting the required quality of human interaction with the machine and the comfort of the working conditions of the staff.”

Usually it is written at this point that the system should have a convenient and beautiful interface. But how to measure convenience and beauty? Therefore, either we omit this requirement, or we say that the interface will correspond to the design project developed later, or we provide standards, for example, the so-called guidelines for developing mobile applications: Material Design for Android and Human Interface Guidelines for iOS.

You can also give a limit on the number of transitions (clicks) when implementing certain functions that are especially important to us, the average speed of data retrieval, etc.

7.1.7. Clause 4.1.7. "Requirements for transportability for mobile speakers" / p. 2.6.1.7 GOST 34.602-89 /

Say some obsolete requirement. Now the server is not transported by trucks, as large computers used to be. Nevertheless, imagine that you have some kind of super protection, an internal circuit behind the DMZ and ... the need for remote work through a laptop. Yes, VPN is configured at any time, but it is better if this is reflected in the Administration Guide, and the opportunity itself is provided for by the network configuration.

7.1.8. Clause 4.1.8. "Requirements for operation, maintenance, repair and storage" / p. 2.6.1.8 GOST 34.602-89 /

These requirements relate to the maintenance of a complex of technical means (server, firewalls, switches, workstations, etc.). If the equipment requires some special maintenance, then it is necessary to describe this in this section. For example, you have a special device that needs to be calibrated once a month.

7.1.9. Clause 4.1.9. "Requirements for protecting information from unauthorized access" / p. 2.6.1.9 GOST 34.602-89 /

The topic of protecting information from unauthorized access is quite extensive, as well as measures to ensure it. Of course, if we are talking about access to the personal account of the web site and the administration panel of this site, then there are enough authorization requirements, password complexity, role-based access model. But if you create a financial system or a system for state needs, then there are special requirements.

It is important to note that in this subsection are given not only the measures that need to be applied during the development of the system, but also its operation.

Thus, for financial systems, the Payment Card Industry Data Security Standard (PCI DSS) should be used. For systems in which personal data are stored - Government Decree of November 1, 2012 No. 1119 “On approval of requirements for the protection of personal data when they are processed in personal data information systems”. There may be other standards in your subject area.

In general, remedies can be divided into the following types:

1. Funds provided by the created software product.
2. Measures provided by the system administrator.
3. Physical protection measures.
4. General organizational measures.
5. Measures taken in the software development process.

1. Remedies provided by the software being created:

• Password requirement for users, especially for users with an administrator role.
• Implement role-based access model.
• Requirement for the use of electronic signature keys to perform particularly important operations.
• Delivering software components responsible for interfacing with external systems into a demilitarized zone (DMZ).
• Ensuring registration of events and actions of users.

2. Measures provided by the system administrator:

• The use of firewalls (firewalls).
• Documentation and monitoring of services and protocols used.
• Configuring the DMZ.
• Monitoring compliance with the rules of using laptop computers: connecting to the internal network, using firewalls.
• Disable default accounts before connecting to the network equipment and systems.
• Configure wireless devices: set passwords and change default access settings.
• Installation of updates that eliminate the identified hardware and software vulnerabilities.
• Security during remote access to the system (for example, using a VPN).
• Install, update and monitor the operation of antivirus software.
• Conducting periodic network scanning and scanning after making important changes.
• Assigning each employee a unique account, periodically checking for unresolved accounts of dismissed employees, changing passwords. Issuance and registration of electronic signature tokens.
• Configuring access restrictions to databases.
• Control time synchronization on all servers and workstations (to ensure the correctness of the time recorded in the event logs).
• Configure event logs.
• Periodic inventory of wireless access points and other equipment installed software.

3. Physical protection measures:

• Restriction of access to critical premises.
• Disconnect network connectors in public places.
• Installing CCTV cameras for critical premises.

4. General organizational measures:

• Approving a security policy and conducting periodic staff training on information security rules.
• Introduce a security incident response procedure.
• Check for output in screen forms or reports of confidential data.
• Issuance of badges to all visitors, escorting visitors when they are in critical premises.
• Comprehensive verification of hired employees.
• Security provided by software and hardware service provider organizations.

5. Measures taken in the software development process:

• Control by responsible persons of making changes to the program code, checking the code for compliance with information security rules (controlling buffer overflow, correct error handling, checking for cross-site scripting, for access mechanism errors, etc.)
• The use of robust cryptography.
• Apply security rules for public web applications.
• Develop cancellation procedures for each change.
• Documenting changes.

7.1.10. Clause 4.1.10. "Requirements for the safety of information in case of accidents" / p. 2.6.1.10 GOST 34.602-89 /

This section provides a list of possible accidents and failures, under which information security should be ensured. These events may include:

• loss of nutrition;
• server down;
• failure of storage device (hard disk).

7.1.11. Clause 4.1.11. "Requirements for protection from the influence of external influences" / p. 2.6.1.11 GOST 34.602-89 /

This section will be useful in the case of placing servers, workstations and other equipment in a cold warehouse or, on the contrary, in industrial premises with high temperatures, in dusty places or places with high humidity. Also, sometimes it is worth considering vibration, radiation or other effects.

7.1.12. Subsection 4.1.12. “Patent Cleanliness Requirements” / p. 2.6.1.12 GOST 34.602-89 /

If you suspect that you will use any technologies patented in other countries (or in our country), and the patent owner may sue the owner of the system, in this paragraph indicate the list of countries in which you want to check on patent purity.

7.1.13. Clause 4.1.13. "Requirements for standardization and unification" / p. 2.6.1.13 GOST 34.602-89 /

This item is also rarely found in the Terms of Reference for software. It indicates both the requirements for the use of specific technologies and unified forms of documents and classifiers.

This description is especially important if you have specific requirements for the frameworks used, plug-ins, protocols, devices, mathematical algorithms, third-party software, etc. Just do not forget to indicate in which part and for what purposes these tools should be used.

Also sometimes in systems of some classes it is customary to use certain data exchange protocols. For example, OCG standards are used to exchange data between geographic information systems, and OCPP is used to control charging stations for electric vehicles.

7.1.14. Clause 4.1.14. “Additional Requirements” / p. 2.6.1.14 GOST 34.602-89 /

This item should be found in the text of the GOST. He does not need comments.

7.2. Subsection 4.2. "Requirements for functions (tasks) performed by the system" / p. 2.6.2 GOST 34.602-89 /

This section is central to modern computer systems. Actually, the system is created to perform certain functions. Often TK created on the basis of foreign standards and generally without standards, contain only this section.

7.2.1. Functional Description Structure

First, we consider the structure of the functional requirements for the system: a subsystem - a complex of functions - a function - a task. A task is a part of a function, and a task can be described as a separate function. For example, for the login function, we present the password as one of the tasks. And we can write the password entry procedure already as a separate function: checking for correctness, password recovery, display of prompts, etc. Complex - this is what combines the functions. For example, “Accounting for Basic Information”, “Holding an Auction”, etc. The complex has two or more functions.

If your system consists of several subsystems, then basically TK should list the functions for the subsystems, and describe in detail the functional requirements for the subsystems in separate TK for the subsystems (they are often called ChTZ now - a particular technical task).

7.2.2. Types of functions in terms of their performance

In fact, all functions (or their tasks; there can be several tasks in the function) can be divided into the following types:

• Enter information. Sometimes also referred to as "accounting information."
• Information output.
• Automatic information processing.

7.2.3. Types of functions in terms of their role

Functions can be general and special. Common functions, for example, include working with lists of objects, working with an object card, working with an interactive map. These functions may apply to all special or parts of special functions.

7.2.4. Requirement, not script

Do not forget that the requirements for the system and the process of its creation are given in the TOR. Not scripts. TK answers the question what the system should do. To the question HOW the technical design answers. If you begin to describe in detail the technical implementation, then immerse yourself in the details and fail to provide a complete list of requirements: our brain cannot simultaneously work in the modes of wide coverage and consideration of the details.

The structure of the functions of the TOR and the technical design can vary greatly: in one scenario, several functions can be implemented, and vice versa.

7.2.5. Registration of functional requirements

We give some recommendations on how to make out the description of the functions:

1. Requirements for functions and tasks should usually be put into the application. Thus, the document is organically divided into non-functional and functional parts. In addition, the application can always be printed and viewed separately.
2. Avoid large paragraphs. Best of all, if the requirements are broken down into paragraphs and sub-clauses: it is easier to perceive and control their fulfillment (check marks). If a list of requirements or information is given, let it be numbered or bulleted.
3. For functions whose purpose is not obvious from their name, it is necessary to indicate the purpose and the task to be solved. Otherwise, even the compiler of TK risks forgetting why he described this or that functionality.

7.2.6. Function Description Example

5.6. Vehicle Registration in the System

The following requirements are made:

1) The system should allow to take into account the following general information:

• state license plate (GRNZ);
• Name of the owner;
• the address of the owner;
• data from the vehicle data acquisition service (see clause 3.3, Appendix B);
• note.

2) The system should allow to take into account the following information relating to the payment of travel (this information is informational in nature, the possibility of changing them directly in the registration card of the vehicle is not required):

• current vehicle class (see clause 3.3, Appendix A);
• current tariff (see clause 5.1, Appendix A);
• current contract (see clause 5.5, Appendix A);
• vehicle class according to information from the Ministry of Internal Affairs of the Republic of Kazakhstan;
• information about the personal account and its state (see clause 3.6, Appendix A);
• information on being in the vehicle registry with a reduced fare (see clause 3.5, Appendix A).

3) The system should allow to register and change information about the vehicle in the following ways:

• manually by the operator;
• when information is received from the RFID tag registration system (see clause 1.1, Appendix B);
• when identifying the vehicle using the GRNZ camera.

4) When registering a new vehicle in the system, the system should request the vehicle data from the vehicle data retrieval service (see clause 3.3, Appendix B). It should be possible to update the specified information of the individual vehicle.

7.3. Subsection 4.3. “Requirements for types of collateral” / p. 2.6.3 GOST 34.602-89 /

The section of requirements for the types of security in general is often cited as an example of an excess volume of TK according to GOST. When it comes to whether all sections and subsections should be cited, they recall the software for which, in most cases, there is simply nothing to write.

In fact, this is a very important subsection, although not everyone understands its purpose. It describes the conditions without which it is impossible to implement either the development or commissioning. These terms are described as “collateral.”

When reading this subsection, one wonders what the originators of the standard meant by “mathematical software”, “linguistic software”, “information software”, etc. Answers should be sought in GOST 34.003-90, where all these terms are spelled out.

7.3.1. Clause 4.3.1 "Mathematical software" / p. 2.6.3.1 GOST 34.602-89 /

Imagine a situation that you need to create a system in which you want to implement an automatic calculation of the optimal route. The “Calculate Route” button may look simple, but very complex mathematical algorithms and calculations may follow it. It is clear that you should not undertake the development of such algorithms; professional mathematicians are engaged in this. In the case of the presence of such algorithms, the requirements for their development or the use of ready-made ones are specified.

7.3.2. Clause 4.3.2 "Information support" / p. 2.6.3.2 GOST 34.602-89 /

When reading the description of this requirement in the text of the GOST, it seems that this is a repetition of what has already been said in other sections. For example, why again describe the requirements for "the composition, structure and methods of organizing data in the system" and "to the information exchange between the components of the system"? But we again forget that the compilers of the GOST under the system had not only software, but also the entire set of organizational measures.

Here you encounter when implementing with such a situation that the customer has not provided for his part an operator who will enter any data into the system, and at the same time declares to you that the system is not working. Common situation? But if the requirement for the given input were spelled out in TK, it would be possible to directly and poke the customer into this point. Or you need access to a specific address classifier for work, and the customer does not give it to you.

Thus, in this clause it makes sense to specify the requirements for incoming information and information transmitted from component to component of the system in a non-automated form. Automated information processing, the use of DBMS, information exchange within the system is fully described in other sections.

7.3.3. Clause 4.3.3 "Linguistic support" / p. 2.6.3.3 GOST 34.602-89 /

This paragraph provides:

• requirements for the use of programming languages ​​(if there are specific preferences);
• interface language (which languages, multilingual interface);
• language for communication of project teams, requirements for translation;
• other features of data input and output, if available: encryption, non-standard methods of user interaction with the system.

7.3.4. Paragraph 4.3.4 "Software" / p. 2.6.3.4 GOST 34.602-89 /

This paragraph provides a list of purchased software if it is determined at the stage of development of the TK.

7.3.5. Clause 4.3.5 "Technical Support" / p. 2.6.3.5 GOST 34.602-89 /

Any information system cannot operate without hardware, servers, networks, etc. Determination of the specific characteristics of the equipment is usually advisable to carry out in the technical design, but in the TOR can provide an approximate composition, so that the customer has an idea of ​​future costs.

7.3.6. Clause 4.3.6 "Metrological support" / p. 2.6.3.6 GOST 34.602-89 /

If the system is going to receive data from the sensors, then it is necessary to understand what measurement tools will be used, what accuracy the measuring tools must provide, whether these tools should be certified and certified.

7.3.7. Clause 4.3.7 "Organizational support" / p. 2.6.3.7 GOST 34.602-89 /

Imagine that you are creating a system from scratch. For example, this is a warehouse management system for a new logistics complex. In other words, there are only walls. Or you are upgrading the system, and for the introduction of changes you need to modify the organizational structure. In such cases, you should specify the conditions regarding the organization of the processes under which the system you supply will actually work.

7.3.8. Clause 4.3.8 "Methodological support" / p. 2.6.3.8 GOST 34.602-89 /

Sometimes the management of the system requires personnel having any specific competencies. In this case, the list of techniques, standards and standards with which the employees interacting with the system should be presented should be given in the TOR.

7.3.9. Other types of security

When developing each new TZ, you should consider what you will need for successful commissioning. For example, I often prescribe requirements for legal support, when the legal scheme used is not fully defined and its development may affect implementation. Although such issues are best dealt with before drawing up a technical task .

8. Section 5 "Composition and content of work on the creation (development) of the system" / p. 2.7 GOST 34.602-89 /

This section is organizational and it is often submitted to the contract. However, this information in the TOR can be clarified.

In essence, this is a short development and deployment plan. When compiling it, I usually quote a table that lists some or all of the following columns:

• The name of the stage (substage).
• Work content (brief description, list of tasks).
• Result of work (approved documents, developed and submitted solutions).
• Project, working or reporting documentation.
• Responsible (who performs this work: customer, performer or other person). If both parties are to give a joint result, the roles are indicated.
• Duration (dates, dates, start of timing).

An example of the content of this section is given in the table below.

Stage	Content of work	Order of acceptance and documents	Timing	Responsible
1. Drafting of technical specifications (TZ)	Development of functional and non-functional system requirements	TK approval	60 days from the date of prepayment. The customer provides the first option for approval after 45 days	Development - Artist; approval - Customer
2. Technical design (TP)	Development of system scripts and web application interface layouts	Approval of the document "Description of automated functions"	60 days from the date of approval of the TZ. The customer provides the first option for approval after 45 days	Executor
	Development of corporate identity for website and mobile applications	Corporate identity approval		Customer
	Site content development (public web application)	Claim approval		Customer
	Development of a design layout of a public web application	Design Layout Approval		Executor
	Development of design layouts of public mobile applications	Design Layout Approval		Executor
	Selection of SMS aggregator, preparation of exchange rules with the server module	Design Layout Approval		Customer, according to the recommendations of the Contractor
3. Development of software	Development of server module, data storage module and file storage module	Acceptance is carried out in the process of testing	100 days from the date of approval of the TP	Development - Customer. The contractor provides data for filling directories
	Administration Panel Development	Acceptance is carried out in the process of testing		Customer
	Static website development (public web application)	Acceptance is carried out in the process of testing		Executor
	Development of integration of public web application and server module	Acceptance is carried out in the process of testing		Executor
	IOS mobile app development (including server module integration)	Acceptance is carried out in the process of testing		Executor
	Development of Android mobile applications (including integration with the server module)	Acceptance is carried out in the process of testing		Executor
	Development of working and operational documentation	Approval of documents: - "The program and methods of preliminary autonomous testing." - “Program and methods of preliminary complex tests”. - “Trial Operation Program”		Executor
4. Preliminary autonomous testing	- Verification of compliance with non-functional requirements (design). - Check the documentation set. - Verification of system performance, without interaction with adjacent (external) systems. - Improvements and re-tests to eliminate deficiencies	Approval of the Preliminary Autonomous Test Report	14 days from the date of completion	Performer - conducting tests. Customer - infrastructure preparation and test organization
5. Preliminary complex tests	- Check the interaction with adjacent external systems. - Improvements and re-tests to eliminate deficiencies	Approval of the preliminary complex test report	14 days from the date of completion of autonomous tests	Performer - conducting tests. Customer - infrastructure preparation and test organization
6. Preparation for trial operation	- Deployment of the system on industrial servers. - Execution of a complex of preparatory works (for more details, see clause 7 Requirements for the composition and content of works on preparation of the automation facility for commissioning the system)	No acceptance	5 days from the date of completion of the preliminary tests	Preparation of the program part and filling out reference books - the Customer. The contractor provides data for filling reference books and organizes OE
7. Trial operation	- Operation with the involvement of a small number of participants (several auctions among friends). - Improvements and re-tests to eliminate deficiencies	Protocol of trial operation (log of errors and results of their correction)	30 days	Artist - elimination of deficiencies. Customer - OE
8. Entering into industrial (commercial) operation	See preparatory stage for trial operation.	No acceptance	Preparation of the program part and filling out reference books - 10 days	Preparation of the program part and filling out reference books - the Customer. The contractor performs the organization of industrial operation
9. Industrial (commercial) operation	Industrial exploitation	No acceptance

9. Section 6 “Procedure for control and acceptance of the system” / p. 2.8 GOST 34.602-89 /

This section describes in detail the process of acceptance of the system by the customer: what tests should be carried out, what will be included in these tests, according to which documents will be tested, how comments will be made and eliminated.

9.1. Subsection 6.1. "Types, composition, scope and test methods of the system and its components" / p. 2.8.1 GOST 34.602-89 /

Usually, here I specify the list of tests and mention that test methods will be presented in the document “Program and Test Methods”, which is a description of the main test cases and test scenarios.

Let us dwell on the types of tests. Types of tests, their composition, requirements for documents are established by GOST 34.603-92 “Information technology. Types of testing automated systems. Therefore, when developing this section and technical project, be sure to refer to this standard; here we will explain only the main points.

Let's try to figure out what the tests are:

1. Tests are divided into the following types:

• Preliminary.
• Trial operation.
• Acceptance.

2. Preliminary (and partially acceptance) tests, in turn, are divided into:

• Autonomous (without integration with adjacent systems).
• Complex (in a complex with adjacent systems).

Why are the tests divided into different stages? First, because GOST 34.603-92 does not separate the internal acceptance and the external, part of the tests can be carried out without a customer. Secondly, the sequential testing process is described, part by part, and then all in a complex.

Let's try to describe the testing process in simple words:

1. Pre-autonomous testing of parts of the system. Parts of the system are tested separately if there are several subsystems or large modules in the composition. Typically, such testing is carried out autonomously, that is, without integration with adjacent systems. If the system is simple, this stage can be safely skipped.

2. Preliminary autonomous testing of the system as a whole.The entire system in the complex is tested offline, that is, without integration with adjacent systems. Functions associated with adjacent systems are not checked. In the extreme case, “stubs” (integration emulation) are put in or the database is pre-filled with data that must come from external sources.

3. Preliminary complex tests. The system is tested in complex mode, that is, in conjunction with adjacent systems. In this form, the system is transferred to the customer for trial operation.

4. Trial operation.OE can take place in different modes. The best is to operate on real data, with real users and with the performance of real tasks. Only this type of test will make sure that the system is actually operational. During trial operation disadvantages are eliminated.

5. Acceptance tests. This is the last type of check. Tell me, why the trial operation after eliminating all the flaws does not smoothly go into the industrial? So it usually happens. But after all, high uncles need to see that the system really works, to “touch” it. Acceptance tests are intended for them, for a high commission. Thus, acceptance tests differ from preliminary tests in the first place by the status of the commission.

Also in this paragraph are the documents in which test methods will be given:

• For preliminary and acceptance tests, this is the “Program and methods of preliminary (acceptance) tests”. Instructions for drawing up the document are contained in two standards at once. In short - in GOST 34.603-92 (p. 2.2.2 and 4.1) and in more detail in RD 50-34.698-90 “Methodological guidelines. Information technology. A set of standards and guidance documents for automated systems. Automated systems. Requirements for the content of documents.
• For trial operation , the document “Program of trial operation” is provided, the content of which is given in clause 3.1 of GOST 34.003-90. It is also necessary to prescribe the use of the “Trial Operation Log” (see clause 3.2 of GOST 34.603-92), which will contain the disadvantages and the results of their elimination.

9.2. Subsection 6.2. "General requirements for the acceptance of work in stages" / p. 2.8.2 GOST 34.602-89 /

In this section, I usually specify:

1. On whose territory and on whose equipment the tests will be carried out: customer or performer.
2. General description of how tests will be conducted (for example, that documents will be checked, the presence of user interface elements, scripts will be worked out).
3. List of participants.
4. The list of documents that make up the test result:
   
   
   • For preliminary and acceptance tests, this is a test report that lists the checks and their results.
   • For trial operation - trial operation magazine.

10. Section 7 "Requirements for the composition and content of work on the preparation of the automation object to put the system into operation" / p. 2.9 GOST 34.602-89 /

The process described in this section is often referred to as deployment. Please note that these works are also given in section 5 "Composition and content of work on the creation (development) of the system . " But, in section 5 they are only briefly mentioned, here is a detailed description.

In preparing the object, as a rule, the following work should be done:

1. Reorganization, recruitment of new staff, if necessary.
2. Training.
3. For web applications: development of common sections of the site and user agreement (consent to the processing of personal data).
4. Filling reference books and other background information.
5. Transfer data from the old system.
6. Deploying the system on industrial servers.
7. Setting integration with related systems.
8. Setting up an access system and creating accounts.

Some of these points should be described in great detail, especially with regard to the transfer of data and the filling of directories.

11. Section 8 “Documentation Requirements” / p. 2.10 GOST 34.602-89 /

It is not necessary to documents formally. Documents are a project management, project document circulation. You can't keep everything in your head, and the success of the project depends on the availability and quality of documents. Of course, there are documents “for weight”, and they should be treated appropriately, but the project cannot be implemented without documentation in a calm and orderly mode.

Documentation of the automation project according to GOST 34 is governed by the following standards:

• GOST 34.201-89 Types, completeness and designation of documents when creating automated systems.
• RD 50-34.698-90 Methodical instructions. Information technology. A set of standards and guidance documents for automated systems. Automated systems. Requirements for the content of documents.
• For the Technical Specification - GOST 34.602-89, which we are now discussing.

The first standard (GOST 34.201-89) provides a list and structure of the documentation. In the second - RD 50-34.698-90 - the contents of the following documents are indicated:

• Documents outline and technical projects.
• Documents developed in the pre-project stages.
• Organizational and administrative documents (acts, protocols, etc.)

11.1 Features of the documentation structure

When drawing up the list of necessary documents, they usually look through the RD 50-34.698-90 and select the required ones. This makes a lot of mistakes, because the documentation has a rather complex structure, which is described in GOST 34.201-89.

Let's try to identify a few rules that will help in drawing up the list of documents.

1. For each of the stages there is a set of documentation.

Each stage has its own set of documentation. It is very important to clarify. It is not necessary to prescribe the development of operational documents at the design stages and vice versa. Purely formal papers are obtained, on which you will spend considerable time. And if the “User Guide” before the end of the development of the system is usually no one (although I also met such figures), then the “Description of Automated Functions”, which usually contains scripts for programmers, is constantly made after the end of development. Also, when reading RD 50-34.698-90, one may get the impression that the content of some documents overlaps: this is also due to the fact that the documents are intended for different stages.

Since some documents can be developed either at one or at another stage, in GOST 34.201-89, in order to avoid repetition, a list of documents that can be produced both at the technical design stage and working documentation, and lists of documents for each of these stages separately. Thus, when drawing up the list of documents for one of the stages, one has to look through the lists of documents in several sections of the standard.

In order not to get confused, I have compiled an Excel table , in which, using filters, you can immediately display the full list of documents for a particular stage.

2. Documents are divided into topics (parts of the project).

In GOST 34 there are documents describing system-wide solutions, as well as organizational, technical, mathematical, software, information support (we discussed the types of software above ). In RD 50-34.698-90, these documents are provided with a breakdown by parts of the project (topics). Attention should always be paid to determine the purpose of the document.

3. Documents can be combined.

GOST 34.201-89 explicitly states in which cases one document is included in another. This is done to ensure that there are no degenerate documents, with one or two pages. If something needs to be described, but the volume is very small, it is best to include the text in another document. In most cases, there is such a document as the “Explanatory Note to the Technical Project” in which sections can be added.

4. Operational and design and estimate documentation are highlighted separately.

The compilers of GOST 34.201-89 in separate columns of the table with the list of documents indicated the belonging to the operational and design and estimate documentation.

Design estimates include documents regulating construction and electrical work: estimates, procurement plans, drawings and wiring diagrams.

The operational documents include the documents that govern the use and maintenance of the system: manuals and instructions, lists of materials and data, documents containing information on violations during operation.

11.2 Features of the list of documents

As you noted earlier, when describing the stages of work in Section 5 “Composition and content of work on the creation (development) of a system” , a list of documentation is also given. A double list of documents is provided for a simple reason: it is not enough to indicate the name of the document, it is necessary to clarify its purpose and provide a summary (of course, there is no sense to specify the content for the “User Guide”). Otherwise it will not determine what the value of a document in the management of the project. GOST guest, and on each project the content and role of documents may differ. In addition, the list may contain documents that are not regulated by GOST 34, which need to be explained without fail.

In the documentation rules, I usually list a table with the following columns:

• Stage.
• Title of the document.
• Note: indicate the development standard, purpose, summary and main features of the document.

11.3 Example of a list of documentation

For a large project to introduce a complex system, a rather large list of documentation may be required. We give an example of such a list in the table below.

Stage	Document	Document content	Notes
1. Technical design	Technical design sheet	List of technical project documents
	Explanatory note to the technical project	- description of the main technical solutions; - a description of the process of activity using the system; - arrangements for preparing the automation facility for commissioning the system	When supplying generic products not developed
	Description of automated functions	- detailed scenarios of the system; - UI mock-ups with a detailed description of the elements; - list of subsystems (modules) with a description of the functions performed; - a description of the data structure, where necessary; - forms and rules for generating reports	When upgrading, a description of the functions being upgraded is given in the “as it should be” format. - By delivery of standard products is not developed
	Description of the complex of technical means	- description of the equipment complex: servers, firewalls, switches, etc .; - description of the local network and subnets, Internet access parameters	When upgrading is developed in the event of changes in the CCC, describes the changes.
	Description of integration solutions	Description of the developed integration protocols with related systems, the frequency of exchange operations	The document is being developed in place of the GOST “List of input signals and data” and “List of output signals (documents)”. - When upgrading is developed in the event of changes, described in the format "as it should be"
	Description of the organizational structure	Changes in the organizational structure necessary for the functioning of the system	When upgrading is developed in case of changes in the organizational structure
	Estimate	Specified cost of work on the creation and implementation of the system
2. Development of working and operational documentation	Statement of working and operational documentation	The list of working (operational) documents of the technical project
	Formulary	- general instructions for operating the system; - a list of documentation for staff; - the amount of support; - information required for the organization involved in the maintenance of the system; - a list of emergencies and information about their elimination; - information on the repair of technical equipment; - information about software changes; - information on the performance of maintenance work; - information on reclamations and the elimination of comments	- When upgrading the system, the document is updated. - By delivery of standard products is not developed
	General system description	- system structure; - A list of related systems and links between systems; - description of subsystems; - structural scheme of a complex of technical means; - list of operational documents	In case of completion of a typical product, it can be fully developed.
	User Guide (Administrator)	Description of operations with the system
	Specification of purchased equipment	For each position is indicated: - name of the equipment; - type, brand; - manufacturer, supplier; - quantity	Developed if necessary
	Technological instruction	Instructions for an operation or a set of operations associated with the use of the system	When upgrading - updated if necessary
	Description of integration solutions		Updated document created at the stage of technical design
	User training program	- self-training plan; - lesson plan, number of hours; - a list of study topics in the classroom; - handouts; - test cases
	Program and test methods (for each test separately)	- scripts check functions of the system; - load testing scenarios	Upon delivery of typical products during testing, the following is checked: - the overall system performance and its integration with adjacent systems; - level of user readiness
3. Commissioning	Staff training protocol	The list of staff with marks of training and the implementation of control tasks
	System Deployment Protocol
	Protocol of initial database filling
	Preliminary Test Report	The list of tests with notes on the passage and comments
	The act of acceptance into trial operation
	Trial Operation Log	List of comments and information on their elimination
	The act of completion of trial operation
	Acceptance Test Report	The list of tests with notes on the passage and comments
	The act of acceptance of the system in continuous operation
4. Warranty and after-sales service (maintenance)	Formulary	The document is developed at stage 5 (Development of working and operational documentation) and is filled in the course of maintenance.

12. Section 9 "Sources of development" / p. 2.11 GOST 34.602-89 /

It seems to be a formal section, but very useful. Imagine a situation where you remember that while developing a TK you read an article, and for some reason you need to find it, for example, to clarify something or substantiate your decisions. But you absolutely do not remember its name or where it was contained. Therefore, when I use some useful materials, I must list them. And in the text I put a footnote indicating the source.

If there are many sources, then they should be divided into subsections, for example:

• Materials describing analogues (prototypes) of the developed system.
• Materials describing the general idea of ​​the system. Often, these documents are at the pre-design stages, and they are usually referred to in the section “Characteristics of the automation object”.
• Materials for the development of the project: a list of used GOST series 34, used standards for project management.
• Materials related to the implementation of the main process: a list of laws, standards, internal regulations and orders establishing the rules for the implementation of automated processes.
• Materials and standards containing requirements for general and information security.

Conclusion

Of course, drawing up a Terms of Reference according to GOST 34 cannot be called easy and simple. And not because the GOST is bad, - just GOST makes you think over the whole project, to paint all the little things. On the other hand, a well-designed TK is half the success of the project.

Write in the comments if you consider it necessary to clarify or supplement something. Be sure to make changes to the article.

Read other articles by the author:

• Pre-project surveys in the development of an information system.
• Secrets of successful design of IP (information system) on the example of the construction of the hospital.
• Some notes on the design of information systems.