В проектной документации довольно часто встречаются различные термины, которые по сути сводятся к описанию функциональных требований и технического задания. Примеры вариаций на эту тему: концептуальный дизайн, функциональное задание, бизнес-техническое задание и т.п. И это очень опасные в первую очередь для аналитика и архитектора «гибриды» из функциональных требований и технического задания. Почему такая гибридизация крайне нежелательна?
Для этого давайте определимся что это за документы, кто их готовит и кто оп ним работает.
Функциональные требования – это документ, который готовит аналитик на основании информации, полученной от потребителя с описанием того как внешне для пользователя будет выглядеть разрабатываемый функционал. При этом документ должен быть согласован с потребителем, т.е. то, что мы написали и нарисовали в этом документе понятно потребителю и это его устраивает. Пишутся функциональные требования обычно в формате: «Форма документа N должна содержать следующие кнопки управления: … Общий вид формы документа N приведен на рисунке A». После того, как функционал разработан именно с этим документом потребитель сверяет полученный результат.
Техническое задание – это документ, который готовит технический архитектор, либо ведущий аналитик для разработчика. В этом документе должно быть техническим языком, понятным разработчику, написано от том как нужно переделать систему для того, чтобы она начала соответствовать функциональным требованиям. И этот документ уже будет написан совсем по-другому, например: «На форме документа N необходимо разместить кнопку командной панели C. Разработать команду кнопки, алгоритм которой будет выполнять перебор строк табличной части К документа N, находить несоответствие сумм в реквизитах X и Z и выводить сообщение пользователю».
А теперь давайте посмотрим чем эти два документа отличаются. Ответ – абсолютно всем. Один написан для потребителя, второй – для разработчика. Один служит фактически договором между потребителем и исполнителем, второй – нарядом на работы для разработчика. Один написан человеческим языком, второй – узкоспециальным. Что будет, если вы попытаетесь согласовать с потребителем техническое задание? Что будет если разработчику дать функциональные требования и предложить выполнить разработку в меру его фантазии? Понятно, что ничего хорошего. Поэтому если Вы аналитик на проекте и менеджмент проекта с целью упростить себе жизнь или сэкономить начинает предлагать все свалить в одну кучу – не соглашайтесь, настаивайте на разделении этих веток документооборота в проекте. Это позволит Вам избежать очень большого количества проблем.