GOST 19 201 78 example technical specifications. Requirements for information structures and solution methods

The terms of reference are the source material for creating an information system or other product. That's why technical task(abbreviated as TK) must first of all contain the main technical requirements to the product and answer the question what this system should do, how to work and under what conditions.

As a rule, the stage of drawing up technical specifications is preceded by a survey of the subject area, which ends with the creation analytical report. It is the analytical report (or analytic note) forms the basis of the Technical Specifications document.

If the report can state the customer's requirements in general view and illustrated with UML diagrams, the technical specifications should describe in detail all functional and user requirements for the system. The more detailed the technical specifications are, the less controversial situations will arise between the customer and the developer during acceptance testing.

Thus, the technical specification is a document that allows both the developer and the customer to present the final product and subsequently check for compliance with the requirements.

The guiding standards for writing technical specifications are GOST 34.602.89 “Technical specifications for the creation of an automated system” and GOST 19.201-78 “Technical specifications. Requirements for content and design." The first standard is intended for developers of automated systems, the second for software (we discussed the difference between these series in the article “What is GOST”).

So, below we present a list and description of the sections that the technical specifications should contain in accordance with GOSTs.

GOST 19.201-78 Technical specifications. Requirements for content and design	GOST 34.602.89 Technical specifications for the creation automated system
1. Introduction	1. General information
2. Reasons for development
3. Purpose of development	2. Purpose and goals of creating the system
	3. Characteristics of the automation object
4. Requirements for a program or software product	4. System requirements
4.1. Requirements to functional characteristics	4.2. Requirements for functions (tasks) performed by the system
	4.1. Requirements for the system as a whole
	4.1.1. Requirements for the structure and functioning of the system
	4.1.3. Destination indicators
4.2. Reliability requirements	4.1.4. Reliability requirements
	4. 1.5. Security requirements
	4. 1.6. Requirements for ergonomics and technical aesthetics
4.3. terms of Use	4.1.2. Requirements for the number and qualifications of system personnel and their mode of operation
	4. 1.9. Requirements for protecting information from unauthorized access
	4. 1.10. Requirements for the safety of information in case of accidents
	4. 1.11. Requirements for protection from influence external influences
	4. 1.12. Requirements for patent purity
	4. 1.13. Requirements for standardization and unification
4.4. Requirements for the composition and parameters of technical means	4. 1.8. Operating requirements maintenance, repair and storage of system components
4.5. Requirements for information and software compatibility
4.6. Labeling and packaging requirements
4.7. Transportation and storage requirements	4. 1.7. Transportability requirements for mobile systems
4.8. Special Requirements	4. 1.14. Additional requirements
	4.3. Requirements for types of collateral
5. Requirements for program documentation	8. Documentation requirements
6. Technical and economic indicators
7. Stages and stages of development	5. Composition and content of work to create the system
8. Procedure for control and acceptance	6. Procedure for control and acceptance of the system
	7. Requirements for the composition and content of work to prepare the automation object for commissioning of the system
	9.Sources of development

So, the Technical Specifications document should, in fact, reflect all the requirements for the designed product, identified at the stage of analytical research of the automation object.

Based on the table above, we can highlight the main sections of the technical specifications:

• General information about the system (program);
• Purpose, goals and objectives of the system (program);
• System requirements (functional requirements, user requirements, requirements for the system as a whole, etc.);
• Requirements for types of security;
• Documentation requirements;
• Stages and stages of development;
• The procedure for control and acceptance of the system (program).

General information
This section of the Technical Specification document must contain the full name of the system and all abbreviations that will be used in developing the documentation.

Example:

"IN this document The information system being created is called “Single window of access to educational resources”, abbreviated as SW.
The Single Window for Access to Educational Resources system may be referred to as the Single Window or the System later in this document.”

Also here you should include subsections providing details of the organizations involved in the development (Customer and Contractor).

The subsection “Bases for development” of the Technical Specifications document lists the main documents on the basis of which this work is carried out. For example, for a system commissioned by the Government of a country or another State body, laws, decrees and government regulations must be indicated.

An integral part of the Technical Specifications document should also be a list of terms and abbreviations. It is better to present terms and abbreviations in the form of a table with two columns “Term” and “Full Form”.

Terms and abbreviations are arranged in alphabetical order. First of all, it is customary to decipher Russian-language terms and abbreviations, then English-language ones.

Purpose and goals of creating the system

This section of the Technical Specification document must contain the purpose and goals of creating the system.

