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 “Terms of Reference for the Creation automated system". The following is an example of the contents of this document. A possible variant of the TOR is marked 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 cipher consists of the enterprise code, the serial number of the document being developed and its designation, for example, KKB. 123456. 001ТЗ.

1.2 The number of the contract 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 The name of the organizations of the Developer and the Customer of the system and their details.

1.4 Deadlines for the implementation of work on the creation of the system

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

Stages of work:

1. Design work - 2 months.

2. Completion and manufacture of equipment - 3 months.

3. Development of software together with equipment at the contractor's stand. Supply of equipment to the Customer - 1 week.

4. Chief of installation work on the equipment of automated process control systems - 1 week.

5. Start-up and adjustment work on the equipment of automated process control systems - 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 automated control system for the technological process of mashing and filtering beer wort is designed for:

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

- regulation of technological parameters;

- control of actuators and equipment drives;

- signaling the limit values ​​of the process parameters and the state of the equipment;

- 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 operational personnel.

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

2.2 Purpose of creation:

When developing this section, it must be taken into account that the implementation of the process control system should ensure the achievement of the main goal of the enterprise's policy in the field of quality. Depending on the specifics of production and the features of the APCS being created, the goals can 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 due to the production of competitive products;

- stabilization of technological parameters and quality indicators of products;

- increase in the output of marketable products;

- reduction of material and energy;

- improvement of management efficiency, due to the increase in information support;

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

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

- improving the quality indicators of the final product (indicate specifically which indicators and which products);

- prevention of emergencies;

- improvement of the environmental situation by reducing the pollution of industrial joints and the emission of harmful substances into the atmosphere (if it 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 scheme should be provided indicating technological objects, main and auxiliary material flows, a description of the processing technology and the purpose of the equipment.

APPENDIX 2. The initial list of inputs-outputs of the automated control system for the section for mashing and filtering beer wort.

APPENDIX 3. Consolidated lists of inputs and outputs of the DCS of the area for mashing and filtering beer wort.

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

4. System Requirements

The system must perform information, control functions, as well as signaling and blocking functions.

APCS should provide:

4.1. Requirements for the structure and functioning of the system

APCS should perform the following functions:

1. Automated collection and primary processing of technological information:

a) Interrogation of analog sensors:

- steam pressure in the mashers and wort kettle and at their inlet;

- the level of mash in mash machines;

- the density of the saccharified mash in the lauter tun;

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

- wort flow after hop separator

b) Interrogation of discrete sensors:

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

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

- electric drives for agitators in mash machines and wort kettle;

- electric drives of pumps pumping mash between mash machines;

- control valves for supplying steam to the mashing apparatus and the brew kettle;

- control valves for water supply to masher I, lauter tun and hop separator;

- control valve for the supply of saccharified mash to the filtration tank;

- valves for crushed malt supply to the mash apparatus I;

- valves for supplying hops to the brew kettle;

- valves for supplying hopped wort to the hop separator;

- valves for the release of wort from the filtration tank;

- valves for the release of hot wort from the hop separator.

3. Warning signaling when technological parameters go beyond the set value:

- mash temperatures in the mash apparatus and wort kettle;

- water temperature at the inlet to masher I, lauter tun and hop separator;

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

- the flow rate of steam entering the mash apparatus and the brew kettle;

- the flow rate of water entering the mash apparatus I, the lauter tun and the hop separator;

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

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

4. Process control in real time.

4.1. Regulation of technological parameters:

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

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

- control of the duration of mashing in the mash apparatus I by a signal from the saccharimeter;

- control of the duration of wort brewing in the wort kettle by means of a valve;

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

- regulation of the level of hopped wort in the wort kettle by feeding hops and sugared 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 by a signal from the density sensor.

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

4.3. Formation of blocking commands when certain parameters go beyond allowed values(specify which locks are provided).

5. Calculation of technological and technical and economic indicators

The calculation of technical and economic indicators includes the determination of 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 process and equipment, presented in the form of mnemonic diagrams, trends, summaries, parameter values.

On the displayed frames, warning and emergency signaling should be provided for two violation boundaries (upper and lower), an alarm for exceeding the reliability limits and an alarm for a sensor break. Out of bounds signaling is expressed by flashing the values ​​of the variables, after the flashing is removed, the values ​​of the variables are lit with the color corresponding to the state of the variables.

8. Printing of technological documentation

Any information (mimic diagrams, trends) at any time must be able to be printed by process operators 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 personnel of the system, in accordance with the role they perform, are divided into two categories:

Operational technological personnel: apparatchiks, 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, the personnel must receive appropriate training.

4.3. Reliability Requirements

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

Centralized control of parameters and signaling 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 allowable recovery time of 1 hour. This time should include, in addition to the time of failure detection and replacement of a failed plug-in unit, the organizational time spent on receiving and delivering a serviceable unit from the spare parts kit to the equipment location and checking it. At the same time, the system must allow the restoration of its individual parts without interrupting the operation of the entire system.

The average service life of the system is 10 years. Warranty period of storage of the system is 2 years from the date of its acceptance at the factory. The warranty period of operation is 18 months within the warranty period of storage, provided that the customer observes the storage and operation conditions specified in this TOR.

The system must be provided with a set of spare parts and accessories for the entire guarantee period determined by the reliability calculation, while the probability of providing spare parts for this period should 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 contract.

4.4. Safety requirements

1. In the system, if necessary, signals should be introduced that warn of the formation of unacceptable concentrations in production areas.

2. Technical means (sensors, actuators, etc.) located in explosive areas of premises and outdoor installations and having connections with the system must have a degree of protection corresponding to the group and category of the explosive mixture that can form in this area.

3. Pre-emergency signaling must be provided for the parameters that determine the explosive hazard of objects.

4. For actuating mechanisms, signaling of extreme positions should be provided.

5. Provide sound alarm:

Preventive technological;

emergency;

6. All external elements of the technical means of the system under voltage must be protected from accidental human contact, and the technical means themselves must be grounded.

4.5. Ergonomics and technical aesthetics requirements

Interaction of a person with the system is carried out through controllers equipped with a hard disk, an alphanumeric keyboard, and a functional graphic 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 complete characteristics the current state of the technological process and equipment and the ability to control them in the most convenient way for perception in each specific situation.

The screen size must be sufficient to display certain fragments of each process unit. Fragments should not be oversaturated with information and a variety of colors.

Warning alarms should be accompanied by a flickering or color change of the digital values ​​of the variables or the background on the display screens. Emergencies are accompanied, additionally, by an audible alarm acknowledged by the operator-technologist. The connection of the process operator with the process and the system is realized through requests, which should be as simple as possible and have an adequate mnemonic.

The location of the technical means of the system should be rational both in terms of mounting connections between them and the convenience of their operation and maintenance.

4.6. operating requirements, maintenance, repair and storage

The system can be operated around the clock. Types, frequency and maintenance schedule of technical means should be specified in the relevant instructions.

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

Fluctuations in the voltage of the industrial network (starts of pumps, compressors, welding machines, etc.) and impulse noise should not affect the power supply of the automatic process control system.

The maintenance staff should include specialists in the following profiles:

According to KIP and A;

Technologist to support functional tasks;

Electronic 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, to prevent the 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 - a priority. Password enforcement can be performed using keys or programmatically.

4.8. Requirements for means of protection against external influences

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

Ambient temperature from 15 to 25С;

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

Atmospheric pressure from 84 kPa to 107 kPa (from 630 to 800 mmHg)

The protection of technical equipment from external electric and magnetic fields, as well as interference in the power 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 technological equipment;

The use of twisted pairs for the transmission of electrical signals;

Noise filtering on power circuits and information circuits;

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

4.9. patent clearance requirements

The developed system is not intended for export, so there are no restrictions on patent purity.

4.10. Requirements for standardization and unification

The developed system should 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. Information support requirements .

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

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

Limits of variables of different levels, settings of control algorithms, information of software binding to a specific object;

