На этой стадии производится формализация и утверждение требований к системе, что во многом определяет конечный результат. Документ полностью должен соответствовать ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы». Ниже приведен пример содержания этого документа. Курсивом выделен возможный вариант ТЗ.

1. Общие сведения

1.1 Полное наименование системы и ее условное обозначение

Автоматизированная система управления процессом затирания и фильтрования пивного сусла.

Шифр состоит из кода предприятия, порядкового номера разрабатываемого документа и его обозначения, например, ККБ. 123456. 001ТЗ.

1.2 Номер договора между организацией Разработчик и организацией Заказчик, на основании которого производится разработка АСУ ТП.

1.3 Наименование организаций Разработчика и Заказчика системы и их реквизиты.

1.4 Сроки выполнения работы по созданию системы

Сроки начала выполнения этапов работы определяются началом финансирования и получения соответствующих исходных данных.

Этапы работы:

1. Проектные работы – 2 месяца.

2. Комплектация и изготовление оборудования – 3 месяца.

3. Отработка программного обеспечения совместно с оборудованием на стенде исполнителя. Поставка оборудования Заказчику – 1 неделя.

4. Шеф монтажные работы по оборудованию АСУ ТП– 1 неделя.

5. Пуско-наладочные работы по оборудованию АСУ ТП– 1 неделя.

6. Обучение оперативного персонала Заказчика – 1 неделя.

2. Назначение и цели создания системы.

2.1. Назначение системы

Разрабатываемая АСУ технологического процесса затирания и фильтрования пивного сусла предназначена для:

- контроля состояния объекта путём измерения его технологических параметров и параметров состояния оборудования;

- регулирования технологических параметров;

-управления исполнительными механизмами и приводами оборудования;

- сигнализации предельных значений параметров технологического процесса и состояния оборудования;

- отображение принимаемой и обрабатываемой информации.

- определения аварийных ситуаций на технологических узлах путем опроса датчиков в автоматическом режиме, анализа измеренных значений, выдачи управляющих воздействий на исполнительные механизмы в автоматическом режиме или по инициативе оперативного персонала.

Разрабатываемая АСУТП относится к информационно-управляющей системе и предназначена для управления технологическим процессом затирания и фильтрования пивного сусла.

2.2 Цели создания :

При разработке этого раздела необходимо учитывать, что внедрение АСУТП должно обеспечить достижение главной цели политики предприятия в области качества. В зависимости от специфики производства и особенностей создаваемой АСУ ТП целями могут быть:

- сбор и обработка сигналов уровня 4-20 мA;

- сбор и обработка дискретных сигналов положения концевых выключателей;

- получение стабильной прибыли за счет производства конкурентоспособной продукции;

- стабилизация технологических параметров и качественных показателей продукции;

- увеличение выхода товарной продукции;

- уменьшение материальных и энергетических;

- повышение эффективности управления, обусловленное увеличением информационного обеспечения;

- повышение культуры труда технологического персонала за счет предоставляемого системой сервиса;

- уменьшение количества выполняемых технологическим персоналом функций за счет их автоматизации;

- улучшение качественных показателей конечной продукции (указать конкретно каких показателей и какой продукции);

- предотвращение аварийных ситуаций;

- улучшение экологической обстановки за счет уменьшения загрязненности промышленных стыков и выброса вредных веществ в атмосферу (если это предусматривается системой);

- обеспечение (в случае необходимости) развитие системы и ее интеграцию в производственную информационную сеть.

3. Характеристики объекта управления

Основные характеристики объекта автоматизации приведены в приложениях:

ПРИЛОЖЕНИЕ 1. Описание технологического процесса затирания и фильтрования пивного сусла.

Должна быть приведена технологическая схема с указанием технологических объектов, основных и вспомогательных материалопотоков, описание технологии переработки и назначение оборудования.

ПРИЛОЖЕНИЕ 2. Исходный перечень входов-выходов АСУ участка затирания и фильтрования пивного сусла.

ПРИЛОЖЕНИЕ 3. Сводные перечни входов-выходов РСУ участка затирания и фильтрования пивного сусла.

ПРИЛОЖЕНИЕ 4. Структурная схема АСУ участка затирания и фильтрования пивного сусла.

4. Требования к системе

Система должна выполнять информационные, управляющие функции, а также функции сигнализации и блокировок.

АСУ ТП должна обеспечивать:

4.1. Требования к структуре и функционированию системы

АСУ ТП должна выполнять следующие функции:

1. Автоматизированный сбор и первичную обработку технологической информации:

а) Опрос аналоговых датчиков:

- давления пара в заторных аппаратах и сусловарочном котле и на входе в них;

- уровня затора в заторных аппаратах;

- плотности осахаренного затора в фильтрационном чане;

- плотности горячего сусла на выходе из хмелеотделителя;

- расхода сусла после хмелеотделителя

б) Опрос дискретных датчиков:

- уровня затора в фильтрационном чане, сусловарочном котле и хмелеотделителе.

2. Автоматический контроль состояния оборудования технологического процесса (сигналов состояния):

- электроприводов мешалок в заторных аппаратах и сусловарочном котле;

- электроприводов насосов, перекачивающих затор между заторными аппаратами;

- регулирующих клапанов подачи пара в заторные аппараты и сусловарочный котёл;

- регулирующих клапанов подачи воды в заторный аппарат I, фильтрационный чан и хмелеотделитель;

- регулирующего клапана подачи осахаренного затора в фильтрационный чан;

- задвижки подачи дроблёного солода в заторный аппарат I;

- задвижки подачи хмеля в сусловарочный котёл;

- задвижки подачи охмеленного сусла в хмелеотделитель;

- задвижки выпуска сусла из фильтрационного чана;

- задвижки выпуска горячего сусла из хмелеотделителя.

3. Предупредительную сигнализацию при выходе технологических параметров за установленное значение:

- температуры затора в заторных аппаратах и сусловарочном котле;

- температуры воды на входе в заторный аппарат I, фильтрационный чан и хмелеотделитель;

- давления пара в заторных аппаратах и сусловарочным котлом и на входе в них;

- расхода пара, поступающего в заторные аппараты и сусловарочный котёл;

- расхода воды, поступающей в заторный аппарат I, фильтрационный чан и хмелеотделитель;

- уровня затора в заторных чанах, фильтрационном чане, сусловарочном котле и хмелеотделителе;

- плотности затора в фильтрационном чане и на выходе из хмелеотделителя.

4. Управление технологическим процессом в реальном масштабе времени.

4.1. Регулирование технологических параметров:

- регулирование температуры и давления в заторных аппаратах и сусловарочном котле путём подачи в них пара;

- регулирование уровня затора в заторном аппарате I путём подачи в него воды и дроблёного солода;

- управление длительностью затирания в заторном аппарате I по сигналу с сахариметра;

- управление длительностью варки сусла в сусловарочном котле при помощи задвижки;

- регулирование уровня осахаренного затора в фильтрационном чане путём подачи в него воды и дроблёного солода;

- регулирование уровня охмеленного сусла в сусловарочном котле путём подачи в него хмеля и осахаренного затора;

- регулирование уровня горячего сусла в хмелеотделителе путём подачи в него воды и охмеленного сусла;

- управление длительностью фильтрации в фильтрационном чане по сигналу с датчика плотности.

4.2 Программно-логическое управление технологическим оборудованием (указать основные алгоритмы и управления).

4.3. Формирование команд блокировки при выходе определенных параметров за допустимые значения (указать какие блокировки предусмотрены).

5. Расчет технологических и технико-экономических показателей

Расчет технико-экономических показателей включает определение количеств веществ, израсходованных или полученных за определенные интервалы времени (указать каких продуктов).

6. Представление информации в виде значений или графиков на дисплее.

Функция отображения информации должна обеспечить по запросу оператора-технолога вывод на экран дисплея оперативной информации о текущем состоянии технологического процесса и оборудования, представляемой в виде мнемосхем, трендов, сводок, значений параметров.

На выводимых кадрах должна быть предусмотрена предупредительная и аварийная сигнализация по двум границам нарушений (верхней и нижней), сигнализация выхода за границы достоверности и сигнализация обрыва датчика. Сигнализация выхода за границы выражается миганием значений переменных, после снятия мигания значения переменных горят цветом, соответствующим состоянию переменных.

8. Печать технологической документации

Любую информацию (мнемосхемы, тренды) операторы-технологи в любой момент времени должны иметь возможность вывести на печать с использованием внешнего носителя информации (USB Flash Drive) в виде текстовых и графических файлов.

4.2. Требования к численности и квалификации персонала.

Весь персонал системы в соответствии с выполняемой ролью делится на две категории:

Оперативный технологический персонал: аппаратчики, технологи, начальники технологических установок, оператор - технолог, начальник смены, начальник цеха.

Эксплуатационный персонал: инженер-электрик; инженер-программист; начальник сектора, сменный инженер.

Численность и номенклатура персонала устанавливается в зависимости от специфики объекта автоматизации. Внедрение Системы потребует специальной подготовки персонала. Перед вводом Системы в эксплуатацию персонал должен пройти соответствующее обучение.

4.3. Требования к надежности

Система должна быть многофункциональной, восстанавливаемой и должна характеризоваться показателями безотказности (наработка на отказ в тыс. часов) по основным выполняемым функциям:

Централизованный контроль параметров и сигнализация нарушений;

Дистанционное управление;

Регулирование.

Показатели надежности должны отвечать требованиям ГОСТ 24.701-86. Система должна отвечать следующим требованиям к надежнос¬ти (РД 50-650): - для АСУ ТП комплексным показателем надежности по каждой функции является коэффициент готовности. Коэффициент готовности, должен быть не менее 0.995 при допустимом времени восстановления 1 час. В это время должно входить, помимо времени обнаружения отказа и замены отказавшего сменного блока, организационное время, затрачиваемое на получение и доставку исправного блока из комплекта ЗИП к месту расположения оборудования и его проверку. При этом система должна допускать восстановление отдельных ее частей без прерывания функционирования всей системы.

Средний срок службы системы - 10 лет. Гарантийный срок хранения системы - 2 года с момента ее приемки на заводе-изготовителе. Гарантийный срок эксплуатации - 18 месяцев в пределах гарантий ного срока хранения при соблюдении заказчиком условий хранения и эксплуатации, оговоренных настоящим ТЗ.

Система должна быть обеспечена комплектом ЗИП на весь гарантийный срок, определенным по расчету надежности, при этом вероятность обеспечения ЗИП на этот срок должна быть не менее 0.99. В течение всего оставшегося срока службы комплект ЗИП должен пополняться в соответствии с условиями договора на сервисное обслуживание.

4.4. Требования безопасности

1. В систему, при необходимости, должны вводиться сигналы, предупреждающие об образовании недопустимых концентраций в производственных помещениях.

2. Технические средства (датчики, исполнительные механизмы и т.д.), размещаемые во взрывоопасных зонах помещений и наружных установок и имеющие связи с системой, должны иметь степень защиты, соответствующую группе и категории взрывоопасной смеси, которая может образовываться в данной зоне.

3. Для параметров, определяющих взрывоопасность объектов, должна быть предусмотрена предаварийная сигнализация.

4. Для исполнительных механизмов должна быть предусмотрена сигнализация крайних положений.

5. Предусмотреть звуковую сигнализацию:

Предупредительная технологическая;

Аварийная;

6. Все внешние элементы технических средств системы, находящиеся под напряжением, должны иметь защиту от случайного прикосновения человека, а сами технические средства – заземлены.

4.5. Требования по эргономике и технической эстетике

Взаимодействие человека с системой осуществляется через контроллеры, оборудованные жестким диском, алфавитно-цифровой клавиатурой, функциональным средством графического управления типа "мышь".

Отображение информации на экране цветного графического дисплея должно обеспечивать получение оператором-технологом полной характеристики текущего состояния технологического процесса и оборудования и возможность управления ими в виде, наиболее удобном для восприятия в каждой конкретной ситуации.

Размеры экрана должны быть достаточными для вывода на него определенных фрагментов каждой технологической установки. Фрагменты не должны быть перенасыщены информацией и разнообразием цветовой гаммы.

Предупредительная сигнализация должна сопровождаться мерцанием или изменением цвета цифровых значений переменных или фона на экранах дисплеев. Аварийные ситуации сопровождаются, дополнительно, звуковой сигнализацией, квитируемой оператором-технологом. Связь оператора-технолога с процессом и системой реализуется через запросы, которые должны быть максимально упрощены и обладать адекватной мнемоникой.

Расположение технических средств системы должно быть рациональным как с точки зрения монтажных связей между ними, так и удобства их эксплуатации и обслуживания.

4.6. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению

Система может эксплуатироваться круглосуточно. Виды, периодичность и регламент обслуживания технических средств должны быть указаны в соответствующих инструкциях.

Система должна иметь бесперебойное электропитание, обеспечивающее ее функционирование в течение 15 мин. после аварийного отключения электроэнергии.

Колебание напряжения промышленной сети (пуски насосов, компрессора, сварочные аппараты и т.д.) и импульсные помехи не должны сказываться на питании АСУ ТП.

В состав обслуживающего персонала должны входить специалисты следующих профилей:

По КИП и А;

Технолог для сопровождения функциональных задач;

Инженер-электронщик;

Системный программист.

Количество специалистов определяется Заказчиком.

4.7. Требования к защите информации от несанкционированного доступа

Для обеспечения нормального функционирования системы, предотвращения искажения информации от случайных воздействий со стороны лиц обслуживающего персонала, не имеющих доступа к отдельным частям системы, в программном обеспечении системы должна быть предусмотрена защита информации от несанкционированного доступа.

Технически защита осуществляется через пароль - приоритетно. Исполнение пароля может быть выполнено с применением ключей или программно.

4.8. Требования к средствам защиты от внешних воздействий

Технические средства системы должны быть устойчивы к воздействию температуры и влажности окружающего воздуха:

Температура окружающего воздуха от 15 до 25С;

Относительная влажность окружающего воздуха от 40 до 80 % при температуре 25С;

Атмосферное давление от 84 кПа до 107 кПа (от 630 до 800 мм. рт. ст.)

Защита технических средств от внешних электрических и магнитных полей, а также помех по цепям питания должна быть достаточной для нормального функционирования системы. Для этих целей в системе применяются специальные аппаратные (схемные) и программные решения:

Гальваническая развязка технических средств от технологического оборудования;

