At this stage, the requirements for the system are formalized and approved, which largely determines the final result. The document must fully comply with GOST 34.602-89 “Technical specifications for the creation automated system" Below is an example of the contents of this document. A possible version of the technical specification is highlighted in italics.

1. General information

1.1 Full name of the system and its symbol

Automated control system for the process of mashing and filtering beer wort.

The code consists of the enterprise code, the serial number of the document being developed and its designation, for example, KKB. 123456. 001ТЗ.

1.2 Number of the agreement between the organization Developer and the organization Customer, on the basis of which the development of automated process control systems is carried out.

1.3 Names of the organizations of the System Developer and Customer and their details.

1.4 Time frame for completing the work to create the system

The timing of the start of the work stages is determined by the beginning of financing and receipt of relevant initial data.

Stages of work:

1. Design work – 2 months.

2. Complete set and manufacturing of equipment – ​​3 months.

3. Testing the software together with the equipment at the performer’s stand. Delivery of equipment to the Customer – 1 week.

4. Supervised installation work on automated process control system equipment – ​​1 week.

5. Commissioning work on automated process control system equipment – ​​1 week.

6. Training of the Customer’s operational personnel – 1 week.

2. Purpose and goals of creating the system.

2.1. Purpose of the system

The developed automated control system for the technological process of mashing and filtering beer wort is intended for:

- monitoring the condition of an object by measuring its technological parameters and parameters of the equipment condition;

- regulation of technological parameters;

-control of actuators and equipment drives;

- signaling limit values ​​of technological process parameters and equipment condition;

- display of received and processed information.

- determination of emergency situations at technological units by polling sensors in automatic mode, analyzing measured values, issuing control actions on actuators in automatic mode or at the initiative of operating personnel.

The automated process control system being developed belongs to the information and control system and is designed to control the technological process of mashing and filtering beer wort.

2.2 Purposes of creation:

When developing this section, it is necessary to take into account that the implementation of automated process control systems should ensure the achievement of the main goal of the enterprise policy in the field of quality. Depending on the specifics of production and the characteristics of the automated process control system being created, the goals may be:

- collection and processing of 4-20 mA level signals;

- collection and processing of discrete signals of the position of limit switches;

- obtaining a stable profit through the production of competitive products;

- stabilization of technological parameters and quality indicators of products;

- increasing the yield of marketable products;

- reduction of material and energy costs;

- increasing management efficiency due to increased information support;

- improving the work culture of technological personnel due to the service provided by the system;

- reducing the number of functions performed by process personnel due to their automation;

- improving the quality indicators of the final product (specify specifically what indicators and what products);

- prevention of emergency situations;

- improving the environmental situation by reducing the pollution of industrial joints and the release of harmful substances into the atmosphere (if this is provided for by the system);

- ensuring (if necessary) the development of the system and its integration into the production information network.

3. Characteristics of the control object

The main characteristics of the automation object are given in the appendices:

APPENDIX 1. Description of the technological process of mashing and filtering beer wort.

A technological diagram indicating technological objects, main and auxiliary material flows, a description of the processing technology and the purpose of the equipment must be provided.

APPENDIX 2. Initial list of inputs and outputs of the automatic control system of the beer wort mashing and filtering section.

APPENDIX 3. Summary lists of inputs and outputs of the DCS of the beer wort mashing and filtering section.

APPENDIX 4. Block diagram of the automated control system for the beer wort mashing and filtering section.

4. System requirements

The system must perform information, control functions, as well as alarm and interlock functions.

The automated process control system must provide:

4.1. Requirements for the structure and functioning of the system

The process control system must perform the following functions:

1. Automated collection and primary processing of technological information:

a) Poll of analog sensors:

- steam pressure in the mash apparatus and wort boiler and at the inlet to them;

- level of congestion in mash devices;

- density of the saccharified mash in the lauter tun;

- density of hot wort at the outlet of the hop separator;

- wort consumption after the hop separator

b) Interrogation of discrete sensors:

- mash level in the lauter tun, wort kettle and hop separator.

2. Automatic monitoring of the state of process equipment (status signals):

- electric drives for mixers in mash machines and wort boilers;

- electric drives of pumps pumping mash between mash devices;

- control valves for steam supply to the mash apparatus and wort boiler;

- control valves for water supply to mash apparatus I, filtration tank and hop separator;

- control valve for supplying saccharified mash to the filtration tank;

- valves for supplying crushed malt to mash apparatus I;

- valves for supplying hops to the wort kettle;

- valves for supplying hopped wort to the hop separator;

- valves for releasing wort from the filtration tank;

- valves for releasing hot wort from the hop separator.

3. Warning alarm when process parameters go beyond the set value:

- temperature of the mash in the mash apparatus and the wort boiler;

- water temperature at the inlet to mash apparatus I, the filtration tank and the hop separator;

- steam pressure in the mash apparatus and wort boiler and at the inlet to them;

- steam consumption entering the mash apparatus and wort boiler;

- flow of water entering mash apparatus I, filtration tank and hop separator;

- mash level in the mash tuns, lauter tun, wort kettle and hop separator;

- mash density in the lauter tun and at the outlet of the hop separator.

4. Real-time process control.

4.1. Regulation of technological parameters:

- regulation of temperature and pressure in the mash apparatus and wort boiler by supplying steam to them;

- regulation of the mash level in mash apparatus I by supplying water and crushed malt into it;

- control of mashing duration in mash apparatus I based on a signal from a saccharimeter;

- control of the duration of wort cooking in the wort boiler using a valve;

- regulation of the level of saccharified mash in the lauter tun by supplying water and crushed malt into it;

- regulation of the level of hopped wort in the wort kettle by feeding hops and saccharified mash into it;

- regulation of the level of hot wort in the hop separator by supplying water and hopped wort into it;

- control of the duration of filtration in the filtration tank based on a signal from the density sensor.

4.2 Program-logical control of technological equipment (indicate the main algorithms and controls).

4.3. Generating blocking commands when certain parameters go beyond valid values(indicate which locks are provided).

5. Calculation of technological and technical-economic indicators

The calculation of technical and economic indicators includes determining the quantities of substances consumed or received over certain time intervals (indicate which products).

6. Presentation of information in the form of values ​​or graphs on the display.

The information display function should provide, at the request of the process operator, the display of operational information about the current state of the technological process and equipment, presented in the form of mnemonic diagrams, trends, summaries, and parameter values.

The output frames must provide warning and alarm signaling for two violation limits (upper and lower), signaling of exceeding the reliability limits and signaling of sensor breakage. Signaling that the limits are exceeded is expressed by the blinking of the variable values; after the blinking is removed, the variable values ​​light up in a color corresponding to the state of the variables.

8. Printing technological documentation

Technological operators must be able to print any information (mnemonic diagrams, trends) at any time using an external storage medium (USB Flash Drive) in the form of text and graphic files.

4.2. Requirements for the number and qualifications of personnel.

All system personnel are divided into two categories according to their role:

Operational technological personnel: operators, technologists, heads of technological installations, operator - technologist, shift supervisor, shop manager.

Operational personnel: electrical engineer; software engineer; head of sector, shift engineer.

The number and nomenclature of personnel is established depending on the specifics of the automation object. Implementation of the System will require special training of personnel. Before putting the System into operation, personnel must undergo appropriate training.

4.3. Reliability requirements

The system must be multifunctional, recoverable and must be characterized by reliability indicators (mean time between failures in thousand hours) for the main functions performed:

Centralized control of parameters and signaling of violations;

Remote control;

Regulation.

Reliability indicators must meet the requirements of GOST 24.701-86. The system must meet the following reliability requirements (RD 50-650): - for automated process control systems, a comprehensive indicator of reliability for each function is the availability factor. The availability factor must be at least 0.995 with an acceptable recovery time of 1 hour. This time should include, in addition to the time of detecting the failure and replacing the failed replacement unit, the organizational time spent on receiving and delivering a serviceable unit from the spare parts kit to the equipment location and checking it. In this case, the system must allow the restoration of its individual parts without interrupting the functioning of the entire system.

The average service life of the system is 10 years. The guaranteed shelf life of the system is 2 years from the date of its acceptance at the manufacturer. The warranty period of operation is 18 months within the warranty period of storage, subject to the customer’s compliance with the storage and operation conditions stipulated by this TOR.

The system must be provided with a set of spare parts for the entire guarantee period, determined by reliability calculation, while the probability of providing spare parts for this period must be at least 0.99. During the entire remaining service life, the spare parts kit must be replenished in accordance with the terms of the service agreement.

4.4. Safety requirements

1. If necessary, signals must be introduced into the system to warn of the formation of unacceptable concentrations in production premises.

2. Technical means (sensors, actuators, etc.) located in explosive zones of premises and outdoor installations and connected to the system must have a degree of protection corresponding to the group and category of the explosive mixture that can be formed in this area.

3. For parameters that determine the explosion hazard of objects, a pre-emergency alarm must be provided.

4. Signaling of extreme positions must be provided for actuators.

5. Provide an audible alarm:

Preventive technological;

Emergency;

6. All external elements of the technical means of the system that are energized must be protected from accidental human touch, and the technical means themselves must be grounded.

4.5. Requirements for ergonomics and technical aesthetics

Human interaction with the system is carried out through controllers equipped with a hard drive, an alphanumeric keyboard, and a functional graphical control tool such as a mouse.

The display of information on the screen of a color graphic display should ensure that the operator-technologist receives full characteristics the current state of the technological process and equipment and the ability to control them in a form that is most convenient for perception in each specific situation.

The screen dimensions must be sufficient to display certain fragments of each technological installation. Fragments should not be oversaturated with information and a variety of colors.

The warning alarm shall be accompanied by flickering or changing color of the numeric variable values ​​or background on the display screens. Emergency situations are accompanied, additionally, by an audible alarm acknowledged by the operator-technologist. The connection between the operator-technologist and the process and system is realized through queries, which should be simplified as much as possible and have adequate mnemonics.

The location of the system's technical means must be rational both in terms of the installation connections between them and the ease of their operation and maintenance.

4.6. Operating requirements maintenance, repair and storage

The system can be operated around the clock. The types, frequency and maintenance schedule of technical equipment must be specified in the relevant instructions.

The system must have an uninterruptible power supply that ensures its operation for 15 minutes. after a power outage.

Voltage fluctuations in the industrial network (start-ups of pumps, compressors, welding machines, etc.) and impulse noise should not affect the power supply of the automated process control system.

The maintenance personnel should include specialists in the following profiles:

According to instrumentation and A;

Technologist to support functional tasks;

Electronics engineer;

System programmer.

The number of specialists is determined by the Customer.

4.7. Requirements for protecting information from unauthorized access

To ensure the normal functioning of the system and prevent distortion of information from accidental influences on the part of service personnel who do not have access to individual parts of the system, the system software must provide for the protection of information from unauthorized access.

Technically, protection is carried out through a password - priority. Password execution can be done using keys or programmatically.

4.8. Requirements for means of protection against external influences

The technical means of the system must be resistant to ambient temperature and humidity:

Ambient temperature from 15 to 25С;

Relative humidity of ambient air from 40 to 80% at a temperature of 25С;

Atmospheric pressure from 84 kPa to 107 kPa (from 630 to 800 mm Hg)

Protection of technical equipment from external electric and magnetic fields, as well as interference in power supply circuits, must be sufficient for the normal functioning of the system. For these purposes, the system uses special hardware (circuit) and software solutions:

Galvanic isolation of technical means from process equipment;

The use of twisted pairs for transmitting electrical signals;

Filtering interference through power supply and information circuits;

The use of microcircuit element base with increased performance and noise immunity.

4.9. Requirements for patent purity

The system being developed is not intended for export, therefore no restrictions on patent clearance are imposed.

4.10. Requirements for standardization and unification

The developed system must be universal, provide the possibility of its use on a wide class of control objects and correspond to the achieved world level in the field of creating automated process control systems, functional development, ease of operation and maintenance.

5. Requirements for types of collateral

5.1. Requirements for Information Support .

Information support of the process control system includes the following categories of data:

Current values ​​of process variables entering the system as a result of polling sensors and primary processing of information;

Boundaries of variables at various levels, settings of control algorithms, information linking software to a specific object;

Program texts and load modules.

To exchange information within the distributed System, a database must be created that provides access to data from local network elements, which are:

Peripheral microprocessor devices - controllers;

Multifunctional operator stations - workplaces for process personnel;

Engineering station.

For the convenience of operation of technologists-operators with large volumes of various information, and for the development of appropriate stereotypes of interaction with the System, the Information support of the System must be structured and have a hierarchical organization.

The following standard operating panels (video images, frames, windows) must be provided:

1. General overview panels

Designed to control the operation of the entire production as a whole and to gain access to more detailed panels when the need arises.

2. Mnemonic diagrams

They are among the most important types of operating panels. They represent a graphical representation of the main process equipment, instrumentation and automation equipment, and display the structure of control and protection algorithms and their status.

