GOST Standards for Automated Systems

Key ideas#

What GOST 34 and GOST 19 are#

“GOST” is an abbreviation of the Russian term for “state standard”. Two series matter to analysts:

• GOST 34 is a family of standards for automated systems. In this family, an automated system includes the staff who operate it as well as hardware and software, so the standards cover people and organization, not only code.
• GOST 19 is an older family for software documentation, known as the Unified System for Program Documentation.

You meet them on projects for government bodies and large or state-owned enterprises in Russia and other CIS countries, where contracts and procurement rules refer to them. Maglinets’s course (2007) describes GOST 34.602-89 as still required for Russian government contracts. Standards are revised from time to time, so always check which standard and edition your contract actually cites.

GOST 19.201-78: the general technical specification#

This earlier standard sets the content and layout of a technical specification (often called a “TZ”) for a software program. Maglinets describes GOST 34.602-89 as a more detailed version of the same idea, adapted to automated systems.

GOST 34.601-90: stages, and a concept stage with alternatives#

This standard defines the stages of creating an automated system. After requirements are formed, it includes a separate concept development stage: study the organization being automated, carry out any research needed, develop variants of the system concept, and report on the work.

The distinctive point is that the concept must offer several alternatives. Each variant is assessed for the resources it needs and the functionality it provides, with its advantages and drawbacks. The concept also covers quality estimates, acceptance conditions and the expected effect, and the report justifies the recommended variant. Maglinets explains the logic: customers find it hard to invent a vision from scratch, but they can choose well among argued options. Most Western methods, such as RUP and MSF, produce a single vision document instead.

GOST 34.602-89: the technical specification for an automated system#

The specification is organized into nine main sections, described here in summary:

1. General information: the parties, legal details and funding.
2. Purpose and goals: which indicators of the organization the system must improve, and how achievement will be judged. Maglinets notes that this section is often treated as a formality, although it is where business requirements belong.
3. Characteristics of the objects being automated: organizational and management structure, sites and branches.
4. Requirements for the system (see below).
5. Composition and content of the work: methodology, stages and phases.
6. Control and acceptance: roles of customer and developer in testing, test scenarios, acceptance criteria.
7. Preparing the organization for commissioning: staffing, training and organizational changes needed before go-live.
8. Documentation requirements.
9. Development sources: existing documents the work builds on.

Appendices may include a calculation of expected efficiency and an assessment of the system’s technical level.

Three classes of requirements#

Section 4 divides requirements into three classes:

• Requirements for the system as a whole: structure, operating modes, staff numbers and skills, reliability, safety, ergonomics, operation and maintenance, protection against unauthorized access, data preservation in failures, protection from external effects, patent clearance, and standardization.
• Requirements for functions (tasks): a list of functions tied to subsystems and implementation phases, timing, quality for each function (output format, accuracy, execution time, reliability of results), and failure criteria.
• Requirements for types of support: mathematical, information, linguistic, software, technical, metrological, organizational and methodological.

Mapping to Western documents#

Maglinets’s assessment is that the standard remains sound in content because it is technology-neutral, and that it adds what an SRS or Vision lacks: explicit acceptance, preparation of the organization, and types of support.