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

соответствии с ГОСТ 34.602-89. Пример технического задания

для учебного примера. Международный стандарт

IEEE 830-1993

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

Задачи, решаемые при разработке ТЗ

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

• Разработать и обосновать требования, предъявляемые к подсистемам

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

• Установить общие требования к проектируемой системе

• Определить перечень задач и исполнителей

• Определить этапы создания системы и сроки выполнения

• Провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.

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

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

Структура ТЗ

•Предварительные замечания к проекту

•Системные сервисы

•Системные ограничения

•Проектные вопросы

•Приложения

СОСТАВ И СОДЕРЖАНИЕ ГОСТ 34.602-89

1) общие сведения; 2) назначение и цели создания (развития) системы; 3) характеристика объектов автоматизации; 4) требования к системе; 5) состав и содержание работ по созданию системы; 6) порядок контроля и приемки системы; 7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие; 8) требования к документированию; 9) источники разработки.

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

1) полное наименование системы и ее условное обозначение; 2) шифр темы или шифр (номер) договора; 3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты; 4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы; 5) плановые сроки начала и окончания работы по созданию системы; 6) сведения об источниках и порядке финансирования работ; 7) порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.

1. Общие сведения Настоящее Техническое задание на создание

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

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

Полное наименование системы «Автоматизированная информационная система учета оплаты обучения и начисления заработной платы преподавателям»

1.2. Краткое наименование

Краткое наименование Системы ««Договора»

Пример

1. Общие сведения 1.3 Обозначение, присвоенное исполнителем

Шифр: КИТИС-Договора

1.2 НАИМЕНОВАНИЕ ЗАКАЗЧИКА И ИСПОЛНИТЕЛЯ, ИХ РЕКВИЗИТЫ

1.2.1 Наименование Заказчика

Полное наименование: федеральное государственное автономное образовательное учреждение высшего профессионального образования «Национальный исследовательский университет «МИЭТ».

Подразделение: Центр экономики учебного процесса МИЭТ

1.2.2 Наименование Исполнителя

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

Сокращенные наименования:

1. Национальный исследовательский университет «МИЭТ»;

2. МИЭТ.

Юридический адрес: 124498, Москва, Зеленоград, проезд 4806, дом 5.

Телефон: (499) 731-44-41. Факс: (499) 710-22-33. Электронная почта: netadm@miee.ru.

Пример

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

1.3 ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ

Основанием для проведения работ по созданию автоматизированной информационной системы послужил приказ №12 от 1 февраля 2014 года

1.4 СВЕДЕНИЯ ОБ ИСТОЧНИКАХ И ПОРЯДКЕ ФИНАНСИРОВАНИЯ

1.4.1 Источник финансирования

Источником финансирования является федеральный бюджет (код бюджетной классификации – 19203112200000268226).

1.4.2 Порядок финансирования

Финансирование производится в соответствии с Календарным планом проведения работ (Приложение №2 к приказу №12 от 1 февраля 2014 года).

Пример

1. Общие сведения 1.5 ПЛАНОВЫЕ СРОКИ НАЧАЛА И ОКОНЧАНИЯ РАБОТ

Начало: 12.02.2015 окончание 31.05.2015

1.6 ПОРЯДОК ОФОРМЛЕНИЯ И ПРЕДЪЯВЛЕНИЯ РЕЗУЛЬТАТОВ РАБОТ

1.6.1 Выполнение работ по разработке Системы

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

- ГОСТ 34.601-90 Автоматизированные системы. Стадии создания.

- РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов.

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

1. Общие сведения 1.6.2 Сроки представления результатов работ

Работы по созданию Системы должны быть проведены в 3 этапа:

1 этап – март 2015 год;

2 этап – апрель 2015 год;

3 этап – май 2015 год

1.6.3 Приемка результатов работ

Приемка результатов работ должна проводиться в порядке, установленном в разделе 6 настоящего Технического задания.

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

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

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

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

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

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