Texts of programs and load modules.

To exchange information within a 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 of technological personnel;

Engineering station.

For the convenience 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) should be provided:

1. Overview panels

Designed to control the work 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 technological equipment, instrumentation and control equipment, and display the structure of control and protection algorithms, and their state.

3. Dashboards

Represent and describe the state of the front panels of 8-12 devices.

4. Adjustment panels

Describe the parameters of a specific device / device / controller and provide the possibility of its settings.

5. Alarm panels

Reflect in chronological order the warning and pre-alarm signaling of the process.

6. Process Progress Recording Panels (Trends) 2 types of panels should be provided for graphical display of process progress data over time:

Group panel of 6 - 12 trends,

Single trend panel.

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

Button on the functional keyboard;

Indicating an element on the screen;

Choice from the menu;

Data entry through the corresponding zone on the screen.

All tuning 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, focused on the specialists of the process control system developers. These tools can significantly minimize the development time, and give exceptional clarity to the algorithms for processing information and control.

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

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.

For the development of emergency protection systems, it is additionally provided:
3. Ladder Logic Diagrams - Graphical tools for describing logic circuits.

For the development of applied programs, in particular, technological and feasibility calculations, it should 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 demand and on time with appropriate priorities.

All semantic and textual information presented on monitor screens and in printed reports for technological 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 that operates in the environment of a multitasking real-time operating system. The characteristics of the software must meet the requirements for performing the functions specified in the previous sections.

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

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

All erroneous situations that occur during the operation of programs must be diagnosed, accompanied by messages, and must not cause disturbances in the operation of the System.

5.4. Requirements for applied software ("mathematical") support.

The mathematical software of the System 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 application software of the process control system must ensure the implementation of the required algorithms for control, regulation and protection, 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 automated process control systems should be sufficient to implement the functions defined by this TOR, and be built on the basis of the following specialized software and hardware systems:

Means of instrumentation and automation, including sensors, actuators, electronic microprocessor controllers and in-line quality analyzers;

Peripheral microprocessor devices - control subsystems, or controllers;

Multifunctional operator and engineering stations;

Means of data archiving;

Network hardware;

Specialized microprocessor controllers of the PAZ system;

Means of metrological verification of equipment.

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

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

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

Signal input 4-20mA;

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

Millivolt inputs with built-in IS 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 laws of regulation must be carried out through modules for outputting analog current signals to electro-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 assurance.

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:

Appointment of IS, and information about its use in the field (or outside the scope) of the 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 measured quantities and their characteristics;

Lists of measuring channels and norms of their errors;

Measurement conditions;

Terms of metrological service.

The specification of the APCS equipment should include special technical and software for calibrating the measuring channels.

The range of controlled 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 IS, recommendations (instructions) for verification (calibration) of the MC, approved in the prescribed manner, must be submitted.

Appropriate operating conditions (temperature, humidity) must be provided for the technical means involved in the process of measuring controlled parameters. The conditions of their operation in the control rooms should be monitored.

5.7. Organizational support of process control systems

should be sufficient for the effective performance by the personnel of the duties assigned to them for the operation of the System. Organizational support should include requirements for the number and qualifications of the APCS and instrumentation personnel, instructions for each type of activity, and a precise definition of the functions performed.

Document's name:
Document Number:	34.602-89
Type of document:	GOST
Host body:	State Standard of the USSR
Status:	current
Published:	official publication
Acceptance date:	March 24, 1989
Effective start date:	January 01, 1990
Revision date:	February 01, 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

Introduction date 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 INTRODUCED BY Decree State Committee USSR according to the standards of 03.24.89 N 661

3. REPLACE GOST 24.201-85

4. REFERENCE REGULATIONS AND TECHNICAL DOCUMENTS

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

5. RE-ISSUE


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 processing the document "Terms of Reference for the creation (development or modernization) systems" (hereinafter referred to as TK for NPPs).

The recommended procedure for the development, approval and approval of technical specifications for nuclear power plants is given in Appendix 1.

1. GENERAL PROVISIONS

1. GENERAL PROVISIONS

1.1. ToR for the NPP is the main document that defines the requirements and procedure for the creation (development or modernization - further creation) of an automated system, in accordance with which the development of the NPP and its acceptance upon commissioning is carried out.

1.2. Specifications for nuclear power plants are developed for the system as a whole, designed to work independently or as part of another system.

Additionally, technical specifications for parts of the NPP can be developed: for NPP subsystems, NPP task complexes, 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 the ESPD standards; for information products in accordance with GOST 19.201 and NTD, which is in force in the department of the NPP customer.

Note. In the TOR for the automated control system for a group of interrelated objects, only requirements common to a group of objects should be included. The specific requirements of a separate control object should be reflected in the TOR for the ACS of this object.

1.3. The requirements for the AU in the scope established by this standard can be included in the assignment for the design of a newly created automation object. In this case, technical specifications for nuclear power plants are not developed.

1.4. The requirements included in the TOR for NPPs must correspond to the current level of development of science and technology and not be inferior to similar requirements for the best modern domestic and foreign analogues.

The requirements specified in the TOR for NPPs should not limit the system developer in the search and implementation of the most effective technical, feasibility and other solutions.

1.5. Specifications for NPPs 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 NPPs", established by GOST 24.601.

1.6. The TOR for nuclear power plants includes only those requirements that supplement the requirements for systems of this type (ACS, CAD, ASNI, etc.) contained in the current NTD, and are determined by the specifics of the particular object for which the system is being created.

1.7. Changes to the TOR at the NPP are formalized by an addition or a protocol signed by the customer and the developer. The addendum or the specified protocol is an integral part of the ToR for the NPP. On the title page of the TK on the AC should be the entry "Valid from ...".

2. COMPOSITION AND CONTENT

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

1) general information;

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

3) characteristics of automation objects;

4) system requirements;

5) the 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) requirements for documentation;

9) development sources.

Applications may be included in the TOR for the AU.

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

The TOR for parts of the system does not include sections that duplicate the content of the sections of the TOR for the NPP as a whole.

2.3. In the section "General information" indicate:

1) the full name of the system and its symbol;

2) cipher of the topic or cipher (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 completion of work on the creation of the system;

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

7) the procedure for formalizing and presenting to the customer the results of work on the creation of the system (its parts), on the manufacture and adjustment of individual means (hardware, software, information) and software and hardware (software and methodological) complexes of the system.

2.4. The section "Purpose and objectives of the creation (development) of the system" consists of subsections:

1) purpose of the system;

2) the purpose of creating the system.

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

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

2.4.2. In the subsection "Goals of creating a system" give 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 AU, and indicate the criteria for assessing the achievement of the goals of creating a system.

2.5. In the section "Characteristics of the automation object" they give:

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 the functions (tasks) performed by the system;

3) requirements for types of collateral.

The composition of the requirements for the system included in this section of the ToR for NPPs is established depending on the type, purpose, specific features and operating conditions specific system. Each subsection provides links to the current NTD, which define 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 the system personnel and their mode of operation;

- destination indicators;

- reliability requirements;

- safety requirements;

- requirements for ergonomics and technical aesthetics;

- requirements for transportability for mobile AU;

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

- requirements for the protection of information from unauthorized access;

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

- requirements for protection from the influence of external influences;

- requirements for patent clearance;

Requirements for standardization and unification;

Additional requirements.

2.6.1.1. The requirements for the structure and functioning 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 interconnections of the created system with related systems, requirements for its compatibility, including instructions on how to exchange information (automatically, by sending documents, by phone, etc.);

4) requirements for the operating modes of the system;

5) requirements for diagnosing the system;

6) prospects for development, modernization of the system.

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

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

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

- required mode of work of NPP personnel.

2.6.1.3. In the requirements for indicators of the purpose of the AS, the values ​​of the 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 management methods, to deviations in the parameters of the control object;

- admissible limits of modernization and development of the system;

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

2.6.1.4. Reliability requirements include:

1) the 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 should 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 creating a system in accordance with the current regulatory and technical documents.

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

2.6.1.6. The requirements for ergonomics and technical aesthetics include AS indicators that specify the required quality of human-machine interaction and the comfort of staff working conditions.

2.6.1.7. For mobile nuclear power plants, the transportability requirements include design requirements that ensure the transportability of the system's technical means, as well as requirements for vehicles.

2.6.1.8. Operation, maintenance, repair and storage requirements include:

1) conditions and regulations (mode) of operation, which should 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 allowable areas for the placement of personnel and TS of the system, for the parameters of power supply networks, etc.;

3) requirements for the number, qualifications of maintenance personnel and modes of their work;

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

5) requirements for the maintenance schedule.

2.6.1.9. The requirements for protecting information from unauthorized access include the requirements established in the NTD operating in the industry (department) of the customer.

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

2.6.1.11. In the requirements for means of protection against external influences, the following are given:

1) requirements for radio-electronic protection of NPP facilities;

2) requirements for resistance, 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 that establish the required degree of use of standard, unified methods for implementing the functions (tasks) of the system, supplied software, typical 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, requirements for the use of typical automated workstations, components and complexes.
_____________________
* In the Russian Federation there are PR 50-733-93.

2.6.1.14. Additional requirements include:

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

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

3) system requirements associated with special operating conditions;

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

2.6.2. In the subsection "Requirements for the 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) to be automated;

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

2) time schedule 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, the characteristics of the required accuracy and execution time, the requirements for the simultaneity of the execution of a group of functions, the reliability of the results;

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

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

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

2.6.3.2. For the information support of the system, the following requirements are given:

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 adjacent 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, transferring data in the system and presenting data;

7) to protect data from destruction in case of accidents and power failures of the system;

8) control, storage, updating and recovery of data;

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

2.6.3.3. For the 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 encoding and decoding data, data input / output languages, data manipulation languages, means of describing the subject area (automation object ), to ways of organizing the dialogue.

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

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

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

3) if it is necessary to harmonize the newly developed software with the fund of algorithms and programs.

2.6.3.5. For the 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 that are acceptable for use in the system;

2) to the functional, constructive and operational characteristics of the technical support of the system.

2.6.3.6. The requirements for metrological support include:

1) a 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 the 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 the metrological support of hardware and software included in the measuring channels of the system, built-in control tools, metrological suitability of the measuring channels and measuring instruments used in the adjustment and testing of the system;

6) type of metrological certification (state or departmental) with an indication of the procedure for its implementation and 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 the NPP personnel and the personnel of the automation object;

3) to protection against erroneous actions of the system personnel.

2.6.3.8. For methodological support of CAD, requirements are given for the composition of the regulatory and technical documentation of the system (a list of standards, norms, methods, etc. used during 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 stages 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 creating a system, or a record identifying the person responsible (customer or developer) for carrying out these works.

This section also provides:

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

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

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 the creation of the system, indicating their deadlines and executing organizations (if necessary).

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

1) types, composition, scope and methods of testing the system and its components (types of tests in accordance with the 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 agreeing and approving acceptance documentation;

3) the 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 putting the system into operation" 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 AU 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 TOR is guaranteed;

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

5) terms and procedure for staffing and staff training.

For example, for ACS they give:

- changes in the applied management methods;

- creation of conditions for the operation of the ACS components, under which the system's compliance with the requirements contained in the TOR 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 that meet the requirements of GOST 34.201 and the NTD of the customer's industry, agreed by the system developer and customer; list of documents issued on machine media; requirements for microfilming documentation;

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

3) in the absence of state standards that define the requirements for documenting system elements, they 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 study, reports on completed research works, information materials on domestic, foreign analogue systems, etc.), on the basis of which the TK was developed and which should be used to create the system.

2.12. The composition of the TOR at NPPs, in the presence of approved methods, includes applications 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 TOR for the NPP as agreed between the developer and the customer of the system.

3. DESIGN RULES

3.1. Sections and subsections of the TOR for the NPP must be placed in the manner prescribed in section 2 of this standard.

3.2. TK for the AU is drawn up in accordance with the requirements of GOST 2.105 on sheets of A4 format in accordance with GOST 2.301 without a frame, a main inscription and additional columns to it.

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

3.3. The values ​​of indicators, norms and requirements indicate, as a rule, with maximum deviations or maximum and minimum values. If these indicators, norms, requirements are unambiguously regulated by the NTD, the TOR for the NPP should provide 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 the specific values ​​of indicators, norms and requirements cannot be established in the process of developing the TOR for the NPP, it should record the procedure for establishing and agreeing on these indicators, norms and requirements:

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

3.4. On the title page, the signatures of the customer, developer and coordinating organizations are placed, which are sealed with a stamp. If necessary, the title page is drawn up on several pages. The signatures of the developers of the ToR for the NPP and the officials involved in the approval and review of the draft ToR for the NPP are placed on the last page.

The form of the title page of the TK for the AU is given in Appendix 2. The form of the last sheet of the TK for the AU is given in Appendix 3.

3.5. If necessary, on the title page of the TK on the AU, it is allowed to place codes established in the industry, for example: security stamp, work code, registration number of the TK, etc.

3.6. The title page of the Supplement to the ToR for NPPs is drawn up in the same way as the title page of the terms of reference. Instead of the name "Terms of Reference" they write "Addendum N ... to the TOR for NPPs ...".

3.7. On subsequent sheets of the Supplement to the TOR on the AU, 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 supplement to the TOR, the numbers of the relevant paragraphs, subparagraphs, tables of the main TOR at the NPP, etc., should be indicated. and use the words: "replace", "supplement", "delete", "rewrite".

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

1. The draft TOR for NPPs is developed by the system developer with the participation of the customer on the basis of technical requirements (application, performance specification, etc.).

In the case of a competitive organization of work, the variants of the draft TOR for the NPP are considered by the customer, who either chooses the preferred option, or, on the basis of a comparative analysis, prepares the final version of the TOR for the NPP with the participation of the future NPP developer.

2. The need for approval of the draft ToR for NPPs with the state supervision authorities and other interested organizations is determined jointly by the customer of the system and the developer of the draft ToR at the NPP.

The work on the approval of the draft TOR for NPPs is carried out jointly by the developer of the TOR for NPPs and the customer of the system, each in the organizations of their own ministry (department).

3. The term for approval of the draft TOR for NPPs in each organization should not exceed 15 days from the date of its receipt. It is recommended to send copies of the draft ToR for nuclear power plants (copies) simultaneously to all organizations (divisions) for approval.

4. Comments on the draft TOR for NPPs must be submitted with technical justification. Decisions on comments must be made by the developer of the draft ToR for the NPP and the customer of the system prior to the approval of the ToR for the NPP.

5. If disagreements arose between the developer and the customer (or other interested organizations) when agreeing on the draft TOR at the NPP, then a protocol of disagreements is drawn up (arbitrary form) and a specific decision is made in the prescribed manner.

6. Approval of the draft TOR at the NPP is allowed to be drawn up as a separate document (letter). In this case, under the heading "Agreed" make a link to this document.

7. Approval of technical specifications for nuclear power plants is carried out by the heads of enterprises (organizations) of the developer and customer of the system.

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

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

10. Coordination and approval of additions to the ToR for NPPs is carried out in the manner established for the ToR for NPPs.

11. Changes to the TOR at NPPs are not allowed to be approved after the system is submitted for its turn for acceptance tests.

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

__

name of the organization - developer of technical specifications for nuclear power plants

APPROVE		APPROVE
Head (position, Business name - AC customer)		Head (position, Business name - AS developer)
Personal signature Seal the date	Decryption signatures	Personal signature Seal the date	Full name

_____________________________________________________________________________________

name of AC type

_____________________________________________________________________________________

name of the automation object

_____________________________________________________________________________________

abbreviation AS

TECHNICAL TASK

On _______ sheets

Valid from

AGREED