Example:

“The information system “Single Window of Access to Educational Resources” is designed to provide users with complete, timely and convenient information regarding the education system of the Russian Federation and organizations performing the function of educational institutions.

The main goal of the System is to create a unified information environment and automate business processes of educational institutions Russian Federation.

The creation of the Single Window information system should ensure:

• providing users wide range information resources;
• level up information security;
• increasing the efficiency of educational institutions and departments by optimizing a number of business processes;
• increasing the efficiency of the process of interaction between information systems and services within the department.

The creation of the System will reduce operating costs as a result of increasing the efficiency of the department.”

System requirements

This section of the Terms of Reference document is intended to describe the main functional requirements systems. This is the most an important part technical specifications, since it will be your main argument in disputes with the Customer in the process of putting the system into operation. Therefore, it is necessary to approach its writing very carefully.

The Terms of Reference document must contain all the requirements identified at the stage of analysis of the automation object. It is best to highlight the main business processes, which should be disclosed through a description of functional requirements.

Example:

“4.1 Business process “Providing information about educational institutions of the Russian Federation

The following participants are identified in this business process:

Moderator is an employee of the department who is part of the service personnel Systems responsible for the correctness of the data provided

The user is a citizen who needs to receive information about the work of educational institutions of the Russian Federation.

4.1.1 Registration educational institution in system

Registration of an educational institution of the Russian Federation is carried out by the responsible employee of the institution (“Government Decree ...”).

The process of registering an educational institution includes the following steps:

• The author creates a record about the organization;
• The author enters the organization's data;
• The system checks for a license for a given organization

• If the license exists in the database, the System sends a message to the Author about successful registration;
• If the license is not found in the database, the System sends a message to the Author about the absence of a license for this organization.”

If time permits, the information given in this section, should be more fully disclosed in the appendix to the Terms of Reference document. In the appendix to the technical specifications, you can provide a screen form and below describe all the events that are present on it (creation, viewing, editing, deleting, etc.).

Requirements for the system as a whole include a disclosure of its architecture with a description of all subsystems. This part of the Terms of Reference should describe the requirements for integrating the system with other products (if any). Further, the terms of reference should include:

• requirements for system operating modes
• destination indicators
• reliability requirements
• safety requirements
• requirements for the number and qualifications of personnel and their work schedule
• information protection requirements
• requirements for the safety of information in case of accidents
• patent clearance requirements
• requirements for standardization and unification
• etc.

Requirements for types of collateral

This section of the Technical Specification document should contain requirements for mathematical, information, linguistic, software, technical and other types of support (if any).

Documentation requirements

The “Documentation Requirements” section of the technical specification includes a list of design and operational documents that must be provided to the customer.

This section of the technical specification is as important as the description of the functional requirements, so you should not limit yourself to the phrase “The Customer must be provided with all documentation in accordance with GOST 34.” This means that you must provide the entire package of documents including the “Form”, “Passport”, etc. Most of the documents from the list specified in GOST 34.201-89 are not needed by either you or the customer, so it is better to immediately agree on the list at the stage of developing the Technical Specifications document.

The minimum package of documents usually includes:

• Technical task;
• Statement of preliminary (technical) design;
• Explanatory note To Technical project;
• Description of the organization information base;
• User guide;
• Administrator's Guide;
• Test program and methodology;
• Acceptance test report;
• Certificate of completion

It is better to present the list of documents in the technical specifications in the form of a table, which indicates the name of the document and the standard on the basis of which it should be developed.

Stages and stages of development

This section of the Terms of Reference document should provide information about all stages of work that must be carried out.

The description of the stage should include the name, timing, description of work and the final result.

Procedure for control and acceptance of the system

In this section of the Technical Specifications document, it is necessary to indicate the document on the basis of which acceptance tests should be carried out.

If necessary, the technical specification can be supplemented with other sections, or reduced by removing inappropriate items.

When changing the structure of the technical specifications, in order to avoid conflict situations, it must be agreed upon with the customer before the document is developed.

TECHNICAL TASK.

GOST 19.201-78

STATE STANDARD OF THE USSR UNION

TECHNICAL TASK. REQUIREMENTS FOR CONTENT AND DESIGN United System for Program Documentation. Technical specification for development. Requirements to contents and form of presentation

GOST 19.201-78

Resolution State Committee USSR according to standards of December 18, 1978 No. 3351, the introduction date is established

from 01/01/1980

