Основные ошибки и подводные камни написания ТЗ на создание Информационной системы и ее защиты

05/04/24

Б-152

Кристина Ахременко

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

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

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

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

На практике ИС создается операторами чаще всего не по проектным документам. Она масштабируется постепенно в зависимости от потребностей бизнеса и его динамики развития.

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

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

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

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

• Какую цель преследует Заказчик при создании АС?
• Какие функции должны быть реализованы в системе?
• В каких условиях и режимах должна работать система?
• Каким требованиям система должна соответствовать в плане надежности, безопасности, производительности и прочих аспектов?
• Какие работы необходимо выполнить для разработки, внедрения и сопровождения системы?

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

Грамотно составленное ТЗ – это уже половина успеха для разрабатываемого проекта.

– Представить готовый продукт.

– Провести попунктную проверку готового продукта (приемочное тестирование — проведение испытаний).

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

2. Заказчику:

– Четко понимать свои требования.

– Требовать от исполнителя удовлетворения всех условий, оговоренных в ТЗ.

3. Исполнителю:

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

– Запланировать выполнение проекта и работать по определенному плану.

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

То есть ТЗ должно содержать объективные критерии, чтобы определить, были ли реализованы определенные требования или нет.

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

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

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

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

2. Специальные требования и рекомендации по технической защите конфиденциальной информации (СТР-К) – в соответствии с п. 3.7 разработка автоматизированной системы включает следующие этапы: предпроектная стадия, включающая предпроектное обследование объекта, аналитическое обоснование необходимости создания СЗИ и разработка технического (частного технического) задания на ее создание;

3. Руководящий документ «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации» (РД СВТ), от 30 марта 1992 г., утв. Гостехкомиссией – согласно п 1.3. РД СВТ в состав комплекса средств защиты должна входить конструкторская документация, включающая в себя техническое задание, в целях определения требований к показателям защищенности СВТ.

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

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

Правильно сформулированное техническое задание дает исполнителю понимание того, что должно быть на выходе, а заказчику — как оценивать результат. Чем меньше в техническом задании абстрактных формулировок, которые можно трактовать по-разному, тем лучше.

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

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

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

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

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

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

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

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

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

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

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

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

Качественный пример технического задания на разработку ПО обычно включает несколько обязательных разделов:

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

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

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

При подготовке документации для государственных заказчиков или работе по 44-ФЗ особенно востребован пример ТЗ на разработку программного обеспечения, соответствующий требованиям ГОСТ 34.602-2020. Такой образец технического задания на разработку программного обеспечения проходит обязательную экспертизу и должен содержать исчерпывающую информацию для объективной оценки стоимости и сроков реализации проекта.

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

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

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

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

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

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

На этой стадии также следует разработать эксплуатационную документацию (ЭД) для системы. Часто при разработке ЭД возникает неопределенность относительно ее содержания. Однако, основной задачей ЭД является составление инструкций и последовательности шагов для работы с системой. Разработка ЭД может быть относительно простой задачей, при условии, но могут возникнуть вопросы:

Где найти список операций, которые следует описать в ЭД?

• Каким режимам работы отнести различные операции: штатный, регламентный или аварийный режимы?
• Каким образом следует описывать аварийные ситуации?
• Насколько подробно следует описать ЭД?

Чтобы избежать затруднений при разработке ЭД, следует предъявить соответствующие требования в ТЗ. Необходимо указать:

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

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

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

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

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

Теоретические аргументы в пользу разработки ТЗ звучат убедительно, но на практике многие компании продолжают пренебрегать этим этапом, рассчитывая сэкономить время и бюджет. Результат, как правило, оказывается противоположным.
Первый и самый распространенный сценарий ― бесконечное расширение объема работ. Без зафиксированных границ проекта заказчик начинает вносить дополнительные требования уже в процессе разработки. Исполнитель вынужден либо выполнять их бесплатно, рискуя уйти в убыток, либо отказываться, провоцируя конфликт. В обоих случаях страдает результат.

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

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

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

Особенно заметно это при попытке самостоятельно разработать ТЗ, так как на практике только 30% таких проектов успешно завершаются из-за отсутствия опыта и профессиональных навыков, необходимых для качественного составления ТЗ

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

Существуют российские стандарты ГОСТ 34 и 19 серии, которые устанавливают требования к техническим заданиям и описывают их основные характеристики.

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

Разработка профессионального ТЗ – это сложная задача, требующая определенных знаний и навыков. Здесь на помощь приходит наша компания — Б152.

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

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

Ввод оборотных штрафов за утечки откладывается минимум до 1 июля 2023 года

Подписывайтесь на наш Telegram-канал, чтобы быть в курсе последних новостей и событий!

Материалы по теме