Head (position, name
coordinating organization)

	Personal signature Seal the date	Full name

___________________________________

MADE

	Position of the performer	Full Name

AGREED

Name of organization, enterprise	Job title	Full Name

The text of the document is verified by:
official publication
Information technology.
Automated systems.
Basic provisions:
Sat. GOSTs. - 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
Type of document:	GOST
Host body:	State Standard of the USSR
Status:	current
Published:	official publication Information technology. Automated systems. Basic provisions: Sat. GOSTs. - M.: IPK Standards Publishing House, 2002
Acceptance date:	March 24, 1989
Effective start date:	January 01, 1990
Revision date:	February 01, 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 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. In the process of work, I realized that it would not work 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 terms of reference, 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 the identification and formulation of requirements for the information system.

First you need to figure out what question really interests those who ask "How to develop a technical task?". The fact is that the approach to the development of technical specifications will greatly depend on the purposes for which this is done, and also 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 person must develop the TOR and give it to a third-party organization for development;
• A commercial organization decided to implement an automated system. It has its own IT service. We decided to do this: develop a technical task, then coordinate it between the IT service and interested parties, and implement it on our own;
• The state structure decided to start an IT project. Everything is so muddy here, a lot of formalities, kickbacks, cuts, etc. I will not consider this option in this article.
• An IT company is engaged in 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 its own specialists with their own views, and they have specific requirements for the terms of reference.
2) The terms of reference are developed for our own developers (the client does not care).
3) The terms of reference are developed for transfer to the contractor (a group of programmers who are outside the company's staff, or an individual specialist).
4) There is a misunderstanding between the companies 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 latter case may seem like a paradox, but it is true.

• Other, less common options are also possible;

I think now the reader should have questions:

• Why can't the terms of reference always be developed in the same way?
• Are there any standards, methods, recommendations? Where to get them?
• Who should develop the terms of reference? Does this person need to have any special knowledge?
• How do you know if the terms of reference are well written or not?
• At whose expense should it be developed, and is it needed at all?

This list could be endless. I speak so confidently because I have been in professional software development for 15 years, and the question of technical specifications pops up in any team of developers with whom I have to work. The reasons for this are different. Raising the topic of developing technical specifications, I am well aware that I cannot present it 100% for all those interested in the topic. But, I'll try, as they say, "put everything on the shelves."

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 your own brilliant thoughts . It is enough to type in the search engine “How to develop terms of reference” and you will be able to read a lot of interesting, but, unfortunately, repeated many times. As a rule, those who like to be clever on the forums (try to search after all!), Never made a sensible TK themselves, and continuously quote GOST recommendations on this issue. And those who really seriously deal with the issue usually have no time to sit on the forums. By the way, we will also talk about GOSTs.

