ООО «Техническая документация»

разработка техдокументации

Требования к программному обеспечению АСУ по ГОСТ 24.104-85

Требования к программному обеспечению АСУ по ГОСТ 24.104-85

Программное обеспечение АСУ должно быть достаточным для выполнения всех функций АСУ, реализуемых с применением средств вычислительной техники, а также иметь средства организации всех требуемых процессов обработки данных, позволяющие своевременно выполнять все автоматизированные функции во всех регламентированных режимах функционирования АСУ [из п. 1.5.1 ГОСТ 24.104-85]

Программное обеспечение АСУ должно обладать следующими свойствами:

[из п. 1.5.2 ГОСТ 24.104-85]

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

В АСУ должны быть преимущественно использованы системы управления базами данных (СУБД), зарегистрированные в установленном порядке [из п. 1.5.4 ГОСТ 24.104-85]

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

Программное обеспечение АСУ должно иметь средства диагностики технических средств АСУ и контроля на достоверность входной информации [из п. 1.5.6 ГОСТ 24.104-85]

В программном обеспечении АСУ должны быть реализованы меры по защите от ошибок при вводе и обработке информации, обеспечивающие заданное качество выполнения функций АСУ [из п. 1.5.7 ГОСТ 24.104-85]

Общее программное обеспечение АСУ должно позволять осуществлять настройку компонентов специального программного обеспечения и дальнейшее развитие программного обеспечения АСУ без прерывания процесса ее функционирования. Должна быть обеспечена защита уже сгенерированной и загруженной части программного обеспечения от случайных изменений [из п. 1.5.8 ГОСТ 24.104-85]

Все программы специального программного обеспечения конкретной АСУ должны быть совместимы как между собой, так и с ее общим программным обеспечением [из п. 1.5.9 ГОСТ 24.104-85]

Эксплуатационная программная документация на АСУ должна соответствовать стандартам ЕСПД и содержать все сведения, необходимые персоналу АСУ для использования программного обеспечения АСУ, для его первоначальной загрузки и (или) генерации, загрузки информации внутримашинной информационной базы, запуска программ АСУ, проверки их функционирования с помощью соответствующих тестов [из п. 1.5.10 ГОСТ 24.104-85]

Вновь разрабатываемые при создании конкретной АСУ программные изделия, включенные в состав ее программного обеспечения, должны быть зарегистрированы в государственном, отраслевом или других фондах алгоритмов и программ (по принадлежности) [из п. 1.5.11 ГОСТ 24.104-85]

Программное обеспечение

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

Единая система программной документации. Общие положения

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

Единая система программной документации. Виды программ и программных документов

Единая система программной документации. Стадии разработки

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

Единая система программной документации. Основные надписи

Единая система программной документации. Общие требования к программным документам

Единая система программной документации. Требования к программным документам, выполненным печатным способом

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

Единая система программной документации. Спецификация. Требования к содержанию и оформлению

Единая система программной документации. Программа и методика испытаний. Требования к содержанию и оформлению

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

Единая система программной документации. Описание программы

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

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

Единая система программной документации. Формуляр. Требования к содержанию и оформлению

Единая система программной документации. Описание применения. Требования к содержанию и оформлению

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

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

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

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

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

Единая система программной документации. Руководство по техническому обслуживанию. Требования к содержанию и оформлению

Единая система программной документации. Общие правила дублирования, учета и хранения

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

Единая система программной документации. Общие правила внесения изменений

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

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

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

Качество программных средств. Термины и определения

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

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

Защита информации. Испытания программных средств на наличие компьютерных вирусов. Типовое руководство

Средства программные систем вооружения. Порядок разработки

ГОСТ Р 51904-2002

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

ГОСТ Р 52657-2006

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

ГОСТ Р ИСО 9127-94

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

ГОСТ Р ИСО/МЭК 10746-1-2004

Информационная технология. Открытая распределенная обработка. Базовая модель. Часть 1. Основные положения

ГОСТ Р ИСО/МЭК 10746-4-2004

Информационная технология. Открытая распределенная обработка. Базовая модель. Часть 4. Архитектурная семантика

ГОСТ Р ИСО/МЭК 12119-2000

Информационная технология. Пакеты программ. Требования к качеству и тестирование

ГОСТ Р ИСО/МЭК 12207-99

Информационная технология. Процессы жизненного цикла программных средств

ГОСТ Р ИСО/МЭК 14764-2002

Информационная технология. Сопровождение программных средств

ГОСТ Р ИСО/МЭК 15026-2002

Информационная технология. Уровни целостности систем и программных средств

