ООО САТУРС- Два подхода к разработке технического задания
Технологии создания понятных систем
Два подхода к разработке технического задания

 

А.Н. Тимофеев,  к.т.н.,
генеральный директор ООО "САТУРС" 

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

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

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

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

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

 

Рис.1. Схема формирования структуры системы – первый подход.

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

Рис. 2. Схема формирования структуры системы по методологии на базе ГОСТ 34.

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

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

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

В результате совместной работы, итерация за итерацией, должна быть спроектирована система требований к будущей системе. Тогда далее можно перейти к синтезу проектных решений на её основе – вариантов концепции, описывающих работу будущей системы. В них, не вдаваясь в детали реализации, разработчики системы доказывают ЧТО необходимо разработать в соответствии с заданными целями и системой разработанных требований. Именно доказывают, а не показывают. Мотивировано и аргументировано разъясняя заказчику каждый из возможных вариантов решений.

Очень хорошо, если защита концепции сопровождается показом и обсуждением прототипа будущей системы. Прототип – это не программа. На этом этапе лучше иметь макет, сделанный из «подручных» материалов - таких, которые можно «почиркать». Сделанную программу-прототип на этом тапе могут воспринять как некую скороспелку – неудачное, сырое решение исполнителя. Еще могут и попенять: «Эка вы братцы поспешили и понаписали тут всякого». А макеты в виде алгоритмов, функциональных схем, экранных форм на бумаге воспримут как должное и с удовольствием почиркают. Обратная связь от заказчика получиться более глубокой и качественной. И только после того, когда концепция выбрана, согласована и утверждена заказчиком, переходят к этапу разработки ТЗ.

Таким образом, к моменту начала разработки и согласования ТЗ «на руках» всех заинтересованных в создании системы сторон должны быть:

Если это так, то далее можно переходить непосредственно к формированию разработанных материалов в шаблоне ТЗ.

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

Так, очень кратко, обстоит дело с написанием ТЗ по методологии ГОСТ 34. Я не буду утверждать, что это самая лучшая в мире методология пригодная абсолютно во всех случаях. Известно, что самой лучшей методологии нет, да и не будет - иначе прогресс человечества завершится. Методология проектирования систем, заложенная в ГОСТ 34, особенно хороша при проектировании сложных систем. Что же касается её применения с хорошей, качественной системой управления требованиями, то тут даже я могу позавидовать моим сегодняшним студентам, осваивающим все это в совокупности и имеющим возможность делать сложные проекты в разы быстрее. В их время я такой возможности не имел.

Как грамотно разрабатывать ТЗ по методологии ГОСТ 34 мы учим на наших курсах. Приходите.

Любое копирование и публикация материала допускается только с письменного разрешения автора.
Для ссылки на статью правильно использовать:
[Тимофеев 2013] Тимофеев А.Н. Два подхода к разработке технического задания. [электронный ресурс]/А.Н. Тимофеев, 2013. — Режим доступа: http://www.saturs.ru, свободный. — Загл. с экрана