Over the years of my work, I had to see many options for technical documentation, compiled by both individual specialists and eminent teams and consulting companies. Sometimes I also do such activities: I allocate time for myself and search for information on a topic of interest from unusual sources (such 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 public sources or the irresponsibility of consultants (they scatter information over the Internet). Therefore, I immediately say: I do not share confidential information that belongs to other companies, regardless of the sources of its occurrence (professional ethics).

What is a technical task?

The first thing we will do now is to figure out what kind of animal this is - "Terms of Reference".

Yes, there really are GOSTs and standards in which attempts are made 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 is somewhere in the middle. I would answer with 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 the GOST clearly does not even give a definition, it only says: “ToR for NPP is the main document that defines the requirements and procedure for the creation (development or modernization - further creation) of an automated system, in accordance with which the development of the NPP and its acceptance upon commissioning into action."

If someone is wondering what GOSTs I'm talking about, then here they are:

• GOST 2.114-95 " one system design documentation. Specifications";
• 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. Terms of reference for the creation of an automated system.

A much better definition is presented on Wikipedia: “The terms of reference is the source document for the design technical object. The terms of reference establishes the main purpose of the object being developed, its technical and tactical and technical 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. The task as a source document for the creation of something new exists in all areas of activity, differing in name, content, and order of registration. (For example, a design assignment in construction, a combat assignment, homework, contract for literary work)».

So, as follows from the definition, the main purpose of the terms of reference is to formulate requirements for the object being developed, in our case, for an automated system. It's time to take on the main thing: to put everything "on the shelves", as promised.

What do you need to know about the requirements? It must be clearly understood that all requirements must be divided by type and by properties. Now we will learn how to do it. To separate the requirements by type, GOST will just 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;
• Requirements for security and access rights;
• Personnel qualification requirements, etc.

I think it is obvious to you that well-defined requirements for functionality are the key factor in a successful technical task. It is these requirements that are devoted to most of the works and methods that I spoke about. Functionality requirements are 90% of the complexity of the work on the development of technical specifications. Everything else is often "camouflage" that is put on these requirements. If the requirements are formulated poorly, then no matter what beautiful camouflage you put on them, a successful project will not work. Yes, formally all the requirements will be met (according to GOST), the TOR has been developed, approved and signed, and money has been received for it. So what? And then the fun begins: what to do? If this is a project on the State order, then there are no problems - there is such a budget that it won’t fit into any pocket, everything will be clarified in the process of implementation (if any). It is in this way that most of the budgets of projects on State orders are sawn. (They fired up "TK", leaked ten million, but did not begin to do the project. All formalities were observed, there were no guilty parties, a new car was near the house. Beauty!). But we are talking about commercial organizations where money is counted, and the result is different. Therefore, let's deal with the main thing, how to develop useful and working technical specifications.

I said about the types of requirements, but what about the properties? If the types of requirements can be different (depending on the goals of the project), then with the 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 tested;

Moreover, the last property is impossible without the two previous ones, 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 possession of these three properties of requirements that skill and professionalism lie. In fact, everything is very simple. When you figure it out.

On this story about what such a technical task could be completed and move on to the main thing: how to formulate requirements. But it's not all that fast. There is another extremely important point:

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

There is a very insidious thing in the answers to these questions. That is why disputes often arise about the sufficiency or absence of the necessary detailing of requirements, about the comprehensibility of the document by the customer and performers, about redundancy, presentation format, etc. And where is the boundary between the technical task and the technical project?

So here it is: technical task- This is a document based on requirements formulated in a language understandable (usual, familiar) for the customer. In this case, industry terminology understandable to the customer can and should be used. There should not be any bindings to the features of the technical implementation. At the TOR stage, in principle, it does not matter on which platform these requirements will be implemented. Although there are exceptions. When it comes to implementing a system based on an existing software product, then such a binding can take place, but only at the level of screen forms, report forms, etc. A business analyst should be involved in clarifying and formulating requirements, as well as developing terms of reference. And certainly not a programmer (unless he combines these roles, this happens). This person should speak with 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 terms of reference. Just in this document, data structures, triggers and stored procedures, algorithms and other things that will be required by technical specialists are described. It is not necessary for the customer to delve into this at all (he may not understand such terms either). The technical project is done by the system architect (combining this role with a programmer is quite normal). To be more precise, a group of AO specialists led by an architect. The larger the project, the more people working on the terms of reference.

What do we have in practice? It's funny to watch when the director is brought for approval by the terms of reference, which is replete with technical terminology, a description of data types and their values, the structure of the database, etc. He, of course, tries to understand, since it is necessary to assert, trying to find familiar words between the lines and not lose the chain business requirements. What, familiar situation? And how does it end? As a rule, such TOR is approved, then implemented, and in 80% of cases then it does not correspond at all to the fact of the work performed - they decided to change, redo a lot of things, misunderstood, thought wrong, etc. And then the handover series begins. “But here it’s not the way we need it,” but “it won’t work for us,” “it’s too complicated,” “it’s inconvenient,” etc. Familiar?! So I know, I had to fill 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. It floats between TK and TP in a variety of ways. And that's bad. And it turns out that way, because the development culture has become weak. This is partly due to the competence of specialists, partly due to the desire to reduce budgets and deadlines (after all, documentation takes a lot of time - this is a fact). There is another important factor influencing the use technical project as a standalone document: the rapid development of rapid development tools as well as development methodologies. But this is a separate story, I will say a few words about it below.

Another small but important point. Sometimes a technical task is called a small piece of requirements, simple and understandable. For example, to refine the search for an object according to some conditions, add a column to the report, etc. This approach is quite justified, why complicate your life. But it is used not on large projects, but on minor improvements. I would say it's closer to maintaining a software product. In this case, a specific technical solution for the implementation of the requirement can also be described in the terms of reference. For example, “To make such and such a change in the 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.

Do you really need a technical specification? What about a technical project?

Am I overheated? Is this possible, without a technical task at all? Imagine perhaps (more precisely, it occurs), and this approach has many followers, and their number is increasing. As a rule, after young specialists read books about Scrum, Agile and other rapid development technologies. In fact, these are wonderful technologies, and they work, only they do not 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 fixing of requirements, and it is clearly stated there. It is there that the requirements are fixed based on the three wonderful properties that I spoke about above. It's just that some people's consciousness is arranged in such a way that if something can be simplified, let's simplify it to complete absence. As Albert Einstein said, "Make it as simple as possible, but not simpler than that." Words of gold go with everything. So the terms of reference are needed, otherwise you will not see a successful project. Another question is how to compose 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. Basically, I agree with this.

But what about the technical project? This document is very useful and has not lost its relevance. Moreover, often it is simply impossible to do without it. Especially when it comes to transferring development work to a third party, according to the principle of outsourcing. If this is not done, there is a risk of learning a lot about how the system you have in mind should look like. Should the customer get to know him? If he wants to, why not, but there is no need to insist and approve this document, it will only restrain 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 bureaucratized, then generally leave all the nerves there. It is precisely this kind of design reduction that is being discussed in modern rapid development methodologies, which I mentioned above. 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 TOR that is understandable to the customer, and use the technical project as an internal document for the relationship between the system architect and programmers.

An interesting detail about technical design: some development tools arranged according to the principle of subject orientation (such as 1C and similar) suggest that design (meaning the documentation process) is required only in really complex areas where interaction between entire subsystems is required. In the simplest case, for example, to create a reference book, a document, only correctly formulated business requirements are sufficient. This is evidenced by the business strategy of this platform in terms of training specialists. If you look at the exam ticket of a specialist (that’s what it is called, and not a “programmer”), you will see that there are only business requirements there, and how to implement them in a programming language is the task of a specialist. That part of the problem that the technical project is designed to solve, the specialist must solve "in the head" (we are talking about tasks medium difficulty), and here and now, following certain development and design standards, which are again formed by 1C for its platform. Thus, out of two specialists, the result of whose work outwardly looks the same, one can pass the exam, and the second cannot, as he grossly violated the development standards. It is obviously assumed that specialists should have such qualifications that they can design typical tasks on their own, without involving system architects. And this approach works.

Let's continue the study of the question: "What requirements should be included in the terms of reference?"

Formulation of requirements for the information system. TK structure

Let's make it clear right away: we will talk about the formulation of 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 refinements can be performed at this stage, but just refinements. The automation project itself does not solve the business problem—keep that in mind. This is an axiom. For some reason, some managers are trying to refute it, believing that if they buy the program, then order will come in a chaotic business. But after all, an axiom is an axiom that does not require proof.

As with any activity, the formulation of requirements can (and should) be divided into stages. Everything has its time. This is hard intellectual work. And, if it is treated 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 to 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 such as C++, then detailed technical design is indispensable. If we are talking about the implementation of a system on the 1C platform, then the situation with the 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 requirements statement is the main part of the terms of reference, in some cases it becomes the only section of the TOR, you should pay attention to the fact that this is an important document and should be drawn up accordingly. Where to begin? First of all, you need to start with the content. Compose the content and then start unrolling it. Personally, I do this: first I outline the content, describe the goals, all the introductory information, and then I take on the main part - the formulation of the requirements. Why not vice versa? 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 describing all the introductory information, you tune in to the main thing. Well, whoever likes it. Over time, you will develop your own template for the terms of reference. To begin with, I recommend taking as content exactly the one that is described in GOST. It's great for content! Then we take and begin to describe each section, not forgetting the recommendations for 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 TK 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 on the creation of the system.

6. Order of 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. Development sources.

In total, there are nine sections, each of which is also divided into subsections. Let's take 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 cipher or cipher (number) of the agreement;	This is not relevant, but you can specify if required.
Name of enterprises (associations) of the developer and customer (user) of the system and their details;	Specify who (what organizations) will work on the project. You can also specify their roles. You can generally delete this section (rather formal).
The list of documents on the basis of which the system is created, by whom and when these documents were approved;	Useful information. Here it is worth indicating the regulatory and reference documentation that you were provided to familiarize yourself with a certain part of the requirements
Scheduled start and end dates for the creation of the system;	Timing wishes. Sometimes they write about this in the TOR, but more often such things are described in work contracts
Information about the sources and procedure for financing the work;	Similarly, as in the previous paragraph about the timing. More relevant for government orders(for state employees)
The procedure for registration and presentation to the customer of the results of work on the creation of the system (its parts), on the manufacture and adjustment of individual tools (hardware, software, information) and software and hardware (software and methodological) systems of the system.	I don’t see the need for this paragraph, the requirements for documentation are made separately, and besides this, 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 with it in practice
Purpose of the system	On the one hand, the appointment is simple. But I would like to be specific. If you write something like “high-quality automation of warehouse accounting in company X”, then you can then discuss the result for a long time at its completion, even regardless of the good wording of the requirements. The customer can always say that he meant something else by quality. In general, nerves can spoil each other a lot, but why? It is better to immediately write something like this: "The system is designed to maintain warehouse records in company X in accordance with the requirements fixed in this specification."
The goals of creating a system	Goals are definitely an important section. If we turn it on, then we must be able to formulate these goals. If you're having trouble setting goals, it's best to skip this section altogether. An example of an unsuccessful goal: "Ensure fast paperwork by the manager." 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." Such a goal may appear if, for example, the manager currently spends about an hour on this, which is too much for this company and it is important for them. In this formulation, the goal already intersects with the requirements, which is quite natural, when expanding the tree of goals (dividing them into smaller related goals), we will approach the requirements anyway. Therefore, you should not get carried away. In general, the ability to identify goals, formulate them, build a tree of goals is a completely separate topic. Remember the main thing: if you know how - write, if you are not sure - do not write at all. What happens if you don't set 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 with it in practice
General system requirements. GOST deciphers the list of such requirements: requirements for the structure and functioning of the system; requirements for the number and qualifications of the personnel of the system and the mode of its work; destination indicators; reliability requirements; safety requirements; requirements for ergonomics and technical aesthetics; transportability requirements for mobile AS; requirements for operation, maintenance, repair and storage of system components; requirements for the protection of information from unauthorized access; requirements for the safety of information in case of accidents; requirements for protection from the influence of 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 can also have great importance(and in most cases it has). 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 staff are clearly insufficient, it is better to prescribe the requirements for the organization of training, the training program, terms, etc. Requirements for the protection of information from unauthorized access. There are no comments here. This is precisely the requirements for access control 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 the functional requirements (comprehensibility, specificity, testability). Therefore, these requirements can be included in the section with functional requirements. requirements for standardization. If there are any development 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 the integration of systems with each other can be described, a description of the general architecture is presented. More often, integration requirements are singled out in general in a separate section or even a separate technical task - these requirements can turn out to be quite complex. All other requirements are less important and can be left out. In my opinion, they only make the documentation heavier and are of little practical use. And it is very difficult to describe the requirements for ergonomics 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" can be formulated. In my opinion, this is still closer to specific functional requirements, although it refers to ergonomics.
Requirements for the 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 at "3", then the result for the project will be at best "3", or even the project will fail. These are the ones 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 of applies.
Requirements for types of collateral GOST distinguishes the following types: Mathematical informational Linguistic Software Technical Metrological Organizational methodical and others…	At first glance, it may seem that these requirements are not important. This is true for most projects. But not always. When to describe these requirements: No decision has been made as to which language (or platform) development will be in; The system is subject to the requirements of a multilingual interface (for example, Russian / English) For the functioning of the system, 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 some equipment is supposed 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 on the creation of the system

Section 6. Procedure for control and acceptance of the system

What to do with it in practice

Types, composition, scope and methods of testing the system and its components (types of tests in accordance with the current standards applicable to the system being developed); General requirements for the acceptance of work by stages (list of participating enterprises and organizations, place and timing), the procedure for agreeing and approving 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 spelled out. For example, a common trap: the system is done, it is fully functional, but the customer, for some reason, is not ready to work in it. These reasons can be any: once, goals have changed, someone quit, etc. And he says: “Since we are not working with the new system yet, we cannot be sure that it works.” So learn to correctly identify the stages of work, ways 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 the terms of reference, then you can always refer 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 putting the system into operation

	What to do with 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 the contract used to be entered as a text line in an arbitrary form, but now the number is required separately, the date separately, etc. There can be many such conditions. Some of them can be perceived with the resistance of the staff, so it is better to register all such cases at the level of requirements for the order of data entry
Changes to be made in the automation object Creation of conditions for the functioning of the automation object, under which the compliance of the created system with the requirements contained in the TOR 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 this is not done, then any module will not work. Perhaps something has been simplified, but now it 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 subdivisions and services necessary for the functioning of the system; Timing and procedure for staffing and staff training	We have already talked about this before. Perhaps the system is being developed for a new structure or type of activity that did not exist before. If there is no appropriate personnel, and even trained, the system will not work, no matter how competently it is not built.

Section 8 Documentation Requirements

What to do with it in practice

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

Having full documentation is an important part of the result. We all know that documenting something is hard work. Therefore, it is necessary to discuss in advance with the customer what types of documentation will be developed, how they will look (content and preferably examples). Consider how user guides will be presented. Perhaps the customer has accepted corporate standards, so you need to contact 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. We did not agree on the documentation at all and did not talk. And suddenly, when the work is handed over, one of the top managers of the customer, who did not even participate in the project, but participates in the acceptance of work, asks: “Where are the user manuals?”. And he begins to convince you that it is not necessary to agree on the availability of user manuals, this “by itself” is allegedly implied. And that's it, he doesn't want to take the job. At whose expense will you develop guidelines? Many teams have already fallen for this hook.

Section 9 Development Sources

We have considered all the 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 some separate section will not bring you closer to the result, then you do not need it and do not need to spend time on it.

But without the main thing - functional requirements - not a single competent technical task can do. I want to note that in practice such technical tasks are encountered, and how! There are figures who will be able to dilute 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 smart words in it, and even the customer may like it (he will approve it). But working on it may not work, there is little practical use from it. In most cases, such documents are born when you need to get a lot of money specifically for the terms of reference, and you need to do it quickly and without diving into details. Especially if it is known that the matter will not go further, or it will be done by completely different people. In general, just for the development of the budget, especially the state.

In the second article, we will only talk about section No. 4 “System Requirements”, and specifically we will formulate the 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 are developed by specialists either turn out to be unclaimed (do not correspond to reality), or become a problem for the one who should implement them, as the customer begins to manipulate non-specific terms and requirements. I will give a few examples of what phrases I encountered, what this led to, and then I will try to give recommendations on how to avoid such problems.

Type of requirement

Wrong 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.

Hosted at http://www.allbest.ru/

• Content
• Introduction
• 1. Terms of reference
• 1.1 General information
• 1.2 Basis 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 the 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 stages of development
• 1.7.1 Development stages
• 1.7.2 Development stages
• 1.7.3 Content of work by stages
• 1.8 System control and acceptance procedure
• 1.8.1 Types, composition, scope and test methods of the system and its components
• 1.8.2 General requirements for acceptance of works by stages
• 1.8.3 Status of the acceptance committee (state, interdepartmental, departmental)
• 2. Technical project
• 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 of construction and platform for the implementation of IS
• 2.2.2 Structure information system, composition of functional and supporting subsystems
• 2.2.3 Technical support of IS
• 2.3 Information support of IP
• 2.3.1 Description of the logical structure of the infobase
• 2.3.2 Description of the physical implementation of the database
• Conclusion
• Bibliography

Introduction

The course work deals with the creation of terms of reference for the development of an information system for a system for an agency for the sale and booking 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 the creation of an information system begins with the formation of customer requirements for the system being created and their execution in the form of a technical task (TOR). The TOR 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, on the basis of the TOR, the calculation of work is carried out, labor costs are specified.

TK consists of three stages:

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

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

3. development and approval of TOR - determination of requirements for programs, development of a feasibility study of the system, determination of the stages, stages and terms of development of the system and documentation for it, choice of programming languages, determination of the need for R&D at the last stages, coordination and approval of TOR.

TK performs the following functions:

Organizational function - a fixed task for the Contractor and final requirements from the Customer.

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

Communication function - a mutual agreement on the "subject of the project", excluding claims.

Legal function - TK has equal legal force with the "Contract".

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

1. Terms of reference

1.1 General information

The full name of the system and its symbol: "Automated information system of the agency for the sale and booking 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 booking of air tickets.

The order of registration and presentation to the customer of the results of work on the creation of the system (its parts), on the manufacture and adjustment of individual tools (hardware, software, information) and software and hardware (software and methodological) systems of the system: AIS "Ticket" is supplied in the form of executable modules according to completion of the entire scope of work, the technical means are purchased by the Customer independently. Registration of the results of work on the creation of the system is carried out 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 Basis for development

The basis for the development of the terms of reference is the task for the course work on 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 booking of air tickets"

Symbol of the development topic (theme 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 the agency for the sale and booking of air tickets.

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

Purposes of the system: The system speeds up the process of ordering air tickets, thereby simplifying the work of the agency.

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 an order;

Issuing a ticket;

Accounting with the customer.

The subsystem "Acceptance of the order" is intended for registration of the order of air tickets.

The subsystem "Settlement with the customer" 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 through a local network.

Requirements for the operating modes of the system:

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

Requirements for the number and qualifications of the system personnel

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

The receptionist should have user-level PC skills. The number of staff may vary depending on the volume of orders.

Reliability Requirements

System recovery in case of errors in the operation of hardware (except for data carriers and programs) and errors associated with software (OS and device drivers), recovery is the responsibility of the OS.

In case of failures in the power supply system of the hardware, leading to an OS reboot, the program should be restored after the OS is restarted and the system executable file is launched.

The operability of the system as a whole should also be ensured in the event of failures, accidents and failures at individual workstations. Network filters should be used to protect the equipment from voltage surges and switching interference, and in order to be able to save data by the user 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 the current standards, safety regulations, fire safety and explosion safety, and environmental protection.

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

The operating conditions, as well as the types and frequency of maintenance of the technical means of the subsystem must comply with the requirements for operation, maintenance, repair and storage set forth 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) user identification and authentication;

b) checking the rights and restrictions of user access 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, the cascade model of the software life cycle should be applied.