ГОСТ Р ИСО/МЭК 15288-2005

Информационная технология. Системная инженерия. Процессы жизненного цикла систем

ГОСТ Р ИСО/МЭК 15910-2002

Информационная технология. Процесс создания документации пользователя программного средства

ГОСТ Р ИСО/МЭК 8631-94

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

ГОСТ Р ИСО/МЭК 9126-93

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

ГОСТ Р ИСО/МЭК ТО 12182-2002

Информационная технология. Классификация программных средств

ГОСТ Р ИСО/МЭК ТО 15271-2002

Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)

ГОСТ Р ИСО/МЭК ТО 16326-2002

Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом

ГОСТ Р ИСО/МЭК ТО 9294-93

Информационная технология. Руководство по управлению документированием программного обеспечения

Последние документы

ГОСТ Р 52488-2005

Средства для стирки. Общие технические условия

ГОСТ Р 51697-2000

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

ГОСТ Р 51696-2000

Товары бытовой химии. Общие технические требования

Товары бытовой химии. Методы определения фосфорсодержащих соединений

Товары бытовой химии. Методы определения анионного поверхностно-активного вещества

Товары бытовой химии. Метод определения смываемости с посуды

Товары бытовой химии. Метод определения нерастворимого в воде остатка (абразива)

Пример шаблона технического задания (ТЗ) на сайт

ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА РАЗРАБОТКУ ИНТЕРНЕТ-САЙТА

Термин

Описание

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

World wide web (WWW, web, веб)

Единое информационное пространство на базе сети Internet, состоящее из совокупности сайтов. Приставка «веб-» может использоваться для обозначения объектов, ориентированных на использование в WWW или использующих типичные для WWW технологии (например, веб-интерфейс — интерфейс на базе веб-страниц)

HTML-страница (веб-страница, страница)

Основной носитель информации в World ide Web. Особым образом сформатированный файл (набор файлов), просматриваемый с помощью www-браузера как единое целое (без перехода по гиперссылкам)

Управляющие коды, посредством которых осуществляется форматирование HTML-страницы

Гиперссылка (ссылка, линк)

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

Клиентская программа, поставляемая третьими сторонами и позволяющая просматривать содержимое HTML-страниц

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

Поле (поле БД, поле формы)

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

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

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

Администратор (менеджер, редактор) сайта

Лицо, осуществляющее от имени Заказчика информационную поддержку сайта

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

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

Информация о деятельности Заказчика. Может включать графические, текстовые, аудио или видео материалы. Предоставляется Заказчиком

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

Элемент наполнения (контента)

Отдельная запись в базе данных, внешнее представление которой зависит от управляющего ей программного модуля (например, в модуле «новостная лента» элементом наполнения является отдельная новость)

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

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

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

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

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

Редактор языка HTML, имеющий возможности по работе в текстовом режиме и в режиме WYSIWYG (What You See Is What You Get). В режиме WYSIWYG элементы HTML страницы при редактировании представляются в том же виде, что и при просмотре

Класс пользователей системы, обладающих определенным набором прав доступа

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

Общие положения

Предмет разработки

Предметом разработки является Интернет-сайт компании ООО «…», с системой динамического управления наполнением на базе веб-интерфейса.
Назначение сайта:
— предоставление информации о компании ООО «…»;
— предоставление информации о деятельности компании ООО «…»;
— т.д.;
— пр.

Цель создания сайта: . .

Назначение документа

В настоящем документе приводится полный набор требований к реализации сайта компании ООО «».
Подпись Заказчика и Исполнителя на настоящем документе подтверждает их согласие с нижеследующими фактами и условиями:
1. Исполнитель подготовил и разработал настоящий документ, именуемый Техническое Задание, который содержит перечень требований к выполняемым работам.
2. Заказчик согласен со всеми положениями настоящего Технического Задания.
3. Заказчик не вправе требовать от Исполнителя в рамках текущего Договора выполнения работ либо оказания услуг, прямо не описанных в настоящем Техническом Задании.
4. Исполнитель обязуется выполнить работы в объёме, указанном в настоящем Техническом Задании.
5. Заказчик не вправе требовать от Исполнителя соблюдения каких-либо форматов и стандартов, если это не указано в настоящем Техническом Задании.
6. Все неоднозначности, выявленные в настоящем Техническом задании после его подписания, подлежат двухстороннему согласованию между Сторонами. В процессе согласования могут быть разработаны дополнительные требования, которые оформляются дополнительным соглашением к Договору и соответствующим образом оцениваются.

Читайте так же:  Киви требования к качеству

