Идеальный процесс создания информационных систем. Техническое задание.

Что такое техническое задание?

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

Функциональные требования

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

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

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

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

Кстати, подробно описывать что откуда берется, какие запросы используются, какие контрольные механизмы присутствуют нужно уже в техническом проекте, а не в техническом задании. Техническое задание – это просто задание заказчика, выраженное техническим языком.

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

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

Нефункциональные требования

Каков состав нефункциональных требований?

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

Например, для подсистемы интеграции с биллингом можно указать, что 10000 документов биллинга (оплата + реализация) должны быть загружены и обработаны в системе не более чем за 2 часа, что бы была возможность их корректировки бухгалтерами в разумное время.

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

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

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

В общем, нефункциональные требования важны не менее, чем функциональные.

Что же еще должно быть в техническом задании?

Структура технического задания.

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

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

Как писать техническое задание?

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

Если заказчик получает готовое техническое задание без единой встречи – это повергает его в ступор. Замечено на практике.

Теперь несколько слов о том как и в какой последовательности должен быть подан материал из все тех же функциональных требований.

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

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

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