The system should use (if necessary) all-Russian classifiers and unified classifiers and dictionaries for various types of alphanumeric and textual information.

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

Screen forms should be designed taking into account the requirements of unification:

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

1.4.2 Requirements for the functions (tasks) performed by the system

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

The information system should provide the following functions:

Order acceptance subsystem,

Subsystem of settlement with the client.

1.4.3 Requirements for types of collateral

To the information support of the system

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

System data is stored on one local machine. The description of the order is sent to the input of the system, the output must be an invoice and the identification number of the customer.

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 issued to the user in the required form (electronic, printed).

To protect data from destruction during accidents and power failures of the system

The complex of technical means should include an uninterruptible power supply. The work of this source should be at least half an hour for the correct shutdown of the system.

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 that are acceptable for use in the system.

Workstations;

Uninterrupted power supply unit;

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

Printer.

Technical means are purchased by the Customer independently.

To the functional, constructive and operational characteristics of the means of technical support of the system.

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

body requirementssystem insulation

For organizational support, the following requirements are given:

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

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

To the organization of the functioning of the system and the order of interaction between the NPP personnel and the personnel of the automation object.

Organizational support should be sufficient for the effective performance by the personnel of the duties assigned to them in the implementation of the functions of the system.

To protect against erroneous actions of the system personnel.