Применение витых пар для передачи электрических сигналов;

Фильтрация помех по цепям питания и информационным цепям;

Применение микросхемной элементной базы, обладающей повышенными быстродействием и помехозащищенностью.

4.9. Требования к патентной чистоте

Разрабатываемая система не предназначается на экспорт, поэтому ограничения по патентной чистоте не накладываются.

4.10. Требования к стандартизации и унификации

Разрабатываемая система должна быть универсальной, обеспечивать возможность ее использования на широком классе объектов управления и соответствовать достигнутому мировому уровню в области создания АСУ ТП, функциональному развитию, удобству эксплуатации и обслуживания.

5. Требования к видам обеспечения

5.1. Требования к Информационному обеспечению .

Информационное обеспечение АСУТП включает в себя следующие категории данных:

Текущие значения технологических переменных, поступающих в систему в результате опроса датчиков и первичной переработки информации;

Границы переменных различных уровней, настройки алгоритмов управления, информация привязки программного обеспечения к конкретному объекту;

Тексты программ и загрузочные модули.

Для обмена информацией в рамках распределённой Системы должна быть создана база данных, обеспечивающая доступ к данным с локальных элементов сети, которыми являются:

Периферийные микропроцессорные устройства - контроллеры;

Многофункциональные операторские станции - рабочие места технологического персонала;

Инженерная станция.

Для удобства работы технологов-операторов с большими объемами разнообразной информации, и для выработки соответствующих стереотипов взаимодействия с Системой, Информационное обеспечение Системы должно быть структурировано и иметь иерархическую организацию.

Должны быть предусмотрены следующие стандартные операционные панели (видеоизображения, кадры, окна):

1. Панели общего обзора

Предназначены для контроля над работой всего производства в целом и для получения доступа к более подробным панелям при возникновении такой необходимости.

2. Мнемосхемы

Относятся к наиболее важным типам операционных панелей. Представляют собой графическое изображение основного технологического оборудования, средств КИПиА, и отображают структуру алгоритмов управления и защиты, и их состояние.

3. Панели группы приборов

Представляют и описывают состояние лицевых панелей 8-12 приборов.

4. Панели настройки

Описывают параметры конкретного устройства / прибора / регулятора и предоставляют возможность его настройки.

5. Панели сигналов тревоги

Отражают в хронологическом порядке предупредительную и предаварийную сигнализацию процесса.

6. Панели регистрации хода процесса (тренды) Должны быть предусмотрены 2 вида панелей для графического отображения данных о ходе процесса во времени:

Панель группы из 6 - 12 трендов,

Панель одиночного тренда.

Технологу-оператору должны быть представлены простые и естественные способы вызова и ввода данных для различных панелей, как то:

Кнопка на функциональной клавиатуре;

Указание элемента на экране;

Выбор из меню;

Ввод данных через соответствующую зону на экране.

Все настроечные константы, информация привязки, алгоритмы решения задач и тексты программ должны храниться на дублирующих носителях и обновляться при внесении изменений в Систему.

5.2. Требования к Лингвистическому обеспечению.

Для реализации функций АСУТП должны использоваться современные средства конфигурирования и визуального программирования, ориентированные на специалистов-разработчиков АСУТП.Эти средства позволяют существенно минимизировать время разработки, и придают исключительную наглядность алгоритмам переработки информации и управления.

Ввиду отсутствия отечественных нормативных документов, в качестве их прототипа необходимо использовать разработанный Международной Электротехнической Комиссией (МЭК) стандарт IEC 61131-3, регламентирующий полноту и синтаксис языков технологического программирования.

В соответствии с этим стандартом Система должна иметь, как минимум, следующие средства технологического программирования:

1. Function Block Diagrams - Графический язык функциональных блоков;

2. Sequential Function Chart - Функциональные схемы для описания последовательности операций.

Для разработки систем противоаварийной защиты дополнительно предусматривается:
3. Ladder Logic Diagrams - Графические средства описания логических схем.

Для разработки прикладных программ, в частности, технологических и технико-экономических расчётов, должен быть предусмотрен

4. Проблемно-ориентированный язык высокого уровня, позволяющий создавать новые задачи, оперативно их корректировать, сохранять результаты решения задач в базе данных, организовывать запуск задач по запросу и по времени с соответствующими приоритетами.

Вся представленная на экранах мониторов и в печатных отчетах смысловая и текстовая информация для технологического и эксплуатационного персонала должна быть на русском языке.

5.3. Требования к стандартному Программному обеспечению.

Для реализации задач распределённой Системы должно использоваться специализированное программное обеспечение, функционирующее в среде многозадачной операционной системы реального времени. Характеристики программного обеспечения должны удовлетворять требованиям по выполнению функций, указанных в предыдущих разделах.

Сетевые программные средства, обеспечивающие объединение подсистем управления, операторских станций и средств архивирования данных в единую Систему, должны реализовывать загрузку и управление запуском задач, обеспечивать обмен между задачами и базами данных, и предоставлять доступ к периферийным устройствам.

Система управления должна иметь возможность оперативного конфигурирования прикладного программного обеспечения в процессе функционирования АСУТП.

Все ошибочные ситуации, возникающие при работе программ, должны диагностироваться, сопровождаться сообщениями, и не должны вызывать нарушений в работе Системы.

5.4. Требования к прикладному программному ("математическому") обеспечению.

Математическое обеспечение Системы должно обеспечивать реализацию перечисленных в данном ТЗ функций, а также выполнение операций конфигурирования, программирования, управления базами данных и документирования.

Прикладное программное обеспечение АСУТП должно обеспечить реализацию требуемых алгоритмов контроля, регулирования и защиты, отображения информации, сигнализации и архивирования данных.

Алгоритмы управления должны иметь возможность пере-конфигурирования, и реализовываться через библиотечные блочные структуры.

5.5. Требования к Техническому обеспечению.

Комплекс технических средств АСУ ТП должен быть достаточен для реализации определенных данным ТЗ функций, и строиться на базе следующих специализированных программно-технических комплексов:

Средства КИПиА, в том числе датчики, исполнительные механизмы, электронные микропроцессорные регуляторы и поточные анализаторы качества;

Периферийные микропроцессорные устройства -подсистемы управления, или контроллеры;

Многофункциональные операторские и инженерные станции;

Средства архивирования данных;

Сетевое оборудование;

Специализированные микропроцессорные контроллеры системы ПАЗ;

Средства метрологической поверки оборудования.

Система измерений должна строиться на базе электронных датчиков расхода, давления, уровня, температуры, перепада давления, интегрирующих счетчиков, анализаторов качества и состава.

Средства измерений расходов, давлений, уровней и перепадов давлений должны иметь стандартные сигналы диапазона 4-20 мА.

Для реализации сбора и обработки информации в составе подсистем управления должны быть предусмотрены модули:

Ввода сигналов 4-20мА;

Ввода сигналов 4-20мА со встроенными барьерами искрозащиты;

Входа милливольтовых сигналов со встроенными барьерами искрозащиты;

Ввода дискретных сигналов;

Ввода по протоколу RS-422/RS-485 от периферийных микропроцессорных устройств.

Вывод управляющих воздействий, рассчитанных по законам регулирования, должен осуществляться через модули вывода аналоговых токовых сигналов на электропневмопозиционеры, установленные на пневматических исполнительных механизмах.

Вывод дискретных управляющих воздействий и блокировок для управления электрооборудованием выполняется через модули вывода дискретных сигналов.

5.6. Требования к Метрологическому обеспечению.

Метрологическое обеспечение измерительных систем должны соответствовать ГОСТ Р 8.596-2002. ГСИ. "Метрологическое Обеспечение измерительных систем. Основные положения". Должны быть предоставлены следующие сведения и документы:

Назначение ИС, и сведения об ее использовании в сфере (или вне сферы) Государственного метрологического контроля и надзора;

Сертификат об утверждении типа ИС, описание типа ИС, методику поверки, - если они используются в сфере Государственного метрологического контроля и надзора;

Сведения об измеряемых величинах и их характеристиках;

Перечни измерительных каналов и нормы их погрешностей;

Условия измерений;

Условия метрологического обслуживания.

В спецификацию оборудования АСУТП должны быть включены специальные технические и программные для калибровки измерительных каналов.

В номенклатуру контролируемых параметров входят расходы жидкостей, газов и пара, температура, давление, уровень, концентрация и т.д.

Все методики измерения, используемые в сфере государственного метрологического контроля и надзора, должны быть аттестованы.

Для измерительных каналов ИС должны быть представлены рекомендации (инструкции) по поверке (калибровке) ИК, утвержденные в установленном порядке.

Для технических средств, участвующих в процессе измерения контролируемых параметров должны быть обеспечены соответствующие условия эксплуатации (температура, влажность). Должен быть обеспечен контроль условий их эксплуатации в помещениях управления.

5.7. Организационное обеспечение АСУТП

должно быть достаточным для эффективного выполнения персоналом возложенных на него обязанностей по эксплуатации Системы. Организационное обеспечение должно включать требования по численности и квалификации персонала АСУТП и КИПиА, инструкции по каждому виду деятельности, и точное определение выполняемых функций.

Название документа:
Номер документа:	34.602-89
Вид документа:	ГОСТ
Принявший орган:	Госстандарт СССР
Статус:	Действующий
Опубликован:	официальное издание
Дата принятия:	24 марта 1989
Дата начала действия:	01 января 1990
Дата редакции:	01 февраля 2002

ГОСТ 34.602-89 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

ГОСТ 34.602-89

Группа П87

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

Комплекс стандартов на автоматизированные системы.
Техническое задание на создание автоматизированной системы

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

ОКСТУ 0034

Дата введения 1990-01-01

ИНФОРМАЦИОННЫЕ ДАННЫЕ

1. РАЗРАБОТАН И ВНЕСЕН Государственным комитетом СССР по стандартам, Министерством приборостроения, средств автоматизации и систем управления СССР

2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по стандартам от 24.03.89 N 661

3. ВЗАМЕН ГОСТ 24.201-85

4. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ

	Номер пункта, приложения
ГОСТ 2.105-95
ГОСТ 2.301-68
ГОСТ 2.501-88	Приложение 1
ГОСТ 6.10.1-88
ГОСТ 6.10.4-84
ГОСТ 19.201-78
ГОСТ 34.201-89
ГОСТ 34.601-90

5. ПЕРЕИЗДАНИЕ


Настоящий стандарт распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т.п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа "Техническое задание на создание (развитие или модернизацию) системы" (далее - ТЗ на АС).

Рекомендуемый порядок разработки, согласования и утверждения ТЗ на АС приведен в приложении 1.

1. ОБЩИЕ ПОЛОЖЕНИЯ

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

1.2. ТЗ на АС разрабатывают на систему в целом, предназначенную для работы самостоятельно или в составе другой системы.

Дополнительно могут быть разработаны ТЗ на части АС: на подсистемы АС, комплексы задач АС и т.п. в соответствии с требованиями настоящего стандарта; на комплектующие средства технического обеспечения и программно-технические комплексы в соответствии со стандартами ЕСКД и СРПП; на программные средства в соответствии со стандартами ЕСПД; на информационные изделия в соответствии с ГОСТ 19.201 и НТД, действующей в ведомстве заказчика АС.

Примечание. В ТЗ на АСУ для группы взаимосвязанных объектов следует включать только общие для группы объектов требования. Специфические требования отдельного объекта управления следует отражать в ТЗ на АСУ этого объекта.

1.3. Требования к АС в объеме, установленном настоящим стандартом, могут быть включены в задание на проектирование вновь создаваемого объекта автоматизации. В этом случае ТЗ на АС не разрабатывают.

1.4. Включаемые в ТЗ на АС требования должны соответствовать современному уровню развития науки и техники и не уступать аналогичным требованиям, предъявляемым к лучшим современным отечественным и зарубежным аналогам.

Задаваемые в ТЗ на АС требования не должны ограничивать разработчика системы в поиске и реализации наиболее эффективных технических, технико-экономических и других решений.

1.5. ТЗ на АС разрабатывают на основании исходных данных, в том числе содержащихся в итоговой документации стадии "Исследование и обоснование создания АС", установленной ГОСТ 24.601.

1.6. В ТЗ на АС включают только те требования, которые дополняют требования к системам данного вида (АСУ, САПР, АСНИ и т.д.), содержащиеся в действующих НТД, и определяются спецификой конкретного объекта, для которого создается система.

1.7. Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись "Действует с …".

2. СОСТАВ И СОДЕРЖАНИЕ

2.1. ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:

1) общие сведения;

2) назначение и цели создания (развития) системы;

3) характеристика объектов автоматизации;

4) требования к системе;

5) состав и содержание работ по созданию системы;

6) порядок контроля и приемки системы;

7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

8) требования к документированию;

9) источники разработки.

В ТЗ на АС могут включаться приложения.

2.2. В зависимости от вида, назначения, специфических особенностей объекта автоматизации и условий функционирования системы допускается оформлять разделы ТЗ в виде приложений, вводить дополнительные, исключать или объединять подразделы ТЗ.

В ТЗ на части системы не включают разделы, дублирующие содержание разделов ТЗ на АС в целом.

2.3. В разделе "Общие сведения" указывают:

1) полное наименование системы и ее условное обозначение;

2) шифр темы или шифр (номер) договора;

3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;

4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

5) плановые сроки начала и окончания работы по созданию системы;

6) сведения об источниках и порядке финансирования работ;

7) порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.

2.4. Раздел "Назначение и цели создания (развития) системы" состоит из подразделов:

1) назначение системы;

2) цели создания системы.

2.4.1. В подразделе "Назначение системы" указывают вид автоматизируемой деятельности (управление, проектирование и т.п.) и перечень объектов автоматизации (объектов), на которых предполагается ее использовать.

Для АСУ дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов.

2.4.2. В подразделе "Цели создания системы" приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы.

2.5. В разделе "Характеристики объекта автоматизации" приводят:

1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;

2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

Примечание. Для САПР в разделе дополнительно приводят основные параметры и характеристики объектов проектирования.

2.6. Раздел "Требования к системе" состоит из следующих подразделов:

1) требования к системе в целом;

2) требования к функциям (задачам), выполняемым системой;

3) требования к видам обеспечения.