3. Instrument panel panels

Present and describe the condition of the front panels of 8-12 devices.

4. Settings panels

They describe the parameters of a specific device/instrument/controller and provide the ability to configure it.

5. Alarm panels

Reflects the warning and pre-emergency alarms of the process in chronological order.

6. Panels for recording process progress (trends) There should be 2 types of panels for graphically displaying data on the progress of the process over time:

Panel group of 6 - 12 trends,

Single trend panel.

The operator technologist should be provided with simple and natural ways to call up and enter data for various panels, such as:

Button on the functional keyboard;

Indicating an element on the screen;

Select from a menu;

Enter data through the appropriate area on the screen.

All setting constants, binding information, algorithms for solving problems and program texts must be stored on duplicate media and updated when changes are made to the System.

5.2. Requirements for linguistic support.

To implement the functions of the process control system, modern configuration and visual programming tools should be used, aimed at specialist developers of process control systems. These tools can significantly minimize development time and give exceptional visibility to information processing and control algorithms.

Due to the lack of domestic regulatory documents, it is necessary to use the IEC 61131-3 standard developed by the International Electrotechnical Commission (IEC), which regulates the completeness and syntax of technological programming languages, as their prototype.

In accordance with this standard, the System must have at least the following technological programming tools:

1. Function Block Diagrams - Graphic language of function blocks;

2. Sequential Function Chart - Functional diagrams for describing the sequence of operations.

To develop emergency protection systems, the following is additionally provided:
3. Ladder Logic Diagrams - Graphic tools for describing logic circuits.

For the development of application programs, in particular, technological and technical-economic calculations, it must be provided

4. A high-level problem-oriented language that allows you to create new tasks, quickly correct them, save the results of solving problems in a database, organize the launch of tasks on request and on time with appropriate priorities.

All semantic and textual information presented on monitor screens and in printed reports for process and operational personnel must be in Russian.

5.3. Requirements for standard Software.

To implement the tasks of a distributed System, specialized software must be used, operating in the environment of a multitasking real-time operating system. The software specifications must meet the requirements to perform the functions specified in the previous sections.

Network software that ensures the integration of control subsystems, operator stations and data archiving tools into a single System must implement loading and control of task launches, ensure exchange between tasks and databases, and provide access to peripheral devices.

The control system must be able to quickly configure application software during the operation of the process control system.

All error situations that arise during the operation of programs must be diagnosed, accompanied by messages, and must not cause disruptions in the operation of the System.

5.4. Requirements for application software ("mathematical") software.

The System's software must ensure the implementation of the functions listed in this TOR, as well as the execution of configuration, programming, database management and documentation operations.

The automated process control system application software must ensure the implementation of the required control, regulation and protection algorithms, information display, signaling and data archiving.

Control algorithms must be reconfigurable and implemented through library block structures.

5.5. Requirements for technical support.

The complex of technical means of the automated process control system must be sufficient to implement the functions specified in this technical specification, and be built on the basis of the following specialized software and hardware systems:

Instrumentation and control equipment, including sensors, actuators, electronic microprocessor controllers and in-line quality analyzers;

Peripheral microprocessor devices - control subsystems, or controllers;

Multifunctional operator and engineering stations;

Data archiving tools;

Network hardware;

Specialized microprocessor controllers of the ESD system;

Means for metrological verification of equipment.

The measurement system should be built on the basis of electronic sensors for flow, pressure, level, temperature, differential pressure, integrating counters, quality and composition analyzers.

Instruments for measuring flow rates, pressures, levels and pressure differences must have standard signals in the 4-20 mA range.

To implement the collection and processing of information, the following modules must be provided as part of the control subsystems:

Input signals 4-20mA;

Input of 4-20mA signals with built-in spark protection barriers;

Millivolt signal input with built-in spark protection barriers;

Input of discrete signals;

Input via RS-422/RS-485 protocol from peripheral microprocessor devices.

The output of control actions calculated according to the control laws must be carried out through modules for outputting analog current signals to electric pneumatic positioners installed on pneumatic actuators.

The output of discrete control actions and interlocks for controlling electrical equipment is carried out through discrete signal output modules.

5.6. Requirements for metrological support.

Metrological support of measuring systems must comply with GOST R 8.596-2002. GSI. "Metrological Support of Measuring Systems. Basic Provisions." The following information and documents must be provided:

The purpose of the IS, and information about its use in the field (or outside the field) of State metrological control and supervision;

Certificate of approval of the IS type, description of the IS type, verification methodology - if they are used in the field of State metrological control and supervision;

Information about the measured quantities and their characteristics;

Lists of measuring channels and their error rates;

Measurement conditions;

Conditions of metrological service.

The specification of the automated control system equipment must include special technical and software for calibrating the measuring channels.

The range of monitored parameters includes flow rates of liquids, gases and steam, temperature, pressure, level, concentration, etc.

All measurement methods used in the field of state metrological control and supervision must be certified.

For measuring channels of the IC, recommendations (instructions) for verification (calibration) of the IC, approved in the prescribed manner, must be provided.

For technical means involved in the process of measuring controlled parameters, appropriate operating conditions (temperature, humidity) must be provided. Control of their operating conditions in control rooms must be ensured.

5.7. Organizational support of process control systems

must be sufficient for the personnel to effectively perform their duties in operating the System. Organizational support should include requirements for the number and qualifications of process control and instrumentation systems personnel, instructions for each type of activity, and a precise definition of the functions performed.

Document's name:
Document Number:	34.602-89
Document type:	GOST
Receiving authority:	State Standard of the USSR
Status:	Active
Published:	official publication
Acceptance date:	March 24, 1989
Start date:	01 January 1990
Revision date:	01 February 2002

GOST 34.602-89 Information technology(IT). Set of standards for automated systems. Terms of reference for the creation of an automated system

GOST 34.602-89

Group P87

INTERSTATE STANDARD

INFORMATION TECHNOLOGY

Set of standards for automated systems.
Terms of reference for the creation of an automated system

Information technology. Set of standards for automated systems.
Technical directions for automated system making

OKSTU 0034

Date of introduction 1990-01-01

INFORMATION DATA

1. DEVELOPED AND INTRODUCED by the USSR State Committee for Standards, the Ministry of Instrument Engineering, Automation and Control Systems of the USSR

2. APPROVED AND ENTERED INTO EFFECT by the Resolution State Committee USSR according to standards dated 03.24.89 N 661

3. INSTEAD GOST 24.201-85

4. REFERENCE REGULATIVE AND TECHNICAL DOCUMENTS

	Item number, application
GOST 2.105-95
GOST 2.301-68
GOST 2.501-88	Annex 1
GOST 6.10.1-88
GOST 6.10.4-84
GOST 19.201-78
GOST 34.201-89
GOST 34.601-90

5. REISSUE


This standard applies to automated systems (AS) for automating various types of activities (management, design, research, etc.), including their combinations, and establishes the composition, content, rules for drawing up the document “Technical specifications for the creation (development or modernization) systems" (hereinafter referred to as TK for the AS).

The recommended procedure for developing, agreeing and approving technical specifications for nuclear power plants is given in Appendix 1.

1. GENERAL PROVISIONS

1. GENERAL PROVISIONS

1.1. The technical specification for a nuclear power plant is the main document that defines the requirements and procedure for creating (development or modernization - then creation) of an automated system, in accordance with which the development of the nuclear power plant is carried out and its acceptance upon commissioning.

1.2. Specifications for the NPP are developed for the system as a whole, intended to operate independently or as part of another system.

Additionally, technical specifications can be developed for parts of the AS: for AS subsystems, complexes of AS tasks, etc. in accordance with the requirements of this standard; for hardware components and software and hardware systems in accordance with ESKD and SRPP standards; for software in accordance with ESPD standards; for information products in accordance with GOST 19.201 and NTD valid in the department of the customer of the AS.

Note. The technical specifications for an automated control system for a group of interconnected objects should include only requirements common to the group of objects. The specific requirements of an individual control object should be reflected in the technical specifications for the automated control system of this object.

1.3. Requirements for AS in the scope established by this standard can be included in the design assignment for a newly created automation facility. In this case, technical specifications for the nuclear power plant are not developed.

1.4. The requirements included in the technical specifications for nuclear power plants must correspond to the current level of development of science and technology and not be inferior to similar requirements imposed on the best modern domestic and foreign analogues.

The requirements specified in the technical specifications for the NPP should not limit the system developer in the search and implementation of the most effective technical, technical, economic and other solutions.

1.5. Technical specifications for nuclear power plants are developed on the basis of initial data, including those contained in the final documentation of the stage “Research and justification for the creation of nuclear power plants”, established by GOST 24.601.

1.6. The technical specifications for the AS include only those requirements that complement the requirements for systems of this type (ACS, CAD, ASNI, etc.) contained in the current normative and technical documentation, and are determined by the specifics of the specific object for which the system is being created.

1.7. Changes to the technical specifications for the NPP are formalized by an addition or a protocol signed by the customer and developer. The addition or the specified protocol is an integral part of the technical specifications for the NPP. On the title page of the technical specification for the speaker there should be the entry “Valid from …”.

2. COMPOSITION AND CONTENTS

2.1. The technical specification for the NPP contains the following sections, which can be divided into subsections:

1) general information;

2) the purpose and goals of the creation (development) of the system;

3) characteristics of automation objects;

4) system requirements;

5) composition and content of work to create the system;

6) the procedure for control and acceptance of the system;

7) requirements for the composition and content of work to prepare the automation object for putting the system into operation;

8) documentation requirements;

9) sources of development.

Applications may be included in the technical specifications for the speakers.

2.2. Depending on the type, purpose, specific features of the automation object and the operating conditions of the system, it is possible to draw up sections of the technical specifications in the form of applications, introduce additional ones, exclude or combine subsections of the technical specifications.

The technical specifications for parts of the system do not include sections that duplicate the contents of the technical specifications sections for the system as a whole.

2.3. In the "General Information" section indicate:

1) full name of the system and its symbol;

2) subject code or code (number) of the contract;

3) the name of the enterprises (associations) of the developer and customer (user) of the system and their details;

4) a list of documents on the basis of which the system is created, by whom and when these documents were approved;

5) planned dates for the start and end of work on creating the system;

6) information about the sources and procedure for financing the work;

7) the procedure for registration and presentation to the customer of the results of work on creating the system (its parts), on the production and adjustment of individual means (hardware, software, information) and software and hardware (software and methodological) complexes of the system.

2.4. Section "Purpose and goals of creation (development) of the system" consists of subsections:

1) purpose of the system;

2) the goals of creating the system.

2.4.1. In the subsection "Purpose of the system" indicate the type of activity being automated (management, design, etc.) and the list of automation objects (facilities) on which it is supposed to be used.

For automated control systems, a list of automated control bodies (points) and controlled objects is additionally indicated.

2.4.2. In the subsection “Goals for creating a system”, the names and required values ​​of technical, technological, production-economic or other indicators of the automation object that must be achieved as a result of creating an AS are given, and indicate the criteria for assessing the achievement of the goals for creating the system.

2.5. In the section "Characteristics of the automation object" the following is given:

1) brief information about the automation object or links to documents containing such information;

2) information about the operating conditions of the automation object and the characteristics of the environment.

Note. For CAD, the section additionally provides the main parameters and characteristics of design objects.

2.6. The "System Requirements" section consists of the following subsections:

1) requirements for the system as a whole;

2) requirements for functions (tasks) performed by the system;

3) requirements for types of security.

The composition of the system requirements included in this section of the technical specifications for the NPP is established depending on the type, purpose, specific features and operating conditions specific system. Each subsection provides links to the current normative and technical documentation that defines the requirements for systems of the corresponding type.

2.6.1. In the subsection "Requirements for the system as a whole" indicate:

- requirements for the structure and functioning of the system;

- requirements for the number and qualifications of system personnel and their mode of operation;

- destination indicators;

- reliability requirements;

- safety requirements;

- requirements for ergonomics and technical aesthetics;

- requirements for transportability for mobile speakers;

- requirements for operation, maintenance, repair and storage of system components;

- requirements for protecting information from unauthorized access;

- requirements for the safety of information in case of accidents;

- requirements for protection from external influences;

- requirements for patent purity;

Requirements for standardization and unification;

Additional requirements.

2.6.1.1. The requirements for the structure and operation of the system include:

1) a list of subsystems, their purpose and main characteristics, requirements for the number of hierarchy levels and the degree of centralization of the system;

2) requirements for methods and means of communication for information exchange between system components;

3) requirements for the characteristics of the relationships of the created system with related systems, requirements for its compatibility, including instructions on methods of information exchange (automatically, by sending documents, by telephone, etc.);

4) requirements for system operating modes;

5) requirements for diagnosing the system;

6) prospects for development and modernization of the system.

2.6.1.2. The requirements for the number and qualifications of plant personnel include:

- requirements for the number of personnel (users) of the NPP;