Protection against personnel errors consists in checking the filling of data in some fields, the possibility of restoring the original data and canceling recent changes, delimiting access by functions and authority 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 industrial and office premises.

1.6 Documentation requirements

For the system at various stages of creation, the following documents should be issued:

Scheme of the organizational structure;

Scheme of the functional structure;

List of input signals and data;

List of output signals (documents);

Explanatory note to the technical project;

Description of automated functions;

Description of the task setting (a set of tasks);

Description of the information base organization;

Description of the array of information;

Description of the software;

User's manual.

1.7 Stages and stages of development

1.7.1 Development stages

Development should be carried out in 6 stages:

1. Development of terms of reference

2. Development of project documentation

3. Creation of a draft design

4. Detailed design

5. Commissioning

6. Maintenance and modernization

1.7.2 Development stages

At the stage of development of the terms of reference, the stage of development, coordination and approval of this terms of reference must be completed.

At the stage of development of project documentation, the stage of development of project documentation should be completed.

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

At the stage of detailed design, the following stages of work should be performed:

1) development of an information system;

2) development of documentation.

At the implementation stage, the preparation and transfer of the program to the customer must be completed.

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 the terms of reference, the following works should be performed:

1) statement of the problem;

2) definition and specification of requirements for technical means;

3) determination of requirements for the information system;

4) determination of stages, stages and terms for the development of an information system and documentation for it;

5) justification and choice of tools;

6) coordination and approval of the terms of reference.

At the stage of development of project documentation, the following works should be performed:

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

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

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

4) designing the main components and algorithms of the System in the form of appropriate UML diagrams;

5) designing the structure of the user interface;

6) coordination and approval of project documentation.

At the development stage, work should be done on the development of an information system based on project documentation, coding and debugging.

At the documentation development stage, the development of policy documents in accordance with the requirements should be carried out. "Preliminary composition of the program documentation" of this terms of reference.

At the stage of preparation and transfer of the program, work must be done on the preparation and transfer of 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 terms of reference and project

5. Coordination and approval of terms of reference and project

6. Drawing up a plan for the work

7. Hardware preparation

8. Software development

9. Check for compatibility of hardware and software

10. Integration and testing of software and hardware

11. Making changes

12. Development of operating instructions for IS

13. Registration of complete documentation for IP

14. Delivery of 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 terms of reference and project
	5. Coordination and approval of the terms of reference and project
	6. Drawing up a plan for the work
	7.Hardware preparation
	8.Software development
	9.Hardware and software compatibility check
	10.Integration and testing of software and hardware
	11. Making changes
	12.Development of operating instructions for the IS
	13. Registration of complete documentation for IP
	14. Delivery of IP to the customer

Figure 1 - Setting goals

Figure 2 - Gantt Chart

Figure 3 - Network schedule of work execution

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

Table 2 - Time parameters of events

Event number	The timing of the event	Reserve time

Table 3 - Calculation of full and free time reserves

	Duration, days	Time parameters of work, days	Full reserve	Free reserve
		early start	early ending	late start	late ending

1.8 System control and acceptance procedure

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. Screen forms are checked for compliance with the description in the user manual (interface testing).

1.8.2 General requirements for acceptance of works by stages