This standard establishes the procedure for constructing and completing technical specifications for the development of a program or software product for computers, complexes and systems, regardless of their purpose and scope.

1. GENERAL PROVISIONS

The information part (annotation and content), the change registration sheet may not be included in the document.

1.3. To make changes or additions to the technical specifications at subsequent stages of development of a program or software product, an addition to it is released. Coordination and approval of additions to the technical specifications are carried out in the same manner as established for the technical specifications.

1.4. The terms of reference must contain the following sections:

name and scope of application;

basis for development;

purpose of development;

technical requirements for a program or software product;

technical and economic indicators;

stages and stages of development;

control and acceptance procedure;

applications.

Depending on the characteristics of the program or software product, it is possible to clarify the content of sections, introduce new sections, or combine individual ones.

2. SECTION CONTENTS

2.1. In the section “Name and scope” indicate the name, brief description the scope of application of the program or software product and the object in which the program or software product is used.

2.2. The section “Basis for development” should indicate:

document(s) on the basis of which the development is carried out;

the organization that approved this document and the date of its approval;

name and (or) symbol development topics.

2.3. The section “Purpose of development” must indicate the functional and operational purpose of the program or software product.

2.4. The section “Technical requirements for a program or software product” should contain the following subsections:

requirements for functional characteristics;

reliability requirements;

terms of Use;

requirements for the composition and parameters of technical means;

requirements for information and software compatibility;

labeling and packaging requirements;

requirements for transportation and storage;

special requirements.

2.4.1. The subsection “Requirements for functional characteristics” must indicate the requirements for the composition of the functions performed, the organization of input and output data, timing characteristics, etc.

2.4.2. The subsection “Reliability requirements” must indicate the requirements for ensuring reliable operation (ensuring sustainable functioning, control of input and output information, recovery time after a failure, etc.).

2.4.3. The subsection “Operating conditions” must indicate operating conditions (ambient temperature, relative humidity and so on. for selected types of storage media), which must ensure the specified characteristics, as well as the type of service, required amount and personnel qualifications.

2.4.4. In the subsection “Requirements for the composition and parameters of technical means” indicate required composition technical means indicating their main technical characteristics.

2.4.5 The subsection “Requirements for information and software compatibility” should indicate the requirements for information structures at the input and output and solution methods, source codes, programming languages.

Information and programs should be provided as necessary.

2.4.6. In the subsection “Labelling and packaging requirements” in general case indicate requirements for software product labeling, packaging options and methods.

2.4.7. The subsection “Requirements for transportation and storage” must indicate transportation conditions for the software product, storage locations, storage conditions, storage conditions, storage periods in various conditions.

2.5. In the section “Technical and economic indicators” the following should be indicated: approximate economic efficiency, estimated annual demand, economic advantages of the development compared to the best domestic and foreign samples or analogues.

2.6. In the section “Stages and stages of development”, the necessary stages of development, stages and content of work are established (list program documents, which must be developed, agreed upon and approved), and, as a rule, the development time frame determines the performers.

2.7. The section “Procedure for control and acceptance” must indicate the types of tests and General requirements for acceptance of work.

2.8. In the appendices to the technical specifications, if necessary, the following is given:

a list of research and other works justifying the development;

algorithm diagrams, tables, descriptions, justifications, calculations and other documents that can be used during development;

other development sources.

This standard establishes the order of construction and design terms of reference for the development of a program or software product for computers, complexes and systems, regardless of their purpose and scope.

The standard fully complies with ST SEV 1627-79.

Design rules

The terms of reference are drawn up in accordance with GOST 19.106-78 on sheets of format 11 and 12 in accordance with GOST 2.301-68, as a rule, without filling out the fields of the sheet. Sheet (page) numbers are placed at the top of the sheet above the text.

Approval Sheet and Cover Sheet

Approval sheet and title page drawn up in accordance with GOST 19.104-78.

The information part (annotation and content), the change registration sheet may not be included in the document.

Changes and additions

To make changes or additions to the technical specifications at subsequent stages of development of a program or software product, an addition to it is released. Coordination and approval of additions to the technical specifications are carried out in the same manner as established for the technical specifications.

Take into account all the details on initial stage development is impossible. On practice specified approach used quite often. In the section “Stages and stages of development”, the possibility of making changes and additions to the technical specifications should be clearly indicated: “The content of sections of this technical specification can be changed and supplemented by agreement with the Customer.”

Composition of sections of technical specifications

The terms of reference must contain the following sections:

introduction; reasons for development; purpose of development; requirements for a program or software product; requirements for program documentation; technical and economic indicators; stages and stages of development; control and acceptance procedure; Applications may be included in the technical specifications.

Depending on the characteristics of the program or software product, it is possible to clarify the content of sections, introduce new sections, or combine individual ones. Strictly in agreement with the Customer. The Customer’s consent must be reflected in the text of the technical specifications.

As a training program, we will use a real program with a graphical user interface, which provides the ability to perform several template functions (for example, a simple text editor).

Introduction

The section indicates the name, a brief description of the scope of application of the program or software product and the object in which the program or software product is used.

The basic rule for working with text is detailing, breaking the text into structural units, subsections, paragraphs and subparagraphs. The table of contents of the text will have a clear structure that makes it easy to find the required material. The text of the document will become structured and easy to read. Create subsections:

Program name

Name – “Text editor for working with rtf files.”

Brief description of the field of application

The program is intended for use in specialized departments at the Customer's facilities.

Content individual items not always obvious. If you have any difficulties, you should approach them formally. Corrections can be made at the stage of approval of the technical specifications with the Customer.

Reasons for development

The section should indicate:

Document(s) on the basis of which the development is carried out; the organization that approved this document and the date of its approval; name and (or) symbol of the development topic.

The subsection should contain the information contained in the Agreement.

Basis for development

The basis for the development is Agreement (letter, etc.) No. 000 dated January 1, 2001 (incoming No. such and such from such and such). The agreement was agreed upon with the Director of the State Unitary Enterprise “Spetstyazhmontazhstroyselkhozavtomatika” Ivanov Petr Ivanovich, referred to as further by the Customer, and approved General Director Blumkins Ivan Aronovich, hereinafter referred to as the Executor, such and such March 2008.

It is convenient to use the “General Information” section of GOST 34.602-89, since the developer has every right supplement and delete sections of the technical specifications at your discretion. At the same time, the information specified above is contained in the Agreement. Whether they should be included in the Terms of Reference depends on the specific case.

Name and symbol of the development topic

The name of the development topic is “Development text editor for working with rtf files."

The designation of the development topic (topic code) is “RTF-007”.

Purpose of development

The section must indicate the functional and operational purpose of the program or software product.

Functional purpose

The functional purpose of the program is to provide the user with the opportunity to work with text documents in rtf format.

The subsection must indicate “enlarged” functional purpose programs. Details - list of functions, etc. - will be given below in the relevant sections.

Operational purpose can be interpreted quite broadly. Where, how, by whom, with what should the program be used?

Tires of the same size can be successfully used on Zhiguli and Volga vehicles, but not on KamAZ. And vice versa. But for each specific rubber size, its operational purpose can be determined.

Let's use a formal approach:

Operational purpose

The program must be used in specialized departments at the Customer's facilities.

The end users of the program must be employees of specialized departments of the Customer's facilities.

Requirements for a program or software product

The section should contain the following subsections:

Requirements for functional characteristics; reliability requirements; terms of Use; requirements for the composition and parameters of technical means; requirements for information and software compatibility; labeling and packaging requirements; requirements for transportation and storage; special requirements.

If there are standards containing general (technical) requirements for a program, system or product, for example, “GOST. Automated information and measurement systems. General (technical) requirements”, the development of technical specifications is significantly simplified. Most of the contents of the specified standard are simply rewritten into the technical specifications.

Functional requirements

The subsection must indicate the requirements for the composition of the functions performed, the organization of input and output data, timing characteristics, etc.

Requirements for the composition of functions performed

The program must provide the ability to perform the following functions:

1. functions for creating a new (empty) file.

2. functions for opening (loading) an existing file.

4. functions for editing the current file using buffer exchange operating system.

5. functions of saving the file with the original name.

6. functions of saving a file with a name different from the original one.

7. Functions for sending the contents of the current file by email using an external client mail program.

8. functions for displaying online information in string format (tips).

9. functions of the online help system.

10. functions for displaying the program name, program version, copyright and developer comments.

The cliché “to provide executability” applies to modern software developed using a graphical user interface. Specified software for the most part“idle”, waiting for operator action.

Requirements for organizing input data

The input data of the program must be organized in the form separate files rtf format corresponding to the specification.

Files of the specified format must be placed (stored) on local or removable media formatted according to the requirements of the operating system.

Any file of a different format, but with the rtf extension, should not be opened.