- requirements for personnel qualifications, the procedure for their training and control of knowledge and skills;

- required operating mode of the plant personnel.

2.6.1.3. In the requirements for indicators of the purpose of the AS, the values ​​of parameters characterizing the degree of compliance of the system with its purpose are given.

For ACS indicate:

- the degree of adaptability of the system to changes in processes and control methods, to deviations in the parameters of the control object;

- acceptable limits of modernization and development of the system;

- probabilistic-time characteristics under which the intended purpose of the system is preserved.

2.6.1.4. Reliability requirements include:

1) composition and quantitative values ​​of reliability indicators for the system as a whole or its subsystems;

2) a list of emergency situations for which reliability requirements must be regulated, and the values ​​of the corresponding indicators;

3) requirements for the reliability of hardware and software;

4) requirements for methods for assessing and monitoring reliability indicators at different stages of system creation in accordance with current regulatory and technical documents.

2.6.1.5. The safety requirements include requirements for ensuring safety during installation, commissioning, operation, maintenance and repair of technical equipment of the system (protection from the effects of electric current, electromagnetic fields, acoustic noise, etc.), according to permissible levels illumination, vibration and noise loads.

2.6.1.6. The requirements for ergonomics and technical aesthetics include AC indicators that set the required quality of human-machine interaction and the comfort of working conditions for personnel.

2.6.1.7. For mobile speakers, the requirements for transportability include design requirements that ensure the transportability of the technical means of the system, as well as requirements for vehicles.

2.6.1.8. Requirements for operation, maintenance, repair and storage include:

1) conditions and regulations (mode) of operation, which must ensure the use of technical means (TS) of the system with specified technical indicators, including the types and frequency of maintenance of the TS of the system or the admissibility of operation without maintenance;

2) preliminary requirements for the permissible areas for accommodating personnel and vehicle systems, for the parameters of power supply networks, etc.;

3) requirements for the number, qualifications of service personnel and their operating modes;

4) requirements for the composition, placement and storage conditions of a set of spare products and devices;

5) requirements for maintenance regulations.

2.6.1.9. The requirements for protecting information from unauthorized access include the requirements established in the scientific and technical documentation applicable in the customer’s industry (department).

2.6.1.10. The requirements for the safety of information provide a list of events: accidents, failures of technical equipment (including loss of power), etc., in which the safety of information in the system must be ensured.

2.6.1.11. The requirements for means of protection against external influences include:

1) requirements for radioelectronic protection of nuclear power plants;

2) requirements for durability, stability and strength to external influences (environment of use).

2.6.1.12. The requirements for patent purity indicate a list of countries in respect of which the patent purity of the system and its parts must be ensured.

2.6.1.13. The requirements for standardization and unification include: indicators establishing the required degree of use of standard, unified methods for implementing functions (tasks) of the system, supplied software, standard mathematical methods and models, standard design solutions, unified forms of management documents established by GOST 6.10.1* , all-Union classifiers of technical and economic information and classifiers of other categories in accordance with their scope of application, requirements for the use of standard automated workstations, components and complexes.
_____________________
* In the Russian Federation PR 50-733-93 is in force.

2.6.1.14. Additional requirements include:

1) requirements for equipping the system with devices for personnel training (simulators, other devices for similar purposes) and documentation for them;

2) requirements for service equipment, stands for testing system elements;

3) system requirements related to special operating conditions;

4) special requirements at the discretion of the system developer or customer.

2.6.2. In the subsection "Requirements for functions (tasks)" performed by the system, the following is given:

1) for each subsystem, a list of functions, tasks or their complexes (including those ensuring the interaction of parts of the system) subject to automation;

when creating a system in two or more queues - a list of functional subsystems, individual functions or tasks put into operation in the 1st and subsequent queues;

2) time regulations for the implementation of each function, task (or set of tasks);

3) requirements for the quality of implementation of each function (task or set of tasks), for the form of presentation of output information, characteristics of the required accuracy and execution time, requirements for the simultaneous performance of a group of functions, the reliability of the results;

4) list and failure criteria for each function for which reliability requirements are specified.

2.6.3. In the subsection “Requirements for types of support,” depending on the type of system, requirements for mathematical, information, linguistic, software, technical, metrological, organizational, methodological and other types of support for the system are given.

2.6.3.1. For the mathematical support of the system, requirements are given for the composition, scope of application (limitations) and methods of using mathematical methods and models, standard algorithms and algorithms to be developed in the system.

2.6.3.2. The requirements for information support of the system are:

1) to the composition, structure and methods of organizing data in the system;

2) to information exchange between system components;

3) to information compatibility with related systems;

4) on the use of all-Union and registered republican, industry classifiers, unified documents and classifiers operating at a given enterprise;

5) on the use of database management systems;

6) to the structure of the process of collecting, processing, transmitting data in the system and presenting data;

7) to protect data from destruction during accidents and system power failures;

8) to control, store, update and restore data;

9) to the procedure for giving legal force to documents produced by technical means of the NPP (in accordance with GOST 6.10.4).

2.6.3.3. For linguistic support of the system, requirements are given for the use of high-level programming languages ​​in the system, user interaction languages ​​and technical means of the system, as well as requirements for data encoding and decoding, data input-output languages, data manipulation languages, means of describing the subject area (automation object). ), to ways of organizing dialogue.

2.6.3.4. For system software, a list of purchased software is provided, as well as requirements:

1) to the independence of software from the used SVT and operating environment;

2) to the quality of software, as well as to the methods of its provision and control;

3) if necessary, coordinate newly developed software with the fund of algorithms and programs.

2.6.3.5. For technical support of the system the following requirements are given:

1) to the types of technical means, including the types of complexes of technical means, software and hardware complexes and other components allowed for use in the system;

2) to the functional, design and operational characteristics of the system’s technical support means.

2.6.3.6. The requirements for metrological support include:

1) preliminary list of measuring channels;

2) requirements for the accuracy of measurements of parameters and (or) for the metrological characteristics of measuring channels;

3) requirements for metrological compatibility of technical means of the system;

4) a list of control and computing channels of the system for which it is necessary to evaluate the accuracy characteristics;

5) requirements for metrological support of hardware and software included in the measuring channels of the system, built-in control means, metrological suitability of measuring channels and measuring instruments used during commissioning and testing of the system;

6) type of metrological certification (state or departmental) indicating the procedure for its implementation and the organizations conducting certification.

2.6.3.7. For organizational support the following requirements are given:

1) to the structure and functions of the units involved in the operation of the system or ensuring operation;

2) to the organization of the functioning of the system and the procedure for interaction between plant personnel and automation facility personnel;

3) to protect against erroneous actions of system personnel.

2.6.3.8. For methodological support, CAD provides requirements for the composition of the regulatory and technical documentation of the system (a list of standards, regulations, methods, etc. used in its operation).

2.7. The section "Composition and content of work on the creation (development) of the system" should contain a list of stages and phases of work on the creation of the system in accordance with GOST 34.601, the timing of their implementation, a list of organizations performing the work, links to documents confirming the consent of these organizations to participate in creation of a system, or a record identifying the person responsible (customer or developer) for carrying out this work.

This section also provides:

1) a list of documents in accordance with GOST 34.201, presented at the end of the relevant stages and phases of work;

2) type and procedure for conducting the examination of technical documentation (stage, stage, volume of documentation being checked, expert organization);

3) a program of work aimed at ensuring the required level of reliability of the system being developed (if necessary);

4) a list of works on metrological support at all stages of creating the system, indicating their deadlines and executing organizations (if necessary).

2.8. In the section "Procedure for control and acceptance of the system" indicate:

1) types, composition, scope and testing methods of the system and its components (types of tests in accordance with current standards applicable to the system being developed);

2) general requirements for the acceptance of work by stages (list of participating enterprises and organizations, place and timing), the procedure for coordination and approval of acceptance documentation;

3) status of the acceptance committee (state, interdepartmental, departmental).

2.9. In the section “Requirements for the composition and content of work to prepare the automation object for commissioning of the system,” it is necessary to provide a list of the main activities and their performers that should be performed when preparing the automation object for putting the plant into operation.

The list of main activities includes:

1) bringing the information entering the system (in accordance with the requirements for information and linguistic support) to a form suitable for processing using a computer;

2) changes that need to be made in the automation object;

3) creation of conditions for the functioning of the automation object, under which the compliance of the created system with the requirements contained in the technical specifications is guaranteed;

4) creation of units and services necessary for the functioning of the system;

5) timing and procedure for staffing and training.

For example, for automated control systems they give:

- changes in applied management methods;

- creation of conditions for the operation of automated control system components, under which the system’s compliance with the requirements contained in the technical specifications is guaranteed.

2.10. In the “Documentation Requirements” section the following is given:

1) a list of sets and types of documents to be developed, agreed upon by the developer and the customer of the system, that meet the requirements of GOST 34.201 and the NTD of the customer’s industry; list of documents issued on computer media; requirements for microfilming documentation;

2) requirements for documenting component elements for cross-industry use in accordance with the requirements of the ESKD and ESPD;

3) in the absence of state standards defining the requirements for documenting system elements, additionally include requirements for the composition and content of such documents.

2.11. The section “Sources of development” should list documents and information materials (feasibility studies, reports on completed research work, information materials on domestic and foreign analogue systems, etc.), on the basis of which the technical specifications were developed and which should be used to create the system.

2.12. In the presence of approved methods, the technical specifications for nuclear power plants include annexes containing:

1) calculation of the expected efficiency of the system;

2) assessment of the scientific and technical level of the system.

Applications are included in the technical specifications for the NPP as agreed between the developer and the customer of the system.

3. RULES OF REGISTRATION

3.1. Sections and subsections of the technical specifications for the NPP must be placed in the order established in Section 2 of this standard.

3.2. Technical specifications for the AS are drawn up in accordance with the requirements of GOST 2.105 on A4 sheets in accordance with GOST 2.301 without a frame, main inscription and additional columns to it.

Sheet (page) numbers are placed, starting from the first sheet following the title page, at the top of the sheet (above the text, in the middle) after indicating the TK code on the AC.

3.3. The values ​​of indicators, norms and requirements are indicated, as a rule, with maximum deviations or maximum and minimum values. If these indicators, norms, and requirements are clearly regulated by the scientific and technical documentation, the technical specifications for the plant should contain a link to these documents or their sections, as well as additional requirements that take into account the features of the system being created. If specific values ​​of indicators, norms and requirements cannot be established during the development of technical specifications for the NPP, it should make a record of the procedure for establishing and agreeing on these indicators, norms and requirements:

"The final requirement (value) is clarified in the process... and agreed upon by the protocol with... at the stage...". At the same time, no changes are made to the text of the technical specifications for the NPP.

3.4. The title page contains the signatures of the customer, developer and approving organizations, which are sealed with an official seal. If necessary, the title page is drawn up on several pages. The signatures of the developers of the technical specifications for the nuclear power plant and the officials involved in the approval and consideration of the draft technical specifications for the nuclear power plant are placed on the last sheet.

The form of the title page of the technical specifications for the motor vehicle is given in Appendix 2. The form of the last sheet of the technical specifications for the motor vehicle is given in Appendix 3.

3.5. If necessary, codes established in the industry may be placed on the title page of the technical specification on the AS, for example: security classification, work code, registration number of technical specification, etc.

3.6. The title page of the addition to the technical specifications for the NPP is designed in the same way as the title page of the technical specifications. Instead of the name “Technical specifications” they write “Addition N... to the technical specifications for the NPP...”.

3.7. On subsequent sheets of the addendum to the technical specifications for the AS, the basis for the change, the content of the change and links to the documents in accordance with which these changes are made are placed.

3.8. When presenting the text of the addition to the technical specifications, the numbers of the corresponding paragraphs, subparagraphs, tables of the main technical specifications for the plant, etc. should be indicated. and use the words: “replace”, “supplement”, “exclude”, “state in a new edition”.

APPENDIX 1 (recommended). PROCEDURE FOR DEVELOPMENT, APPROVAL AND APPROVAL OF TOR FOR NPP

1. The draft technical specifications for the NPP are developed by the organization - the system developer with the participation of the customer on the basis of technical requirements (application, tactical and technical specifications, etc.).

During the competitive organization of work, options for the design specifications for the NPP are considered by the customer, who either selects the preferred option, or, based on a comparative analysis, prepares the final version of the technical specifications for the NPP with the participation of the future NPP developer.

2. The need to coordinate the draft technical specifications for the NPP with state supervisory authorities and other interested organizations is determined jointly by the customer of the system and the developer of the draft technical specifications for the nuclear power plant.

The work on approving the draft technical specifications for the nuclear power plant is carried out jointly by the developer of the technical specifications for the nuclear power plant and the customer of the system, each in the organizations of his ministry (department).

3. The period for approval of the draft technical specifications for the NPP in each organization should not exceed 15 days from the date of its receipt. It is recommended to send copies of the draft technical specifications for the AS (copies) simultaneously to all organizations (divisions) for approval.