Требования к графическому дизайну сайта

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

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

В дизайне сайта не должны присутствовать:
— мелькающие баннеры;
— много сливающегося текста;
— т.д.;
— пр.

Порядок утверждения дизайн-концепции

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

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

Требования к представлению сайта

Требования к представлению главной страницы сайта Главная страница сайта должна содержать графическую часть, навигационное меню сайта, а также контентную область для того, чтобы посетитель сайта с первой страницы мог получить вводную информацию о компании, а также ознакомиться с последними новостями компании.
Контентная область первой страницы должна делиться на следующие разделы:
— вступительная статья о компании со ссылкой «подробнее», ведущей на раздел «О компании»;
— новости — содержит 3 последние новости (анонсы) в формате: дата, заголовок, краткое содержание;
— краткая контактная информация — телефон и e-mail компании;
— вверху страницы отображаются облегченная навигационная панель, которая обеспечивает переход к основным пунктам меню сайта (О компании, Новости и т.д.);
— поле поиска – предназначено для выполнения полнотекстового поиска по сайту;
— поле выбора языка – русский\английский;
— счетчики и ссылка на страницу обмена ссылками.

Рис. 1. Пример размещения элементов главной страницы.

Графическая оболочка внутренних страниц (общая для всех подразделов)
Графическая оболочка внутренних страниц должна делиться на следующие разделы:
— графическая шапка
— навигационное меню сайта (навигационная панель 2 обеспечивает переход к основным пунктам меню сайта);
— поле поиска – предназначено для выполнения полнотекстового поиска по сайту;
— поле выбора языка – русский\английский;
— ссылка «На главную»;
— навигационная панель по подразделам выбранного раздела сайта;
— поле для отображения контента выбранной страницы сайта;
— внизу страницы — краткая контактная информация — телефон и e-mail компании;
— кнопка «Для печати» — обеспечивает вывод контентной области в виде, отверстанном для печати на листах формата А4;
— кнопка «Задать вопрос» — обеспечивает переход к форме «Задать вопрос».

Рис. 2. Пример размещения элементов внутренних страниц сайта.

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

a. История компании
b. Дипломы и сертификаты
c. Наши партнеры
d. Наши клиенты
e. Наши координаты
f. .

2. Новости
3. т.д.
4. пр.

Требования к системе управления сайтом

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

— О компании
— Новости
— т.д.;


Рис. 3. Макет формы главной страницы административной части сайта.

Требования к управлению разделами сайта
Для управления разделами сайта должны быть предусмотрены следующие функции:
— создание подраздела 1 уровня;
— создание подраздела 2 (и далее) уровня;
— редактирование контента страницы;
— удаление раздела;
— перемещение раздела вверх в списке;
— перемещение раздела вниз в списке;
— признак показа (show) или не показа (hide) страницы в клиентской части сайта;
— отображение списка подразделов выбранного уровня.

Управление наполнением сайта
Для управления наполнением сайта должны быть предусмотрены следующие блоки:
1. поле элемента контента, может быть одного из следующих типов:
— строка;
— дата;
— ссылка на файл;
— многострочный текст;
2. элемент контента – состоит из набора полей элемента контента;
3. список элементов контента – состоит из набора элементов контента.


Рис. 4. Поля элемента контента.

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


Рис. 5. Редактор многострочного текста в административной части.

Для каждого элемента контента должен определяться требуемый набор полей. Например, для элемента «Новость» определяется следующий набор полей контента:


Рис. 6. Пример представления элемента контента «Новость» в административной части.

Список элементов контента должен позволять:
• перейти к редактированию полей элемента списка;
• удалить элемент списка;
• определить порядок элементов списка вывода в клиентской части;
• указать признак hide\show.


Рис. 7. Пример представления списка элементов контента в административной части и их отображения в клиентской части.

В списке элементов должны выводиться все поля элемента, кроме полей вида «Многострочный текст».

Управление настройками сайта
В состав настроек сайта должны входить:
— e-mail для …;
— т.д.;
— пр.

Дополнительные функции административной части
В состав дополнительных функций административной части должны входить:
— …;

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

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

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

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

Требования к хранению данных
Все данные сайта должны храниться в структурированном виде под управлением реляционной СУБД. Исключения составляют файлы данных, предназначенные для просмотра и скачивания (изображения, видео, документы и т.п.). Такие файлы сохраняются в файловой системе, а в БД размещаются ссылки на них.
Наполнение различных сайтов, функционирование которых поддерживается одной и той же инсталляцией системы, должно храниться под управлением единой СУБД.
Требования к языкам программирования
Для реализации статических страниц и шаблонов должны использоваться языки HTML 4.0 и CSS. Исходный код должен разрабатываться в соответствии со стандартами W3C (HTML 4.0).
Для реализации интерактивных элементов клиентской части должны использоваться языки JavaScript и DHTML.
Для реализации динамических страниц должен использоваться язык PHP.
Требования к организации гиперссылок
Все ссылки на сайте должны быть относительными (за исключением внешних).

