Вряд ли для кого-либо из посвященных будет секретом, что техническое задание, ТЗ, редко бывает изложено так, что исполнителю (да и заказчику) сразу становится понятно что делать, как делать и что из всего этого должно получиться. Оговорюсь сразу, что речь идет о ТЗ на проектирование систем в области информационных технологий, впрочем, некоторые описываемые далее принципы будут справедливы и для других областей.
Если не уделить достаточно внимания проработке ТЗ на самой начальной стадии работы над проектом, то вас гарантированно ждут трудности при сдаче работы, а нередко потеря прибыли и безупречной ранее репутации.
Существует множество тяжеловесных систем работы с требованиями, стандартов и методологий, описывающих эту работу. Ну, например, известны методологии PMI - института проектного менеджмента. В таких методологиях подробно расписаны подходы к выявлению требований, их сортировке, выделению приоритетов, противоречий, способов согласования, уточнения и так далее. Однако, как показывает практика, это все настолько громоздко - что использовать не хочется от слова "совсем".
Существуют графические нотации, типа UML или его расширения SysML, которые также позволяют описать систему и требования к ней. Они, вроде как, считаются сейчас устаревшими и популярностью не пользуются. На смену им пришли более современные нотации, которые производят на меня впечатление каких то комиксов с забавными картинками и подходят больше для презентаций, нежели для глубинного понимания.
Мое мнение, что и перегруженная методология и отказ от системных нотаций - это ошибка. Грамотная комбинация схем и подходов, описывающих проектируемую систему и требования к ней, весьма сильно помогает сделать нечто предсказуемое и полезное, ожидаемое Заказчиком с большой буквы "З".
В этой статье я хотел бы рассказать о своем подходе к анализу ТЗ и составлению некоторых полезных схем, позволяющих наглядно представить текстовое изложение требований и их проверок.