Files http:///file. rtf or ftp:///file. rtf should not be opened. If the file system is formatted as FAT32, files from local or removable media formatted, for example, in ext3 format should not be opened.

Requirements for organizing output data

See Requirements for organizing input data.

The requirements are the same as for organizing output data. This is the very case when both points of the technical specifications should be combined.

Timing requirements

There are no requirements for the timing characteristics of the program.

It should be clarified whether the Customer has requirements for the speed of the program, for example, how long it takes for the program to start, open and close files of a given size. If the Customer specifies specific numbers, you should play it safe and include in the requirements for the composition and parameters of technical equipment a supercomputer costing $2,500 or more. True, such an amount will have to be justified. If time characteristics are not important for the Customer, it is necessary to write about the waiver of requirements for time characteristics (see the wording above).

Reliability requirements

The subsection must indicate the requirements for ensuring reliable operation (ensuring stable operation, monitoring input and output information, recovery time after a failure, etc.).

Reliability is a delicate and very dangerous thing. But the list of functions and their failure modes, according to clause 1.3.2. GOST 24.701-86, must be drawn up by the Customer and agreed with the Contractor. Most likely, it will not be possible to expect anything intelligible from the Customer. It is worth explaining to the Customer that the reliable operation of the program depends not so much on the Contractor, but on the reliability of the hardware and operating system, and also to offer the Customer a number of stringent measures to increase the reliability and stability of the program.

Requirements for ensuring reliable (stable) operation of the program

Reliable (sustainable) operation of the program must be ensured by the Customer’s implementation of a set of organizational and technical measures, the list of which is given below:

Organization of uninterruptible power supply of technical equipment; using a licensed software; regular implementation of the recommendations of the Ministry of Labor and social development of the Russian Federation, set out in the Resolution of 01.01.01 “On approval of intersectoral standard standards time to work on service PCs and office equipment and software support"; regular compliance with GOST requirements. Information protection. Testing software for the presence of computer viruses.

You can add a dozen more to the list. regulatory documents. During the initial approval of the technical specifications, the Customer will most likely begin to show a tendency to compromise.

A more humane approach is possible. Reliability (of a system, however, according to the same GOST) can be considered the failure-free performance of a certain i-th function during a specific time interval. We suggest that the Customer consider the criterion for reliable operation of the program next indicator: The customer opens and closes the file 100 times within an hour. If the program does not fail within the specified time interval, the reliability requirements are considered met.

If the Customer is finally convinced that reliability depends not so much on the Contractor, but on the reliability of the hardware and operating system, and gives up, the following phrase must be written in the section:

There are no requirements to ensure reliable (stable) operation of the program.

Recovery time after failure

Recovery time after a failure caused by a power failure of technical equipment (other external factors), not a fatal failure (not crash) of the operating system, should not exceed so many minutes, provided that the operating conditions of the hardware and software are observed.

The recovery time after a failure caused by a malfunction of hardware or a fatal failure (crash) of the operating system should not exceed the time required to eliminate hardware malfunctions and reinstall software.

Scroll emergency situations also drawn up by the Customer and agreed upon with the Contractor. In fact, this is the time to reboot the operating system, if the failure is not fatal, is not caused by the crash of the operating system or failure of hardware.

Failures due to incorrect operator actions

Program failures are possible due to incorrect actions of the operator (user) when interacting with the operating system. To avoid program failures for the above reason, you should ensure that the end user can work without granting him administrative privileges.

terms of Use

The subsection must indicate operating conditions (ambient temperature, relative humidity etc. for selected types of storage media), which must ensure the specified characteristics, as well as the type of service, the required number and qualifications of personnel.

Climatic operating conditions

Climatic conditions operation, during which the specified characteristics must be ensured, must satisfy the requirements for technical means in terms of their operating conditions.

The program will work perfectly from plus 5 to plus 35 °C with a relative humidity of 90% and an atmospheric pressure of 462 mm. rt. Art., since such conditions approximately correspond to the operating conditions of modern computers non-industrial execution. But, as soon as the specifications are specific and the task is approved, the Customer gets an excellent chance to force the Contractor to conduct climate tests in in full at the expense of the Contractor.

Requirements for types of services

See Requirements for ensuring reliable (stable) operation of the program.

The program does not require any types of maintenance.

Types of maintenance should be borrowed from the subsection “Requirements for ensuring reliable (sustainable) operation.”