Требования к иллюстрациям
Все рисунки и фото объемом более 1 kb (кроме элементов дизайна страницы) должны быть выполнены с замещающим текстом. Все рисунки должны быть в формате gif или jpg.
Требования к объему одной страницы
Объем одной стандартной загружаемой страницы сайта в среднем не должен превышать 170 kb.
Объем flash-заставки не должен превышать 300 Kb.

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

Требования к программному обеспечению серверной части
Для функционирования сайта необходимо следующее программное обеспечение:
— Операционная система – Windows XP и Windows Server 2003;
— Веб-сервер – Apache версии не ниже 1.3.26;
— СУБД – MySQL версии не ниже 3.23;
Требования к клиентскому программному обеспечению
Сайт должен быть доступен для полнофункционального просмотра с помощью следующих браузеров:
• MS IE 5.0 и выше;
• Opera 6.0 и выше;
• Mozilla Firefox 1.0;
• Mozilla 1.7.
Сайт должен быть работоспособен (информация, расположенная на нем, должна быть доступна) при отключении в браузере поддержки flash и JavaScript.

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

Для функционирования сайта необходимо следующее техническое обеспечение со следующими минимальными характеристиками:
— процессор – Intel Pentium III 1 Ghz;
— оперативная память – 512 Mb RAM;
— жесткий диск — 20 Gb HDD.
— т.д.;
— пр.

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

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

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

Сайт должен быть оптимизирован для просмотра при разрешении 1024*768, 1280*1024 без горизонтальной полосы прокрутки и без пустых (белых) полей для основных типов разрешения.
Элементы управления должны быть сгруппированы однотипно – горизонтально либо вертикально – на всех страницах.
На каждой странице должны отображаться логотип компании и контактная информация.
Интерфейс подключаемых модулей должен быть выполнен в едином стиле с интерфейсом ядра системы и должен обеспечивать возможность прозрачного перемещения администратора между модулями системы и использование одинаковых процедур управления и навигационных элементов для выполнения однотипных операций.

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

Требования к наполнению информацией

Общие требования к информационному наполнению
В рамках работ по данному проекту Исполнитель обеспечивает наполнение разделов сайта предоставленными Заказчиком материалами в порядке, указанном в п. 6.1.2.
Исполнитель обеспечивает обработку иллюстраций для приведения их в соответствие с техническими требованиями и HTML-верстку подготовленных материалов. Сканирование, набор и правка-вычитка текстов, ретушь, монтаж, перевод и другие работы могут быть выполнены Исполнителем на основании дополнительного соглашения (после просмотра имеющихся у заказчика материалов).
После сдачи системы в эксплуатацию информационное наполнение разделов, осуществляется на основании договора на поддержку сайта.
Объем текста и количество иллюстраций в других типах разделов определяется предусмотренной настоящим ТЗ структурой данных и уточняется на этапе согласования дизайн-концепции.
Порядок предоставления информационного наполнения
Заказчик предоставляет материалы в электронной форме в zip-архиве, содержащем дерево директорий, соответствующих структуре сайта.
В каждой директории размещается набор документов в формате MS Word – по одному документу на каждый информационный модуль, информационные блоки которого опубликованы в соответствующем разделе. Не допускается размещение текста в виде графических изображений или иных нетекстовых элементов.
Изображения могут быть размещены как в тексте внутри файла, так и в виде отдельного изображения. Однако, в последнем случае текст должен содержать ссылку на изображение в виде указания пути и названия файла изображения.
Для каждого информационного модуля структура документа должна соответствовать шаблонам, предоставляемым Исполнителем до начала этапа предоставления материалов.
Материалы для первоначального наполнения разделов должны быть полностью представлены Исполнителю в сроки, установленные планом-графиком работ. Допускается передача материалов частями, в нескольких zip-файлах, соответствующих приведенным требованиям.
Передача материалов в объеме и формате, соответствующем настоящему ТЗ закрепляется подписанием Акта о передаче информационного наполнения.
Любые изменения информационного наполнения силами Исполнителя после подписания данного Акта допускаются только на основании отдельного соглашения за дополнительную плату.
Информационные материалы, не предоставленные Заказчиком в сроки, установленные планом-графиком работ, размещаются Исполнителем по гарантийному письму Исполнителя в течение 2-х недель после сдачи-приемки проекта. На эту часть информационных материалов также накладываются требования к формату предоставления, изложенные выше.

