?

Log in

No account? Create an account

Чт, 19 фев, 2009, 15:26
Консультанту на заметку

Объём любой части техзадания должен быть пропорционален сложности её реализации.

Например, если некоторое требование реализуемо очевидным образом, незачем описывать его на трёх страницах со скриншотами. Но более опасны «подводные камни» — когда одно простое с виду предложение в техзадании может обернуться тысячью-другой строк кода из-за того, что требование не ложится на архитектуру системы. Ошибка в оценке сроков реализации в таком случае практически гарантирована.

Чт, 19 фев, 2009 13:33 (UTC)
zlobny_reader

Это точно о техническом задании, а не о техническом проекте, спецификации, постановке к разработке?
У нас обычно ТЗ содержит функциональные требования в терминах, понятных закачкику. То есть про реализицию там может ничего не быть. Опять же, с использованием разных инструментов, в дальнейшем, реализация можеть быть как очевидной, так и сложной.
Хотя я согласна, что подробно описывать, что 2+2 должно возвращать всегда 4 - не стоит ;-)

Лично меня всегда "радует" желание заказчиков включить в ТЗ "система должна работать в режиме 24x7". На всякий случай, даже если речь идет не о жизненно важной системе.

Чт, 19 фев, 2009 14:26 (UTC)
egorius

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

Чт, 19 фев, 2009 21:16 (UTC)
loveyoupeople

также недопустимо включать в ТЗ или как его там фразы типа: по желанию заказчика в систему будут включены модули синхронизации данных с внешними базами (Блумберг, Шлюмберг, Хэзэнберг,...)

особенно следует избегать многоточий

Пт, 20 фев, 2009 07:43 (UTC)
egorius

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