4. Comments on the draft technical specifications for the NPP must be submitted with a technical justification. Decisions on comments must be made by the developer of the draft technical specifications for the nuclear power plant and the customer of the system before approval of the technical specifications for the nuclear power plant.

5. If, when agreeing on a draft technical specification for a nuclear power plant, disagreements arise between the developer and the customer (or other interested organizations), then a protocol of disagreements is drawn up (the form is arbitrary) and a specific decision is made in the prescribed manner.

6. Approval of the draft technical specifications for the NPP may be formalized in a separate document (letter). In this case, under the heading “Agreed” a link is made to this document.

7. The approval of technical specifications for the NPP is carried out by the heads of enterprises (organizations) of the developer and customer of the system.

8. Before submitting it for approval, the technical specification for the NPP (addition to the technical specification) must be checked by the regulatory control service of the organization that developed the technical specification and, if necessary, subjected to metrological examination.

9. Copies of the approved Technical Specifications for the NPP are sent by the developer of the Technical Specifications for the NPP to the participants in the system creation within 10 days after approval.

10. Coordination and approval of additions to the technical specifications for the nuclear power plant are carried out in the manner established for the technical specifications for the nuclear power plant.

11. Changes to the technical specifications for the NPP are not allowed to be approved after the system has been submitted for its turn for acceptance testing.

12. Registration, accounting and storage of technical specifications on the NPP and additions to it are carried out in accordance with the requirements of GOST 2.501.

__

name of the organization that developed the technical specifications for the NPP

I APPROVED		I APPROVED
Manager (position, Business name - customer AC)		Manager (position, Business name - speaker developer)
Personal signature Seal date	Decoding signatures	Personal signature Seal date	Full name

_____________________________________________________________________________________

name of the type of speaker

_____________________________________________________________________________________

name of the automation object

_____________________________________________________________________________________

abbreviated name of AC

TECHNICAL TASK

On________ sheets

Valid from

AGREED

Head (position, name
coordinating organization)

	Personal signature Seal date	Full name

___________________________________

COMPLETED

	Performer's position	Full Name

AGREED

Name of organization, enterprise	Job title	Full Name

The text of the document is verified according to:
official publication
Information technology.
Automated systems.
Key points:
Sat. GOST. - M.: IPK
Standards Publishing House, 2002

GOST 34.602-89 Information technology (IT). Set of standards for automated systems. Terms of reference for the creation of an automated system

Document's name:
Document Number:	34.602-89
Document type:	GOST
Receiving authority:	State Standard of the USSR
Status:	Active
Published:	official publication Information technology. Automated systems. Basic provisions: Sat. GOST. - M.: IPK Publishing House of Standards, 2002
Acceptance date:	March 24, 1989
Start date:	01 January 1990
Revision date:	01 February 2002

GOST 34.602-89 Information technology (IT). Set of standards for automated systems. Terms of reference for the creation of an automated system

How to develop it correctly technical task for an automated system? This question is so broad that it is impossible to answer in a nutshell. Therefore, I decided to write a long article on this topic. During the process, I realized that it would not be possible to put everything in one article and decided to break it into two parts:

• In the first part, I will try to answer the questions of the topic in detail, consider the structure and purpose of the technical specifications, and give some recommendations on the formulation of requirements.
• The second part “Development of technical specifications. How to formulate requirements? » will be entirely devoted to identifying and formulating requirements for the information system.

First, you need to figure out what question actually interests those who ask “How to develop a technical specification?” The fact is that the approach to developing the technical specifications will greatly depend on the purposes for which it is being done, as well as by whom it will be used. What options am I talking about:

• A commercial organization decided to implement an automated system. It does not have its own IT service and decided to do this: the interested party must develop technical specifications and submit it for development to a third-party organization;
• A commercial organization decided to implement an automated system. It has its own IT service. We decided to do this: develop a technical specification, then agree on it between the IT service and interested parties, and implement it on our own;
• The government agency decided to start an IT project. Everything here is so murky, a lot of formalities, kickbacks, cuts, etc. I will not consider this option in this article.
• An IT company provides services for the development and/or implementation of automated systems. This is the most difficult case, because you have to work in a variety of conditions:

1) The client has his own specialists with their own views, and they make specific requirements for the technical specifications.
2) The technical specifications are developed for in-house developers (the client doesn’t care).
3) The terms of reference are developed for transfer to the contractor (a group of programmers on staff of the company, or an individual specialist).
4) A misunderstanding arises between the company and the client regarding the result obtained, and the company again and again asks the question: “How should the terms of reference be developed?” The last case may seem like a paradox, but it is true.

• Other, less common options are also possible;

I think the reader should now have questions:

• Why can’t technical specifications always be developed in the same way?
• Are there any standards, methods, recommendations? Where can I get them?
• Who should develop the terms of reference? Should this person have any special knowledge?
• How to understand whether the terms of reference are well written or not?
• At whose expense should it be developed, and is it even necessary?

This list can be endless. I say this with confidence because I have been in professional software development for 15 years, and the question of technical specifications comes up in any development team with whom I work. The reasons for this are different. Raising the topic of developing technical specifications, I am well aware that I will not be able to present it 100% to everyone interested in the topic. But, I’ll try, as they say, “to sort everything out.”

Those who are already familiar with my articles know that I do not use “copy-paste” of other people’s work, do not reprint other people’s books, do not quote multi-page standards and other documents that you yourself can find on the Internet, passing them off as my own brilliant thoughts . Just type in a search engine “How to develop a technical specification” and you can read a lot of interesting, but, unfortunately, repetitive things. As a rule, those who like to be clever on forums (just try searching!) have never made a proper technical specification themselves, and constantly quote GOST recommendations on this issue. And those who are really serious about the issue usually have no time to sit on the forums. By the way, we will also talk about GOST standards.

Over the years of my work, I have seen many versions of technical documentation compiled by both individual specialists and eminent teams and consulting companies. Sometimes I also engage in this activity: I allocate time for myself and search for information on a topic of interest from unusual sources (such as a little intelligence). As a result, I had to see documentation for such “monsters” as “ GazProm, Russian Railways and many other interesting companies. Of course, I comply with the confidentiality policy, despite the fact that these documents come to me from publicly available sources or the irresponsibility of consultants (scattering information on the Internet). Therefore, I say right away: I do not share confidential information that belongs to other companies, regardless of the sources (professional ethics).

What is a technical specification?

The first thing we will do now is figure out what kind of beast this “Technical Assignment” is.

Yes, there really are GOSTs and standards that attempt to regulate this part of the activity (software development). Once upon a time, all these GOSTs were relevant and actively used. Now there are different opinions about the relevance of these documents. Some argue that GOSTs were developed by very far-sighted people and are still relevant. Others say they are hopelessly outdated. Perhaps someone now thought that the truth was somewhere in the middle. I would answer in the words of Johann Goethe: “They say that between two opposing opinions lies the truth. In no case! There is a problem between them." So, there is no truth between these opinions. Because GOSTs do not reveal the practical problems of modern development, and those who criticize them do not offer alternatives (specific and systemic).

Note that GOST clearly does not even give a definition, it only says: “TK for a nuclear power plant is the main document that defines the requirements and procedure for creating (development or modernization - then creation) of an automated system, in accordance with which the development of a nuclear power plant is carried out and its acceptance upon commissioning into action."

If anyone is interested in what GOSTs I’m talking about, here they are:

• GOST 2.114-95 " one system design documentation. Technical conditions";
• GOST 19.201-78 “Unified system of program documentation. Technical task. Requirements for content and design";
• GOST 34.602-89 “Information technology. Set of standards for automated systems. Technical specifications for the creation of an automated system."

A much more successful definition is presented in Wikipedia: “Technical specifications are the initial design document technical object. The terms of reference establish the main purpose of the object being developed, its technical and performance characteristics, quality indicators and technical and economic requirements, instructions for completing the necessary stages of creating documentation (design, technological, software, etc.) and its composition, as well as special requirements. A task as an initial document for the creation of something new exists in all areas of activity, differing in name, content, and order of execution. (For example, a design task in construction, a combat task, homework, contract for literary work)».

So, as follows from the definition, the main purpose of the terms of reference is to formulate the requirements for the object being developed, in our case, for an automated system. The time has come to get down to the main thing: to put everything “on the shelves”, as promised.

What do you need to know about the requirements? It is necessary to clearly understand that all requirements must be divided by type and properties. Now we will learn how to do this. To separate requirements by type, GOST will help us. The list of types of requirements that is presented there is a good example of what types of requirements should be considered. For example:

• Functionality requirements;
• Security and access rights requirements;
• Requirements for personnel qualifications, etc.

I think it is obvious to you that the key factor in a successful technical specification is precisely well-formulated functionality requirements. Most of the works and methods that I spoke about are devoted to these requirements. Functionality requirements are 90% of the complexity of the work on developing technical specifications. Everything else is often a “camouflage” that covers these requirements. If the requirements are formulated poorly, then no matter what beautiful camouflage you put on them, a successful project will not come out. Yes, formally all requirements will be met (according to GOST), the technical specification has been developed, approved and signed, and money has been received for it. And what? And then the most interesting part begins: what to do? If this is a government contract project, then there are no problems - the budget there is such that it won’t fit into anyone’s pocket, and during the implementation process (if there is one) everything will be clarified. This is exactly how most project budgets for government orders are cut. (They scribbled “TK”, lost tens of millions, but did not do the project. All formalities were completed, there were no guilty parties, a new car is near the house. Beauty!). But we are talking about commercial organizations where money is counted, and a different result is needed. Therefore, let’s understand the main thing, how to develop useful and working technical specifications.

I said about the types of requirements, but what about properties? If the types of requirements can be different (depending on the goals of the project), then with properties everything is simpler, there are three of them:

1. The requirement must be understandable;
2. The requirement must be specific;
3. The requirement must be test takers;

Moreover, the last property is impossible without the previous two, being a kind of “litmus test”. If the result of a requirement cannot be tested, then it is either unclear or non-specific. Think about it. It is in the mastery of these three properties of requirements that mastery and professionalism lie. In fact, everything is very simple. When you figure it out.

This concludes the story that such a technical task could be completed and move on to the main thing: how to formulate requirements. But it's not that fast. There is one more extremely important point:

• In what language (in terms of difficulty of understanding) should the technical specification be written?
• Should it describe the specifications of various functions, algorithms, data types and other technical things?
• What is technical design, which, by the way, is also mentioned in GOSTs, and how is it related to the technical specifications?

There is a very insidious thing hidden in the answers to these questions. That is why disputes often arise about the sufficiency or lack of necessary detail of requirements, about the understandability of the document by the customer and performers, about redundancy, presentation format, etc. Where is the line between the terms of reference and the technical project?

So here it is: technical task– this is a document based on requirements formulated in a language that is understandable (ordinary, familiar) to the customer. In this case, industry terminology that is understandable to the customer can and should be used. There should be no connections to the specifics of the technical implementation. At the technical specification stage, in principle, it does not matter on which platform these requirements will be implemented. Although there are exceptions. If we are talking about implementing a system based on an existing software product, then such a link can take place, but only at the level of screen forms, report forms, etc. A business analyst should be involved in identifying and formulating requirements, as well as developing technical specifications. And certainly not a programmer (unless he combines these roles, this happens). This person must speak to the customer in his language business.

Technical project– this is a document that is intended for the technical implementation of the requirements formulated in the technical specifications. This document describes data structures, triggers and stored procedures, algorithms and other things that technical specialists will need. The customer does not need to delve into this at all (even such terms may not be clear to him). The technical project is done by the system architect (combining this role with a programmer is quite normal). Or rather, a group of JSC specialists headed by an architect. The larger the project, the more people work on the technical specifications.

What do we have in practice? It’s funny to watch when the director is presented with a technical specification for approval, which is replete with technical terminology, descriptions of data types and their values, database structure, etc. He, of course, tries to understand, since he needs to approve, trying to find familiar words between the lines and not lose the chain business requirements. Is this a familiar situation? And how does it end? As a rule, such a technical specification is approved, then implemented, and in 80% of cases it does not at all correspond to the fact of the work performed - they decided to change a lot of things, redo them, misunderstood them, didn’t think so, etc. And then the series about submitting work begins. “But here it’s not what we need,” but “this won’t work for us,” “this is too complicated,” “this is inconvenient,” etc. Sound familiar?! That’s familiar to me, I had to hit the bumps in due time.

So what do we have in practice? But in practice, we have a blurred boundary between the terms of reference and the technical project. She floats between TK and TP in a variety of manifestations. And that's bad. But it turns out this way because the development culture has become weak. This is partly due to the competencies of specialists, partly due to the desire to reduce budgets and deadlines (after all, documentation takes a lot of time - that’s a fact). There is another important factor influencing the use technical project as a separate document: the rapid development of rapid development tools, as well as development methodologies. But this is a separate story; I’ll say a few words about it below.