Требования к персоналу

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

Порядок предоставления дистрибутива

По окончании разработки Исполнитель должен предоставить Заказчику дистрибутив системы в составе:
-архив с исходными кодами всех программных модулей и разделов сайта;
— дамп проектной базы данных с актуальной информацией.
Дистрибутив предоставляется на CD-диске в виде файлового архива.

Читайте так же:  Договор с мфц москва

Порядок переноса сайта на технические средства заказчика

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

Корпоративные хранилища данных. Интеграция систем. Проектная документация.

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы (пример)

В данной статье приведен пример (образец) проектного документа «Техническое задание на создание автоматизированной системы (АС)» согласно ГОСТ 34.602-89. В качестве примера АС для заполнения разделов использовались требования на разработку информационно-аналитической системы «Корпоративное хранилище данных».

Разделы технического задания:

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

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

1.1. Наименование системы

1.1.1. Полное наименование системы

Например:
Полное наименование: Корпоративное хранилище данных.

1.1.2. Краткое наименование системы

Например:
Краткое наименование: КХД, Система.

1.2. Основания для проведения работ

Перечень документов, на основании которых создается система, кем и когда утверждены документы. Указывается шифр темы или шифр (номер) договора, дата договора.

Например:
Работа выполняется на основании договора № … от … между …

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

Заказчик: ОАО Заказчик
Адрес фактический: г. Москва .
Телефон / Факс: +7 (495) 2222222

1.3.2. Разработчик

Разработчик: ЗАО Разработчик
Адрес фактический: г. Москва .
Телефон / Факс: +7 (495) 3333333

1.4. Плановые сроки начала и окончания работы

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

1.5. Источники и порядок финансирования

Если не целесообразно указывать эти сведения, то дается ссылка на Договор.

1.6. Порядок оформления и предъявления заказчику результатов работ

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

Например:
Работы по созданию КХД сдаются Разработчиком поэтапно в соответствии с календарным планом Проекта. По окончании каждого из этапов работ Разработчик сдает Заказчику соответствующие отчетные документы этапа, состав которых определены Договором.

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

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

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

КХД предназначена для повышения оперативности и качества принимаемых управленческих решений сотрудниками Заказчика.
Основным назначением КХД является автоматизация информационно-аналитической деятельности в бизнес-процессах Заказчика.
В рамках проекта автоматизируется информационно-аналитическая деятельность в следующих бизнес-процессах:
1. анализ финансово-хозяйственной деятельности;
2. информационная поддержка процессов бюджетирования;
3. .

2.2. Цели создания системы

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

КХД создается с целью:
— обеспечения сбора и первичной обработки исходной информации, необходимой для подготовки отчетности по показателям деятельности;
— создания единой системы отчетности по показателям деятельности;
— повышения качества (полноты, точности, достоверности, своевременности, согласованности) информации;
— .

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

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

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

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

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

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

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

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

Система КХД должна быть централизованной, т.е. все данные должны располагаться в центральном хранилище. Система КХД должна иметь трехуровневую архитектуру (можно привести общую схему, на которой определить уровни. Например, первый — источник, второй — хранилище, третий — отчетность).
В Системе предлагается выделить следующие функциональные подсистемы:
подсистема сбора, обработки и загрузки данных, которая предназначена для реализации процессов сбора данных из систем источников, приведения указанных данных к виду, необходимому для наполнения подсистемы хранения данных;
подсистема хранения данных, которая предназначена для хранения данных в структурах, нацеленных на принятие решений;
подсистема формирования и визуализации отчетности, которая предназначена для формирования бизнес-ориентированных витрин данных и отчетности.

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

В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP.
Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня, такие как: NFS, HTTP и его расширение HTTPS, NetBios/SMB, Oracle TNS.
Для организации доступа пользователей к отчетности должен использоваться протокол презентационного уровня HTTP и его расширение HTTPS.

Приводятся требования к характеристикам взаимосвязей со смежными системами.

Смежными системами для КХД являются:
— информационные системы оперативной обработки данных Заказчика;
— информационные системы планирования;
— .
Источниками данных для Системы должны быть:
— Информационная система управления предприятием (СУБД MS SQL).
— Информационно-справочная система (СУБД MS SQL).
— Информационная система обеспечения бюджетного процесса (СУБД Oracle).
— .
Перечень предпочтительных способов взаимодействия со смежными системами приведен ниже.
— Информационная система управления предприятием — с использованием промежуточной базы данных (ПБД).
— Информационно-справочная система — обмен файлами ОС определенного формата.
— Информационная система обеспечения бюджетного процесса — интеграция «точка – точка».
— .