Состав требований к системе, включаемых в данный раздел ТЗ на АС, устанавливают в зависимости от вида, назначения, специфических особенностей и условий функционирования конкретной системы. В каждом подразделе приводят ссылки на действующие НТД, определяющие требования к системам соответствующего вида.

2.6.1. В подразделе "Требования к системе в целом" указывают:

- требования к структуре и функционированию системы;

- требования к численности и квалификации персонала системы и режиму его работы;

- показатели назначения;

- требования к надежности;

- требования безопасности;

- требования к эргономике и технической эстетике;

- требования к транспортабельности для подвижных АС;

- требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;

- требования к защите информации от несанкционированного доступа;

- требования по сохранности информации при авариях;

- требования к защите от влияния внешних воздействий;

- требования к патентной чистоте;

Требования по стандартизации и унификации;

Дополнительные требования.

2.6.1.1. В требованиях к структуре и функционированию системы приводят:

1) перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы;

2) требования к способам и средствам связи для информационного обмена между компонентами системы;

3) требования к характеристикам взаимосвязей создаваемой системы со смежными системами, требования к ее совместимости, в том числе указания о способах обмена информацией (автоматически, пересылкой документов, по телефону и т.п.);

4) требования к режимам функционирования системы;

5) требования по диагностированию системы;

6) перспективы развития, модернизации системы.

2.6.1.2. В требованиях к численности и квалификации персонала АС приводят:

- требования к численности персонала (пользователей) АС;

- требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков;

- требуемый режим работы персонала АС.

2.6.1.3. В требованиях к показателям назначения АС приводят значения параметров, характеризующие степень соответствия системы ее назначению.

Для АСУ указывают:

- степень приспособляемости системы к изменению процессов и методов управления, к отклонениям параметров объекта управления;

- допустимые пределы модернизации и развития системы;

- вероятностно-временные характеристики, при которых сохраняется целевое назначение системы.

2.6.1.4. В требования к надежности включают:

1) состав и количественные значения показателей надежности для системы в целом или ее подсистем;

2) перечень аварийных ситуаций, по которым должны быть регламентированы требования к надежности, и значения соответствующих показателей;

3) требования к надежности технических средств и программного обеспечения;

4) требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами.

2.6.1.5. В требования по безопасности включают требования по обеспечению безопасности при монтаже, наладке, эксплуатации, обслуживании и ремонте технических средств системы (защита от воздействий электрического тока, электромагнитных полей, акустических шумов и т.п.), по допустимым уровням освещенности, вибрационных и шумовых нагрузок.

2.6.1.6. В требования по эргономике и технической эстетике включают показатели АС, задающие необходимое качество взаимодействия человека с машиной и комфортность условий работы персонала.

2.6.1.7. Для подвижных АС в требования к транспортабельности включают конструктивные требования, обеспечивающие транспортабельность технических средств системы, а также требования к транспортным средствам.

2.6.1.8. В требования к эксплуатации, техническому обслуживанию, ремонту и хранению включают:

1) условия и регламент (режим) эксплуатации, которые должны обеспечивать использование технических средств (ТС) системы с заданными техническими показателями, в том числе виды и периодичность обслуживания ТС системы или допустимость работы без обслуживания;

2) предварительные требования к допустимым площадям для размещения персонала и ТС системы, к параметрам сетей энергоснабжения и т.п.;

3) требования по количеству, квалификации обслуживающего персонала и режимам его работы;

4) требования к составу, размещению и условиям хранения комплекта запасных изделий и приборов;

5) требования к регламенту обслуживания.

2.6.1.9. В требования к защите информации от несанкционированного доступа включают требования, установленные в НТД, действующей в отрасли (ведомстве) заказчика.

2.6.1.10. В требованиях по сохранности информации приводят перечень событий: аварий, отказов технических средств (в том числе - потеря питания) и т.п., при которых должна быть обеспечена сохранность информации в системе.

2.6.1.11. В требованиях к средствам защиты от внешних воздействий приводят:

1) требования к радиоэлектронной защите средств АС;

2) требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения).

2.6.1.12. В требованиях по патентной чистоте указывают перечень стран, в отношении которых должна быть обеспечена патентная чистота системы и ее частей.

2.6.1.13. В требования к стандартизации и унификации включают: показатели, устанавливающие требуемую степень использования стандартных, унифицированных методов реализации функций (задач) системы, поставляемых программных средств, типовых математических методов и моделей, типовых проектных решений, унифицированных форм управленческих документов, установленных ГОСТ 6.10.1*, общесоюзных классификаторов технико-экономической информации и классификаторов других категорий в соответствии с областью их применения, требования к использованию типовых автоматизированных рабочих мест, компонентов и комплексов.
_____________________
* В Российской Федерации действуют ПР 50-733-93 .

2.6.1.14. В дополнительные требования включают:

1) требования к оснащению системы устройствами для обучения персонала (тренажерами, другими устройствами аналогичного назначения) и документацией на них;

2) требования к сервисной аппаратуре, стендам для проверки элементов системы;

3) требования к системе, связанные с особыми условиями эксплуатации;

4) специальные требования по усмотрению разработчика или заказчика системы.

2.6.2. В подразделе "Требования к функциям (задачам)", выполняемым системой, приводят:

1) по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации;

при создании системы в две или более очереди - перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях;

2) временной регламент реализации каждой функции, задачи (или комплекса задач);

3) требования к качеству реализации каждой функции (задачи или комплекса задач), к форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов;

4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

2.6.3. В подразделе "Требования к видам обеспечения" в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другим видам обеспечения системы.

2.6.3.1. Для математического обеспечения системы приводят требования к составу, области применения (ограничения) и способам использования в системе математических методов и моделей, типовых алгоритмов и алгоритмов, подлежащих разработке.

2.6.3.2. Для информационного обеспечения системы приводят требования:

1) к составу, структуре и способам организации данных в системе;

2) к информационному обмену между компонентами системы;

3) к информационной совместимости со смежными системами;

4) по использованию общесоюзных и зарегистрированных республиканских, отраслевых классификаторов, унифицированных документов и классификаторов, действующих на данном предприятии;

5) по применению систем управления базами данных;

6) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;

7) к защите данных от разрушений при авариях и сбоях в электропитании системы;

8) к контролю, хранению, обновлению и восстановлению данных;

9) к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4).

2.6.3.3. Для лингвистического обеспечения системы приводят требования к применению в системе языков программирования высокого уровня, языков взаимодействия пользователей и технических средств системы, а также требования к кодированию и декодированию данных, к языкам ввода-вывода данных, языкам манипулирования данными, средствам описания предметной области (объекта автоматизации), к способам организации диалога.

2.6.3.4. Для программного обеспечения системы приводят перечень покупных программных средств, а также требования:

1) к независимости программных средств от используемых СВТ и операционной среды;

2) к качеству программных средств, а также к способам его обеспечения и контроля;

3) по необходимости согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ.

2.6.3.5. Для технического обеспечения системы приводят требования:

1) к видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе;

2) к функциональным, конструктивным и эксплуатационным характеристикам средств технического обеспечения системы.

2.6.3.6. В требованиях к метрологическому обеспечению приводят:

1) предварительный перечень измерительных каналов;

2) требования к точности измерений параметров и (или) к метрологическим характеристикам измерительных каналов;

3) требования к метрологической совместимости технических средств системы;

4) перечень управляющих и вычислительных каналов системы, для которых необходимо оценивать точностные характеристики;

5) требования к метрологическому обеспечению технических и программных средств, входящих в состав измерительных каналов системы, средств встроенного контроля, метрологической пригодности измерительных каналов и средств измерений, используемых при наладке и испытаниях системы;

6) вид метрологической аттестации (государственная или ведомственная) с указанием порядка ее выполнения и организаций, проводящих аттестацию.

2.6.3.7. Для организационного обеспечения приводят требования:

1) к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию;

2) к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации;

3) к защите от ошибочных действий персонала системы.

2.6.3.8. Для методического обеспечения САПР приводят требования к составу нормативно-технической документации системы (перечень применяемых при ее функционировании стандартов, нормативов, методик и т.п.).

2.7. Раздел "Состав и содержание работ по созданию (развитию) системы" должен содержать перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 34.601 , сроки их выполнения, перечень организаций - исполнителей работ, ссылки на документы, подтверждающие согласие этих организаций на участие в создании системы, или запись, определяющую ответственного (заказчик или разработчик) за проведение этих работ.

В данном разделе также приводят:

1) перечень документов по ГОСТ 34.201 , предъявляемых по окончании соответствующих стадий и этапов работ;

2) вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт);

3) программу работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости);

4) перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организаций-исполнителей (при необходимости).

2.8. В разделе "Порядок контроля и приемки системы" указывают:

1) виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);

2) общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации;

3) статус приемочной комиссии (государственная, межведомственная, ведомственная).

2.9. В разделе "Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие" необходимо привести перечень основных мероприятий и их исполнителей, которые следует выполнить при подготовке объекта автоматизации к вводу АС в действие.

В перечень основных мероприятий включают:

1) приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;

2) изменения, которые необходимо осуществить в объекте автоматизации;

3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;

4) создание необходимых для функционирования системы подразделений и служб;

5) сроки и порядок комплектования штатов и обучения персонала.

Например, для АСУ приводят:

- изменения применяемых методов управления;

- создание условий для работы компонентов АСУ, при которых гарантируется соответствие системы требованиям, содержащимся в ТЗ.

2.10. В разделе "Требования к документированию" приводят:

1) согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и НТД отрасли заказчика; перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации;

2) требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;

3) при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.

2.11. В разделе "Источники разработки" должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

2.12. В состав ТЗ на АС при наличии утвержденных методик включают приложения, содержащие:

1) расчет ожидаемой эффективности системы;

2) оценку научно-технического уровня системы.

Приложения включают в состав ТЗ на АС по согласованию между разработчиком и заказчиком системы.

3. ПРАВИЛА ОФОРМЛЕНИЯ

3.1. Разделы и подразделы ТЗ на АС должны быть размещены в порядке, установленном в разд.2 настоящего стандарта.

3.2. ТЗ на АС оформляют в соответствии с требованиями ГОСТ 2.105 на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней.

Номера листов (страниц) проставляют, начиная с первого листа, следующего за титульным листом, в верхней части листа (над текстом, посередине) после обозначения кода ТЗ на АС.

3.3. Значения показателей, норм и требований указывают, как правило, с предельными отклонениями или максимальным и минимальным значениями. Если эти показатели, нормы, требования однозначно регламентированы НТД, в ТЗ на АС следует приводить ссылку на эти документы или их разделы, а также дополнительные требования, учитывающие особенности создаваемой системы. Если конкретные значения показателей, норм и требований не могут быть установлены в процессе разработки ТЗ на АС, в нем следует сделать запись о порядке установления и согласования этих показателей, норм и требований:

"Окончательное требование (значение) уточняется в процессе... и согласовывается протоколом с... на стадии...". При этом в текст ТЗ на АС изменений не вносят.

3.4. На титульном листе помещают подписи заказчика, разработчика и согласующих организаций, которые скрепляют гербовой печатью. При необходимости титульный лист оформляют на нескольких страницах. Подписи разработчиков ТЗ на АС и должностных лиц, участвующих в согласовании и рассмотрении проекта ТЗ на АС, помещают на последнем листе.

Форма титульного листа ТЗ на АС приведена в приложении 2. Форма последнего листа ТЗ на АС приведена в приложении 3.

3.5. При необходимости на титульном листе ТЗ на АС допускается помещать установленные в отрасли коды, например: гриф секретности, код работы, регистрационный номер ТЗ и др.

3.6. Титульный лист дополнения к ТЗ на АС оформляют аналогично титульному листу технического задания. Вместо наименования "Техническое задание" пишут "Дополнение N ... к ТЗ на АС …".

3.7. На последующих листах дополнения к ТЗ на АС помещают основание для изменения, содержание изменения и ссылки на документы, в соответствии с которыми вносятся эти изменения.

3.8. При изложении текста дополнения к ТЗ следует указывать номера соответствующих пунктов, подпунктов, таблиц основного ТЗ на АС и т.п. и применять слова: "заменить", "дополнить", "исключить", "изложить в новой редакции".

ПРИЛОЖЕНИЕ 1 (рекомендуемое). ПОРЯДОК РАЗРАБОТКИ, СОГЛАСОВАНИЯ И УТВЕРЖДЕНИЯ ТЗ НА АС

1. Проект ТЗ на АС разрабатывает организация - разработчик системы с участием заказчика на основании технических требований (заявки, тактико-технического задания и т.п.).

При конкурсной организации работ варианты проекта ТЗ на АС рассматриваются заказчиком, который либо выбирает предпочтительный вариант, либо на основании сопоставительного анализа подготавливает с участием будущего разработчика АС окончательный вариант ТЗ на АС.

2. Необходимость согласования проекта ТЗ на АС с органами государственного надзора и другими заинтересованными организациями определяют совместно заказчик системы и разработчик проекта ТЗ на АС.

Работу по согласованию проекта ТЗ на АС осуществляют совместно разработчик ТЗ на АС и заказчик системы, каждый в организациях своего министерства (ведомства).

3. Срок согласования проекта ТЗ на АС в каждой организации не должен превышать 15 дней со дня его получения. Рекомендуется рассылать на согласование экземпляры проекта ТЗ на АС (копий) одновременно во все организации (подразделения).

4. Замечания по проекту ТЗ на АС должны быть представлены с техническим обоснованием. Решения по замечаниям должны быть приняты разработчиком проекта ТЗ на АС и заказчиком системы до утверждения ТЗ на АС.

5. Если при согласовании проекта ТЗ на АС возникли разногласия между разработчиком и заказчиком (или другими заинтересованными организациями), то составляется протокол разногласий (форма произвольная) и конкретное решение принимается в установленном порядке.

6. Согласование проекта ТЗ на АС разрешается оформлять отдельным документом (письмом). В этом случае под грифом "Согласовано" делают ссылку на этот документ.

7. Утверждение ТЗ на АС осуществляют руководители предприятий (организаций) разработчика и заказчика системы.

8. ТЗ на АС (дополнение к ТЗ) до передачи его на утверждение должно быть проверено службой нормоконтроля организации - разработчика ТЗ и, при необходимости, подвергнуто метрологической экспертизе.

9. Копии утвержденного ТЗ на АС в 10-дневный срок после утверждения высылаются разработчиком ТЗ на АС участникам создания системы.