Another small but important point. Sometimes a technical specification is called a small piece of requirements, simple and understandable. For example, improve the search for an object according to some conditions, add a column to the report, etc. This approach is completely justified, why complicate your life. But it is used not on large projects, but on minor improvements. I would say this is closer to software product maintenance. In this case, the technical specification may also describe a specific technical solution for implementing the requirement. For example, “Make such and such a change to such and such an algorithm,” indicating a specific procedure and a specific change for the programmer. This is the case when the boundary between the terms of reference and the technical project is completely erased, there is no economic feasibility to inflate paperwork where it is not needed, and a useful document is created. And it is right.

Is technical specification necessary at all? What about the technical project?

Am I overheating? Is this possible without any technical specifications at all? Imagine it is possible (or rather, it is possible), and this approach has many followers, and their number is growing. As a rule, after young specialists have read books about Scrum, Agile and other rapid development technologies. In fact, these are wonderful technologies, and they work, but they don’t literally say “no need to do technical tasks.” They say “a minimum of paperwork,” especially unnecessary ones, closer to the customer, more specifics and faster results. But no one canceled the recording of requirements, and this is clearly stated there. It is there that the requirements are fixed based on the three remarkable properties that I mentioned above. It’s just that some people’s minds are structured in such a way that if something can be simplified, then let’s simplify it to the point of complete absence. As Albert Einstein said: “Make it as simple as possible, but not simpler than that.” These are golden words that go with everything. So you need technical specifications, otherwise you won’t see a successful project. Another question is how to compose it and what to include there. In the light of rapid development methodologies, you need to focus only on the requirements, and all the “camouflage” can be discarded. In principle, I agree with this.

What about the technical project? This document is very useful and has not lost its relevance. Moreover, often you simply cannot do without it. Especially when it comes to transferring development work to the outside, on the principle of outsourcing. If you don't do this, you run the risk of learning a lot about what the system you have in mind should look like. Should the customer get to know him? If he wants, why not, but there is no need to insist and approve this document, it will only hold back and interfere with work. It is almost impossible to design a system down to the smallest detail. In this case, you will have to continuously make changes to the technical project, which takes a lot of time. And if the organization is heavily bureaucratic, then you’ll leave all your nerves there. Reducing this kind of design is exactly what modern rapid development methodologies that I mentioned above are all about. By the way, they are all based on the classic XP approach (extreme programming), which is already about 20 years old. So make a high-quality technical specification that is understandable to the customer, and use the technical project as an internal document for the relationship between the system architect and programmers.

Interesting detail about technical design: some development tools designed on the subject-oriented principle (such as 1C and similar) assume that design (meaning the documentation process) is required only in truly complex areas where interaction between entire subsystems is required. In the simplest case, for example, to create a directory or document, all you need is correctly formulated business requirements. This is also evidenced by the business strategy of this platform in terms of training specialists. If you look at the exam card of a specialist (that’s what it’s called, not a “programmer”), you will see that there are only business requirements, and how to implement them in a program language is the specialist’s task. The specialist must solve that part of the problem that the technical project is intended to solve “in his head” (we are talking about tasks medium difficulty), and here and now, following certain development and design standards, which again are formed by the 1C company for its platform. Thus, of two specialists whose work results look identical, one can pass the exam, but the other cannot, because he grossly violated development standards. It is obviously assumed that specialists must have such qualifications that they can design typical tasks independently, without the involvement of system architects. And this approach works.

Let’s continue to study the question: “What requirements should be included in the terms of reference?”

Formulation of requirements for the information system. Structure of technical specifications

Let’s be clear right away: we will talk specifically about formulating requirements for an information system, assuming that the work on developing business requirements, formalizing business processes and all previous consulting work has already been completed. Of course, some clarifications can be made at this stage, but just clarifications. The automation project itself does not solve business problems - remember this. This is an axiom. For some reason, some managers are trying to refute it, believing that if they buy the program, order will come to a chaotic business. But an axiom is an axiom because it does not require proof.

Like any activity, formulating requirements can (and should) be divided into stages. Everything has its time. This is hard intellectual work. And, if you treat it with insufficient attention, then the result will be appropriate. According to expert estimates, the cost of developing technical specifications can be 30-50%. I am of the same opinion. Although 50 is perhaps too much. After all, the terms of reference are not the last document that must be developed. After all, there must also be technical design. This variation is due to different automation platforms, approaches and technologies used by project teams during development. For example, if we are talking about development in a classical language like C++, then detailed technical design is indispensable. If we are talking about implementing a system on the 1C platform, then the situation with design is somewhat different, as we saw above (although, when developing a system from scratch, it is designed according to the classical scheme).

Despite the fact that the formulation of requirements is the main part of the technical specification, in some cases it becomes the only section of the technical specification, you should pay attention to the fact that this is an important document, and it should be drawn up accordingly. Where to begin? First of all, you need to start with the content. Write the content and then start expanding it. Personally, I do this: first I sketch out the content, describe the goals, all the introductory information, and then get down to the main part - the formulation of the requirements. Why not the other way around? I don't know, it's more convenient for me. Firstly, this is a much smaller part of the time (compared to the requirements), and secondly, while you are describing all the introductory information, you tune in to the main thing. Well, that's what you like. Over time, you will develop your own technical specification template. To begin with, I recommend taking as content exactly the one described in GOST. It's perfect for content! Then we take and begin to describe each section, not forgetting about the recommendations of following three properties: understandability, specificity and testability. Why do I insist on this so much? More on this in the next section. And now I propose to go through those points of the technical specifications that are recommended in GOST.

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 putting the system into operation.

8. Documentation requirements.

9. Sources of development.

In total, there are nine sections, each of which is also divided into subsections. Let's look at them in order. For convenience, I will present everything in the form of a table for each item.

Section 1. General information

Full name of the system and its symbol;	Everything is clear here: we write what the system will be called, its short name
Subject code or contract code (number);	This is not relevant, but you can specify it if required
Name of the enterprises (associations) of the developer and customer (user) of the system and their details;	Indicate who (which organizations) will work on the project. You can also specify their roles. You can remove this section altogether (quite formal).
A list of documents on the basis of which the system is created, by whom and when these documents were approved;	Helpful information. Here you should indicate the regulatory and reference documentation that was provided to you to familiarize yourself with a certain part of the requirements
Planned dates for the start and end of work on creating the system;	Requests for timing. Sometimes they write about this in the technical specifications, but more often such things are described in work contracts
Information about the sources and procedure for financing the work;	Same as in the previous paragraph about deadlines. More relevant for government orders(for state employees)
The procedure for registration and presentation to the customer of the results of work on creating the system (its parts), on the production and adjustment of individual means (hardware, software, information) and software and hardware (software and methodological) complexes of the system.	I don’t see the need for this point, the documentation requirements are set out separately, and in addition there is a whole separate section “Procedure for control and acceptance” of the system.

Section 2. Purpose and goals of creation (development) of the system

	What to do about it in practice
Purpose of the system	On the one hand, the purpose is simple. But it is advisable to formulate it specifically. If you write something like “high-quality automation of warehouse accounting in company X,” then you can discuss the result for a long time upon its completion, even regardless of the good formulation of the requirements. The customer can always say that by quality he meant something else. In general, you can spoil each other’s nerves a lot, but why? It’s better to immediately write something like this: “The system is designed to maintain warehouse records in company X in accordance with the requirements specified in this technical specification.”
Goals of creating the system	Goals are definitely an important section. If we are to include it, then we must be able to formulate these goals. If you have difficulty formulating goals, then it is better to exclude this section altogether. An example of an unsuccessful goal: “Ensure that the manager completes documents quickly.” What is fast? This can then be proven endlessly. If this is important, then it is better to reformulate this goal as follows: “The sales manager should be able to issue a document “Sales of goods” of 100 lines in 10 minutes.” A goal like this might come up if, for example, a manager is currently spending about an hour on this, which is too much for that company and it's important to them. In this formulation, the goal already intersects with the requirements, which is quite natural; when expanding the tree of goals (splitting them into smaller related goals), we will already get closer to the requirements. Therefore, you shouldn’t get carried away. In general, the ability to identify goals, formulate them, and build a tree of goals is a completely separate topic. Remember the main thing: if you know how, write, if you are not sure, don’t write at all. What happens if you don’t formulate goals? You will work according to the requirements, this is often practiced.

Section 3. Characteristics of automation objects

Section 4. System Requirements

	What to do about it in practice
Requirements for the system as a whole. GOST deciphers the list of such requirements: requirements for the structure and functioning of the system; requirements for the number and qualifications of system personnel and their mode of operation; destination indicators; reliability requirements; safety requirements; requirements for ergonomics and technical aesthetics; transportability requirements for mobile speakers; requirements for operation, maintenance, repair and storage of system components; requirements for protecting information from unauthorized access; requirements for the safety of information in case of accidents; requirements for protection from external influences; requirements for patent purity; requirements for standardization and unification;	Despite the fact that the main one, of course, will be the section with specific requirements (functional), this section may also have great importance(and in most cases it does). What may be important and useful: Qualification requirements. It is possible that the system being developed will require retraining of specialists. These can be both users of the future system and IT specialists who will be needed to support it. Insufficient attention to this issue often develops into problems. If the qualifications of the existing personnel are clearly insufficient, it is better to specify requirements for the organization of training, training program, timing, etc. Requirements for protecting information from unauthorized access. No comments here. These are precisely the requirements for delimiting access to data. If such requirements are planned, then they need to be written separately, in as much detail as possible, according to the same rules as functional requirements (understandability, specificity, testability). Therefore, these requirements can be included in the section with functional requirements Requirements for standardization. If there are any design standards that are applicable to the project, they can be included in the requirements. As a rule, such requirements are initiated by the customer’s IT service. For example, the 1C company has requirements for the design of program code, interface design, etc.; Requirements for the structure and functioning of the system. Here the requirements for integrating systems with each other can be described, and a description of the general architecture is presented. More often, integration requirements are separated into a separate section or even a separate technical specification - these requirements can turn out to be quite complex. All other requirements are less important and need not be described. In my opinion, they only make the documentation heavier and have little practical benefit. But it is very difficult to describe ergonomic requirements in the form of general requirements; it is better to transfer them to functional ones. For example, the requirement “Get information about the price of a product by pressing only one button” may be formulated. In my opinion, this is still closer to specific functional requirements, although it relates to ergonomics.
Requirements for functions (tasks) performed by the system	Here it is, the very main and key point that will determine success. Even if everything else is done perfectly, and this section is “3”, then the result of the project will be at best “3”, or even the project will fail altogether. It is these that we will deal with in more detail in the second article. It is to this point that the “rule of three properties of requirements” that I spoke about relates.
Requirements for types of collateral GOST identifies the following types: Mathematical Informational Linguistic Software Technical Metrological Organizational Methodical and others…	At first glance, these requirements may seem unimportant. In most projects this is true. But not always. When to describe these requirements: No decisions have been made on which language (or platform) development will be carried out; The system requires a multilingual interface (for example, Russian/English) For the system to function, a separate unit must be created or new employees must be hired; For the system to function, the customer must undergo changes in working methods and these changes must be specified and planned; Integration with any equipment is expected and requirements are imposed on it (for example, certification, compatibility, etc.) Other situations are possible, it all depends on the specific goals of the project.

Section 5. Composition and content of work to create the system

Section 6. Procedure for control and acceptance of the system

What to do about it in practice

Types, composition, scope and methods of testing the system and its components (types of tests in accordance with current standards applicable to the system being developed); General requirements for acceptance of work by stages (list of participating enterprises and organizations, place and timing), procedure for coordination and approval of acceptance documentation;

But even the presence of testable requirements may not be enough when the system is delivered if the procedure for acceptance and transfer of work is not clearly stated. For example, a common trap: the system is built and is fully operational, but the customer for some reason is not ready to work in it. These reasons can be any: no time, goals have changed, someone quit, etc. And he says: “Since we are not yet working with the new system, it means that we cannot be sure that it works.” So learn to correctly identify the stages of work, and how to check the results of these stages. Moreover, such methods should be clear to the customer from the very beginning. If they are fixed at the level of technical specifications, then you can always turn to them if necessary and bring the work to handover.

Section 7. Requirements for the composition and content of work to prepare the automation object for commissioning of the system

	What to do about it in practice
Bringing the information entering the system (in accordance with the requirements for information and linguistic support) to a form suitable for processing using a computer;	A very important point. For example, for the system to function as intended, it may be necessary to use any industry or all-Russian directories and classifiers. These directories must somehow appear in the system, be updated and used correctly. There may be any other rules for entering information adopted by the company (or planned). For example, information about a contract used to be entered as a text string in any form, but now a separate number, a separate date, etc. are required. There can be a lot of such conditions. Some of them may be perceived with resistance from staff, so it is better to register all such cases at the level of requirements for the data entry procedure
Changes that need to be made to the automation object Creation of conditions for the functioning of an automation object, under which the compliance of the created system with the requirements contained in the technical specifications is guaranteed	Any changes that may be required. For example, the company does not have a local network, an outdated fleet of computers on which the system will not work. Perhaps some necessary information was processed on paper, and now it needs to be entered into the system. If you do not do this, then any module will not work. Perhaps something was simplified, but now needs to be taken into account in more detail, so someone must collect information according to certain rules. This list can be long, look at the specific case of your project.
Creation of departments and services necessary for the functioning of the system; Timing and procedure for staffing and training	We already talked about this earlier. Perhaps the system is being developed for a new structure or type of activity that did not exist before. If there are no appropriate personnel, and even trained ones, the system will not work, no matter how competently it is built.

