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

Often you hear the opinion that drawing up 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: the development of this GOST was carried out by entire research institutes, 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 article
 
3r330. 2. Characteristics of the Terms of Reference according to GOST 34
 
2.1. What is the standard for TK?
 
3r340. 2.2. Why do we need GOST for the technical task?
 
2.3. What role does the technical assignment take in the project?
 
2.4. How old is GOST ???-89 and are there newer standards?
 
3. General principles of drawing up TZ in accordance with GOST 34
 
3.1. Which specialist should make a technical task according to GOST 34?
 
3r362. 3.2. Which side should make the technical task?
 
3r366. 3.3. How far can you go from GOST 34?
 
3.4. Why in the TOR, according to GOST 3? are there so many requirements that are not directly related to the functions of the system?
 
3.5. Why in different sections says the same thing?
 
3.6. Do I need to make out a quality specification?
 
4. Section 1. "General Information" /p. 2.3 GOST ???-89 /
 
3r388. 5. Section 2. "Purpose and objectives of the creation (development) of the system" /p. 2.4 GOST ???-89 /
 
3r3394. 6. Section 3. "Characteristics of the automation object" /p. 2.5 GOST ???-89 /
 
3r3-300. 7. Section ? System Requirements 3r332395.
 
7.1. Subsection 4.1. System requirements in general "/p. ??? GOST ???-89 /
 
3r3111. ???. Clause ???. "Requirements for the structure and functioning of the system" /p. ???.1 GOST ???-89 /3r3323261.
 
3r3115. ???. Clause ???. "Requirements for the number and qualifications of staff" /p. ???.2 GOST ???-89 /
 
3r3119. ???. Clause ???. "Requirements for indicators of appointment" /p. ???.3 GOST ???-89 /3r3323261.
 
???. Clause ???. "Requirements for reliability" /p. ???.4 GOST ???-89 /3r3323261.
 
???. Clause ???. "Security Requirements" /p. ???.5 GOST ???-89 /

 
???. Clause ???. "Requirements for ergonomics and technical aesthetics" /p. ???.6 GOST ???-89 /3r3323261.
 
???. Clause ???. "Requirements for transportability for mobile speakers" /p. ???.7 GOST ???-89 /3r3323261.
 
???. Clause ???. "Requirements for operation, maintenance, repair and storage" /p. ???.8 GOST ???-89 /

 
3r3143. ???. Clause ???. "Requirements for protecting information from unauthorized access" /p. ???.9 GOST ???-89 /3r3323261.
 
3r3147. ???. Clause ???. "Requirements for the safety of information in case of accidents" /p. ???.10 GOST ???-89 /3r3323261.
 
3r3151. ???. Clause ???. "Requirements for protection against the influence of external influences" /p. ???.11 GOST ???-89 /3r3323261.
 
???. Clause ???. “Patent Cleanliness Requirements” /p. ???.12 GOST ???-89 /3r3323261.
 
???. Clause ???. "Requirements for standardization and unification" /p. ???.13 GOST ???-89 /3r3323261.
 
???. Clause ???. “Additional Requirements” /p. ???.14 GOST ???-89 /3r32961.

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

 
3r3173. ???. The structure of the functional description
 
3r33177. ???. Types of functions in terms of their performance
 
3r3181. ???. Types of functions in terms of their role
 
3r3185. ???. Requirement, not script
 
3r3189. ???. Design of functional requirements
 
3r3193. ???. An example of the function description 3r332961.

 
7.3. Subsection 4.3. “Requirements for types of collateral” /p. ??? GOST ???-89 /
 
???. Clause ??? "Mathematical software" /p. ???.1 GOST ???-89 /3r3323261.
 
???. Clause ??? "Information support" /p. ???.2 GOST ???-89 /3r32961.
 
???. Clause ??? "Linguistic support" /p. ???.3 GOST ???-89 /3r32961.
 
???. Paragraph ??? "Software" /p. ???.4 GOST ???-89 /3r3323261.
 