If the Customer, during the approval of the technical specifications, refers to a lack of resources or desire to carry out all types of maintenance on our own, it makes sense to offer the development of technical specifications for software support for some money a separate agreement. If it refuses, the program should be considered unsupported.

Requirements for the number and qualifications of personnel

The minimum number of personnel required to operate the program must be at least 2 staffing units– system administrator and end user programs - operator.

The system administrator must have a higher education degree specialized education and certificates from the operating system manufacturer. The list of tasks performed system administrator, should include:

The task of maintaining the functionality of technical means; tasks of installation (installation) and maintaining the functionality of system software - the operating system; the task of installing a program.

The end user of the program (operator) must have practical skills in working with the graphical user interface of the operating system.

Personnel must be certified for qualification group II in electrical safety (for working with office equipment).

In the absence of the most key (bold) phrase in the approved technical specifications, the Customer has the right to request that the Contractor develop a manual for operating the graphical user interface of the operating system, citing the fact that the operator “cannot cope” with the program.

Personnel without II qualification group according to electrical safety, has no right to even come close to a personal computer and office equipment.

Requirements for the composition and parameters of technical means

The subsection indicates the required composition of technical means, indicating their main technical characteristics.

You should select equipment no worse than the one on which the development will be carried out. It is logical to request that the Customer provide the equipment no later than specified period. It's about, of course, about the computer.

The hardware must include an IBM-compatible Personal Computer(PC), including:

Pentium-1000 processor with a clock frequency of 10 GHz, no less; motherboard with FSB, GHz - 5, no less; RAM volume, Tb - 10, not less; and so on…

Requirements for information and software compatibility

The subsection must indicate the requirements for input and output information structures and solution methods, source codes, programming languages ​​and software used by the program.

If necessary, it should be provided data protection and programs.

Requirements for information structures and solution methods

The information structure of the file must include text containing markup required by the rtf format specification.

There are no requirements for information structures (files) at the input and output, as well as for solution methods.

Requirements for source codes and programming languages

The source codes of the program must be implemented in C++. The Borland C++ Buider environment should be used as an integrated program development environment.

Requirements for software used by the program

System software used by the program must be a licensed localized version of the operating system. You can use such and such service pack.

Requirements for the protection of information and programs

There are no requirements for the protection of information and programs.

Such demands should be avoided. It is possible to ensure a certain level of protection of information and programs, but it is impossible to ensure security. The customer will most likely realize this and will not persist.

Labeling and packaging requirements

The program is supplied as a software product - on a distribution (external optical) medium (CD).

We are talking about labeling and packaging of distribution media - a software product (see GOST 19.004-80).

Labeling requirement

The software product must be marked with the designation trademark developer company, type (name), version number, serial number, date of manufacture and number of the certificate of conformity of the Gosstandart of Russia (if any).

The marking must be applied to the software product in the form of a sticker, made by printing, taking into account the requirements of GOST 9181-74.

The quality of the marking is checked using the most sophisticated methods - first they try to wash off the marking with water, then with gasoline and other organic solvents. Let the printing company bear responsibility for poor quality labeling. The Contractor's task is to hide behind a certificate of conformity (request a certificate from printers).

Packaging requirements

The software product must be packaged in the packaging containers of the manufacturer.

Exactly the manufacturer. The contractor cannot and should not bear greater responsibility than the container manufacturer.

Packing conditions

Packaging of the software product must be carried out in closed ventilated areas at a temperature from plus 15 to plus 40 ° C and a relative humidity of no more than 80% in the absence of aggressive impurities in the environment.

The customer will receive the software product in proper appearance. If the software product is returned in improper condition (scratches, cracks and other defects), the Contractor will be able to make claims regarding the Customer’s violation of the packaging conditions and not accept the software product.

Packing procedure