10. Согласование и утверждение дополнений к ТЗ на АС проводят в порядке, установленном для ТЗ на АС.

11. Изменения к ТЗ на АС не допускается утверждать после представления системы для ее очереди на приемо-сдаточные испытания.

12. Регистрация, учет и хранение ТЗ на АС и дополнений к нему проводят в соответствии с требованиями ГОСТ 2.501 .

__

наименование организации - разработчика ТЗ на АС

УТВЕРЖДАЮ		УТВЕРЖДАЮ
Руководитель (должность, наименование предприятия - заказчика АС)		Руководитель (должность, наименование предприятия - разработчика АС)
Личная подпись Печать Дата	Расшифровка подписи	Личная подпись Печать Дата	Расшифровка подписи

_____________________________________________________________________________________

наименование вида АС

_____________________________________________________________________________________

наименование объекта автоматизации

_____________________________________________________________________________________

сокращенное наименование АС

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

На________ листах

Действует с

СОГЛАСОВАНО

Руководитель (должность, наименование
согласующей организации)

	Личная подпись Печать Дата	Расшифровка подписи

___________________________________

СОСТАВИЛИ

	Должность исполнителя	Фамилия, имя, отчество

СОГЛАСОВАНО

Наименование организации, предприятия	Должность	Фамилия, имя, отчество

Текст документа сверен по:
официальное издание
Информационная технология.
Автоматизированные системы.
Основные положения:
Сб. ГОСТов. - М.: ИПК
Издательство стандартов, 2002

ГОСТ 34.602-89 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

Название документа:
Номер документа:	34.602-89
Вид документа:	ГОСТ
Принявший орган:	Госстандарт СССР
Статус:	Действующий
Опубликован:	официальное издание Информационная технология. Автоматизированные системы. Основные положения: Сб. ГОСТов. - М.: ИПК Издательство стандартов, 2002 год
Дата принятия:	24 марта 1989
Дата начала действия:	01 января 1990
Дата редакции:	01 февраля 2002

ГОСТ 34.602-89 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

Как правильно разработать техническое задание для автоматизированной системы? Этот вопрос настолько широкий, что ответить в двух словах никак нельзя. Поэтому я решил написать большую статью на данную тему. В процессе работы я понял, что уложить все в одной статье не выйдет и решил разбить ее на две части:

• В первой части я подробно попытаюсь ответить на вопросы темы, рассмотрю структуру и назначение технического задания, дам некоторые рекомендации по формулировке требований.
• Вторая часть «Разработка технического задания. Как формулировать требования? » будет полностью посвящена выявлению и формулировке требований к информационной системе.

Для начала надо разобраться, какой в действительности вопрос интересует тех, кто спрашивает «Как разработать техническое задание?». Дело в том, что от того, для каких целей это делается, а также кем будет использоваться, будет сильно зависеть и подход к разработке технического задания. О каких вариантах я говорю:

• Коммерческая организация решила внедрить у себя автоматизированную систему. Она не имеет собственной IT-службы и решили поступить так: заинтересованное лицо должно разработать ТЗ и отдать его на разработку сторонней организации;
• Коммерческая организация решила внедрить у себя автоматизированную систему. Она имеет собственную IT-службу. Решили поступить так: разработать техническое задание, затем согласовать его между IT-службой и заинтересованными лицами, и реализовать собственными силами;
• Госструктура решила затеять IT-проект . Тут все настолько мутно, куча формальностей, откатов, распилов и пр. Я не буду рассматривать такой вариант в данной статье.
• IT-компания занимается услугами по разработке и/или внедрению автоматизированных систем. Это наиболее сложный случай, ведь приходится работать в самых различных условиях:

1) Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к техническому заданию.
2) Техническое задание разрабатывается для собственных разработчиков (клиенту все равно).
3) Техническое задание разрабатывается для передачи подрядчику (группе программистов, находящихся за штатом компании, или отдельному специалисту).
4) Между компаний и клиентом возникает непонимание в вопросе полученного результата , и компания вновь и вновь задается вопросом: «Как надо разрабатывать техническое задание?». Возможно, последний случай кажется парадоксом, но это правда.

• Возможны и другие, реже встречающиеся варианты;

Думаю, сейчас у читателя должны возникнуть вопросы:

• А почему нельзя разрабатывать техническое задание всегда одинаково?
• Существуют ли какие-то стандарты, методики, рекомендации? Где их взять?
• Кто должен разрабатывать техническое задание? Должен ли этот человек обладать какими-то специальными знаниями?
• Как понять, хорошо составлено техническое задание или нет?
• За чей счет должно оно разрабатываться, да и нужно ли оно вообще?

Этот список может быть бесконечным. Говорю так уверенно от того, что уже 15 лет в профессиональной разработке программного обеспечения, а вопрос о технических заданиях всплывает в любом коллективе разработчиков, с кем приходиться работать. Причины тому разные. Поднимая тему разработки технического задания, я прекрасно отдаю себе отчет в том, что не смогу изложить ее на 100% для всех интересующихся темой. Но, попробую, как говорится «разложить все по полочкам».

Те, кто уже знаком с моими статьями, знают, что я не пользуюсь «копипастом» труда других людей, не перепечатываю чужие книги, не цитирую многостраничные стандарты и прочие документы, которые вы и сами сможете найти в интернете, выдавая их за свои гениальные мысли. Достаточно набрать в поисковике «Как разработать техническое задание» и вы сможете прочитать много интересного, но, к сожалению, многократно повторяющегося. Как правило, те, кто любит умничать на форумах (попробуйте все-таки поискать!), сами никогда не делали толкового ТЗ, и непрерывно цитируют рекомендации ГОСТов по данному вопросу. А тем, кто действительно серьезно занимается вопросом, обычно некогда сидеть на форумах. Про ГОСТЫ, кстати, мы тоже поговорим.

В разные годы своей работы мне приходилось видеть множество вариантов технической документации , составленной как отдельными специалистами, так и именитыми командами и консалтинговыми компаниями. Иногда еще я занимаюсь такой деятельностью: выделяю себе время и занимаюсь поиском информации на интересующую тему по необычным источникам (такой небольшой разведкой). В результате приходилось видеть документацию и по таким «монстрам» как «ГазПром», «РЖД» и много других интересных компаний. Конечно же, я соблюдаю политику конфиденциальности, несмотря на то, что эти документы попадают ко мне из общедоступных источников или безответственности консультантов (разбрасывают информацию по интернету). Поэтому сразу говорю: конфиденциальной информацией, которая принадлежит другим компаниям, не делюсь, независимо от источников возникновения (профессиональная этика).

Что такое техническое задание?

Первое, что мы сейчас сделаем, так это разберемся – что за зверь такой – «Техзадание».

Да, действительно существуют ГОСТы и стандарты, в которых предприняты попытки регламентировать эту часть деятельности (разработки программного обеспечения). Когда-то все эти ГОСТы были актуальны и активно применялись. Сейчас существуют разные мнения по поводу актуальности данных документов. Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели. Возможно, кто-то сейчас подумал, что правда где-то посередине. Я бы ответил словами Иоганна Гете: «Говорят, что между двумя противоположными мнениями находится истина. Ни в коем случае! Между ними лежит проблема». Так вот, между этими мнениями истины нет. Потому как ГОСТы не раскрывают практических проблем современной разработки, а те, кто их критикует, альтернативы (конкретной и системной) не предлагают.

Заметим, что в ГОСТе явно не дано даже определения, сказано лишь: «ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации – далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие».

Если кому-то интересно, о каких ГОСТах я говорю, то вот они:

• ГОСТ 2.114-95 «Единая система конструкторской документации. Технические условия»;
• ГОСТ 19.201-78 «Единая система программной документации. Техническое задание. Требования к содержанию и оформлению»;
• ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

Куда более удачное определение представлено в Википедии: «Техническое задание – это исходный документ на проектирование технического объекта. Техническое задание устанавливает основное назначение разрабатываемого объекта, его технические и тактико-технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и ее состав, а также специальные требования. Задание как исходный документ на создание чего-то нового существует во всех областях деятельности, различаясь по названию, содержанию, порядку оформления. (Например, проектное задание в строительстве, боевое задание, домашнее задание, договор на литературное произведение)».

Итак, как следует из определения, основное назначение техзадания – сформулировать требования к разрабатываемому объекту, в нашем случае к автоматизированной системе. Настало время взяться за главное: разложить все «по полочкам», как и обещал.

Что необходимо знать о требованиях? Необходимо четко понимать, что все требования нужно разделять по видам и по свойствам. Сейчас мы научимся это делать. Для разделения требований по видам нам как раз поможет ГОСТ. Тот перечень видов требований, который там представлен, является хорошим образцом того, требования каких видов следует рассматривать. Например:

• Требования в функциональности;
• Требования к безопасности и правам доступа;
• Требования к квалификации персонала и т.д.

Думаю, вам очевидно, что ключевым фактором успешного технического задания являются именно хорошо сформулированные требования к функциональности. Именно этим требованиям посвящено большинство работ и методик, о которых я говорил. Требования к функциональности – это 90% сложности работ по разработке технического задания. Все остальное зачастую является «камуфляжем», который надет на эти требования. Если требования сформулированы плохо, то какой красивый камуфляж на них не натягивай, успешного проекта не выйдет. Да, формально все требования будут соблюдены (по ГОСТу), ТЗ разработано, утверждено и подписано, деньги за него получены. И что? А дальше начнется самое интересное: что делать-то? Если это проект на Госзаказе, то проблем нет – там бюджет такой, что ни в какой карман не влезет, в процессе реализации (если она будет) все и будет выясняться. Именно таким образом и пилится большинство бюджетов проектов на Госзаказах. (Накалякали «ТЗ», слили десяток миллионов, а проект делать не стали. Все формальности соблюдены, виновных нет, новое авто возле дома. Красота!). Но ведь мы говорим о коммерческих организациях, где деньги считают, да и результат нужен другой. Поэтому давайте разбираться с главным, как разрабатывать полезные и работающие ТЗ.

Про виды требований я сказал, а что же со свойствами? Если виды требований могут быть различными (зависит от целей проекта), то со свойствами все проще, их три:

1. Требование должно быть понятным ;
2. Требование должно быть конкретным ;
3. Требование должно быть тестируемым ;

Причем последнее свойство невозможно без двух предыдущих, являясь этакой «лакмусовой бумажкой». Если результат выполнения требования невозможно протестировать, значит, оно либо непонятное, либо неконкретное. Подумайте об этом. Именно во владении этими тремя свойствами требований и заключается мастерство и профессионализм. На самом деле все очень просто. Когда разберешься.

На этом повествование о том, что такое техническое задание можно было бы завершить и перейти к главному: как формулировать требования. Но не так все быстро. Есть еще один крайне важный момент:

• На каком языке (в смысле сложности понимания) должно быть написано техническое задание?
• Должны ли быть описаны в нем спецификации различных функций, алгоритмы, типы данных и прочие технические штуки?
• А что такое техническое проектирование, о котором, кстати, сказано и в ГОСТах, и как оно связано с техническим заданием?

В ответах на эти вопросы кроется очень коварная вещь. Именно поэтому часто возникают споры о достаточности или отсутствии необходимой детализации требований, о понятности документа заказчиком и исполнителями, об избыточности, формате представления и т.д. А где вообще граница между техническим заданием и техническим проектом?

Так вот: техническое задание – это документ, в основе которого лежат требования, сформулированные на понятном (обычном, привычном) для заказчика языке. При этом может и должна использоваться отраслевая терминология, понятная заказчику. Никаких привязок к особенностям технической реализации быть не должно. На этапе ТЗ в принципе неважно, на какой платформе будут реализовываться эти требования. Хотя есть исключения. Если речь идет о внедрении системы на основе уже существующего программного продукта, то такая привязка может иметь место, но только на уровне экранных форм, форм отчетов и пр. Выяснением и формулированием требований, а также разработкой технического задания должен заниматься бизнес-аналитик. И уж никак не программист (если только он не совмещает в себе эти роли, такое случается). Этот человек должен говорить с заказчиком на языке его бизнеса .

Технический проект – это документ, который предназначен для технической реализации требований, сформулированных в техническом задании. Как раз в этом документе описываются структуры данных, триггеры и хранимые процедуры, алгоритмы и прочие штуки, которые потребуются техническим специалистам. Заказчику в это вникать вовсе необязательно (ему и термины такие могут быть непонятны). Технический проект делает архитектор системы (вот совмещение этой роли с программистом вполне нормально). А точнее группа специалистов АО в главе с архитектором. Чем больше проект, тем больше людей работает над техническим заданием.

Что мы имеем на практике? Забавно наблюдать, когда директору приносят на согласование техническое задание, которое изобилует технической терминологией, описанием типов данных и их значений, структуры базы данных и пр. Он, конечно, пытается вникнуть, раз надо утверждать, пытаясь найти между строк знакомые слова и не потерять цепочку бизнес-требований. Что, знакомая ситуация? И чем это заканчивается? Как правило, такое ТЗ утверждается, затем реализуется, а в 80% случаев потом совсем не соответствует факту выполненных работ – много чего решили изменить, переделать, неправильно поняли, не так думали и т.д. А потом начинается сериал про сдачу работ. «А вот тут не так как нам надо», а «это у нас работать не будет», «это слишком сложно», «это неудобно» и т.д. Знакомо?! Вот и мне знакомо, пришлось набить шишек в свое время.

Так что мы имеем на практике-то? А на практике мы имеем размытую границу между техническим заданием и техническим проектом. Она плавает между ТЗ и ТП в самых разных проявлениях. И это плохо. А получается так, потому что культура разработки стала слабой. Частично это связано с компетенциями специалистов, частично со стремлением сократить бюджеты и сроки (ведь документация занимает много времени – это факт). Есть и еще один важный фактор, влияющий на использование технического проекта как отдельного документа: стремительное развитие средств быстрой разработки, а также методологий разработки. Но это отдельная история, чуть ниже несколько слов об этом скажу.

Еще небольшой, но важный момент. Иногда техническим заданием называют небольшой кусочек требований, простой и понятный. Например, доработать поиск объекта по каким-либо условиям, добавить колонку в отчет и пр. Такой подход вполне оправдан, зачем усложнять себе жизнь. Но применяется не на больших проектах, а на мелких доработках. Я бы сказал, это ближе к сопровождению программного продукта. В этом случае в техническом задании может быть описано и конкретное техническое решение реализации требования. Например, «В алгоритм такой-то внести такое-то изменение», с указанием конкретной процедуры и конкретного изменения для программиста. Это тот случай, когда граница между техническим заданием и техническим проектом полностью стирается, нет никакой экономической целесообразности раздувать бумаготворчество там, где это не нужно, а полезный документ создается. И это правильно.

