Как составить техническое задание?
1. Раздел «Цели создания АС»
Очень часто недооценивается важность правильной формулировки целей создания автоматизированной системы. Часто пишут что-то «для галочки». На самом деле, правильная формулировка цели имеет огромное значение (и не всегда это так просто). Все требования, описываемые в ТЗ, должны приводить к достижению этой цели. Поэтому некорректная формулировка цели может привести к тому, что получившаяся система будет значительно отличаться от ожиданий.
Не забывайте, что согласно российским стандартам, цель создания АС должна быть измеримой и иметь критерии достижения. Только четко сформулированная цель с определенными критериями позволит защитить интересы как исполнителя, так и заказчика на этапе сопровождения.
Помимо цели, в ТЗ присутствуют два вида компонентов, которые задают некоторые важные ограничения — показатели назначения и перспективы развития.
Показатели назначения – это условия, в которых должна эксплуатироваться система. Например, максимальное количество пользователей или максимально допустимый объем хранимых данных. Такие ограничения помогают обезопасить заказчика от претензий на этапе сопровождения. Например, если в ТЗ установлено ограничение на 1000 пользователей, то ответственность за любые инциденты, возникающие при большем количестве пользователей, лежит на заказчике.
Перспективы развития определяют границы расширения системы путем добавления компонентов (например, расширение количества серверов). Если заказчик планирует в будущем расширить систему больше, чем указано в ТЗ, то это также становится его ответственностью. Если на этапе разработки невозможно определить границы развития, стоит включить требование отслеживания этих границ.
2. Раздел «Режимы функционирования АС и обучение персонала»
В этом пункте технического задания (ТЗ) нужно уточнить требования к организации функционирования автоматизированной системы (АС) и порядку взаимодействия персонала и пользователей с ней.
На этой стадии также следует разработать эксплуатационную документацию (ЭД) для системы. Часто при разработке ЭД возникает неопределенность относительно ее содержания. Однако, основной задачей ЭД является составление инструкций и последовательности шагов для работы с системой. Разработка ЭД может быть относительно простой задачей, при условии, но могут возникнуть вопросы:
- Где найти список операций, которые следует описать в ЭД?
- Каким режимам работы отнести различные операции: штатный, регламентный или аварийный режимы?
- Каким образом следует описывать аварийные ситуации?
- Насколько подробно следует описать ЭД?
Чтобы избежать затруднений при разработке ЭД, следует предъявить соответствующие требования в ТЗ. Необходимо указать:
- Описание режимов работы системы и процедуры перехода между ними.
- Перечень ролей и типов пользователей, их квалификация и количество.
- Требования к организации рабочего места.
- Список операций системы, их продолжительность и частота выполнения.
- Какие операции могут быть выполнены различными пользователями.
- Перечень регламентных работ.
Если предъявление таких требований на стадии разработки ТЗ затруднительно, то их можно включить в ТЗ как требования по разработке соответствующих решений на стадии разработки технического проекта.
3. Этап формулирования требований
Формулировка требований является важным аспектом при написании документации, чтобы избежать недоразумений и двусмысленностей.
- Все формулировки в ТЗ должны быть четко выверены и не допускать неоднозначности, так как размытые или нечёткие формулировки могут привести к неправильной интерпретации требований заказчиком или командой разработчиков.
- Любые двусмысленности должны быть выявлены и устранены на стадии разработки ТЗ, а не на стадии технического проекта или приёмки системы.
- Относительно любых согласований следует составлять письменное соглашение, так как любое устно сделанное соглашение может быть запутано или не учтено при изменении состава рабочей группы проекта.
- Определяем уровень детализации функций.
Насколько детально описывать функции системы? С одной стороны, в ТЗ должно быть максимальное количество деталей о способах достижения результата и особенностях функционирования системы. Это снижает вероятность разногласий с заказчиком и способствует более быстрой реализации системы.
С другой стороны, слишком детальное описание ограничивает возможности исполнителя. Вариант реализации системы может быть выбран ещё на стадии разработки ТЗ, и, хотя основные решения уже приняты, детали могут быть пока неясны. В ТЗ следует включать требования, которые зафиксируют принятые решения.
Например, если на стадии ТЗ уже известно, что для системы нужно будет установить антивирусное ПО и подключить его к серверу защиты заказчика, это следует прописать в ТЗ соответствующим образом: указать требуемые антивирусные средства, сервер и применяемые политики. Если выбор антивирусного ПО ещё не осуществлен, но является частью работ, следует указать общие требования к наличию антивирусной защиты в ТЗ.
На основании требований о защите информации, одновременно с определением требований, в ТЗ определяются и меры защиты информации, применение которых необходимо для нейтрализации актуальных угроз, выявленных по результатам моделирования угроз безопасности информации. Меры защиты включаются в Техническое задание на систему и затем при необходимости могут уточняться в рамках проектирования.
Таким образом, при разработке ТЗ следует проявить внимание к деталям и формулировкам, представить требования к ЭД и уровню детализации функций системы. Это поможет избежать разночтений и недоразумений, а также обеспечит более эффективную разработку и внедрение автоматизированной системы.
4. Этап определения границ работ
В случае, когда создание автоматизированной системы осуществляется несколькими подрядчиками, определение ответственности между ними может стать проблематичным. Например, в процессе разработки системы мониторинга одновременно создается и вычислительная инфраструктура. В описании требований к проекту зависимость от реализации вычислительной архитектуры, которая еще не создана, является неотъемлемой частью.
Для урегулирования ситуации стандарт ГОСТ 34.602-2020 предусматривает раздел 6 «Порядок разработки автоматизированной системы», в котором можно точно описать зависимости от результатов работы других подрядчиков. Например, указать, что исходные данные необходимо получить от заказчика или смежного исполнителя.
Более того, техническое задание также позволяет распределить ответственность между заказчиком и исполнителем. Раздел 8 «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу в действие» должен включать требования к условиям эксплуатации, которые заказчик должен выполнить перед проведением испытаний системы (организация рабочих мест, найм и обучение персонала и т.д.).