Section 8. Documentation Requirements

What to do about it in practice

A list of sets and types of documents to be developed, agreed upon by the system developer and customer

Having complete documentation is an important part of the result. We all know that documenting anything is time-consuming work. Therefore, it is necessary to agree in advance with the customer what types of documentation will be developed, what they will look like (content and preferably examples). Consider how user manuals will be presented. Perhaps the customer has accepted corporate standards, which means we need to refer to them. Ignoring documentation requirements very often leads to the most unexpected consequences on projects. For example, everything is done and everything works. Users also know how to work. There was no agreement or conversation about documentation at all. And suddenly, when handing over the work, one of the customer’s top managers, who did not even participate in the project, but is involved in accepting the work, asks: “Where are the user manuals?” And it begins to convince you that there is no need to negotiate about the availability of user manuals, this is “of course” supposedly implied. And that’s it, he doesn’t want to accept the job. At whose expense will you develop the guidelines? Many teams have already fallen for this hook.

Section 9. Development Sources

We have considered all sections that can be included in the terms of reference. “Can”, not “Must”, because any document must be developed to achieve a result. Therefore, if it is obvious that a particular section will not bring you any closer to the result, then you don’t need it and you don’t need to waste time on it.

But not a single competent technical task can do without the main thing - functional requirements. I would like to note that in practice such technical tasks do occur, and how! There are figures who will be able to separate the waters in all sections, describe the general requirements in general terms, and the document turns out to be very weighty, and there are a lot of clever words in it, and even the customer may like it (he will approve it). But it may not be possible to work with it; it has little practical use. In most cases, such documents are born when you need to get a lot of money specifically for a technical task, but it needs to be done quickly and without diving into details. Especially if it is known that the matter will not go further, or completely different people will do it. In general, just to manage the budget, especially the state budget.

In the second article we will talk only about section No. 4 “System requirements”, and specifically we will formulate requirements for reasons of clarity, specificity and testability.

Why do requirements need to be clear, specific, and testable?

Because practice shows: at first, most of the technical specifications that specialists develop either turn out to be unclaimed (do not correspond to reality), or become a problem for the one who must implement them, since the customer begins to manipulate non-specific terms and requirements. I will give a few examples of what phrases were encountered, what this led to, and then I will try to give recommendations on how to avoid such problems.

Type of requirement

Incorrect wording

Send your good work in the knowledge base is simple. Use the form below

Students, graduate students, young scientists who use the knowledge base in their studies and work will be very grateful to you.

Posted on http://www.allbest.ru/

• Content
• Introduction
• 1. Technical specifications
• 1.1 General information
• 1.2 Reasons for development
• 1.3 Purpose and goals of creating the system
• 1.4 System requirements
• 1.4.1 Requirements for the system as a whole
• 1.4.2 Requirements for functions (tasks) performed by the system
• 1.4.3 Requirements for types of collateral
• 1.5 Characteristics of automation objects
• 1.6 Documentation requirements
• 1.7 Stages and milestones of development
• 1.7.1 Development stages
• 1.7.2 Development stages
• 1.7.3 Contents of work by stages
• 1.8 Procedure for control and acceptance of the system
• 1.8.1 Types, composition, scope and test methods of the system and its components
• 1.8.2 General requirements for acceptance of work by stages
• 1.8.3 Status of the acceptance committee (state, interdepartmental, departmental)
• 2. Technical design
• 2.1 Functional structure
• 2.1.1 Description of the subject area
• 2.1.2 Functions and organizational structure
• 2.1.3 Description of data flows and business processes
• 2.2 IC system design
• 2.2.1 Development of the concept, architecture and implementation platform for the IS
• 2.2.2 Structure information system, composition of functional and supporting subsystems
• 2.2.3 IS technical support
• 2.3 IS information support
• 2.3.1 Description of the logical structure of the information base
• 2.3.2 Description of the physical implementation of the database
• Conclusion
• Bibliography

Introduction

The course work examines the issues of creating technical specifications for the development of an information system for a system for an agency for the sale and reservation of air tickets. The purpose of the work is to study the basic principles and obtain basic skills in preparing technical specifications for the development of information systems and their software.

Work on creating an information system begins with the formation of customer requirements for the system being created and their formalization in the form of technical specifications (TOR). The technical specification is the main document that defines the requirements and procedure for creating an automated system, in accordance with which the system is developed and accepted upon commissioning. In addition, based on the technical specifications, the work is calculated and labor costs are specified.

TK consists of three stages:

1. justification of the need to develop an information system - statement of the problem, collection of source materials, selection and justification of criteria for the effectiveness and quality of the developed system, justification of the need for research work;

2. Research work - determination of the structure of input and output data, preliminary selection of methods for solving problems, justification of the feasibility of using the developed system, determination of requirements for technical means, justification of the fundamental possibility of solving the problem;

3. development and approval of technical specifications - determination of program requirements, development of a feasibility study of the system, determination of stages, stages and timing of system development and documentation for it, selection of programming languages, determination of the need for research at the final stages, coordination and approval of technical specifications.

TK performs the following functions:

Organizational function - a fixed task for the Contractor and final requirements on the part of the Customer.

Information function - order in the process of the Contractor and thoughtfulness of desires on the part of the Customer.

The communication function is a mutual agreement on the “subject of the project”, excluding claims.

Legal function - TOR has equal legal force with the “Agreement”.

The result of the developed technical project largely depends on the completeness and accuracy of drawing up the technical specifications.

1. Technical specifications

1.1 General information

Full name of the system and its symbol: "Automated information system of the agency for the sale and reservation of air tickets." a brief description of Areas of use

The system is intended for use in the customer's organization, in our case - an agency for the sale and reservation of air tickets.

The procedure for registration and presentation to the customer of the results of work on creating the system (its parts), on the production and adjustment of individual tools (hardware, software, information) and software and hardware (software and methodological) complexes of the system: AIS "Ticket" is supplied in the form of executable modules according to Upon completion of the entire scope of work, technical equipment is purchased by the Customer independently. The results of work on creating the system are formalized by signing an act of acceptance of the system by the Customer in the absence of claims against the Developer. The act is drawn up in two copies. One copy is with the Customer, the other is with the Developer.

1.2 Reasons for development

The basis for the development of technical specifications is the assignment for the course work for the course “Design of Information Systems”.

The name of the development topic is "Development of an information system for an agency for the sale and reservation of air tickets"

Symbol of the development topic (topic code) - "IS APB"

1.3 Purpose and goals of creating the system

Functional purpose of the system: AIS "Ticket" is designed to automate the work of an agency for the sale and reservation of air tickets.

Operational purpose of the system: The system must be operated by employees of the organization.

Goals of creating the system: The system speeds up the process of ordering air tickets, thereby simplifying the agency’s work.

1.4 System requirements

1.4.1 Requirements for the system as a whole

Requirements for the structure and functioning of the system

List of subsystems, their purpose and main characteristics, requirements for the number of hierarchy levels and the degree of centralization of the system

AIS "Ticket" includes the following subsystems:

Acceptance of order;

Ticket registration;

Settlement with the customer.

The "Order Acceptance" subsystem is intended for registering an air ticket order.

The "Settlement with the customer" subsystem provides the customer with a reservation number associated with passport data (payment by card).

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

Information exchange is carried out via a local network.

Requirements for system operating modes:

The system must support multi-user and offline operating modes. Users access the system via the Internet or Call Center.

Requirements for the number and qualifications of system personnel

Requirements for personnel qualifications, the procedure for their training and control of knowledge and skills:

The employee involved in accepting applications must have user-level skills in working with a personal computer. The number of staff may vary depending on the volume of orders.

Reliability requirements

Restoring the system in the event of errors in the operation of hardware (except for storage media and programs) and errors associated with software (OS and device drivers), restoring functionality is the responsibility of the OS.

If there are failures in the hardware power supply system that lead to an OS reboot, the program must be restored after restarting the OS and running the system executable file.

The operability of the system as a whole must also be ensured in the event of failures, accidents and failures at individual workstations. To protect equipment from voltage surges and switching interference, mains filters should be used, and to allow the user to save data in the event of a power failure, it is recommended to use uninterruptible power supplies.

Security requirements

The customer ensures that the technical solutions used in the modification and development of the subsystem comply with current standards, safety regulations, fire and explosion safety, and environmental protection.

Requirements for operation, maintenance, repair and storage of system components

Operating conditions, as well as the types and frequency of maintenance of the subsystem's technical equipment must comply with the requirements for operation, maintenance, repair and storage set out in the manufacturer's (manufacturer's) documentation for them.

Requirements for the protection of information aboutt unauthorized access

To protect information from unauthorized access, the System must provide:

a) identification and authentication of the user;

b) checking user rights and access restrictions at the level of functions and data arrays when working with the system.

Requirements for the safety of information in case of accidents

It is necessary to provide for the possibility of backing up system data using software supplied by the Developer.

Requirements for standardization and unification

For this system, a cascade software life cycle model should be used.

Must be used in the system (if necessary) all-Russian classifiers and unified classifiers and dictionaries for various types of alphanumeric and text information.

The system interface, help files and any text information in the program must be in Russian.

Screen forms must be designed taking into account the unification requirements:

All screen forms of the user interface must be made in a single graphic design, with the same location of the main controls and navigation.

1.4.2 Requirements for functions (tasks) performed by the system

For each subsystem, a list of functions, tasks or their components (including those ensuring interaction between parts of the system) that support automation

The information system must provide the following functions:

Order acceptance subsystem,

Client settlement subsystem.

1.4.3 Requirements for types of collateral

To the information support of the system

To the composition, structure and methods of organizing data in the system

System data is stored on one local machine. The system input is a description of the order; the output should be an invoice and customer identification number.

To the structure of the process of collecting, processing, transmitting data in the system and presenting data.

Data is entered into the system manually, processed and provided to the user in the required form (electronic, printed).

To protect data from destruction during accidents and system power failures

The complex of technical means must include an uninterruptible power supply. The operation of this source must be at least half an hour for the system to shut down correctly.

To control, store, update and restore data

The system must support automatic daily backups.

System software requirements

The system must run on Windows XP/Vista/7/8 operating systems

System hardware requirements

To the types of technical means, including the types of complexes of technical means, software and hardware complexes and other components acceptable for use in the system.

Workstations;

Uninterruptable power source;

Data transmission medium between workstations (for example, twisted pair UTP 5e);

A printer.

Technical means are purchased by the Customer independently.

To the functional, design and operational characteristics of the system's technical support.

Intel Pentium IV processor 2 GHz or higher, RAM at least 2 GB, capacity hard drive at least 500 GB.

Requirements for the bodysystem support

For organizational support the following requirements are given:

To the structure and functions of the units involved in the operation of the system or providing operation.

The functioning of the system is ensured by a systems engineer; 4 employees are involved in operation.

To the organization of the functioning of the system and the order of interaction between plant personnel and automation facility personnel.

Organizational support must be sufficient for personnel to effectively perform their assigned duties when performing the functions of the system.

To protect against erroneous actions of system personnel.

Protection against human errors consists of checking the completion of data in some fields, the ability to restore original data and cancel recent changes, and limiting access by functions and powers of employees.

1.5 Characteristics of automation objects

Brief information about the automation object or links to documents containing such information

The automation object is the process associated with ordering air tickets.

Information about the operating conditions of the automation object and environmental characteristics

This system will be installed in production and office premises.

1.6 Documentation requirements

The following documents must be issued for the system at various stages of creation:

Organizational structure diagram;

Functional structure diagram;

List of input signals and data;

List of output signals (documents);

Explanatory note to the technical project;

Description of automated functions;

Description of the statement of tasks (set of tasks);

Description of the organization of the information base;

Description of the information array;

Description of the software;

User guide.

1.7 Stages and milestones of development

1.7.1 Development stages

Development should be carried out in 6 stages:

1. Development of technical specifications

2. Development of project documentation

3.Creation of a preliminary design

4. Detailed design

5. Commissioning

6. Maintenance and modernization

1.7.2 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 stage of developing project documentation, the stage of developing project documentation must be completed.

At the stage of creating a preliminary design, a preliminary design must be completed for preliminary submission to the customer.

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

1) development of an information system;

2) development of documentation.

At the implementation stage, the program must be prepared and transferred to the customer.