???. Clause ??? "Technical Support" /p. ???.5 GOST ???-89 /3r32961.
 
???. Clause ??? "Metrological support" /p. ???.6 GOST ???-89 /3r32961.
 
???. Clause ??? "Organizational support" /p. ???.7 GOST ???-89 /3r3323261.
 
???. Clause ??? "Methodological support" /p. ???.8 GOST ???-89 /3r3323261.
 
???. Other types of security

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

 
9. Section 6 “Procedure for control and acceptance of the system” /p. 2.8 GOST ???-89 /
 
9.1. Subsection 6.1. "Types, composition, scope and test methods of the system and its components" /p. ??? GOST ???-89 /3r32961.
 
9.2. Subsection 6.2. "General requirements for acceptance of work in stages" /p. ??? GOST ???-89 /3r32961.
 
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 ???-89 /

 
11. Section 8 “Documentation Requirements” /p. ??? GOST ???-89 /
 
11.1. Features of the structure of the documentation
 
11.2. Features of the design of the list of documents
 
11.3. An example of a list of documents 3r332961.
 
12. Section 9 "Sources of development" /p. ??? GOST ???-89 /

 
Conclusion
 
 
 
3r3302.
 

1. What is Article 3r3323228 about?
 
Often you hear the opinion that drawing up 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 entire 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 ???-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”. See my article for details. Pre-project survey in the development of an information system .
 
 
ATTENTION: THE PURPOSE OF THIS ARTICLE IS NOT TO REPLACE GOST, AND TO EXPLAIN SOME POSITIONS.
 
3r33333.
 
2. Characteristics of the Terms of Reference according to GOST 34


 
3r33338.
 

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 ???-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 GOST texts, nor federal laws, or dissertations are easy to understand for a mere mortal, then it is quite possible to read and delve into it, although often not the first time.
 
 
Indeed, the standard uses many obscure terms. What, for example, is meant by linguistic software? To clarify the concepts used, refer to GOST ???-90 “Information Technology (IT). Set of standards for automated systems. Automated systems. Terms and Definitions".
 
system concept. , we talked about this at the very beginning of the article.
 
Secrets of successful design of IP (information system) on the example of the construction of a hospital
0.
and [u] Pre-project survey in the development of an information system .
 
 
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 left by the survey results.
 
Human Interface Guidelines for iOS.
 
 
You can also give the maximum number of transitions (clicks) in the implementation of certain functions that are especially important for us, the average speed of data retrieval, etc.
 

 
3r31676. ???. The structure of the functional description
 
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 entry as one of the tasks. And we can write the password entry procedure as a separate function: checking for correctness, password recovery, display of prompts, etc. The complex is what unites 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 now often called CTZ - private technical task).
 
Although such issues are best dealt with before drawing up the technical task .
 
3r31686.
 

8. Section 5 "Composition and content of work on the creation (development) of the system" /p. 2.7 GOST ???-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 implementation 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).
 
Design, working or reporting documentation.
 