2.2. Цели создания (развития) системы»:

-повышение эффективности работников ЦЭУП, учебного отдела, кафедры, задействованных в процессе учета оплаты обучения;

- автоматизация формирования сводной информации для руководства вуза;

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

Пример

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

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

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

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

3.1. Объект автоматизации Сведения об объекте автоматизации

Объектом автоматизации является подразделение МИЭТ – Центр экономики учебного процесса (ЦЭУП), осуществляющее учет контрактных студентов, обучающихся по направлениям подготовки высшего образования в соответствии с учебными планами, их оплату, а также расчет заработной платы преподавателей, ведущих занятия в контрактных группах

Пр

им

ер

3.2. Общие сведения об объекте автоматизации

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

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

Пр

им

ер

3.2. Общие сведения об объекте автоматизации

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

Сотрудники ЦЭУП на основании приказа о стоимости обучения выписывают квитанции об оплате, фиксируют в журнале учета оплаченных и выданных квитанций о произведенной оплате, рассчитывают з/п преподавателей, ведущих занятия в контрактных группах, а также отслеживают должников по оплате и формируют сводные данные для руководства

Пр

им

ер

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

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

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

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

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

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

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

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

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

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

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

Автоматизированная информационная система для ЦЭУП должна обеспечивать:

• учет студентов;

• учет вносимой студентами оплаты обучения;

• учет дисциплин и видов занятий;

• учет преподавателей и их учебной нагрузки;

• расчет заработной платы преподавателей, ведущих обучение;

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

Пр

им

ер

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

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

1. Сервер базы данных

2. Сервер приложений

3. Клиентские рабочие места для пользователей системы

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

Пример

4.1.2. Требования к диагностированию системы

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

Пр

им

ер

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

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

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

Пример

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

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

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

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

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

Пользователями системы являются: сотрудник учебного отдела, сотрудник кафедры, сотрудник ЦЭУП, проректор по УР.

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

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

Пример

Требования к показателям назначения АС

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

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

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

4.1.5. Требования к показателям назначения АС Система должна обеспечивать одновременную, устойчивую работу

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

Система должна гарантированно отображать одну экранную форму объёмом не более 1 Мбайт в течение не более 10 сек.

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

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

Пр

им

ер

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

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

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

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

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

Пр

им

ер

4.1.6. Требования к надежности Система должна сохранять работоспособность и обеспечивать

восстановление своих функций при возникновении следующих внештатных ситуаций:

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

– при ошибках в работе аппаратных средств (кроме носителей данных и программ) восстановление функции системы возлагается на ОС;

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

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

Пример

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

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

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

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

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

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

Пример

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

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

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

Пример

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

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

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

Пример

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

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

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

ремонту и хранению 1) условия и регламент (режим) эксплуатации, которые должны

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

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

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

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

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

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

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

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

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

Пример

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

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

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

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

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

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

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

– В зависимости от категории пользователя система должна предоставлять соответствующие функции:

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

• Сотруднику кафедры – возможность распределять преподавателей по дисциплинам и группам

• Сотруднику ЦЭУП – работать с информацией по финансам.

• Проректору по УР – получать сводную информацию по финансам

Пр

им

ер

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

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

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

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

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

• перечень стран, в отношении которых должна быть обеспечена патентная чистота системы и ее частей

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

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

Пример

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

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

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

Система должна предоставлять пользователям соглашение об использовании (пользовательское соглашение).

Пример

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

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

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

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

Требование к функциям (задачам)

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

Требование к функциям Функциональные требования по работе с «Учебными планами».

Основным пользователем является сотрудник учебного отдела. Функции:

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

• Работать с факультетами (создавать, редактировать, удалять)

• Работать с группами на факультетах (создавать, редактировать, удалять)

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

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

Пример

Требование к функциям Функциональные требования к работе с преподавателями

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

• Работать с информацией о преподавателе (создавать, редактировать, удалять)

• Работать с назначениями преподавателя на ведение занятий по дисциплине

