ap4 Сообщение 09/12/2009 03:05 Копия темы
Как и шутя и скоро написать хорошее ТЗ Я за последние лет пять написал несколько десятков ТЗ на системы различного размера. Практически по всем написанным ТЗ сделал работу. И могу дать один полезный совет.

Не имеет значения, написано ТЗ по ГОСТ, по IEEE, или в свободной форме. Если у вас с заказчиком установилось взаимное доверие – подробное ТЗ со всеми разделами можно не писать.

Но есть один момент, который неверятно важен как вашему заказчику, так и вам. ТЗ должно позволять ответить на два вопроса. Первый: будет ли система, написанная по этому заданию, удовлетворять чаяниям заказчика? Второй: как вам вместе с вашим заказчиком убедиться в том, что живая, реально разработанная система находится в соответствии с заданием?

На оба вопроса легко ответить одним простым способом: напишите в ТЗ, как вы планируете проверять систему при ее сдаче. Подробно. По шагам. Простым языком. Применяя терминологию заказчика.

Это то, что заказчик может легко понять. Это то, что ему самому потом пригодится – это почти что руководство пользователя по основным действиям в системе. Это то, что позволит вам самому понять – сделали вы работу или еще нет, можно ее уже предъявлять заказчику, или где-то еще надо поработать над ней. И понять – где надо поработать, если еще не готово.

Пример:

Техническое задание на дверной звонок.

Процедура приемки.

В приемке участвуют четыре человека.

Один – взрослый нормального роста. Один – ребенок ростом 1.20. Они будут звонить в дверь.

Еще один – взрослый человек среднего возраста. И один пожилой человек с ослабленным слухом. Они будут внутри квартиры.

Действия:

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

2. Взрослый нажимает кнопку звонка и держит ее непрерывно. В результате в квартире должны раздаваться звонки продолжительностью не меньше двух и не больше трех секунд. Между звонками должна быть пауза продолжительностью от одной до двух секунд. Звонки должны быть слышны обеим людям, находящимся в квартире.

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

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

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

Самое главное – с процедурой приемки заказчик может РАБОТАТЬ. Он может ее ОСОЗНАТЬ. Он может ОЦЕНИТЬ объем процедуры приемки, и сделать косвенные выводы об ОБЪЕМЕ своих требований и СЛОЖНОСТИ получающейся в результате системы.

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

Вот так, очень простыми средствами мы часто достигаем очень хороших результатов. "Кто и шутя и скоро пожелаетъ Пи узнать число – ужъ знает" (c)