Техническое задание (ТЗ) – важнейший документ, определяющий вид и функциональность будущего проекта. ТЗ позволяет избежать многих конфликтов между заказчиком разработчиком, позволяет лучше спрогнозировать временные и человеческие ресурсы, необходимые для реализации проекта, упрощает и организует сам процесс разработки.
Рассмотрим примерную, базовую структуру документа ТЗ применительно к сфере разработки Web-проектов.
1.Фиксация системных требований. Для веб-ресурса здесь должны быть перечислены и согласованы:
— требования к платформе (серверу), где будет размещен сайт (если используются) – название и версия интерпретатора скриптов сайта (например, PHP 5.x), название и версия СУБД, название, версия, плагины http –сервера, необходимое дисковое пространство (базовое и тенденции к расходу), быстродействие и пропускная способность оборудования и так далее;
— требования к программному обеспечению пользователя/посетителя – поддерживаемые браузеры, расширения браузера (Javascript, Flash, Silverlight, AJAX и т.д.).
Чем детальней и конкретней будут зафиксированы системные требования, тем лучше и тем меньше вероятность возникновения неприятных ситуаций, связанных с внедрением и тестированием проекта у заказчика.
2. Фиксация карты сайта и подсистем сайта. Детальное описание структуры сайта, его разделов, а также функциональность каждого из разделов (подсистем – новостных лент, форумов, галерей, поиска и т.д.) просто необходимо для процесса разработки.
3. Механизмы обеспечения безопасности. В данном пункте должны быть перечислены меры по предотвращению «взлома» проекта – методы управления учетными записями, защиты от инъекций и т.д.
4. Определение интерфейса пользователя. Применительно к веб-сайту – его дизайн, как минимум – базовый макет, в идеале – макеты всех подсистем(разделов) сайты, схемы цветов, шрифтов, стандартных элементов (ссылок, кнопок, таблиц и т.д.).
5. План разработки. Этапы разработки сайта с перечислением прогнозируемой функциональности в разрезе времени.
6. Дальнейшие направления разработки. Строго говоря, данный пункт нельзя считать обязательным, но иногда весьма полезно наметить план функциональности для следующих версий проекта с целью заложить их в структуру текущей версии.
Постовой: Рекомендую книгу Замок крови. Дуглас Брайан.