At the stage of maintenance and modernization, work should be carried out to improve the current version of the information system.

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

1) statement of the problem;

2) determination and clarification of requirements for technical means;

3) determination of requirements for the information system;

4) determining the stages, phases and timing of the development of the information system and documentation for it;

5) justification and selection of tools;

6) coordination and approval of technical specifications.

At the stage of development of project documentation, the following work must be performed:

1) identification of main business processes (in the form of IDEF0 diagrams);

2) identification of the main use cases of the System for three categories of users (Guest, Authorized User, Administrator) in the form of UML use case diagrams;

3) designing the database structure in the form of (ER diagram);

4) design of the main components and algorithms of the System in the form of corresponding UML diagrams;

5) designing the user interface structure;

6) coordination and approval of project documentation.

At the development stage, work must be done to develop an information system based on design documentation, coding and debugging.

At the documentation development stage, the development of program documents must be carried out in accordance with the requirements. "Preliminary composition of program documentation" of this technical specification.

At the stage of preparation and transfer of the program, work must be done to prepare and transfer the program and program documentation into operation.

At the stage of improving the current version of the system, work should be carried out to create new versions of the system and add new functions to the old version.

1. Analysis of IP requirements

2. Coordination of requirements with the customer

3. Selection and development of a variant of the system concept

4. Development of technical specifications and project

5. Coordination and approval of technical specifications and project

6. Drawing up a work plan

7. Hardware preparation

8. Software development

9. Checking for hardware and software compatibility

10. Integration and testing of software and hardware

11. Making changes

12. Development of instructions for operating the IS

13. Preparation of complete documentation for IP

14. Delivery of the IP to the customer

Table 1 - Initial data for calculation

Job no.	List of works	Duration of work, days
	1.Analysis of IP requirements
	2. Coordination of requirements with the customer
	3.Selection and development of a variant of the system concept
	4.Development of technical specifications and project
	5. Coordination and approval of technical specifications and project
	6. Drawing up a work plan
	7.Hardware preparation
	8.Software development
	9.Checking for hardware and software compatibility
	10.Integration and testing of software and hardware
	11.Making changes
	12.Development of instructions for operating the IS
	13. Registration of complete documentation for the IP
	14. Delivery of the IP to the customer

Figure 1 - Statement of tasks

Figure 2 - Gantt chart

Figure 3 - Network work schedule

The critical path of the network diagram will be as follows: 0 1 2 3 4 5 6891011121314

Table 2 - Timing parameters of events

Event number	Timing of the event	Time reserve

Table 3 - Calculation of full and free time reserves

	Duration, days	Time parameters of work, days	Full reserve	Free reserve
		early start	Early finish	Late start	Late finish

1.8 Procedure for control and acceptance of the system

1.8.1 Types, composition, scope and test methods of the system and its components

The system is tested by entering a large amount of data, entering the same information, information of a different type of data, data of a larger range. The compliance of the screen forms with the description in the user manual is checked (interface testing).

1.8.2 General requirements for acceptance of work by stages

Delivery and acceptance is carried out by a commission consisting of representatives of the Customer and the Contractor. Based on the results of acceptance, an act of the acceptance committee is signed.

All software products created within the framework of this work are transferred to the Customer, both in the form of ready-made modules and in the form of source codes presented in electronic form on standard computer media (on a CD).

1.8.3 Status of the acceptance committee (state, interdepartmental, departmental)

The status of the acceptance committee is determined by the Customer before testing.

2. Technical design

2.1 Functional structure

2.1.1 Description of the subject area

The subject area is an agency for the sale and reservation of air tickets

The company includes an administrative department (consists of an accountant and a manager), a workstation operation department (information technology management) (system administrator and technicians), and operators.

The administrative department, consisting of an accountant and a manager, is responsible for the quality of services.

2.1.2 Functions and organizational structure

Building an enterprise structure can be divided into three steps: building an organizational model, building a functional model and building an information model.

The Ticket Agency consists of the following departments:

Director;

Administrative department;

Workstations Operations Department;

Operators department.

The organizational structure of the enterprise is shown in Figure 4.

Figure 4 - Organizational model

The director carries out general management of the production, economic and financial-economic activities of the enterprise, and also organizes the interaction of all its structural divisions.

The production department carries out the development of the product design, its subsequent production and assembly.

The administrative department, consisting of an accountant and a manager, is responsible for the quality of service provision.

The workstation operation department is responsible for system performance.

Operators are responsible for accepting orders and entering data into the database.

2.1.3 Description of data flows and business processes

Business Process Modeling

A business process is a set of interrelated activities or tasks aimed at creating a specific product or service for consumers. For clarity, business processes are visualized using a business process flowchart. Business process modeling is the activity of creating models of organizations, including a description of business objects (divisions, positions, resources, roles, processes, operations, information systems, storage media, etc.) and indicating the connections between them. The requirements for the generated models and their corresponding content are determined by the goals of the modeling. Business modeling is also called a discipline and a separate sub-process in the software development process, which describes the company's activities and determines the requirements for the system - those sub-processes and operations that are subject to automation in the information system being developed.

Having analyzed the agency’s activities and conducted a pre-project study, we can identify three main business processes of the AIS “Ticket”:

1. Acceptance of the order.

2. Issuance of an identification number.

3. Settlement with the customer.

Functional modeling of business processes is represented by the IDEF0 methodology. It describes the business processes that take place in the automation object. The IDEF0 methodology is based on a graphical language for describing business processes. A model in IDEF0 is represented by a collection of hierarchically ordered and logically related diagrams. Each diagram is located on a separate sheet. There are four types of diagrams:

Context diagram A-0 (each model can have only one context diagram);

Decomposition diagrams (including the diagram of the first level of decomposition A 0, revealing the contextual one);

Node tree diagrams;

Exposure-only (FEO) charts.

The context diagram is the top of the diagram tree structure and represents the most general description system and its interaction with the external environment (as a rule, the main purpose of the modeled object is described here). After describing the system as a whole, it is divided into large fragments. This process is called functional decomposition, and the diagrams that describe each fragment and the interaction of the fragments are called decomposition diagrams. After decomposing the context diagram (i.e., obtaining the A 0 diagram), each block of the A 0 diagram is decomposed into smaller fragments, and so on, until the desired level of description detail is achieved. After each decomposition session, examination sessions are conducted - subject matter experts (usually enterprise employees interviewed by analysts) indicate the correspondence of real business processes to the created diagrams. Any inconsistencies found are corrected, and only after passing the examination without any comments can the next decomposition session begin. This ensures that the model matches real business processes at any and every level of the model. The syntax for describing the system as a whole and each of its fragments is the same throughout the model.

The main business function of "AIS Ticket" is the sale of air tickets. The input data is the order of tickets. On weekends - receipt. The tools for performing the main business function are the employees of Bilet OJSC (accountant, manager, IT technicians, operators).

Data Flow Diagram

Requirements are represented as a hierarchy of processes connected by data flows. Data flow diagrams show how each process transforms its inputs into outputs and reveal the relationships between these processes. DFD diagrams are successfully used as an addition to the IDEF0 model to describe document flow and information processing. Like IDEF0, DFD represents the system being modeled as a network of related activities. The main components of DFD (as mentioned above) are processes or work, external entities, data flows, data storage (storage). Unlike IDEF0 arrows, which represent rigid relationships, DFD arrows show how objects (including data) move from one job to another.

Unlike IDEF0, which views the system as interrelated activities, DFD views the system as a collection of items. A context diagram often includes works and external links. Works are usually referred to by the name of the system, for example, “Information Processing System.” Including external references in a context diagram does not replace the methodology's requirement to clearly define the purpose, scope, and common point of view of the system being modeled.

In DFD, activities (processes) are system functions that transform inputs into outputs. Although the works are depicted as rectangles with rounded corners, their meaning is the same as the meaning of the IDEF0 and IDEF3 works. Just like IDEF3 processes, they have inputs and outputs, but do not support controls and mechanisms like IDEF0.

External entities represent system entries and/or exits. External entities are depicted as a rectangle with a shadow and are usually located at the edges of the diagram. A single external entity can be used multiple times across one or more diagrams. This technique is usually used to avoid drawing too long and confusing arrows.

Work flows are represented by arrows and describe the movement of objects from one part of the system to another. Since in DFD each side of the work does not have a clear purpose as in IDEF0, arrows can come in and out of any face of the work rectangle. DFD also uses bidirectional arrows to describe command-response conversations between jobs, between a job and an external entity, and between external entities.

Unlike arrows that describe objects in motion, data warehouses depict objects at rest.

2.2 IC system design

terms of reference calculation labor costs booking

2.2.1 Development of the concept, architecture and implementation platform for the IS

The main aspects when choosing an IS architecture are performance, reliability, scalability and security.

Currently the most common architectures are:

file server;

client-server;

multi-level architecture.

The file-server architecture means that the server assumes only the function of storing data, and processing is carried out on client machines. This means that data must be transferred over the network, which will result in heavy network traffic load. And this in turn will lead to a decrease in performance as the number of users increases. Also, when implementing a file-server architecture, the problem of integrity, consistency and simultaneous access to data is solved in a decentralized manner: the data is stored on the server and processed on the client. As a result, the reliability of the application decreases. Another disadvantage is the high costs of upgrading and maintaining business logic services on each client workstation. However, this architecture also has a number of advantages, such as low development cost, high development speed and low cost of updating and changing software.

The client-server architecture does not have the disadvantages of the above-described architecture, because The database server not only provides access to shared data, but also processes it. The client sends requests to the server, in a language “understandable” to the server, and it, in turn, processes the request, while monitoring the integrity and consistency of the data, and returns the result of the processed request to the client. As a result, the network load is reduced: the client no longer needs to process intermediate data. Storage and processing are centralized, so this architecture is more reliable than the file server architecture. The disadvantages of the client-server architecture include, firstly, the sufficient complexity of system development due to the need to execute business logic and provide a user interface in one program and high requirements for workstations for the same reason.

The next stage in the development of IS architectures was a multi-level architecture in which business logic is executed on the application server. Multi-level architecture has the following advantages:

scalability;

configurability - isolation of levels from each other allows you to quickly and easily reconfigure the system when failures occur or during scheduled maintenance at one of the levels;

high security;

high reliability;

low requirements for channel (network) speed between terminals and application server;

low performance requirements and technical specifications terminals, resulting in a reduction in their cost.

However, despite its undeniable advantages, this system has not become widespread for the following reasons:

the difficulty of developing systems based on multi-level architecture, because it is very difficult to “join” different modules, especially if they are written by different groups. And a change in one module, as a rule, causes an avalanche of changes in the rest, and from this point of view, even a simple system based on a multi-level architecture will be 2 times more difficult to implement;

high requirements for the performance of application servers and database servers, and, therefore, the high cost of server equipment;

high requirements for channel (network) speed between the database server and application servers;

high complexity of administration.

Having considered all the advantages and disadvantages of each architecture, we choose the client-server architecture to implement the AIS Ticket system. This architecture allows for optimal distribution of work between the client and server parts of the system: the application running on the workstation does not read database records “directly”, but sends requests to the server, where they are sequentially processed, and the processing results are sent to the workstation. And this significantly reduces information flows on the LAN.

The scheme of functioning and construction of the information system is presented in Figure 5.

Figure 5 - Client-server architecture

2.2.2 Structure of the information system, composition of functional and supporting subsystems