А нужно ли вообще техническое задание? А технический проект?

Не перегрелся ли я? Разве такое возможно, вообще без технического задания? Представьте себе возможно (точнее, встречается), и у такого подхода есть много последователей, и их число увеличивается. Как правило, после того, как молодые специалисты начитаются книг про Scrum, Agile и прочие технологии быстрой разработки. На самом деле это замечательные технологии, и они работают, только в них не говорится дословно «не надо делать технических заданий». В них говорится «минимум бумаг», особенно ненужных, ближе к заказчику, больше конкретики и быстрее к результату. Но фиксирование требований никто не отменял, и там это явно сказано. Как раз там требования и фиксируются исходя из трех замечательных свойств, о которых я говорил выше. Просто у некоторых людей так устроено сознание, что если можно что-то упростить, так давайте это упростим до полного отсутствия. Как сказал Альберт Эйнштейн: «Сделай так просто, как возможно, но не проще этого». Золотые ведь слова, ко всему подходят. Так что техническое задание нужно, иначе успешного проекта вам не видать. Другой вопрос, как составлять и что туда включать. В свете методологий быстрой разработки надо сосредоточиться только на требованиях, а весь «камуфляж» можно отбросить. В принципе, я с этим согласен.

А что же с техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую вы задумали. Должен ли с ним знакомиться заказчик? Если хочет, почему нет, но настаивать и утверждать данный документ нет никакой необходимости, он будет только сдерживать и мешать работать. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP-подходе (экстремальном программировании), которому уже порядка 20 лет. Так что сделайте качественное ТЗ, понятное заказчику, а технический проект используйте как внутренний документ, для взаимоотношений между архитектором системы и программистами.

Интересная деталь по поводу технического проектирования: некоторые средства разработки, устроенные по принципу предметной ориентированности (типа 1С и аналогичных) предполагают, что проектирование (имеется в виду процесс документирования) требуется только на действительно сложных участках, где требуется взаимодействие между собой целых подсистем. В простейшем случае, например, создать справочник, документ, достаточно лишь правильно сформулированных бизнес-требований. Об этом говорит и стратегия бизнеса этой платформы в части подготовки специалистов. Если посмотреть на экзаменационный билет специалиста (именно так он называется, а не «программиста»), то увидите, что там присутствуют лишь бизнес-требования, а как их реализовать на программном языке это и есть задача специалиста. Ту часть задачи, которую призван решать технический проект, специалист должен решить «в голове» (речь идет о задачах средней сложности), причем здесь и сейчас, следуя определенным стандартам разработки и проектирования, которые формирует опять же компания 1С для своей платформы. Таким образом, из двух специалистов, результат работы которых внешне выглядит одинаково, один может экзамен сдать, а второй нет, так как грубо нарушил стандарты разработки. Заведомо предполагается, что специалисты должны обладать такой квалификацией, чтобы типичные задачи проектировать самостоятельно, без привлечения архитекторов системы. И такой подход работает.

Продолжим исследование вопроса: «Какие требования включать в техническое задание?»

Формулирование требований к информационной системе. Структура ТЗ

Сразу определимся: мы будет говорить именно о формулировании требований к информационной системе, предполагая, что работа по выработке бизнес-требований, формализации бизнес-процессов и вся предшествующая консалтинговая работа уже выполнена. Конечно, некоторые уточнения могут выполняться и на этом этапе, но именно уточнения. Сам проект автоматизации не решает проблем бизнеса – помните об этом. Это аксиома. Почему-то некоторые руководители пытаются ее опровергнуть, считая, что если купят программу, то наступит порядок в хаотичном бизнесе. Но ведь аксиома на то и аксиома, что доказательств не требует.

Как и любую деятельность, формулирование требований можно (и нужно) разделить на этапы. Всему свое время. Это тяжелый интеллектуальный труд. И, если относится к нему с недостаточным вниманием, то результат будет соответствующий. По экспертным оценкам, стоимость затрат на разработку технического задания может составлять 30-50%. Я придерживаюсь такого же мнения. Хотя 50 – пожалуй, перебор. Ведь техническое задание – это еще не последний документ, который должен быть разработан. Ведь еще должно быть и техническое проектирование. Такой разброс обусловлен различными платформами автоматизации, подходами и технологиями, применяемыми проектными командами при разработке. Например, если речь идет о разработке на классическом языке типа С++, то без детального технического проектирования тут не обойтись. Если речь идет о внедрении системы на платформе 1С, то тут с проектированием ситуация несколько иная, как мы видели выше (хотя, при разработке системы «с нуля», она проектируется по классической схеме).

Несмотря на то, что формулировка требований является основной частью технического задания, в некоторых случая она становится единственным разделом ТЗ, следует обратить внимание на то, что это важный документ, и оформлять его следует соответственно. С чего начать? В первую очередь начать надо с содержания. Составьте содержание, а затем начните его разворачивать. Лично я делаю так: сначала набрасываю содержание, описываю цели, всю вводную информацию, а затем принимаюсь за основную часть – формулировку требований. Почему не наоборот? Не знаю, мне так удобнее. Во-первых, это гораздо меньшая часть времени (по сравнению с требованиями), во-вторых, пока описываешь всю вводную информацию, настраиваешься на главное. Ну, это кому как нравится. Со временем у вас выработается свой шаблон технического задания. Для начала рекомендую в качестве содержания взять именно тот, что описан в ГОСТ. Для содержания он подходит отлично! Затем берем и начинаем описывать каждый раздел, не забывая про рекомендации следования трем свойствам: понятности, конкретности и тестируемости. Почему я на этом так настаиваю? Об этом в следующем разделе. А сейчас предлагаю все-таки пройтись по тем пунктам ТЗ, которые рекомендуются в ГОСТе.

1. Общие сведения.

2. Назначение и цели создания (развития) системы.

3. Характеристика объектов автоматизации.

4. Требования к системе.

5. Состав и содержание работ по созданию системы.

6. Порядок контроля и приемки системы.

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.

8. Требования к документированию.

9. Источники разработки.

Итого, девять разделов, каждый из которых тоже делится на подразделы. Разберем их по порядку. Для удобства представлю все в виде таблицы по каждому пункту.

Раздел 1. Общие сведения

Полное наименование системы и ее условное обозначение;	Тут все понятно: пишем, как будет называться система, ее краткое наименование
Шифр темы или шифр (номер) договора;	Это не актуально, но можно и указать, если требуется
Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;	Указывают, кто (какие организации) будет работать над проектом. Можно указать и их роли. Можно вообще удалить этот раздел (достаточно формальный).
Перечень документов, на основании которых создается система, кем и когда утверждены эти документы;	Полезная информация. Тут стоит указать ту нормативно-справочную документацию, которую вам предоставили для ознакомления с определенной частью требований
Плановые сроки начала и окончания работы по созданию системы;	Пожелания по срокам. Иногда в ТЗ об этом пишут, но чаще такие вещи описываются в договорах на работы
Сведения об источниках и порядке финансирования работ;	Аналогично, как и в предыдущем пункте про сроки. Более актуально для государственных заказов (для бюджетников)
Порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.	Не вижу необходимости в этом пункте, требования к документированию вынесены отдельно, а кроме этого есть целый отдельный раздел «Порядок контроля и приемки» системы.

Раздел 2. Назначение и цели создания (развития) системы

	Что с этим делать на практике
Назначение системы	С одной стороны с назначением все просто. Но желательно формулировать конкретно. Если написать что-то вроде «качественно автоматизировать складской учет в компании Х», то потом можно долго обсуждать результат при его завершении, даже независимо от хорошей формулировки требований. Заказчик всегда может говорить, что под качеством он имел в виду нечто иное. В общем, нервов можно попортить друг другу много, а зачем? Лучше сразу написать примерно так: «Система предназначена для ведения складского учета в компании Х в соответствии с требованиями, зафиксированными в данном техническом задании».
Цели создания системы	Цели – это, безусловно, важный раздел. Если уж его включать, то надо уметь эти цели формулировать. Если у вас трудности с формулировкой целей, то лучше вообще исключить данный раздел. Пример неудачной цели: «Обеспечить быстрое оформление документов менеджером». Что такое быстрое? Это можно потом доказывать бесконечно. Если это важно, то лучше переформулировать данную цель так: «Менеджер по продажам должен иметь возможность оформить документ «Реализация товаров» из 100 строк за 10 минут». Подобная цель может появиться, если, например, в настоящее время менеджер тратит на это около часа, что слишком много для этой компании и для них это важно. В такой формулировке цель уже пересекается с требованиями, что вполне естественно, при разворачивании дерева целей (дробя их на более мелкие связанные цели), мы и так будем приближаться к требованиям. Поэтому, увлекаться не стоит. Вообще, умение выделять цели, формулировать их, строить дерево целей – это тема совершенно отдельная. Запомните главное: умеете – пишите, не уверены – вообще не пишите. А что будет, если не сформулировать цели? Будете работать по требованиям, такое часто практикуется.

Раздел 3. Характеристика объектов автоматизации

Раздел 4. Требования к системе

	Что с этим делать на практике
Требования к системе в целом. ГОСТ расшифровывает перечень таких требований: требования к структуре и функционированию системы; требования к численности и квалификации персонала системы и режиму его работы; показатели назначения; требования к надежности; требования безопасности; требования к эргономике и технической эстетике; требования к транспортабельности для подвижных АС; требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы; требования к защите информации от несанкционированного доступа; требования по сохранности информации при авариях; требования к защите от влияния внешних воздействий; требования к патентной чистоте; требования по стандартизации и унификации;	Несмотря на то, что основным, безусловно, будет раздел с конкретными требованиями (функциональными), данный раздел тоже может иметь большое значение (и в большинстве случаев имеет). Что может оказаться важным и полезным: Требования к квалификации. Возможно, разрабатываемая система потребует переподготовки специалистов. Это могут быть как пользователи будущей системы, так и IT-специалисты, которые будут нужны для ее поддержки. Недостаточное внимание к данному вопросу нередко перерастает в проблемы. Если квалификация имеющегося персонала явно недостаточна, лучше прописать требования к организации обучения, программе обучения, срокам и т.п. Требования к защите информации от несанкционированного доступа. Тут комментарии излишни. Это как раз и есть требования к разграничению доступа к данным. Если такие требования планируются, то их нужно расписать отдельно, как можно более детально по тем же правилам, что и функциональные требования (понятность, конкретность, тестируемость). Поэтому, можно эти требования включить и в раздел с функциональными требованиями Требования к стандартизации. Если существуют какие-либо стандарты разработки, которые применимы к проекту, они могут быть включены в требования. Как правило, такие требования инициирует IT-служба заказчика. Например, у компании 1С есть требования к оформлению программного кода, проектированию интерфейса и пр.; Требования к структуре и функционированию системы. Тут могут быть описаны требования к интеграции систем между собой, представлено описание общей архитектуры. Чаще требования к интеграции выделяют вообще в отдельный раздел или даже отдельное техническое задание – эти требования могут оказаться достаточно сложными. Все остальные требования менее важны и можно их не описывать. На мой взгляд, они только утяжеляют документацию, и практической пользы несут немного. А требования к эргономике описывать в виде общих требований очень сложно, лучше их перенести к функциональным. Например, может быть сформулировано требование «Получить информацию о цене товара нажав только одну кнопку». На мой взгляд, это все-таки ближе к конкретным функциональным требованиям, хоть и относится к эргономике.
Требования к функциям (задачам), выполняемым системой	Вот он, тот самый главный и ключевой пункт, который будет определять успех. Даже если все остальной сделать на отлично, а этот раздел на «3», то и результат по проекту будет в лучшем случае на «3», а то и вообще проект провалится. Именно эти мы и займемся более детально во второй статье. Именно к этому пункту относится «правило трех свойств требований», о которых я говорил.
Требования к видам обеспечения ГОСТ выделяет такие виды: Математическое Информационное Лингвистическое Программное Техническое Метрологическое Организационное Методическое и другие…	На первый взгляд может показаться, что эти требования не важны. В большинстве проектов это действительно так. Но не всегда. Когда стоит описывать данные требования: Решения о том, на каком языке (или какой платформе) будет вестись разработка не принято; К системе предъявляются требования мультиязычного интерфейса (например, русский/английский) Для функционирования системы должно быть создано отдельное подразделения или приняты на работу новые сотрудники; Для функционирования системы у заказчика должны произойти изменения в методиках работы и эти изменения должны быть конкретизированы и запланированы; Предполагается интеграция с каким-либо оборудованием и к нему предъявляются требования (например, сертификации, совместимости и пр.) Возможны другие ситуации, все зависит от конкретных целей проекта.

Раздел 5. Состав и содержание работ по созданию системы

Раздел 6. Порядок контроля и приемки системы

Что с этим делать на практике

Виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему); Общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации;

Но даже наличие тестируемых требований может оказаться недостаточно при сдаче системы, если четко не прописан порядок приемки-передачи работ. Например, распространенная ловушка: система сделана, вполне работоспособна, но заказчик по каким-либо причинам не готов в ней работать. Причины эти могут быть любые: некогда, поменялись цели, кто-то уволился и т.п. И говорит: «Поскольку мы еще не работаем с новой системой, значит, и не можем быть уверены, что она работает». Так что учитесь правильно выделять этапы работ, способы проверки результатов по этим этапам. Причем заказчику такие способы должны быть понятны изначально. Если они зафиксированы на уровне технического задания, то всегда можно при необходимости к ним обратиться и подвести работы к передаче.

Раздел 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

	Что с этим делать на практике
Приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;	Весьма важный момент. К примеру, для функционирования системы так, как задумано, может потребоваться использование каких-либо отраслевых или общероссийских справочников и классификаторов. Эти справочники должны каким-то образом появляться в системе, обновляться и правильно использоваться. Могут быть и любые другие правила ввода информации, принятые в компании (или планируемые). Например, информация о договоре раньше заносили текстовой строкой в произвольном виде, а теперь требуется номер отдельно, дату отдельно и т.д. Таких условий может быть очень много. Часть из них может быть воспринята с сопротивлением персонала, поэтому лучше все такие случаи прописать на уровне требований к порядку ввода данных
Изменения, которые необходимо осуществить в объекте автоматизации Создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ	Любые изменения, которые могут потребоваться. Например, в компании отсутствует локальная сеть, устаревший парк компьютеров, на которых система не заработает. Возможно, какая-то необходимая информация обрабатывалась на бумаге, а теперь ее необходимо вводить в систему. Если этого не делать, то какой-либо модуль не заработает. Возможно, что-то упрощалось, а теперь требуется учитывать более детально, соответственно кто-то должен собирать информацию по определенным правилам. Этот перечень может быть длинным, смотрите на конкретный случай своего проекта.
Создание необходимых для функционирования системы подразделений и служб; Сроки и порядок комплектования штатов и обучения персонала	Про это мы уже говорили ранее. Возможно, система разрабатывается под новую структуру или вид деятельности, которого раньше не было. Если не будет соответствующего персонала, да еще и обученного, то система не заработает, как грамотно ее не строй.

Раздел 8. Требования к документированию

Что с этим делать на практике

Согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов

Наличие полноценной документации – важная часть результата. Все мы знаем, что документирование чего-либо трудоемкий труд. Поэтому, необходимо заранее оговорить с заказчиком, какие виды документации будут разрабатываться, как они будут выглядеть (содержание и желательно примеры). Подумайте, как будут представлены руководства пользователя. Возможно, у заказчика есть принятые корпоративные стандарты, значит надо к ним обращаться. Игнорирование требований к документации очень часто приводит к самым неожиданным последствиям на проектах. Например, все сделано и все работает. Пользователи тоже умеют работать. Про документацию вообще не договаривались и не разговаривали. И вдруг при сдаче работ кто-то из топ-менеджеров заказчика, который даже не участвовал в проекте, но участвует в приемке работ, спрашивает: «А где руководства пользователя?». И начинает вас убеждать, что о наличии руководств пользователя договариваться и не нужно, это «само собой» якобы подразумевается. И все, не хочет принимать работу. За чей счет будете разрабатывать руководства? На этот крючок попадали уже многие команды.

Раздел 9. Источники разработки

Мы рассмотрели все разделы, которые могут быть включены в техническое задание. «Могут», а не «Обязаны», потому что любой документ должен разрабатываться для достижения результата. Поэтому, если очевидно, что какой-то отдельный раздел к результату не приблизит, значит, он вам не нужен и не надо тратить на него время.

Но вот без главного – функциональных требований – ни одно грамотное техническое задание не обходится. Хочу заметить, что на практике такие технические задания встречаются, и еще как! Есть деятели, которые сумеют развести воды по всем разделам, опишут общие требования общими словами, и документ получается весьма увесистый, и слов в нем умных много, и даже заказчику может понравиться (он его утвердит). Но вот работать по нему может не получиться, практической пользы от него мало. В большинстве случаев такие документы рождаются, когда надо получить много денег именно под техническое задание, а сделать его надо быстро и не погружаясь в детали. Особенно, если известно, что дальше дело не пойдет, или его будут делать совсем другие люди. В общем, просто для освоения бюджета, особенно государственного.

Во второй статье будем говорить только о разделе №4 «Требования к системе», а конкретно будет формулировать требования из соображений понятности, конкретности и тестируемости.

Почему требования должны быть понятными, конкретными и тестируемыми?

Потому что практика показывает: поначалу большинство ТЗ, которые разрабатывают специалисты, либо оказываются невостребованы (не соответствуют действительности), либо становятся проблемой для того, кто их должен реализовать, так как заказчик начинает манипулировать неконкретными терминами и требованиями. Приведу несколько примеров того, какие фразы встречались, к чему это приводило, а затем попробую дать рекомендации, как избежать подобных проблем.

Вид требования

Неправильная формулировка

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

• Содержание
• Введение
• 1. Техническое задание
• 1.1 Общие сведения
• 1.2 Основания для разработки
• 1.3 Назначение и цели создания системы
• 1.4 Требования к системе
• 1.4.1 Требования к системе в целом
• 1.4.2 Требования к функциям (задачам), выполняемым системой
• 1.4.3 Требования к видам обеспечения
• 1.5 Характеристика объектов автоматизации
• 1.6 Требования к документированию
• 1.7 Стадии и этапы разработки
• 1.7.1 Стадии разработки
• 1.7.2 Этапы разработки
• 1.7.3 Содержание работ по этапам
• 1.8 Порядок контроля и приемки системы
• 1.8.1 Виды, состав, объем и методы испытаний системы и ее составных частей
• 1.8.2 Общие требования к приемке работ по стадиям
• 1.8.3 Статус приемочной комиссии (государственная, межведомственная, ведомственная)
• 2. Технический проект
• 2.1 Функциональная структура
• 2.1.1 Описание предметной области
• 2.1.2 Функции и организационная структура
• 2.1.3 Описание потоков данных и бизнес процессов
• 2.2 Системное проектирование ИС
• 2.2.1 Разработка концепции, архитектуры построения и платформы реализации ИС
• 2.2.2 Структура информационной системы, состав функциональных и обеспечивающих подсистем
• 2.2.3 Техническое обеспечение ИС
• 2.3 Информационное обеспечение ИС
• 2.3.1 Описание логической структуры информационной базы
• 2.3.2 Описание физической реализации БД
• Заключение
• Список литературы

Введение

В курсовой работе рассматриваются вопросы создания технического задания на разработку информационной системы для системы для агентства по продаже и бронированию авиабилетов. Целью работы является изучение основных принципов и получение базовых навыков подготовки технических заданий на разработку информационных систем, их программного обеспечения.

Работа по созданию информационной системы начинается с формирования требований заказчика к создаваемой системе и оформления их в виде технического задания (ТЗ). ТЗ является основным документом, определяющим требования и порядок создания автоматизированной системы, в соответствии с которым проводится разработка системы и ее приемка при вводе в действие. Кроме того, на основании ТЗ производится калькуляция работ, уточняются трудозатраты.

ТЗ состоит из трех стадий:

1. обоснование необходимости разработки информационной системы - постановка задачи, сбор исходных материалов, выбор и обоснование критериев эффективности и качества разработанной системы, обоснование необходимости проведения НИР;

2. НИР - определение структуры входных и выходных данных, предварительный выбор методов решения задач, обоснование целесообразности применения разработанной системы, определение требований к техническим средствам, обоснование принципиальной возможности решения поставленной задачи;

3. разработка и утверждение ТЗ - определение требований к программам, разработка технико-экономического обоснования системы, определение стадий, этапов и сроков разработки системы и документация на нее, выбор языков программирования, определение необходимости проведения НИР на последних стадиях, согласование и утверждение ТЗ.

ТЗ выполняет следующие функции:

Организационная функция - зафиксированное задание для Исполнителя и окончательные требования со стороны Заказчика.

Информационная функция - порядок в процессе Исполнителя и продуманность желаний со стороны Заказчика.

Коммуникационная функция - взаимная договоренность о "предмете проекта", исключающая претензий.

Юридическая функция - ТЗ имеет равную юридическую силу с "Договором".

От того полноты и точности составления ТЗ во многом зависит результат разрабатываемого технического проекта.

1. Техническое задание

1.1 Общие сведения

Полное наименование системы и ее условное обозначение: "Автоматизированная информационная система агентства по продаже и бронированию авиабилетов". Краткая характеристика области применения

Система предназначена для применения в организации заказчика, в нашем случае - агентство по продаже и бронированию авиабилетов.

Порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы: АИС "Билет" поставляется в виде исполняемых модулей по завершению всего объема работ, технические средства приобретаются Заказчиком самостоятельно. Оформление результатов работ по созданию системы производится путем подписания акта о принятии системы Заказчиком при отсутствии претензий к Разработчику. Акт составляется в двух экземплярах. Один экземпляр находится у Заказчика, другой - у Разработчика.

1.2 Основания для разработки

Основанием для разработки технического задания является задание к курсовой работе по курсу "Проектирование информационных систем".

Наименование темы разработки - "Разработка информационной системы агентства по продаже и бронированию авиабилетов"

Условное обозначение темы разработки (шифр темы) - "ИС АПБ"

1.3 Назначение и цели создания системы

Функциональное назначение системы: АИС "Билет" предназначена для автоматизации работы агентства по продаже и бронированию авиабилетов.

Эксплуатационное назначение системы: Система должна эксплуатироваться сотрудниками организации.

Цели создания системы: Система ускоряет процесс заказа авиабилетов, тем самым упрощает работу агентства.

1.4 Требования к системе

1.4.1 Требования к системе в целом

Требования к структуре и функционированию системы

Перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы

АИС "Билет" включает следующие подсистемы:

Принятие заказа;

Оформление билета;

Расчет с заказчиком.

Подсистема "Принятие заказа" предназначена для регистрации заказа авиабилетов.

Подсистема "Расчет с заказчиком" обеспечивает заказчика номером брони, связанным с паспортными данными (оплата по карточке).

Требования к способам и средствам связи для информационного обмена между компонентами системы:

Информационный обмен осуществляется посредством локальной сети.

Требования к режимам функционирования системы:

Система должна поддерживать многопользовательский и автономный режимы работы. Пользователи осуществляют доступ к системе через сеть интернет или Call-центр.

Требования к численности и квалификации персонала системы

Требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков:

Сотрудник, занимающиеся приемом заявок, должен обладать навыками работы с персональным компьютером на уровне пользователя. Численность персонала может быть различной в зависимости от объема заказов.

Требования к надежности

Восстановление системы при ошибках в работе аппаратных средств (кроме носителей данных и программ) и ошибках, связанных с программным обеспечением (ОС и драйверы устройств), восстановление работоспособности возлагается на ОС.

При сбоях в системе электроснабжения аппаратной части, приводящих к перезагрузке ОС, восстановление программы должно происходить после перезапуска ОС и запуска исполняемого файла системы.

Также должна быть обеспечена работоспособность системы в целом в случае возникновения сбоев, аварий и отказов на отдельных рабочих станциях. Для защиты аппаратуры от бросков напряжения и коммутационных помех должны применяться сетевые фильтры, а для возможности сохранения данных пользователем при сбое в системе электропитания рекомендуется применять источники бесперебойного питания.

Требования к безопасности

Заказчиком обеспечивает соответствие технических решений, использованных при модификации и разработке подсистемы, действующим нормам, правилам техники безопасности, пожаробезопасности и взрывобезопасности, охраны окружающей среды.

Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

Условия эксплуатации, а также виды и периодичность обслуживания технических средств подсистемы должны соответствовать требованиям по эксплуатации, техническому обслуживанию, ремонту и хранению, изложенным в документации завода-изготовителя (производителя) на них.

Требования к защите информации о т несанкционированного доступа

Для защиты информации от несанкционированного доступа Система должна обеспечивать:

а) идентификацию и аутентификацию пользователя;

б) проверку прав и ограничений доступа пользователя на уровне функций и массивов данных при работе с системой.

Требования по сохранности информации при авариях

Необходимо предусмотреть возможность резервного копирования данных системы средствами программного обеспечения, поставляемого Разработчиком.

Требования по стандартизации и унификации

Для данной системы должна применяться каскадная модель жизненного цикла ПО.

В системе должны использоваться (при необходимости) общероссийские классификаторы и единые классификаторы и словари для различных видов алфавитно-цифровой и текстовой информации.

Интерфейс системы, файлы справок и любая текстовая информация в программе должны быть на русском языке.

Экранные формы должны проектироваться с учетом требований унификации:

Все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации.

1.4.2 Требования к функциям (задачам), выполняемым системой

По каждой подсистеме перечень функций, задач или их компонентов (в том числе обеспечивающих взаимодействие частей системы), поддерживающих автоматизации

Информационная система должна обеспечивать выполнение следующих функций:

Подсистема принятия заказа,

Подсистема расчета с клиентом.

1.4.3 Требования к видам обеспечения

К информационному обеспечению системы

К составу, структуре и способам организации данных в системе

Данные системы хранятся на одной локальной машине. На вход системы подается описание заказа, на выходе должен быть счет и идентификационный номер заказчика.

К структуре процесса сбора, обработки, передачи данных в системе и представлению данных.

Данные вводятся в систему вручную, обрабатываются и выдаются пользователю в требуемом виде (электронный, печатный).

К защите данных от разрушений при авариях и сбоях в электропитании системы

В комплекс технических средств должен входить источник бесперебойного питания. Работа данного источника должна составлять не менее получаса для корректного завершения работы системы.

К контролю, хранению, обновлению и восстановлению данных

Система должна поддерживать автоматическое ежедневное резервное копирование.

Требования к программному обеспечению системы

Система должна работать в операционных системах Windows XP/Vista/7/8

Требования к техническому обеспечению системы

К видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе.

Рабочие станции;

Источник бесперебойного питания;

Среда передачи данных между рабочими станциями (например, витая пара UTP 5e);

Принтер.

Технические средства приобретаются Заказчиком самостоятельно.

К функциональным, конструктивным и эксплуатационным характеристикам средств технического обеспечения системы.

Процессор Intel Pentium IV 2 ГГц и выше, оперативная память не менее 2Гб, объем жесткого диска не менее 500 Гбайт.

Требования к орган изационному обеспечению системы

Для организационного обеспечения приводят требования:

К структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию.

Функционирование системы обеспечивает инженер-системотехник, в эксплуатации участвуют 4 сотрудника.

К организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации.

Организационное обеспечение должно быть достаточным для эффективного выполнения персоналом возложенных на него обязанностей при осуществлении функций системы.

К защите от ошибочных действий персонала системы.

Защита от ошибок персонала заключается в проверке заполнения данных в некоторых полях, возможности восстановления исходных данных и отмены последних изменений, разграничении доступа по функциям и полномочиям сотрудников.

1.5 Характеристика объектов автоматизации

Краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию

В качестве объекта автоматизации выступает процесс, связанный с заказом авиабилетов.

Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды

Данная система будет установлена в производственных и офисных помещениях.

1.6 Требования к документированию

Для системы на различных стадиях создания должны быть выпущены следующие документы:

Схема организационной структуры;

Схема функциональной структуры;

Перечень входных сигналов и данных;

Перечень выходных сигналов (документов);

