Ошибки оформления технического задания по ГОСТу

0
Акашева Василиса Игоревна4/11/2020

Проводя нормоконтроль и разрабатывая методические рекомендации, мы стараемся максимально точно следовать требованиям ГОСТ. Более того, мы всячески призываем избегать некоторых «вольностей», допускаемых нормативными документами. Например, в ГОСТ 34.602 указывается, что «в зависимости от вида, назначения, специфических особенностей объекта автоматизации и условий функционирования системы допускается оформлять разделы ТЗ в виде приложений, вводить дополнительные, исключать или объединять подразделы ТЗ». Мы вынуждены просить обосновать, в чем заключена «специфика», заставляющая менять структуру документа. Почему, например, если система является стационарной и требования к транспортабельности не предъявляются, необходимо исключать соответствующий раздел? Ведь можно просто написать в не единственную фразу: «Требования к транспортабельности не предъявляются». Почему такой вариант лучше? Потому что он однозначно определяет,что такие требования не предъявляются, и заказчик об этом знает. Отсутствие же раздела может означать следующее:

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

Поскольку пока никто не смог обосновать необходимость изменения структуры, заложенной в ГОСТ 34.602,строгое следование ей стало законом для всех, чьи документы проходят у нас нормоконтроль. [...]

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

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

При этом в качестве объектов автоматизации, т.е. объектов, при управлении которыми решают комплекс задач (АС), следует понимать технологические объекты (локомотив, реактор) или подразделения предприятий. Бизнес-процессы, как технологические и прочие процессы, — не объекты автоматизации, а «вид автоматизируемой деятельности». [...]

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

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

  • указать на необходимость (или отсутствие таковой) разработки профиля защиты системы в соответствии с ГОСТ Р ИСО/МЭК 15408-1—2008, либо использования уже разработанного профиля;
  • указать класс АС в соответствии с руководящим документом «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования к информации» (РД АС), ФСТЭК (Гостехкомиссия) России, 1992 г.;
  • при необходимости конкретизировать требования по механизмам защиты информации, приведенные в указанном руководящем документе (например, указать требования к длине пароля, частоте его смены и т.д.);
  • при необходимости (см. п. 2.18 руководящего документа) указать требования к классу защищенности средств вычислительной техники.
В. Бабайлов, Э. Клименко. Опыт нормоконтроля. Техническое задание на разработку автоматизированной системы. // Рекламно-информационное агентство «‎Стандарты и качество». — №7, 2012. — С. 42-45.
Следующая статья
Бизнес и экономика
Что нельзя писать в тексте технического задания (ТЗ)?
Текст документа должен быть кратким, четким и не допускать различных толкований. При изложении обязательных требований в тексте должны применяться слова «должен», «следует», «необходимо», «требуется, чтобы», «разрешается только», «не допускается», «запрещается», «не следует». При изложении других положений следует применять слова «могут быть», «как правило», «при необходимости», «может быть», «в случае» и т. д. При этом допускается использовать повествовательную форму изложения текста документа, например: «применяют», «указывают» и т. п.
Бизнес и экономика
Что нельзя писать в тексте технического задания (ТЗ)?
Бизнес и экономика
Кейнсианство и преодоление социального неравенства
Бизнес и экономика
ТРЕБОВАНИЕ ДОЛЖНО БЫТЬ КОНКРЕТНЫМ! Об общих формулировках и их вреде для разработки
Теория Творчества
МОДУЛОР Ле Корбюзье: система стандартов, принципы, значение
Бизнес и экономика
Метод «уплотнения времени». Советская теория тайм-менеджмента
Искусство и дизайн
Антропометрические факторы и их учет в художественном конструировании
IT
Закон и реалии: противоречия в требованиях
Бизнес и экономика
50 вопросов для работы над пользовательской документацией
Искусство и дизайн
3 группы ошибок конструирования
Бизнес и экономика
Книжная лавка А. Ф. Смирдина: история
Бизнес и экономика
Яндекс.Пиво — необычные проекты компании Yandex
Бизнес и экономика
Первая контекстная реклама в Яндексе / Yandex
Бизнес и экономика
Как написать ТЗ? Критерии к тексту требований.
Бизнес и экономика
8 правил эффективного совещания от Google
Бизнес и экономика
Как организовать свою работу на дому?
Бизнес и экономика
Борьба между Google и Яндекс за российский рынок интернета