Functional subsystems are a complex of economic tasks with a high degree of information exchanges (connections) between tasks (a certain information processing process with a clearly defined set of input and output information. Functional subsystems informationally serve certain types of activities of the economic system (enterprise), characteristic of its structural divisions and ( or) management functions.Integration of functional subsystems into a single system is achieved through the creation and operation of supporting subsystems, such as:

Informational;

Technical;

Software;

Mathematical;

Linguistic.

Supporting subsystems are common to the entire IS, regardless of the specific functional subsystems in which certain types of support are used. In the work, supporting and organizational subsystems are combined into one supporting subsystem. The justification for such a decision can be considered that their components ensure the implementation of the goals and functions of the system.

The composition of the supporting subsystems does not depend on the selected subject area and has:

Functional structure;

Information Support;

Mathematical (algorithmic and software) software;

Technical support;

Organizational support,

and at the stage of IS development additional support:

Legal;

Linguistic;

Technological;

Methodological;

Interfaces with external ICs.

Information support is a set of means and methods for constructing an information base. It defines the methods and forms of displaying the state of a control object in the form of data inside the IS, documents, graphs and signals outside the IS.

Mathematical software consists of algorithmic and software.

Organizational support is a set of means and methods for organizing production and managing them in the conditions of introducing IP.

The purpose of organizational support is: selection and setting of management tasks, analysis of the management system and ways to improve it, development of solutions for organizing the interaction of information systems and personnel, implementation of management tasks. Organizational support includes methods of communicating with clients, requirements for paperwork, job descriptions, etc.

Algorithmic software is a set of mathematical methods, models and algorithms used in the system to solve problems and process information.

2.2.3 IS technical support

The complex of technical means should include the following elements:

Workstations;

Uninterruptible power supplies;

Tools for building a LAN;

DB server;

A printer.

Server requirements:

Memory 8 GB;

Processor 2.2 GHz Intel Xeon 5500 minimum;

SATA disk speed 8 Gb/s;

Network adapter 10 Gbps;

Operating system Windows Server 2008.

Workstation requirements:

Processor 2 GHz;

Memory 2 GB;

Hard disk not less than 500;

Operating system Windows 7;

Network adapter 100 Mbit/s.

The technical means of the IS are described taking into account the requirements for the functioning of the application software complex. Technical means must provide:

Round-the-clock operation of a complex of technical means and equipment;

Guaranteed execution of the entire software package in the event of a failure or failure of a piece of equipment;

Data protection from unauthorized access;

Servers and workstations must be connected by a local network.

Figure 2.3 shows the topology of the local computer network (LAN) for JSC "Bilet".

The figure in question shows that 5 workstations are connected to the database server and file server through the switch. The network topology is star.

Figure 6 - Logical diagram of the network of JSC "Customer"

2.3 IS information support

2.3.1 Description of the logical structure of the information base

Logical (datalogical) design - creating a database schema based on specific model data, for example, a relational data model. For a relational data model, a datalogical model is a set of relationship diagrams, usually indicating primary keys, as well as “links” between relationships, which are foreign keys.

The transformation of a conceptual model into a logical model is usually carried out according to formal rules. This stage can be largely automated.

Normal form is a property of a relation in a relational data model, characterizing it from the point of view of redundancy, potentially leading to logically erroneous results of sampling or changing data. Normal form is defined as a set of requirements that a relation must satisfy. The process of transforming database (DB) relations into a form that corresponds to normal forms is called normalization. Normalization is intended to bring the database structure to a form that provides minimal logical redundancy, and is not intended to reduce or increase work productivity or reduce or increase the physical volume of the database. The ultimate goal of normalization is to reduce the potential for inconsistency in the information stored in a database. The general purpose of the normalization process is to:

Elimination of certain types of redundancy;

Fixed some update anomalies;

Developing a database design that is a good enough representation of the real world is intuitive and can serve as a good basis for later expansion;

Simplify the procedure for applying the necessary integrity constraints.

Elimination of redundancy is carried out, as a rule, by decomposing relations in such a way that only primary facts are stored in each relation (that is, facts that are not inferred from other stored facts).

At the logical level, database normalization is performed, as well as key allocation for each entity. Logical connections are implemented through primary and foreign keys.

2.3.2 Description of the physical implementation of the database

Physical design - creating a database schema for a specific DBMS. The specifics of a particular DBMS may include restrictions on the naming of database objects, restrictions on supported data types, etc. In addition, the specifics of a particular DBMS during physical design include the choice of solutions related to the physical data storage environment (choice of disk memory management methods, division of the database into files and devices, data access methods), creation of indexes, etc.

The physical data model is built on the basis of a logical model and describes the data using the means of a specific DBMS. The relationships developed at the logical modeling stage are converted into tables, attributes into columns, domains into data types accepted in the selected specific DBMS.

Those. in a physical model, there is a one-to-one correspondence between the parameters of an object and a model of the same physical nature. In this case, the element of the system is assigned physical equivalents that reproduce the structure, basic properties and relationships of the object being studied. In physical modeling, the basis of which is the theory of similarity, the features of conducting an experiment in nature are preserved while maintaining the optimal range of changes in the corresponding physical parameters.

Conclusion

As a result of the course work, a technical assignment was completed for the development of an information system for an agency for the sale and reservation of air tickets and its software.

The terms of reference for an information system are the main document that defines the requirements and procedure for creating an information system, in accordance with which it is developed and accepted upon commissioning. It contains the basic requirements for the functional characteristics, reliability, operating conditions and information protection of the information system, and also describes the procedure for developing the system.

In accordance with the objectives of the technical specifications, the following stages of creating a technical project were completed:

- analysis of the subject area was performed;

- a functional diagram of the AIS "Ticket" was developed;

- a concept has been developed, the architecture and implementation platform of the system have been selected;

1. a conceptual model of the AIS "Ticket" was designed;

2. a logical model of the AIS "Ticket" system was designed based on the conceptual model;

3. The physical structure of the database server is determined.

Bibliography

1. GOST 19.201-78 Unified system of program documentation. Technical task. Requirements for content and design

2. GOST 34.602-89 Information technology. Set of standards for automated systems. Terms of reference for the creation of an automated system

3. RD 50-34.698-90 Automated systems. Requirements for the content of documents

4. V.P. Romanov, N.Z. Emelyanova, T.L. Partyka Design of economic information systems. Methodologies and modern technologies. - M: Exam, 2005.- 256 p.;

5. Maklakov S.V. BPWin and ERWin CASE - information systems development tools / Maklakov S.V. - M: DIALOG MEPhI, 2001.-256 p.;

6. Boyko V.V. Design of information systems databases / Boyko V.V., Savinkov V.M. - 2nd ed. - M.: Finance and Statistics, 1989. - 350 p.

Posted on Allbest.ru

...

Similar documents

Terms of reference for the development of an automated system and warehouse accounting for the management of a universal trading base. Designing an information system and choosing an environment for creating a software product. Interface creation and user manual.

thesis, added 07/11/2015


Regulatory legal acts of the Russian Federation in the field of information security. The procedure for organizing work to protect information in information systems. A general approach to the development of technical specifications for the development of a protection system in this area.

course work, added 05/05/2015


Creation of technical specifications for the development of an information system for ordering a plane ticket. Documentation requirements. Procedure for control and acceptance of the system. Development of the concept, architecture and implementation platform of the information system.

course work, added 05/13/2015


Creation of the "Gold" information system, which automates the work of the Jewelry Workshop. Business process modeling using IDEF0 and UML diagrams and DFD and sicuence data flows. Drawing up a technical project and specifications based on GOST 34.602-89.

course work, added 02/10/2013


Composition of the expert system. Requirements for a set of technical means. Structure and organization of technical support for an automatic information system. Technical documentation for the development of software tools and methods of their use.

abstract, added 10/09/2014


Learning programming languages ​​PHP, SQL, C++, HTML. Consideration of the rules for launching and using the local Denwer server. Drawing up technical specifications for the development of a software product. Description of the mobile and web application being created.

course work, added 04/07/2015


Development of an automated information system for accounting and control of repair work, and provision of software development services to the MegionSoftOil company, development of algorithms for software system applications and modules.

thesis, added 06/29/2012


Justification of the need to develop an information system. Domain analysis. Terms of reference for the creation of an EIS. Legal status and brief economic characteristics of the enterprise. The state of accounting and analytical work at the enterprise.

abstract, added 01/09/2009


Development and implementation of an automated information system (AIS) for working with clients of a travel company (receiving and processing applications). Technical and economic assessment of a travel agency, algorithm and interface diagram of its AIS software.

thesis, added 07/21/2011


Counting the number of function points. Calculation of labor costs for developing a software tool and the estimated time of its development, life cycle model. Development of technical specifications for the creation of an automated system, requirements for it.

General provisions

is the main one that determines the order of creation (or - further creation), in accordance with which the AS is carried out and its implementation [from clause 1.1 of GOST 34.602-89]

developed as a whole, intended to work independently or as part of another system.

Additionally, technical specifications for parts of the NPP can be developed: for the NPP, sets of NPP tasks, etc. in accordance with the requirements hereof; at the expense and in accordance with the standards of the ESKD and SRPP; in accordance with ESPD standards; in accordance with GOST 19.201 and NTD valid in the department.

Note - The terms of reference for an automated control system for a group of interconnected objects should include only requirements common to the group of objects. The specific requirements of an individual object should be reflected in the technical specifications for the automated control system of this object [from clause 1.2 of GOST 34.602-89]

Requirements for AS in the scope established by this standard may be included in the newly created one. In this case, technical specifications for the nuclear power plant are not developed [from clause 1.3 of GOST 34.602-89]

The requirements included in the technical specifications for nuclear power plants must correspond to modern ones and not be inferior to similar requirements imposed on the best modern domestic and foreign ones. The requirements specified in the technical specifications for the NPP should not limit the system in the search and implementation of the most technical, technical, economic and other solutions [from clause 1.4 of GOST 34.602-89]

Technical specifications for nuclear power plants are developed on the basis of initial data, including those contained in the final documentation “” established [from clause 1.5 of GOST 34.602-89]

The technical specifications for the NPP include only those requirements that complement the requirements for a given type (ACS, CAD, ASNI, etc.) contained in the current ones, and are determined by the specifics of the specific object for which the system is being created [from clause 1.6 of GOST 34.602- 89]

To the technical specifications for the AS, they are drawn up with the addition or and. The addition or the specified protocol is an integral part of the technical specifications for the NPP. On the title page of the technical specification for the speaker there must be the entry “Valid from...” [from clause 1.7 of GOST 34.602-89]

Composition and content

Purpose of the system

In the “Purpose of the system” subsection, indicate the type (, etc.) and the list of automation objects () on which it is intended to be used.

For ACS, additionally indicate the list and [from clause 2.4.1 of GOST 34.602-89]

Goals of creating the system

In the subsection “Goals for creating a system,” they also provide the required technical, technological, production, economic or other indicators of the automation object that must be achieved as a result of creating an automated system, and indicate the criteria for assessing the achievement of the goals for creating the system [from clause 2.4.2 of GOST 34.602- 89]

Characteristics of the automation object

In the section “Characteristics of the automation object” the following is given:

1. brief information about the automation object;
2. information about the automation object and environmental characteristics.

Note - For CAD, the section additionally provides the main parameters and characteristics of design objects [from clause 2.5 of GOST 34.602-89]

System requirements

The “System Requirements” section consists of the following subsections:

1. requirements for the system as a whole;
2. requirements for functions (tasks) performed by the system;
3. requirements for types of collateral.

The composition of the system requirements included in this section of the technical specifications for the NPP is established depending on the type, purpose, specific features and conditions of a particular system. Each subsection provides links to current normative and technical documentation that define the requirements for systems of the corresponding type [from clause 2.6 of GOST 34.602-89]

Requirements for the system as a whole

In the subsection “Requirements for the system as a whole” indicate:

• requirements for the structure and functioning of the system;
• requirements for the number and qualifications of system personnel and their mode of operation;
• destination indicators;
• reliability requirements;
• safety requirements;
• requirements for ergonomics and technical aesthetics;
• transportability requirements for mobile speakers;
• requirements for operation, maintenance, repair and storage of system components;
• requirements for protecting information from unauthorized access;
• requirements for the safety of information in case of accidents;
• requirements for protection from external influences;
• requirements for patent purity;
• requirements for standardization and unification;
• Additional requirements.

[from clause 2.6.1 GOST 34.602-89]

Requirements for the structure and functioning of the system

The requirements for the structure and operation of the system include:

1. list, their purpose and main characteristics, requirements for the number of levels and degree of centralization of the system;
2. requirements for methods and means of communication for information exchange between;
3. requirements for the characteristics of the system’s interconnections with adjacent systems, requirements for it, including instructions on methods (automatically, sending documents, by telephone, etc.);
4. requirements for system operating modes;
5. system requirements;
6. perspectives, systems.

Requirements for mathematical software

For the system, requirements are given for the composition, scope of application (limitations) and methods of using mathematical methods and models in the system, standard and algorithms to be developed [from clause 2.6.3.1 of GOST 34.602-89]

Requirements for information support

The requirements for the system are:

1. requirements for the composition, structure and methods of organization in the system;
2. requirements for information exchange between;
3. information requirements with related systems;
4. requirements for the use of all-Russian and registered republican, industry, unified documents and classifiers operating on;
5. application requirements;
6. requirements for the structure of the process of collecting, transmitting data in the system and;
7. requirements for data protection from destruction during and during system power supply;
8. requirements for monitoring, updating and;
9. requirements for the procedure for giving legal force to documents produced by technical means of the NPP (in accordance with GOST 6.10.4).

Requirements for the composition and content of work to prepare the automation object for commissioning of the system

In the section “Requirements for the composition and content of work to prepare the automation object for putting the system into operation,” it is necessary to provide a list of the main activities and their performers that should be performed during. The list of main activities includes:

1. bringing the information entering the system into a form suitable for use (in accordance with the requirements for and);
2. changes that need to be made in the automation object;
3. creating conditions for the functioning of the automation object, under which the compliance of the created system with the requirements contained in is guaranteed;
4. creation of departments and services necessary for the functioning of the system;
5. timing and procedures for staffing and training.

For example, for ACS they give:

• changes in methods used;
• creation of conditions for the operation of the automated control system, under which the system’s compliance with the requirements contained in the technical specifications is guaranteed.

Copyright © LLC "Technical Documentation" 2017. Borrow our materials with brilliance!
When citing our materials on your resources, use active links to them.