Определяются требования к режимам функционирования системы.

Например:
Система должна поддерживать следующие режимы функционирования:
— Основной режим, в котором подсистемы КХД выполняют все свои основные функции.
— Профилактический режим, в котором одна или все подсистемы КХД не выполняют своих функций.
В основном режиме функционирования Система КХД должна обеспечивать:
— работу пользователей в режиме – 24 часов в день, 7 дней в неделю (24х7);
— выполнение своих функций – сбор, обработка и загрузка данных; хранение данных, предоставление отчетности.
В профилактическом режиме Система КХД должна обеспечивать возможность проведения следующих работ:
— техническое обслуживание;
— модернизацию аппаратно-программного комплекса;
— устранение аварийных ситуаций.
Общее время проведения профилактических работ не должно превышать X% от общего времени работы системы в основном режиме (Y часов в месяц).

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

Для обеспечения высокой надежности функционирования Системы как системы в целом, так и её отдельных компонентов должно обеспечиваться выполнение требований по диагностированию ее состояния.
Диагностирование Системы должно осуществляться следующими штатными средствами, входящими в комплект поставки программного обеспечения:
— СУБД — ;
— ETL-средство — ..
— средство визуализации — .
Обязательно ведение журналов инцидентов в электронной форме, а также графиков и журналов проведения ППР.
Для всех технических компонентов необходимо обеспечить регулярный и постоянный контроль состояния и техническое обслуживание.

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

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

В состав персонала, необходимого для обеспечения эксплуатации КХД в рамках соответствующих подразделений Заказчика, необходимо выделение следующих ответственных лиц:
— Руководитель эксплуатирующего подразделения — 1 человек.
— Администратор подсистемы сбора, обработки и загрузки данных — 2 человека.
— Администратор подсистемы хранения данных — 2 человека.
— Администратор подсистемы формирования и визуализации отчетности — 1 человек.

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

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

К квалификации персонала, эксплуатирующего Систему КХД, предъявляются следующие требования.
— Конечный пользователь — знание соответствующей предметной области; знание основ многомерного анализа; знания и навыки работы с аналитическими приложениями..
— Администратор подсистемы сбора, обработки и загрузки данных — знание методологии проектирования хранилищ данных; знание методологии проектирования ETL процедур; знание интерфейсов интеграции ХД с источниками данных; знание СУБД; знание языка запросов SQL.
— Администратор подсистемы хранения данных — глубокие знания СУБД; знание архитектуры «Звезда» и «Снежинка»; опыт администрирования СУБД; знание и навыки операций архивирования и восстановления данных; знание и навыки оптимизации работы СУБД.
— Администратор подсистемы формирования и визуализации отчетности — понимание принципов многомерного анализа; знание методологии проектирования хранилищ данных; знание и навыки администрирования приложения; знание языка запросов SQL; знание инструментов разработки.

4.1.2.3. Требования к режимам работы персонала

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

4.1.3. Показатели назначения

4.1.3.1. Параметры, характеризующие степень соответствия системы назначению

Система должна обеспечивать следующие количественные показатели, которые характеризуют степень соответствия ее назначению:
— Количество измерений – X.
— Количество показателей – Y.
— Количество аналитических отчетов – Z.

4.1.3.2. Требования к приспособляемости системы к изменениям

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

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

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

4.1.4.1. Состав показателей надежности для системы в целом

Например:
Уровень надежности должен достигаться согласованным применением организационных, организационно-технических мероприятий и программно-аппаратных средств.
Надежность должна обеспечиваться за счет:
— применения технических средств, системного и базового программного обеспечения, соответствующих классу решаемых задач;
— своевременного выполнения процессов администрирования Системы КХД;
— соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;
— предварительного обучения пользователей и обслуживающего персонала.
Время устранения отказа должно быть следующим:
— при перерыве и выходе за установленные пределы параметров электропитания — не более X минут.
— при перерыве и выходе за установленные пределы параметров программного обеспечением — не более Y часов.
— при выходе из строя АПК ХД — не более Z часов.
Система должна соответствовать следующим параметрам:
— среднее время восстановления Q часов — определяется как сумма всех времен восстановления за заданный календарный период, поделенные на продолжительность этого периода;
— коэффициент готовности W — определяется как результат отношения средней наработки на отказ к сумме средней наработки на отказ и среднего времени восстановления;
— время наработки на отказ E часов — определяется как результат отношения суммарной наработки Системы к среднему числу отказов за время наработки.
Средняя наработка на отказ АПК не должна быть меньше G часов.