Responsible (who performs this work: the 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
 
Work content
 
The order of acceptance and documents
 
Dates
 
Responsible
 
 
 
1. Drafting of technical specifications (TZ)
 
Development of functional and non-functional requirements for the system 3r32882.  
The statement of TZ
 
60 days from the date of prepayment. The customer provides the first option for approval after 45 days
 
Development - Artist; approval - Customer
 
 
 
3r31780. 2. Technical design (TP)
 
Developing system operation scripts and web application interface layouts. 3r-32882.  
Approval of the document "Description of automated functions" 3r-32882.  
3r31780. 60 days from the date of approval of the TZ. The customer provides the first option for approval after 45 days
 
Artist
 
 
 
Development of corporate identity for website and mobile applications
 
corporate identity statement.  
Customer
 
 
 
Website content development (public web application) 3r-32882.  
The approval of the filling of r3r32882.  
Customer
 
 
 
Development of a design layout of a public web application
 
Approval of the design layout
 
Artist
 
 
 
Development of design layouts of public mobile applications
 
Approval of the design layout
 
Artist
 
 
 
Selection of SMS aggregator, preparation of exchange rules with the server module 3r-32882.  
Approval of the design layout
 
The customer, according to the recommendations of the Contractor
 
 
 
3. Development of the software part 3r32882.  
Development of the server module, the data storage module and the file storage module 3r32882.  
Acceptance is carried out during the test
 
100 days from the date of approval of the TP
 
Development - Customer. The contractor provides the data for filling reference books
 
 
 
Development admin panel
 
Acceptance is carried out during the test
 
Customer
 
 
 
Development of a static website (public web application)
 
Acceptance is carried out during the test
 
Artist
 
 
 
Development of integration of a public web application and server module 3r32882.  
Acceptance is carried out during the test
 
Artist
 
 
 
Development of iOS mobile applications (including integration with the server module) 3r-32882.  
Acceptance is carried out during the test
 
Artist
 
 
 
Development of mobile Android applications (including integration with the server module)
 
Acceptance is carried out during the test
 
Artist
 
 
 
Development of working and operational documentation
 
Approval of the documents:
 
- “Program and methods of preliminary autonomous tests”.
 
- “Program and methods of preliminary complex tests”.
 
- “Program of trial operation” 3r-32882.  
Artist
 
 
 
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 repeated tests until the elimination of deficiencies 3r332882.  
Approval of the preliminary autonomous test report
 
14 days from the date of completion of the development
 
Performer - conducting tests. The customer is preparing the infrastructure and organizing the tests
 
 
 
5. Preliminary complex testing
 
- Check the interaction with adjacent external systems.
 
- Improvements and repeated tests until the elimination of deficiencies 3r332882.  
Approval of the protocol of preliminary complex tests
 
14 days from the date of completion of autonomous tests
 
Performer - conducting tests. The customer is preparing the infrastructure and organizing the tests
 
 
 
6. Preparation for trial operation 3r3r88282.  
- Deployment of the system on industrial servers.
 
- Implementation of a complex of preparatory works (for more details, see clause 7 Requirements for the composition and content of works on preparing the automation object for commissioning the system) 3r32882.  
Acceptance is missing
 
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 the OE 3r-33882.  
 
 
7. Trial operation 3r332882.  
- Operation involving a small number of participants (several auctions among friends).
 
- Improvements and repeated tests until the elimination of deficiencies 3r332882.  
Protocol of trial operation (log of errors and results of their correction)
 
30 days
 
Artist - elimination of deficiencies. The customer is conducting the OE
 
 
 
8. Entering into industrial (commercial) operation 3r32882.  
See preparatory stage for trial operation
 
Acceptance is missing
 
Preparation of the program part and filling out reference books - 10 days 3r-32882.  
Preparation of the program part and filling out reference books - the Customer. The contractor performs the organization of industrial operation 3r-32882.  
 
 
9. Industrial (commercial) operation
 
Industrial operation
 
Acceptance is missing
 
 
 
 
 
 
3r32087.
 

9. Section 6 “Procedure for control and acceptance of the system” /p. 2.8 GOST ???-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.
 
5 "The composition and content of work on the creation (development) of the system" 3r332370. . 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: 3r332945.  
 
 
Reorganization, recruitment of new staff, if necessary.
 
Training.
 
For web applications: development of common sections of the site and user agreement (consent to the processing of personal data).
 
Filling out reference books and other background information.
 
Transfer data from the old system.
 
Deploying the system on industrial servers.
 
Setting integration with related systems.
 
Setting up an access system and creating accounts.
 
 
 
Some of these items should be described in great detail, especially with regard to the transfer of data and the filling of directories.
 
[u] Excel spreadsheet
, in which with the help of filters you can display at once 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 software (we talked about the types of software 3-3?38? above 3-3?961.). In RD 50-???-9? 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 ???-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 estimates are highlighted separately.
 
The compilers of GOST ???-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.
 
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.
 
+ 0 -

Add comment