Delivery and acceptance is carried out by a commission, which includes 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 a standard machine medium (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 project

2.1 Functional structure

2.1.1 Description of the subject area

The subject area is an agency selling and booking airline tickets.

The enterprise has an administrative department (consisting 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 broken down into three steps: building an organizational model, building a functional model, and building an information model.

Ticket Agency consists of the following departments:

Director;

Administrative department;

Department of operation of workstations;

Operator 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 and economic activities of the enterprise, as well as organizes the interaction of all its structural divisions.

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

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

The Workstation Operations Department is responsible for the health of the system.

Operators are responsible for accepting an order, 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 forming models of organizations, including a description of business objects (divisions, positions, resources, roles, processes, operations, information systems, information carriers, etc.) and an indication of the relationships between them. The requirements for the generated models and their respective content are determined by the goals of modeling. Business modeling is also called a discipline and a separate sub-process in the software development process, which describes the activities of the company and determines the requirements for the system - those sub-processes and operations that are subject to automation in the information system being developed.

After analyzing the activities of the agency and conducting a pre-project study, three main business processes of the AIS "Ticket" can be distinguished:

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 those 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 set of hierarchically ordered and logically related diagrams. Each diagram is located on a separate sheet. There are four types of charts:

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

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

Node tree diagrams;

Exposure-only charts (FEO).

The context diagram is the top of the diagram tree structure and is 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 fragments are called decomposition diagrams. After decomposition of 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 detail is reached. After each decomposition session, examination sessions are held - subject matter experts (usually these are employees of enterprises interviewed by analysts) indicate the correspondence of real business processes to the created diagrams. Found inconsistencies are corrected, and only after passing the examination without comments, you can proceed to the next decomposition session. 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 is the ticket order. Weekend - 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 for describing workflow 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 jobs, external entities, data flows, data stores (storages). Unlike IDEF0 arrows, which are rigid relationships, DFD arrows show how objects (including data) move from one job to another.

Unlike IDEF0, where the system is viewed as interrelated activities, DFD views the system as a collection of items. The context diagram often includes works and external links. Works are usually referred to by the name of the system, such as "Information Processing System". The inclusion of external links in the context diagram does not cancel the requirements of the methodology 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 jobs are shown as rounded rectangles, their meaning is the same as the IDEF0 and IDEF3 jobs. Just like IDEF3 processes, they have inputs and outputs, but do not support controls and mechanisms like IDEF0.

External entities represent entries into the system and/or exits from the system. External entities are drawn as a rectangle with a shadow and are usually located at the edges of the diagram. One external entity can be used multiple times in one or more diagrams. Usually this technique is used in order not to draw too long and confusing arrows.

Workflows are represented by arrows and describe the movement of objects from one part of the system to another. Because each side of the job does not have a clear purpose in DFD, as in IDEF0, the arrows can go in and out of any face of the job rectangle. DFD also uses double-headed arrows to describe command-response dialogs between jobs, between a job and an external entity, and between external entities.

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

2.2 IC system design

terms of reference costing labor costs booking

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

The main aspects when choosing an architecture for building an IS are speed, reliability, scalability and security.

Currently, the most common architectures are:

file server;

client-server;

layered architecture.

The file-server architecture implies that the server assumes only the function of storing data, and processing is performed on client machines. This means that the data needs to be transferred over the network, resulting in heavy network traffic. And this, in turn, will lead to a decrease in performance with an increase in the number of users. Also, when implementing the file server architecture, the problem of integrity, consistency and simultaneous access to data is solved in a decentralized way: the data is stored on the server and processed on the client. As a result, the reliability of the application is reduced. Another disadvantage is the high cost 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 is devoid of the disadvantages of the above architecture, since 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" by the server, and it, in turn, processes the request, while controlling the integrity and consistency of the data, and returns the result of the completed request to the client. As a result, the load on the network is reduced: the client no longer needs to process intermediate data. Storage and processing is 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 step in the development of IS architectures has become a multi-level architecture in which business logic is executed on an application server. The layered architecture has the following advantages:

scalability;

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

high security;

high reliability;

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

low requirements for the performance and technical characteristics of terminals, as a result, a decrease in their cost.

However, despite the undeniable advantages, this system has not received distribution, for the following reasons:

the complexity of developing systems based on a 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 performance requirements for application servers and database servers, and, hence, the high cost of server hardware;

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

high complexity of administration.

Having considered all the advantages and disadvantages of each of the architectures, we choose the client-server architecture for the implementation of the AIS Ticket system. This architecture allows optimal distribution of work between the client and server parts of the system: an application running on a 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 in the LAN.

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

Figure 5 - Architecture "client-server"

2.2.2 The structure of the information system, the composition of functional and supporting subsystems

Functional subsystems - a complex of economic tasks with a high degree of information exchanges (links) between tasks (some information processing process with a well-defined set of input and output information. Functional subsystems provide information service for 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, the supporting and organizational subsystems are combined into one supporting subsystem. The rationale 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 chosen 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 provisions:

legal;

Linguistic;

Technological;

Methodological;

Interfaces with external IS.

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

Mathematical support consists of algorithmic and software.

Organizational support is a set of means and methods for organizing production and managing them in the context of the introduction of IS.

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 interaction between IS and personnel, implementation of management tasks. Organizational support includes methods of communication with clients, requirements for paperwork, job descriptions, etc.

Algorithmic support is a set of mathematical methods, models and algorithms used in the system for solving problems and processing information.

2.2.3 Technical support of IS

The complex of technical means should include the following elements:

Workstations;

Uninterruptible power supplies;

Tools for building a LAN;

Database server;

Printer.

Server requirements:

Memory 8 GB;

Processor 2.2 GHz Intel Xeon 5500 minimum;

Drive speed SATA 8Gb/s;

Network adapter 10 Gb / s;

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 Mbps.

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

Round-the-clock operation of the 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 area network (LAN) for OJSC "Bilet".

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

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

2.3 Information support of IP

2.3.1 Description of the logical structure of the infobase

Logical (datalogical) design - creating a database schema based on specific model data, such as the relational data model. For a relational data model, a datalogical model is a set of relationship schemas, usually indicating primary keys, as well as "links" between relationships, which are foreign keys.

The transformation of a conceptual model into a logical model, as a rule, is carried out according to formal rules. This step can be largely automated.

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

Exclusion of some types of redundancy;

Elimination of some update anomalies;

Developing a database project that is a fairly "high-quality" 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.

Redundancy is usually eliminated by decomposing relations in such a way that only primary facts are stored in each relation (that is, facts that are not derived from other stored facts).

At the logical level, the database is normalized, as well as the allocation of keys for each entity. Logical relationships 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, and so on. In addition, the specifics of a particular DBMS during physical design include the choice of solutions related to the physical data storage environment (selection of disk storage 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 the logical model and describes the data by means of a specific DBMS. Relations developed at the stage of logical modeling 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, an element of the system is associated with physical equivalents that reproduce the structure, basic properties and relationships of the object under study. In physical modeling, which is based on the theory of similarity, the features of conducting an experiment in nature are preserved while observing the optimal range of changes in the corresponding physical parameters.

Conclusion

As a result of the course work, the terms of reference for the development of an information system for an agency for the sale and booking of air tickets and its software were completed.

The terms of reference for an information system is 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 security of the information system, and also describes the procedure for developing the system.

In accordance with the tasks set in the terms of reference, the following stages of creating a technical project were completed:

- the analysis of the subject area was carried out;

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

- the concept was developed, the architecture of construction and the platform for the implementation of the system were chosen;

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 defined.

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 - development tools for information systems / Maklakov S.V. - M: MEPhI DIALOGUE, 2001.-256s.;

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

Hosted 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. Creating an interface and user manual.

thesis, added 07/11/2015


Normative-legal acts of the Russian Federation in the field of information security. The order of organization of work on the protection of information in information systems. General approach to the development of terms of reference for the development of a protection system for this area.

term paper, added 05/05/2015


Creation of terms of reference for the development of an information system for ordering a plane ticket. Documentation requirements. The order of control and acceptance of the system. Development of the concept, architecture of construction and platform for the implementation of the information system.

term paper, added 05/13/2015


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

term paper, added 02/10/2013


The composition of the expert system. Requirements for the complex of technical means. Structure and organization of technical support of the automatic information system. Technical documentation for the development of software tools and how to use them.

abstract, added 10/09/2014


Learning programming languages ​​PHP, SQL, C++, HTML. Reviewing the rules for running and using a local Denwer server. Preparation of terms of reference for the development of a software product. Description of the mobile and web application being created.

term paper, added 04/07/2015


Development of an automated information system for recording and monitoring the implementation of repair work, and providing services for the development of software for the company "MegionSoftOil", the development of algorithms for applications of the software system and modules.

thesis, added 06/29/2012


Rationale for the need to develop an information system. Domain analysis. Terms of reference for the creation of 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). Feasibility study of a travel agency, algorithm and scheme of its AIS software interface.

thesis, added 07/21/2011


Counting the number of function points. Calculation of labor costs for the development of software 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, determining and order of creation (or - further creation), in accordance with which the AU is carried out and its at [from clause 1.1 GOST 34.602-89]

developed on the whole, designed 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 tasks for the NPP, etc. in accordance with the requirements of this; on funds and in accordance with the standards of ESKD and SRPP; on in accordance with the standards of the ESPD; on in accordance with GOST 19.201 and the NTD in force in the department.

Note - In the TOR for the automated control system for a group of interrelated objects, only requirements common to a group of objects should be included. The specific requirements of an individual object should be reflected in the TOR for the automated control system of this object [from clause 1.2 of GOST 34.602-89]

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

The requirements included in the TOR for NPPs must comply with the modern ones and not be inferior to similar requirements for the best modern domestic and foreign ones. The requirements specified in the TOR for NPPs should not limit the systems in the search and implementation of the most technical, technical, economic and other solutions [from clause 1.4 of GOST 34.602-89]

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

The TOR for NPPs includes only those requirements that supplement the requirements for this type (ACS, CAD, ASNI, etc.) contained in the existing ones, and are determined by the specifics of the particular object for which the system is being created [from clause 1.6 of GOST 34.602- 89]

to the technical specifications for the AU are drawn up in addition or and. The addendum or the specified protocol is an integral part of the ToR for the NPP. On the title page of the TK on the AU there should be an entry “Valid with ...” [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 supposed to be used.

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

The goals of creating a system

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

Characteristics of the automation object

In the section "Characteristics of the automation object" give:

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 the functions (tasks) performed by the system;
3. requirements for types of security.

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

General system requirements

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 the personnel of the system and the mode of its work;
• destination indicators;
• reliability requirements;
• safety requirements;
• requirements for ergonomics and technical aesthetics;
• transportability requirements for mobile AS;
• requirements for operation, maintenance, repair and storage of system components;
• requirements for the protection of information from unauthorized access;
• requirements for the safety of information in case of accidents;
• requirements for protection from the influence of 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 functioning of the system include:

1. list, their purpose and main characteristics, requirements for the number of levels and degree of system centralization;
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 the methods (automatically, by sending documents, by phone, etc.);
4. requirements for the operating modes of the system;
5. system requirements;
6. perspectives, systems.

Software Requirements

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

Requirements for information support

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. requirements for information with related systems;
4. requirements for the use of all-Russian and registered republican, sectoral, unified documents and classifiers applicable to;
5. application requirements;
6. requirements for the structure of the process of collecting, transmitting data in the system and;
7. requirements for protecting data from destruction during and in the power supply of the system;
8. requirements for monitoring, updating and;
9. requirements for the procedure for giving legal force to documents produced by the technical means of the AU (in accordance with GOST 6.10.4).

Requirements for the composition and content of work to prepare the automation object for putting the system into operation

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 when. The list of main activities includes:

1. bringing the information entering the system to a form suitable for using (in accordance with the requirements for and);
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 is guaranteed;
4. creation of subdivisions 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 applied methods;
• creation of conditions for the operation of the automated control system, under which the system's compliance with the requirements contained in the TOR is guaranteed.

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