Читайте так же:  Сколько стоит госпошлина для подачи заявления в загс 2018

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

Например:
Под аварийной ситуацией понимается аварийное завершение процесса, выполняемого той или иной подсистемой КХД, а также «зависание» этого процесса.
При работе системы возможны следующие аварийные ситуации, которые влияют на надежность работы системы:
— сбой в электроснабжении сервера;
— сбой в электроснабжении рабочей станции пользователей системы;
— сбой в электроснабжении обеспечения локальной сети (поломка сети);
— ошибки Системы КХД, не выявленные при отладке и испытании системы;
— сбои программного обеспечения сервера.

4.1.4.3. Требования к надежности технических средств и программного обеспечения

Например:
К надежности оборудования предъявляются следующие требования:
— в качестве аппаратных платформ должны использоваться средства с повышенной надежностью;
— применение технических средств соответствующих классу решаемых задач;
— аппаратно-программный комплекс Системы должен иметь возможность восстановления в случаях сбоев.
К надежности электроснабжения предъявляются следующие требования:
— с целью повышения отказоустойчивости системы в целом необходима обязательная комплектация серверов источником бесперебойного питания с возможностью автономной работы системы не менее X минут;
— система должны быть укомплектована подсистемой оповещения Администраторов о переходе на автономный режим работы;
— система должны быть укомплектована агентами автоматической остановки операционной системы в случае, если перебой электропитания превышает Y минут;
— должно быть обеспечено бесперебойное питание активного сетевого оборудования.
Надежность аппаратных и программных средств должна обеспечиваться за счет следующих организационных мероприятий:
— предварительного обучения пользователей и обслуживающего персонала;
— своевременного выполнения процессов администрирования;
— соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;
— своевременное выполнение процедур резервного копирования данных.
Надежность программного обеспечения подсистем должна обеспечиваться за счет:
— надежности общесистемного ПО и ПО, разрабатываемого Разработчиком;
— проведением комплекса мероприятий отладки, поиска и исключения ошибок.
— ведением журналов системных сообщений и ошибок по подсистемам для последующего анализа и изменения конфигурации.

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

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

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

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

К другим подсистемам предъявляются следующие требования к эргономике и технической эстетике.
В части внешнего оформления:
— интерфейсы по подсистемам должен быть типизированы.
В части диалога с пользователем:
— для наиболее частых операций должны быть предусмотрены «горячие» клавиши;
— при возникновении ошибок в работе подсистемы на экран монитора должно выводиться сообщение с наименованием ошибки и с рекомендациями по её устранению на русском языке.
В части процедур ввода-вывода данных:
— должна быть возможность получения отчетности по мониторингу работы подсистем.

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

Например:
Условия эксплуатации, а также виды и периодичность обслуживания технических средств Системы должны соответствовать требованиям по эксплуатации, техническому обслуживанию, ремонту и хранению, изложенным в документации завода-изготовителя (производителя) на них.
Технические средства Системы и персонал должны размещаться в существующих помещениях Заказчика, которые по климатическим условиям должны соответствовать ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды» (температура окружающего воздуха от 5 до 40 °С, относительная влажность от 40 до 80 % при Т=25 °С, атмосферное давление от 630 до 800 мм ртутного столба). Размещение технических средств и организация автоматизированных рабочих мест должны быть выполнены в соответствии с требованиями ГОСТ 21958-76 «Система «Человек-машина». Зал и кабины операторов. Взаимное расположение рабочих мест. Общие эргономические требования».
Для электропитания технических средств должна быть предусмотрена трехфазная четырехпроводная сеть с глухо заземленной нейтралью 380/220 В (+10-15)% частотой 50 Гц (+1-1) Гц. Каждое техническое средство запитывается однофазным напряжением 220 В частотой 50 Гц через сетевые розетки с заземляющим контактом.
Для обеспечения выполнения требований по надежности должен быть создан комплект запасных изделий и приборов (ЗИП).
Состав, место и условия хранения ЗИП определяются на этапе технического проектирования.

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

4.1.7.1. Требования к информационной безопасности

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

4.1.7.2. Требования к антивирусной защите