Пояснительная записка к техническому проекту;

Описание автоматизируемых функций;

Описание постановки задач (комплекса задач);

Описание организации информационной базы;

Описание массива информации;

Описание программного обеспечения;

Руководство пользователя.

1.7 Стадии и этапы разработки

1.7.1 Стадии разработки

Разработка должна быть проведена в 6 стадий:

1. Разработка технического задания

2. Разработка проектной документации

3.Создание эскизного проекта

4. Рабочее проектирование

5. Ввод в действие

6. Сопровождение и модернизация

1.7.2 Этапы разработки

На стадии разработки технического задания должен быть выполнен этап разработки, согласования и утверждения настоящего технического задания.

На стадии разработки проектной документации должен быть выполнен этап разработки проектной документации.

На стадии создания эскизного проекта должен быть выполнен эскизный проект для предварительного предоставления заказчику.

На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

1) разработка информационной системы;

2) разработка документации.

На стадии внедрения должны быть выполнены подготовка и передача программы заказчику.

На стадии сопровождения и модернизации должны выполняться работы по усовершенствованию текущей версии информационной системы.

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:

1) постановка задачи;

2) определение и уточнение требований к техническим средствам;

3) определение требований к информационной системе;

4) определение стадий, этапов и сроков разработки информационной системы и документации на неё;

5) обоснование и выбор инструментария;

6) согласование и утверждение технического задания.

На этапе разработки проектной документации должны быть выполнены перечисленные ниже работы:

1) определение основных бизнес-процессов (в виде диаграмм IDEF0);

2) определение основных вариантов использования Системы для трех категорий пользователей (Гость, Авторизованный пользователь, Администратор) в виде UML диаграмм вариантов использования;

3) проектирование структуры базы данных в виде (ER диаграммы);

4) проектирование основных компонентов и алгоритмов Системы в виде соответствующих UML диаграмм;

5) проектирование структуры пользовательского интерфейса;

6) согласование и утверждение проектной документации.

На этапе разработки должна быть выполнена работа по разработке информационной системы на основе проектной документации, кодированию и отладке.

На этапе разработки документации должна быть выполнена разработка программных документов в соответствии с требованиями. "Предварительный состав программной документации" настоящего технического задания.

На этапе подготовки и передачи программы должна быть выполнена работа по подготовке и передаче программы и программной документации в эксплуатацию.

На этапе усовершенствования текущей версии системы должны проводиться работы по созданию новых версий системы и добавлению новых функций в старую версию.

1. Анализ требований к ИС

2. Согласование требований с заказчиком

3. Выбор и разработка варианта концепции системы

4. Разработка технического задания и проекта

5. Согласование и утверждение технического задания и проекта

6. Составление плана по проведению работ

7. Подготовка аппаратного обеспечения

8. Разработка ПО

9. Проверка на совместимость аппаратного и программного обеспечения

10. Интеграция и тестирование программного и аппаратного обеспечения

11. Внесение изменений

12. Разработка инструкций по эксплуатации ИС

13. Оформление полной документации на ИС

14. Сдача ИС заказчику

Таблица 1 - Исходные данные для расчета

№ работы	Перечень работ	Продолжительность работы, дни
	1.Анализ требований к ИС
	2.Согласование требований с заказчиком
	3.Выбор и разработка варианта концепции системы
	4.Разработка технического задания и проекта
	5.Согласование и утверждение технического задания и проекта
	6.Составление плана по проведению работ
	7.Подготовка аппаратного обеспечения
	8.Разработка ПО
	9.Проверка на совместимость аппаратного и программного обеспечения
	10.Интеграция и тестирование программного и аппаратного обеспечения
	11.Внесение изменений
	12.Разработка инструкций по эксплуатации ИС
	13.Оформление полной документации на ИС
	14.Сдача ИС заказчику

Рисунок 1 - Постановка задач

Рисунок 2 - Диаграмма Ганта

Рисунок 3 - Сетевой график выполнения работ

Критический путь сетевого графика будет следующим: 0 1 2 3 4 5 6891011121314

Таблица 2 - Временные параметры событий

Номер события	Сроки совершения события	Резерв времени

Таблица 3 - Расчет полного и свободного резервов времени

	Продолжительность, дни	Временные параметры работ, дни	Полный резерв	Свободный резерв
		раннее начало	Раннее окончание	Позднее начало	Позднее окончание

1.8 Порядок контроля и приемки системы

1.8.1 Виды, состав, объем и методы испытаний системы и ее составных частей

Испытание системы производится путем введения большого количества данных, введения одинаковых сведений, сведений другого типа данных, данных большего диапазона. Производится проверка соответствия экранных форм описанию в руководстве для пользователя (тестирование интерфейса).

1.8.2 Общие требования к приемке работ по стадиям

Сдача-приемка осуществляется комиссией, в состав которой входят представители Заказчика и Исполнителя. По результатам приемки подписывается акт приемочной комиссии.

Все создаваемые в рамках настоящей работы программные изделия передаются Заказчику, как в виде готовых модулей, так и в виде исходных кодов, представляемых в электронной форме на стандартном машинном носителе (на компакт-диске).

1.8.3 Статус приемочной комиссии (государственная, межведомственная, ведомственная)

Статус приемочной комиссии определяется Заказчиком до проведения испытаний.

2. Технический проект

2.1 Функциональная структура

2.1.1 Описание предметной области

Предметной областью является агентство по продаже и бронированию авиабилетов

Предприятие имеет в своем составе административный отдел (состоит из бухгалтера и менеджера), отдел эксплуатации рабочих станций (управление информационными технологиями) (системный администратор и техники), операторы.

Административный отдел, состоящий из бухгалтера и менеджера, несет ответственность за качество услуг.

2.1.2 Функции и организационная структура

Построение структуры предприятия можно разбить на три шага: построение организационной модели, построение функциональной модели и построение информационной модели.

Агенство "Билет" состоит из следующих отделов:

Директор;

Административный отдел;

Отдел эксплуатации рабочих станций;

Отдел операторов.

Организационная структура предприятия отражена на рисунке 4.

Рисунок 4 - Организационная модель

Директор осуществляет общее руководство производственно-хозяйственной и финансово-экономической деятельностью предприятия, а так же организует взаимодействие всех его структурных подразделений.

Отдел производства осуществляет разработку проекта изделие, его последующее изготовление и сборку.

Административный отдел, состоящий из бухгалтера и менеджера, отвечает за качество предоставления услуг.

Отдел эксплуатации рабочих станций отвечает за работоспособность системы.

Операторы отвечают за принятие заказа, ввод данных в базу.

2.1.3 Описание потоков данных и бизнес процессов

Моделирование бизнес-процессов

Бизнес-процесс - это совокупность взаимосвязанных мероприятий или задач, направленных на создание определенного продукта или услуги для потребителей. Для наглядности бизнес-процессы визуализируют при помощи блок-схемы бизнес-процессов. Моделирование бизнес-процессов - деятельность по формированию моделей организаций, включающая описание деловых объектов (подразделений, должностей, ресурсов, ролей, процессов, операций, информационных систем, носителей информации и т. д.) и указание связей между ними. Требования к формируемым моделям и их соответствующее содержание определяются целями моделирования. Бизнес-моделированием также называют дисциплину и отдельный подпроцесс в процессе разработки программного обеспечения, в котором описывается деятельность компании и определяются требования к системе - те подпроцессы и операции, которые подлежат автоматизации в разрабатываемой информационной системе.

Проанализировав деятельность агенства, и проведя пред-проектное исследование, можно выделить три основных бизнес-процесса АИС "Билет":

1. Принятие заказа.

2. Выдача идентификационного номера.

3. Расчет с заказчиком.

Функциональное моделирование бизнес-процессов представлено методологией IDEF0. Она описывает те деловые процессы, которые протекают в объекте автоматизации. Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в IDEF0 представлена совокупностью иерархически упорядоченных и логически связанных диаграмм. Каждая диаграмма располагается на отдельном листе. Можно выделить четыре типа диаграмм:

Контекстную диаграмму А-0 (в каждой модели может быть только одна контекстная диаграмма);

Диаграммы декомпозиции (в том числе диаграмма первого уровня декомпозиции А 0, раскрывающая контекстную);

Диаграммы дерева узлов;

Диаграммы только для экспозиции (FEO).

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой (как правило, здесь описывается основное назначение моделируемого объекта). После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы (т.е., получения диаграммы А 0) проводится декомпозиция каждого блока диаграммы А 0 на более мелкие фрагменты и так далее, до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы - эксперты предметной области (обычно это интервьюируемые аналитиками сотрудники предприятий) указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели.

Главная бизнес-функция "АИС Билет" - продажа авиабилетов. Входными данными является заказ билетов. Выходными - квитанция. Инструментами выполнения главной бизнес-функции служат сотрудники ОАО "Билет" (бухгалтер, менеджер, IT-техники, операторы).

Диаграмма потоков данных

Требования представляются в виде иерархии процессов, связанных потоками данных. Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами. DFD-диаграммы успешно используются как дополнение к модели IDEF0 для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет моделируемую систему как сеть связанных работ. Основные компоненты DFD (как было сказано выше) - процессы или работы, внешние сущности, потоки данных, накопители данных (хранилища). В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой.

В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. Работы обычно именуются по названию системы, например "Система обработки информации". Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.

В DFD работы (процессы) представляют собой функции системы, преобразующие входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же, как процессы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0.

Внешние сущности изображают входы в систему и/или выходы из системы. Внешние сущности изображаются в виде прямоугольника с тенью и обычно располагаются по краям диаграммы. Одна внешняя сущность может быть использована многократно на одной или нескольких диаграммах. Обычно такой прием используют, чтобы не рисовать слишком длинных и запутанных стрелок.

Потоки работ изображаются стрелками и описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа "команда-ответ" между работами, между работой и внешней сущностью и между внешними сущностями.

В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое.

2.2 Системное проектирование ИС

техзадание калькуляция трудозатраты бронирование

2.2.1 Разработка концепции, архитектуры построения и платформы реализации ИС

Основными аспектами при выборе архитектуры построения ИС являются быстродействие, надежность, масштабируемость и безопасность.

В настоящее время наиболее распространенными архитектурами являются:

­ файл-сервер;

­ клиент-сервер;

­ многоуровневая архитектура.

Файл-серверная архитектура подразумевает под собой то, что сервер возлагает на себя лишь функцию хранения данных, а обработка производится на клиентских машинах. Это означает, что данные необходимо передавать по сети, что приведет к сильной загрузке сетевого трафика. А это в свою очередь приведет к снижению производительности при увеличении числа пользователей. Также при реализации архитектуры файл-сервер, проблема целостности, согласованности и одновременного доступа к данным решается децентрализовано: данные хранятся на сервере, а обрабатываются на клиенте. Вследствие этого снижается надежность приложения. Еще одним недостатком являются высокие затраты на модернизацию и сопровождение сервисов бизнес - логики на каждой клиентской рабочей станции. Однако данная архитектура обладает и рядом преимуществ, таких как низкая стоимость разработки, высокая скорость разработки и невысокая стоимость обновления и изменения программного обеспечения.

Архитектура клиент-сервер лишена недостатков вышеописанной архитектуры, т.к. сервер баз данных не только обеспечивает доступ к общим данным, но и выполняет их обработку. Клиент посылает на сервер запросы, на языке "понятном" серверу, а он в свою очередь обрабатывает запрос, контролируя при этом целостность и согласованность данных, и возвращает на клиент результат отработанного запроса. В результате нагрузка на сеть снижается: клиенту больше не нужно обрабатывать промежуточные данные. Хранение и обработка производится централизовано, поэтому данная архитектура надежнее архитектуры файл-сервер. К недостаткам клиент-серверной архитектуры относятся, во-первых, достаточная сложность разработки системы из-за необходимости исполнять бизнес-логику и обеспечивать интерфейс с пользователем в одной программе и высокие требования к рабочим станциям по той же причине.

Следующей ступенью развития архитектур ИС стала многоуровневая архитектура, в которой бизнес-логика выполняется на сервере приложений. Многоуровневая архитектура обладает следующими достоинствами:

­ масштабируемость;

­ конфигурируемость - изолированность уровней друг от друга позволяет быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней;

­ высокая безопасность;

­ высокая надёжность;

­ низкие требования к скорости канала (сети) между терминалами и сервером приложений;

­ низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости.

Однако, несмотря на неоспоримые достоинства, данная система не получила распространения, по следующим причинам:

­ сложность разработки систем на основе многоуровневой архитектуры, т.к очень сложно "состыковать" различные модули, особенно если они написаны разными группами. А изменение в одном модуле, как правило, вызывает лавинообразные изменения в остальных, и с этой точки зрения даже простую систему, основанную на многоуровневой архитектуре, будет сложнее выполнить в 2 раза;

­ высокие требования к производительности серверов приложений и сервера базы данных, а, значит, и высокая стоимость серверного оборудования;

­ высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений;

­ высокая сложность администрирования.

Рассмотрев все достоинства и недостатки каждой из архитектур, для реализации системы "АИС Билет" выбираем архитектуру клиент-сервер. Данная архитектура позволяет оптимально распределить работу между клиентскими и серверными частями системы: приложение, работающее на рабочей станции, не читает записи базы данных "напрямую", а посылает запросы на сервер, где они последовательно обрабатываются, а результаты обработки отсылаются на рабочую станцию. А это существенно сокращает информационные потоки в ЛВС.

Схема функционирования и построения информационной системы представлена рисунке 5.

Рисунок 5 - Архитектура "клиент-сервер"

2.2.2 Структура информационной системы, состав функциональных и обеспечивающих подсистем