Software products prepared for packaging are placed in containers, which are boxes made of corrugated cardboard (GOST 7376-89 or GOST 79 according to the drawings of the packaging manufacturer.

The software product is packaged using covers made of waterproof film with mandatory presence chemically non-aggressive desiccant (silica gel).

For filling free space Gaskets made of corrugated cardboard or foam plastic are placed in packaging containers.

Operating documentation must be placed in consumer packaging along with the software product.

Shipping documentation is placed on the top layer of the cushioning material - packing list And statement packaging.

Consumer packaging must be covered with adhesive tape 6-70 according to GOST.

Software products packaged in consumer packaging must be placed on a pallet, tied with tape to prevent loss of shape of the cargo, and packaged in polyethylene film M 0.2 to protect against moisture.

The pallet box must contain shipping documentation, including a packing list in accordance with GOST.

The dimensions of the cargo space must be no more than 1250 x 820 x 1180 mm.

NET weight - no more than 200 kg.

GROSS weight - no more than 220 kg.

The subsection shows the packaging procedure from a previously developed document for some technical equipment. It looks somewhat unusual in the context of a software product. To put it simply in Russian- complete banter.

Transportation and storage requirements

The subsection must indicate transportation conditions for the software product, storage locations, storage conditions, storage conditions, storage periods in various conditions.

The subsection provides the conditions for transportation and storage from a previously developed document for some technical equipment. This also applies to packaging requirements. It looks somewhat unusual in the context of a software product.

The customer has no right to violate the conditions of transportation and storage. The Contractor will be able to refuse to return the software product to the Customer, claiming that the appearance software product is a consequence of non-compliance with transportation and storage conditions.

Transportation and storage conditions

It is allowed to transport the software product in a transport container by all types of transport (including in heated sealed compartments of aircraft without distance restrictions). When transported in railway cars, the type of shipment is small, low-tonnage.

When transporting and storing the software product, protection from dust and precipitation must be provided. It is not allowed to tilt the software product. Climatic conditions for transportation are given below:

ambient air temperature, °C - from plus 5 to plus 50; atmospheric pressure, kPa - such and such; relative air humidity at 25 °C is such and such.

Special Requirements

The program must provide interaction with the user (operator) through a graphical user interface developed in accordance with the recommendations of the operating system manufacturer.

The developers of this standard looked to the future. There were no programs with a graphical user interface in those years.

Requirements for software documentation

The section should indicate the preliminary composition of the program documentation and, if necessary, special requirements for it.

The composition of the program documentation is provided for by GOST 19.101-77.

Preliminary composition of program documentation

The composition of the program documentation should include:

Technical task; test program and methods; system programmer's guide; operator's manual; list of operational documents.

The program and test methods will be required to show the Customer that the program developed by the Contractor meets the requirements of the agreed and approved technical specifications. After carrying out joint (acceptance) tests, the Customer and the Contractor will sign the Work Acceptance (Delivery) Certificate. And, thus, the work will be closed, the terms of the Agreement will be fulfilled.

According to clause 2.6. GOST 19.101-77 “It is allowed to combine individual species operational documents (except for the list of operational documents and the form). The need to combine these documents is indicated in the technical specifications. The merged document is assigned the name and designation of one of the merged documents.”

Software documentation included in preliminary list, must be issued in accordance with the requirements of GOST 19.106-78.

Technical and economic indicators

Estimated economic efficiency is not calculated.

The estimated number of program uses per year is 365 work sessions at one workplace.

The section should indicate: estimated economic efficiency, estimated annual demand, economic advantages of the development in comparison with the best domestic and foreign samples or analogues.

Let's say the Customer equips a dozen workstations with the program. The contractor demanded $1000 for the development. The customer could install on workstations software from a third company, costing $500 per distribution and $100 per license for each workstation.

Economic benefits of development

The economic advantages of the development in comparison with the best domestic and foreign analogues will be:

number of jobs

development

economic benefits

Stages and stages of development

The section establishes the necessary stages of development, stages and content of work (the list of program documents that must be developed, agreed upon and approved), as well as, as a rule, the development time frame and determines the performers.

Development stages and stages are regulated by GOST 19.102-77. GOST 19.102-77 does not prevent the exclusion of individual stages of work, as well as the combination individual stages works

Development stages

Development should be carried out in three stages:

Development of technical specifications; detailed design; implementation.

Development stages

At the stage of development of the technical specifications, the stage of development, coordination and approval of this technical specification must be completed.

At the detailed design stage, the following stages of work must be completed:

Program development; development of program documentation; testing the program.

At the implementation stage, the development stage must be completed - preparation and transfer of the program.

At the stage of development of technical specifications, the following work must be performed:

Formulation of the problem; determination and clarification of requirements for technical means; determining program requirements; determining the stages, stages and timing of the development of the program and documentation for it; choice of programming languages; coordination and approval of technical specifications.

At the program development stage there should be job done on programming (coding) and program debugging.

At the stage of developing program documentation, the development of program documents must be carried out in accordance with the requirements of GOST 19.101-77 with the requirement of clause Preliminary composition of program documentation of this technical specification.

During the testing phase of the program, the following types of work must be performed:

Development, coordination and approval of a program (in GOST, it seems, there is a typo - “order”) and test methods; carrying out acceptance tests; adjustment of the program and program documentation based on test results.

At the stage of preparation and transfer of the program, work must be completed to prepare and transfer the program and program documentation for operation at the Customer’s facilities.

Control and acceptance procedure

The section should indicate the types of tests and general requirements for acceptance of work.

Types of tests

Acceptance tests must be carried out at the Customer’s site within the deadlines...

Acceptance tests of the program must be carried out in accordance with the Program and test methods developed (no later than such and such a period) by the Contractor and agreed upon by the Customer.

The Customer and the Contractor document the progress of acceptance tests in the Test Report.

General requirements for acceptance of work

Based on the Test Protocol, the Contractor, together with the Customer, signs the Program Acceptance and Commissioning Certificate.

Applications

In the appendices to the technical specifications, if necessary, the following is given:

a list of research and other works justifying the development; algorithm diagrams, tables, descriptions, justifications, calculations and other documents that can be used during development; other development sources.

If there is, why not bring it. And be sure to post a list of GOSTs on the basis of which development should be carried out. For example:

GOST 19.201-78. Technical specifications, requirements for content and design; and so on...

Recently they approached me to advise me on standards for writing technical specifications (TOR) for the development of automated systems (AS) and software (software). So I think, now I’ll go to Yandex, find a suitable article and send it. But it was not there! One article listing standards for technical specifications, including templates and examples ready-made documents, I did not find. You'll have to make this article yourself...

And so, the main standards, methodologies and bodies of knowledge that mention TK or SRS (Software (or System) Requirements Specification):

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

GOST 34

GOST 34.602-89 The terms of reference for the creation of an automated system regulates the structure of the technical specifications for the creation of the SYSTEM, which includes software, hardware, people who work with the software, and automated processes.

According to GOST 34, the technical specification must include the following sections:

1. General information
2. Purpose and goals of creation (development) of the system
3. Characteristics of automation objects
4. System requirements
5. Composition and content of work to create the system
6. Procedure for control and acceptance of the system
7. Requirements for the composition and content of work to prepare the automation object for commissioning of the system
8. Documentation requirements
9. Development sources

When developing technical specifications for government projects Customers, as a rule, require compliance with this particular standard.

GOST 19

“GOST 19.xxx one system program documentation (ESPD)” is a complex state standards, establishing interconnected rules for the development, design and circulation of programs (or software) and program documentation. Those. This standard applies specifically to software development.
According to GOST 19.201-78 Technical specifications, requirements for content and design, the technical specifications must include the following sections:

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

Naturally, GOST 34 (and 19) are already outdated, and I don’t like to use them, but with the correct interpretation of the standards, you can get good technical specifications, see Conclusion.

IEEE STD 830-1998

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

Describes the content and quality characteristics correctly drawn up specification of requirements for software(SRS) and provides several SRS templates. This recommended practice is intended to establish requirements for the software being developed, but can also be used to assist in the selection of proprietary and commercial software products.

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

1. Introduction

• 1. Purpose
• 2. Scope
• 3. Definitions, acronyms and abbreviations
• 4. Links
• 5. Brief overview

2. General description

• 1. Product interactions (with other products and components)
• 2. Product features (brief description)
• 3. User characteristics
• 4. Limitations
• 5. Assumptions and dependencies

3. Detailed requirements (can be organized in different ways, e.g. like this)

• 1. Requirements for external interfaces
  • 1. User Interfaces
  • 2. Hardware interfaces
  • 3. Software interfaces
  • 4. Interaction interfaces
• 2. Functional requirements
• 3. Performance requirements
• 4. Design Constraints (and References to Standards)
• 5. Non-functional requirements (reliability, availability, security, etc.)
• 6. Other requirements

4. Applications
5. Alphabetical index

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

Well, whoever read to the end - there’s a bonus: an example of technical specifications that I wrote many years ago (now I haven’t been working as an analyst for a long time, and others are more successful examples prohibits NDA from being made publicly available).

• Presentation by Yuri Buluy Classification of software requirements and its representation in standards and methodologies.
• Analysis of requirements for automated information systems. Lecture 11: Documenting requirements.
• Rules for drawing up Software requirements specification (read along with comments)
• Examples of technical specifications and other documentation for the development of AS for the Ministry of Economic Development
• GOST management style. Article by Gaperton proper operation from technical specifications according to GOST
• Business Analyst Document Templates from