Обновление ГОСТ 34.602: от разработки ТЗ к управлению требованиями

Михаил Острогорский

ГОСТ 34.602-89 устанавливает требования к техническому заданию на автоматизированную систему. Новым его не назовешь: в этом году мы могли бы поздравить его с тридцатилетним юбилеем. И все же, несмотря на то, что авторы этого стандарта жили и работали в другой технической, экономической и социальной реальности, он до сих пор находит широкое применение не только сфере государственного заказа, но и в коммерческом секторе.

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

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

Как же быть? Оставить ГОСТ 34.602-89 неизменным, значит, обречь его на окончательное устаревание, переработать полностью — отказаться от его сильных сторон и обесценить накопленную практику использования стандарта. Вероятно, лучшее решение состоит в его тактичной и вдумчивой переработке.

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

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

Что произойдет, если мы ограничимся этими и другими аналогичными улучшениями? Да, представление об автоматизированной системе, заложенное в основу стандарта, будет приведено в соответствие современности. Однако задаваемый им подход к документированию требований останется прежним. Будем назвать его «писательским», поскольку основная задача, которую он ставит перед разработчиками автоматизированных систем, — написание и утверждение выходных документов.

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

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

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

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

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

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

«Писательскому» подходу к документированию требований противопоставлен «инженерный» подход. Получив развитие в рамках системной и программной инженерии, он включает в себя завидное разнообразие методологий, инструментов (например, IBM DOORS), стандартов (например, ISO/IEC/IEEE 29148:2018).

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

Сильные стороны «инженерного» подхода таковы.

• Каждое атомарное требование претерпевает определенный жизненный цикл: внесение, обсуждение, согласование, утверждение и т. д. Поэтому важные требования не «тонут» большом объеме текста, а риск их недостаточной проработки из-за невнимательности участников проекта снижается.
• На основе заранее подготовленного материала можно быстро формировать разные выходные документы, отбирая из базы данных те требования, которые соответствуют конкретному проекту.
• Работа с требованиями хорошо поддается автоматизации. Отбор требований и проверку зависимостей между ними можно делать автоматически по метаданным. Выходные документы также можно формировать и обновлять автоматически.
• Атомарность требований к автоматизированным системам помогает управлять проектами по созданию последних. Так, оценив затраты на реализацию каждого требования, можно вычислить себестоимость всего проекта.

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

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

Получится ли совместить в одном стандарте преимущества обоих подходов? Для совмещения «писательского» подхода к документированию требований с «инженерным» необходимо явным образом включить в стандарт понятие требования. В действующем стандарте этого не сделано, а представления о требованиях носят интуитивный характер. В обновленном стандарте следует привести определение требования и перечислить наиболее важные свойства требований. Автор представляет себе основной набор таких «метатребований» следующим образом.

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

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

Ниже приведен пример преобразования атомарных требований в группу требований, объединенных общим предметом.

В целом обновленный ГОСТ 34.602 должен определять предпочтительные способы изложения атомарных требований и их соединения в связный текст.

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

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

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