Функциональные подсистемы - комплекс экономических задач с высокой степенью информационных обменов (связей) между задачами (некоторый процесс обработки информации с четко определенным множеством входной и выходной информации. Функциональные подсистемы информационно обслуживают определенные виды деятельности экономической системы (предприятия), характерные для его структурных подразделений и (или) функций управления. Интеграция функциональных подсистем в единую систему достигается за счет создания и функционирования обеспечивающих подсистем, таких как:

Информационная;

Техническая;

Программная;

Математическая;

Лингвистическая.

Обеспечивающие подсистемы являются общими для всей ИС независимо от конкретных функциональных подсистем, в которых применяются те или иные виды обеспечения. В работе обеспечивающие и организационные подсистемы объединены в одну обеспечивающую подсистему. Обоснованием такого решения можно считать, что их составляющие обеспечивают реализацию целей и функций системы.

Состав обеспечивающих подсистем не зависит от выбранной предметной области и имеет:

Функциональную структуру;

Информационное обеспечение;

Математическое (алгоритмическое и программное) обеспечение;

Техническое обеспечение;

Организационное обеспечение,

а на стадии разработки ИС дополнительные обеспечения:

Правовое;

Лингвистическое;

Технологическое;

Методологическое;

Интерфейсы с внешними ИС.

Информационное обеспечение - это совокупность средств и методов построения информационной базы. Оно определяет способы и формы отображения состояния объекта управления в виде данных внутри ИС, документов, графиков и сигналов вне ИС.

Математическое обеспечение состоит из алгоритмического и программного.

Организационное обеспечение - это совокупность средств и методов организации производства и управления ими в условиях внедрения ИС.

Целью организационного обеспечения является: выбор и постановка задач управления, анализ системы управления и путей ее совершенствования, разработка решений по организации взаимодействия ИС и персонала, внедрение задач управления. Организационное обеспечение включает в себя методики общения с клиентами, требования к оформлению документов, должностные инструкции и т. д.

Алгоритмическое обеспечение представляет собой совокупность математических методов, моделей и алгоритмов, используемых в системе для решения задач и обработки информации.

2.2.3 Техническое обеспечение ИС

В комплекс технических средств должны входить следующие элементы:

Рабочие станции;

Источники бесперебойного питания;

Средства для построения ЛВС;

Сервер БД;

Принтер.

Требования к серверу:

Память 8 Гб;

Процессор 2.2 ГГц Intel Xeon 5500 минимум;

Скорость диска SATA 8 Гбит/с;

Сетевой адаптер 10 Гбит/с;

Операционная система Windows Server 2008.

Требования к рабочей станции:

Процессор 2 Ггц;

Память 2 Гб;

Жесткий диск не менее 500;

Операционная система Windows 7;

Сетевой адаптер 100 Мбит/с.

Технические средства ИС описаны с учетом требований к функционированию прикладного пpогpаммного комплекса. Технические средства должны обеспечить:

Круглосуточный режим работы комплекса технических средств и оборудования;

Гарантированное выполнение всего комплекса программного обеспечения в случае сбоя или выхода из строя части оборудования;

Защиту данных от несанкционированного доступа;

Сервера и рабочие места должны быть объединены локальной сетью.

На рисунке 2.3 представлена топология локальной вычислительной сети (ЛВС) для ОАО "Билет".

На рассматриваемом рисунке видно, что через коммутатор к серверу БД и файловому серверу подключены 5 рабочих станций. Топология сети - звезда.

Рисунок 6 - Логическая схема сети ОАО "Заказчик"

2.3 Информационное обеспечение ИС

2.3.1 Описание логической структуры информационной базы

Логическое (даталогическое) проектирование - создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель - набор схем отношений, обычно с указанием первичных ключей, а также "связей" между отношениями, представляющих собой внешние ключи.

Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Этот этап может быть в значительной степени автоматизирован.

Нормальная форма - свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, потенциально приводящей к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение. Процесс преобразования отношений базы данных (БД) к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры БД к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма базы данных. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в базе данных информации. Общее назначение процесса нормализации заключается в следующем:

Исключение некоторых типов избыточности;

Устранение некоторых аномалий обновления;

Разработка проекта базы данных, который является достаточно "качественным" представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;

Упрощение процедуры применения необходимых ограничений целостности.

Устранение избыточности производится, как правило, за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов).

На логическом уровне выполняется нормализация базы данных, а также выделение ключей для каждой сущности. Логические связи реализованы посредством первичных и внешних ключей.

2.3.2 Описание физической реализации БД

Физическое проектирование - создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.д.

Физическая модель данных строится на базе логической модели и описывает данные уже средствами конкретной СУБД. Отношения, разработанные на стадии логического моделирования, преобразуются в таблицы, атрибуты в столбцы, домены в типы данных, принятых в выбранной конкретной СУБД.

Т.е. в физической модели между параметрами объекта и модели одинаковой физической природы существует однозначное соответствие. В этом случае элементом системы ставятся в соответствие физические эквиваленты, воспроизводящие структуру, основные свойства и соотношения изучаемого объекта. При физическом моделировании, основой которого является теория подобия, сохраняются особенности проведения эксперимента в натуре с соблюдением оптимального диапазона изменения соответствующих физических параметров.

Заключение

В результате выполнения курсовой работы было выполнено техническое задание на разработку информационной системы для агентства по продаже и бронированию авиабилетов, ее программного обеспечения.

Техническое задание на информационную систему является основным документом, определяющим требования и порядок создания информационной системы, в соответствии с которым проводится ее разработка и приемка при вводе в действие. Оно содержит основные требования к функциональным характеристикам, надежности, условиям эксплуатации и защите информации информационной системы, а также описывает порядок разработки системы.

В соответствии с поставленными задачами технического задания были выполнены следующие этапы создания технического проекта:

- выполнен анализ предметной области;

- разработана функциональная схема АИС "Билет";

- разработана концепция, выбраны архитектура построения и платформа реализации системы;

1. спроектирована концептуальная модель АИС "Билет";

2. спроектирована логическая модель системы АИС "Билет" на основе концептуальной модели;

3. определена физическая структура сервера баз данных.

Список литературы

1. ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению

2. ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

3. РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов

4. В.П. Романов, Н.З. Емельянова, Т.Л. Партыка Проектирование экономических информационных систем. Методологии и современные технологии. - М: Экзамен, 2005.- 256 с.;

5. Маклаков С.В. BPWin и ERWin CASE - средства разработки информационных систем / Маклаков С.В. - М: ДИАЛОГ МИФИ, 2001.-256с.;

6. Бойко В.В. Проектирование баз данных информационных систем / Бойко В.В., Савинков В.М. - 2-е изд. - М.: Финансы и статистика, 1989. - 350 с.

Размещено на Allbest.ru

...

Подобные документы

Техническое задание на разработку автоматизированной системы и складского учета управления универсальной торговой базы. Проектирование информационной системы и выбор среды для создания программного продукта. Создание интерфейса и руководство пользователя.

дипломная работа , добавлен 11.07.2015


Нормативно-правовые акты Российской Федерации в области информационной безопасности. Порядок организации работ по защите информации в информационных системах. Общий подход к разработкам технического задания на разработку системы защиты этой сферы.

курсовая работа , добавлен 05.05.2015


Создание технического задания на разработку информационной системы для заказа билета на самолет. Требования к документированию. Порядок контроля и приемки системы. Разработка концепции, архитектуры построения и платформы реализации информационной системы.

курсовая работа , добавлен 13.05.2015


Создание информационной системы "Голд", автоматизирующей работу Ювелирной мастерской. Моделирование бизнес-процессов с помощью диаграмм IDEF0 и UML и потоков данных DFD и sicuence. Составление технического проекта и задания на основании ГОСТ 34.602-89.

курсовая работа , добавлен 10.02.2013


Cостав экспертной системы. Требования к комплексу технических средств. Структура и организация технического обеспечения автоматической информационной системы. Техническая документация на разработку программных средств и способы их использования.

реферат , добавлен 09.10.2014


Изучение языков программирования PHP, SQL, C++, HTML. Рассмотрение правил запуска и использования локального сервера Denwer. Составление технического задания по разработке программного продукта. Описание создаваемого мобильного и веб-приложения.

курсовая работа , добавлен 07.04.2015


Разработка автоматизированной информационной системы для учета и контроля выполнения ремонтных работ, и предоставления услуг по разработке программного обеспечения компании "МегионСофтОйл", разработка алгоритмов приложений программной системы и модулей.

дипломная работа , добавлен 29.06.2012


Обоснование необходимости разработки информационной системы. Анализ предметной области. Техническое задание на создание ЭИС. Правовой статус и краткая экономическая характеристика предприятия. Состояние учетно-аналитической работы на предприятии.

реферат , добавлен 09.01.2009


Разработка и внедрение автоматизированной информационной системы (АИС) работы с клиентами туристической фирмы (приема и обработки заявок). Технико-экономическая оценка туристического агентства, алгоритм и схема интерфейса программного обеспечения его АИС.

дипломная работа , добавлен 21.07.2011


Подсчет количества функциональных точек. Расчет трудозатрат на разработку программного средства и ориентировочного времени его разработки, модель жизненного цикла. Разработка технического задания на создание автоматизированной системы, требования к ней.

Общие положения

является основным, определяющим и порядок создания (или - далее создания) , в соответствии с которым проводится АС и ее при [из п. 1.1 ГОСТ 34.602-89]

разрабатывают на в целом, предназначенную для работы самостоятельно или в составе другой системы.

Дополнительно могут быть разработаны ТЗ на части АС: на АС, комплексы задач АС и т.п. в соответствии с требованиями настоящего; на средства и в соответствии со стандартами ЕСКД и СРПП; на в соответствии со стандартами ЕСПД; на в соответствии с ГОСТ 19.201 и НТД, действующей в ведомстве.

Примечание - В ТЗ на АСУ для группы взаимосвязанных объектов следует включать только общие для группы объектов требования. Специфические требования отдельного объекта следует отражать в ТЗ на АСУ этого объекта [из п. 1.2 ГОСТ 34.602-89]

Требования к АС в объеме, установленном настоящим стандартом, могут быть включены в вновь создаваемого. В этом случае ТЗ на АС не разрабатывают [из п. 1.3 ГОСТ 34.602-89]

Включаемые в ТЗ на АС требования должны соответствовать современному и не уступать аналогичным требованиям, предъявляемым к лучшим современным отечественным и зарубежным. Задаваемые в ТЗ на АС требования не должны ограничивать системы в поиске и реализации наиболее технических, технико-экономических и других решений [из п. 1.4 ГОСТ 34.602-89]

ТЗ на АС разрабатывают на основании исходных данных, в том числе содержащихся в итоговой документации «», установленной [из п. 1.5 ГОСТ 34.602-89]

В ТЗ на АС включают только те требования, которые дополняют требования к данного вида (АСУ, САПР, АСНИ и т.д.), содержащиеся в действующих, и определяются спецификой конкретного объекта, для которого создается система [из п. 1.6 ГОСТ 34.602-89]

к ТЗ на АС оформляют дополнением или и. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись «Действует с... » [из п. 1.7 ГОСТ 34.602-89]

Состав и содержание

Назначение системы

В подразделе «Назначение системы» указывают вид (, и т.п.) и перечень объектов автоматизации (), на которых предполагается использовать.

Для АСУ дополнительно указывают перечень и [из п. 2.4.1 ГОСТ 34.602-89]

Цели создания системы

В подразделе «Цели создания системы» приводят и требуемые технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы [из п. 2.4.2 ГОСТ 34.602-89]

Характеристики объекта автоматизации

В разделе «Характеристики объекта автоматизации» приводят:

1. краткие сведения об объекте автоматизации;
2. сведения об объекта автоматизации и характеристиках окружающей среды.

Примечание - Для САПР в разделе дополнительно приводят основные параметры и характеристики объектов проектирования [из п. 2.5 ГОСТ 34.602-89]

Требования к системе

Раздел «Требования к системе» состоит из следующих подразделов:

1. требования к системе в целом;
2. требования к функциям (задачам), выполняемым системой;
3. требования к видам обеспечения.

Состав требований к системе, включаемых в данный раздел ТЗ на АС, устанавливают в зависимости от вида, назначения, специфических особенностей и условий конкретной системы. В каждом подразделе приводят ссылки на действующие НТД, определяющие требования к системам соответствующего вида [из п. 2.6 ГОСТ 34.602-89]

Требования к системе в целом

В подразделе «Требования к системе в целом» указывают:

• требования к структуре и функционированию системы;
• требования к численности и квалификации персонала системы и режиму его работы;
• показатели назначения;
• требования к надежности;
• требования безопасности;
• требования к эргономике и технической эстетике;
• требования к транспортабельности для подвижных АС;
• требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;
• требования к защите информации от несанкционированного доступа;
• требования по сохранности информации при авариях;
• требования к защите от влияния внешних воздействий;
• требования к патентной чистоте;
• требования по стандартизации и унификации;
• дополнительные требования.

[из п. 2.6.1 ГОСТ 34.602-89]

Требования к структуре и функционированию системы

В требованиях к структуре и функционированию системы приводят:

1. перечень, их назначение и основные характеристики, требования к числу уровней и степени централизации системы;
2. требования к способам и средствам связи для информационного обмена между;
3. требования к характеристикам взаимосвязей системы со смежными системами, требования к ее, в том числе указания о способах (автоматически, пересылкой документов, по телефону и т. п.);
4. требования к режимам функционирования системы;
5. требования по системы;
6. перспективы, системы.

Требования к математическому обеспечению

Для системы приводят требования к составу, области применения (ограничения) и способам, использования в системе математических методов и моделей, типовых и алгоритмов, подлежащих разработке [из п. 2.6.3.1 ГОСТ 34.602-89]

Требования к информационному обеспечению

Для системы приводят требования:

1. требования к составу, структуре и способам организации в системе;
2. требования к к информационному обмену между;
3. требования к информационной со смежными системами;
4. требования по использованию общероссийских и зарегистрированных республиканских, отраслевых, унифицированных документов и классификаторов, действующих на;
5. требования по применению;
6. требования к структуре процесса сбора, передачи данных в системе и;
7. требования к защите данных от разрушений при и в электропитании системы;
8. требования к контролю, обновлению и;
9. требования к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4).

Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

В разделе «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» необходимо привести перечень основных мероприятий и их исполнителей, которые следует выполнить при. В перечень основных мероприятий включают:

1. приведение поступающей в систему информации к виду, пригодному для с помощью (в соответствии с требованиями к и);
2. изменения, которые необходимо осуществить в объекте автоматизации;
3. создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в;
4. создание необходимых для функционирования системы подразделений и служб;
5. сроки и порядок комплектования штатов и обучения.

Например для АСУ приводят:

• изменения применяемых методов;
• создание условий для работы АСУ, при которых гарантируется соответствие системы требованиям, содержащимся в ТЗ.

Copyright © ООО «Техническая документация» 2017. Заимствуйте наши материалы с блеском!
При цитировании на своих ресурсах наших материалов используйте активные ссылки на них.