• Работать с данными о реально проведенных занятиях в группах.

Пример

Требование к функциям Функциональные требования к работе с финансовой информацией

Основным пользователем является сотрудник ЦЭУП.

Функции:

• Работать с данными о студенте (создавать, редактировать, удалять)

• Формировать квитанцию об оплате

• Работать с данными по оплате

• Работать с приказами

• Создавать план оплаты

• Формировать отчетные формы: сводную информацию, должники, и др.

Пример

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

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

Математическое обеспечение

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

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

4.3.1. Математическое обеспечение

Заработная плата преподавателя рассчитывается по формуле:

ЗП=ΣТi*Чi, где ЗП – заработная плата

Т – тариф

Ч – количество часов

Пример

Информационное обеспечение

1) к составу, структуре и способам организации данных в системе; 2) к информационному обмену между компонентами системы; 3) к информационной совместимости со смежными системами; 4) по использованию общесоюзных и зарегистрированных республиканских, отраслевых классификаторов, унифицированных документов и классификаторов, действующих на данном предприятии; 5) по применению систем управления базами данных; 6) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных; 7) к защите данных от разрушений при авариях и сбоях в электропитании системы; 8) к контролю, хранению, обновлению и восстановлению данных; 9) к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4).

4.3.2. Информационное обеспечение

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

Пример

Лингвистическое обеспечение

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

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

высокого уровня: SQL, РНР. Должны использоваться встроенные средства диалогового взаимодействия BI приложения: JavaScript; HTML; др.

Должны выполняться следующие требования к кодированию и декодированию данных: Windows CP1251 для подсистемы хранения данных; Windows CP1251 информации, поступающей из систем-источников. Для реализации запросов к БД необходимо использовать стандартный язык SQL

Для описания предметной области (объекта автоматизации) должен использоваться стандарт IDEF0 или DFD, для описания структуры данных IDEF2.

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

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

Пример

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

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

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

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

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

4.3.4. Программное обеспечение В состав программного обеспечения серверной части входит:

• Операционная система Linux

• Система управления базами данных MySQL

• Web-сервер Apach

• Скрипты на языке PHP

В состав программного обеспечения на стороне клиента:

• Операционная система Windows 7

• Браузеры Internet Explorer 9 или Firefox 3.1

Пример

Техническое обеспечение

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

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

4.3.5. Техническое обеспечение Для реализации системы потребуется сервер с характеристиками:

Коммуникационное оборудование:

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

Пример

Метрологическое обеспечение

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

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

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

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

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

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

4.3.6. Метрологическое обеспечение

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

Пример

Организационное обеспечение

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

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

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

4.3.7. Организационное обеспечение

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

Пример

4.3.7. Организационное обеспечение К организации функционирования Системы и

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

Пример

4.3.7. Организационное обеспечение

К защите от ошибочных действий персонала предъявляются следующие требования:

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

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

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

Пример

Методическое обеспечение

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

4.3.8. Методическое обеспечение

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

–Руководство по применению;

–Руководство по установке и настройке;

–Инструкция по работе в системе сотрудника учебного отдела;

–Инструкция по работе в системе сотрудника кафедры;

–Инструкция по работе в системе сотрудника учебного отдела;

–Руководство администратора системы

Пример

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

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

1) перечень документов, по ГОСТ 34.201-89, предъявляемых по окончании соответствующих стадий и этапов работ; 2) вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт); 3) программу работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости); 4) перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организаций-исполнителей (при необходимости).

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

№ Стадии/ этапы работ Сроки

выполнения

Документы

Проектирование БД Сроки должны

соответствова

ть срокам из

плана проекта

MS Project

Схема БД

Проектирование

интерфейса пользователя

Прототип

пользовательского

интерфейса

Пример

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

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

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

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

6. Порядок контроля и приемки системы Испытания Системы должны быть

организованы и проведены в соответствии с ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем».

Предусматриваются следующие виды испытаний:

• предварительные испытания;

• опытная эксплуатация;

• приемочные испытания.

Пример

6. Порядок контроля и приемки системы Объем, виды и методы испытаний определяются

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

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

Пример

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

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

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

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

Пример

Требования к составу и содержанию работ по подготовке объекта

автоматизации к вводу системы в действие

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

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

1) приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ; 2) изменения, которые необходимо осуществить в объекте автоматизации; 3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ; 4) создание необходимых для функционирования системы подразделений и служб; 5) сроки и порядок комплектования штатов и обучения персонала

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

системы в действие Для создания условий функционирования объектов

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

7.1. Технические мероприятия

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

Пример

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

системы в действие 7.2. Организационные мероприятия

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

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

7.3. Предоставление гарантии качества выполненных работ

Исполнитель должен предоставить качество гарантии качества выполненных работ сроком не менее 24 (двадцати четырёх) месяцев с момента передачи Системы в опытную эксплуатацию.

Пример

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

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

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

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

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

•ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;

•ГОСТ 34.003-90 «Автоматизированные системы. Термины и определения»;

•ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»;

•ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем»;

•ГОСТ 34.603-92 «Виды испытаний автоматизированных систем»;

•ГОСТ 19.301-79 «Программа и методика испытаний. Требования к содержанию и оформлению»;

•РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов».

Пример

8. Требования к документированию Документация должна представляться Заказчику

на оптическом (CD) и бумажном носителе (в 2-х экземплярах). Документация, представленная в электронном виде должна быть выполнена в формате MS Word (файлы с расширением *.doc, *.rtf). Формат предоставления документации определяется Заказчиком.

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

Пример

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

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

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

Данное ТЗ разработано на основании следующих материалов:

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

• Реестр требований к ИС

• Диаграммы вариантов использования

• Расширенного описания вариантов использования

Пример

Приложения

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

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

ПОРЯДОК РАЗРАБОТКИ, СОГЛАСОВАНИЯ И УТВЕРЖДЕНИЯ ТЗ НА АС

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

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

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

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

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

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

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

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

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

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

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

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

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

Software Requirements Specification стандарта IEEE 830-1993

Структура документа

1. Введение.

2. Общее описание

3. Конкретные требования

4. Сопровождающая информация

Введение

–цель документа, а не программы;

–область применения, т.е. какие аспекты программы этот документ должен охватывать;

–определения, термины, сокращения

– ссылки на документы, такие как описание архитектуры, план управления проектом, план контроля качества и др.

Общее описание • перспективы продукта (приводится сравнение с другими

программными системами и ожидаемые перспективы данного продукта)

системные интерфейсы (общее представление о

программе)

пользовательские интерфейсы (наброски ГПИ)

аппаратные, программные, коммуникационные интерфейсы (если имеются)

ограничения по оперативной памяти

операции, требуемые от пользователя в процессе использования программной системы

требования по адаптации (к компьютеру, языкам

программирования, СУБД)

Общее описание

• функции продукта (варианты использования и их

расширенные описания)

• пользовательские характеристики (опыт,

профессиональные знания)

• ограничения (ОС, язык программирования, технические

средства, …)

• предположения и зависимости (любые допущения)

• распределение требований (ранжирование)

Конкретные требования • требования к внешним интерфейсам

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

• ограничения проектирования (методология, CASE-

средства)

• атрибуты программной системы: надежность,

доступность, защита, поддержка изменений;

• дополнительные требования (нефункциональные)

Сопровождающая информация

• примеры форматов ввода/вывода,

• описание стоимости изучения и анализа или результатов опроса пользователя,

• описание проблемы, которую должна решить разрабатываемая программная система,

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

Сравнение • стандарт IEEE 830-1993 включает описание

результатов проектирования:

классы и объекты,

модели системы на языке UML,

макет графического пользовательского интерфейса

• ГОСТ 34.602-89 опирается на результаты этапа формирования требований со стороны заказчика