Например:
Средства антивирусной защиты должны быть установлены на всех рабочих местах пользователей и администраторов Системы КХД. Средства антивирусной защиты рабочих местах пользователей и администраторов должны обеспечивать:
— централизованное управление сканированием, удалением вирусов и протоколированием вирусной активности на рабочих местах пользователей;
— централизованную автоматическую инсталляцию клиентского ПО на рабочих местах пользователей и администраторов;
— централизованное автоматическое обновление вирусных сигнатур на рабочих местах пользователей и администраторов;
— ведение журналов вирусной активности;
— администрирование всех антивирусных продуктов.

4.1.7.3. Разграничения ответственности ролей при доступе к

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

Матрица должна раскрывать следующую информацию:
— код ответственности: Ф — формирует, О – отвечает, И – использует и т.п.;
— наименование объекта системы, на который накладываются ограничения;
— роль сотрудника/единица организационной структуры, для которых накладываются ограничения.

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

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

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

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

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

Применительно к программно-аппаратному окружению Системы предъявляются следующие требования к защите от влияния внешних воздействий.
Требования к радиоэлектронной защите:
— электромагнитное излучение радиодиапазона, возникающее при работе электробытовых приборов, электрических машин и установок, приёмопередающих устройств, эксплуатируемых на месте размещения АПК Системы, не должны приводить к нарушениям работоспособности подсистем.
Требования по стойкости, устойчивости и прочности к внешним воздействиям:
— Система должна иметь возможность функционирования при колебаниях напряжения электропитания в пределах от 155 до 265 В (220 ± 20 % — 30 %);
— Система должна иметь возможность функционирования в диапазоне допустимых температур окружающей среды, установленных изготовителем аппаратных средств.
— Система должна иметь возможность функционирования в диапазоне допустимых значений влажности окружающей среды, установленных изготовителем аппаратных средств.
— Система должна иметь возможность функционирования в диапазоне допустимых значений вибраций, установленных изготовителем аппаратных средств.

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

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

Разработка системы должна осуществляться с использованием стандартных методологий функционального моделирования: IDEF0, DFD и информационного моделирования IE и IDEF1Х в рамках рекомендаций по стандартизации Р50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования».
Моделирование должно выполняться в рамках стандартов, поддерживаемых программными средствами моделирования ERWin 4.х и BPWin 4.х.
Для работы с БД должнен использоваться язык запросов SQL в рамках стандарта ANSI SQL-92.
Для разработки пользовательских интерфейсов и средств генерации отчетов (любых твердых копий) должны использоваться встроенные возможности ПО , а также, в случае необходимости, языки программирования .
В системе должны использоваться (при необходимости) общероссийские классификаторы и единые классификаторы и словари для различных видов алфавитно-цифровой и текстовой информации.

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

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

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

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

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

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

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

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

При внедрении, эксплуатации и обслуживании технических средств системы должны выполняться меры электробезопасности в соответствии с «Правилами устройства электроустановок» и «Правилами техники безопасности при эксплуатации электроустановок потребителей».
Аппаратное обеспечение системы должно соответствовать требованиям пожарной безопасности в производственных помещениях по ГОСТ 12.1.004-91. «ССБТ. Пожарная безопасность. Общие требования».
Должно быть обеспечено соблюдение общих требований безопасности в соответствии с ГОСТ 12.2.003-91. «ССБТ. Оборудование производственное. Общие требования безопасности» при обслуживании системы в процессе эксплуатации.
Аппаратная часть системы должна быть заземлена в соответствии с требованиями ГОСТ Р 50571.22-2000. «Электроустановки зданий. Часть 7. Требования к специальным электроустановкам. Раздел 707. Заземление оборудования обработки информации».
Значения эквивалентного уровня акустического шума, создаваемого аппаратурой системы, должно соответствовать ГОСТ 21552-84 «Средства вычислительной техники. Общие технические требования, приемка, методы испытаний, маркировка, упаковка, транспортирование и хранение», но не превышать следующих величин:
— 50 дБ — при работе технологического оборудования и средств вычислительной техники без печатающего устройства;
— 60 дБ — при работе технологического оборудования и средств вычислительной техники с печатающим устройством.

4.1.13. Требования к транспортабельности для подвижных АИС

КСА системы являются стационарными и после монтажа и проведения пуско-наладочных работ транспортировке не подлежат.

4.2. Требования к функциям, выполняемым системой

В данном подразделе приводят:
1) по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации;
при создании системы в две или более очереди — перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях;
2) временной регламент реализации каждой функции, задачи (или комплекса задач);
3) требования к качеству реализации каждой функции (задачи или комплекса задач), форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования к одновременности выполнения групп функций, достоверности выдачи результатов;
4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.