Состав и степень проработки технического задания имеет смысл определять в каждом конкретном случае отдельно. Ниже перечислим компоненты, которые необходимо использовать в техническом задании:
Общие положения. Важной частью общих положений является глоссарий, который приводит понимание прикладной области Исполнителя и Заказчика к одному знаменателю. Наличие глоссария важно для проектов со сложным документооборотом или для очень специфических прикладных областей. Отсутствие глоссария может существенно затормозить разработку технического задания, а в некоторых случаях привести к неоправданным трудозатрадам и срыву графика разработки. Был случай, когда отсутствие общей терминологической базы между нашими партнерами и страховой компанией привело к задержке выполнения очередного этапа на месяц и фактически привело к смене менеджера. И только после фиксации глоссария работы были успешно завершены в течение двух недель.
Цели проекта. Важный раздел. Цели должны быть четко сформулированы. Желательно донести в этой части до Исполнителя, за счет чего Вы собираетесь извлекать прибыль, или что конкретно заставит Заказчика почувствовать удовлетворение от результатов проекта. Невозможно написать техническое задание без пробелов или неопределенностей. Исполнитель часто не может обратиться к Заказчику для прояснения того или иного момента технического задания, поэтому он аппелирует к Целям проекта. Кроме того при составлении технического задания Исполнителю легче предлагать решения, потому что он заранее может определить способствует то или иное решение достижению целей проекта.
Функциональные требования. Требования можно разделить на функциональные и не функциональные или специальные. Функциональные требования имеет смысл описывать в виде вариантов использования. Детально с шаблоном варианта использования можно ознакомиться здесь. пример готового варианта использования здесь. При использовании вариантов использования важно помнить два момента: варианты использования оправдывают себя в приложениях с высоким уровнем интерактивности, любой шаблон варианта использования не обеспечивает прозрачности спецификации. Прозрачность и полнота зависит от опыта аналитика. Процесс создания вариантов использования описан здесь Перечислим специальные требования, которые указывают в техническом задании:
Специальные требования: Важно не просто перечислить специальные требования, но и выбрать их формулировку, которая может быть проверена.
Стандарты: Перечислислить стандарты, которым должна удовлетворять система. Это могут быть стандарты возможностей использования (accessibility), например, стандарты серии WAI, удобства использования (usability), например, ISO/TR 16982:2002, а также другие стандарты общего назначения, такие как XHTML1.0, CSS 2.1 и др.
Системные требования: Поддерживаемые операционные системы, требования по памяти.
Требования по отказоустойчивости: Например, журналирование критических ситуаций, возможность восстановления системы после сбоя.
Требования по производительности: Часто формулируют требования к производительности в виде определенного количества одновременно работающих пользователей, либо общего количества пользователей за определенный период времени. Важно отметить, каким именно инструментом \ спосбом будет проводиться тестирование производительности.
Требования по безопасности: В этом разделе фиксируют методы шифрования данных, их передачи и хранения.
Требования к пользовательскому интерфейсу: Описать специфику отображения элементов пользовательского интерфейса.
При формировании требований важно помнить, что не все они так уж и важны для конечного результата с одной стороны, а с другой каждое требование предполагает какие-то усилия по его реализации и проверки соответствия программного продукта этим требованиям, что повышает стоимость продукта. Наш совет: включайте только те специальные требования, которые существенны для достижения Целей проекта.
Допущения и ограничения. Как правило, этот раздел заполняется Исполнителем, однако, Заказчику тоже важно знать о назначении этого раздела. Любая разработка программного обеспечения ведется в некоторых ограничениях. Это позволяет не раздувать стоимость до бесконечности, а также довести проект до логического завершения. В этом разделе перечисляют, как правило, следующие допущения и ограничения: перечисляется функциональность, выходящую за рамки проекта, задачи, выходящие за рамки проекта, технические ограничения, зависимости от внешних условий, которые могут повлиять на принятые обязательства.
Риски. Это факторы, которые могут повлиять на стоимость и сроки исполнения работ. Риски часто описываются в следующем формате: Заголовок, Идентификация риска, Вероятность риска, Стоимость, Порядок действий при возникновении риска. В качестве примера риска можно привести интеграцию системы с программным обеспечением сторонних разработчиков.
Слишком общее техническое задание
Техническое задание должно быть достаточно детализированным! В нашей практике мы однажды столкнулись со следующим случаем. Компания XXX предоставила видение проекта под видом технического задания. Общая идея их задания: краткий план по захвату мира в кратчайшие сроки. Более того, Заказчик пошел дальше - он обратился к различным Исполнителям и получил разброс цен-сроков исполнения от полутора до двух лет разработки. Ознакомившись с такими вопиющими сроками Закзачик изменил бизнес модель своего предприятия, так как ждать два года они были не в состоянии. После консультации с нашими специалистами выяснилось, что все и сразу Заказчику не нужно, а нужен лишь небольшой кусочек, который делается за два человеко-месяца. При этом было потеряно около полутора месяца на работы с некорректным техническим заданием, с недоумевающими Исполнителями, а потом перекраиванием бизнес-плана. Это удивительно, но многие подходят к разработке программного обеспечения как к строительству жилого помещения. Они ожидают, что только после завершения строительства в доме можно жить, только после завершения разработки программным обеспечением можно пользоваться. Однако, это часто не так. Работы не только можно, но и нужно делить на этапы. Цели проекта необходимо структурировать, чтобы в первую очередь достигать цели с наивысшим приоритетом, которые возможно уже позволят извлекать прибыль из проекта, а значит рефинансировать остаток разработки.
Слишком детализированное техническое задание
Техническое задание не должно быть достаточно детализированным! Да-да! Глаза Вам не изменяют. И конечно случай из практики. Компания YYY хотела себе простой сайт, с банальным функционалом. Нашим аналитиком было предложено решение на основе бесплатной системы управления контентом. Дешево и сердито, однако, контактное лицо со стороны компании YYY настаивало на существенной детализации пользовательских интерфейсов в том числе административной части системы. В результате стоимость разработки с нуля этой системы стало меньше стоимости кастомизации системы управления контентом. Заказчик лишил себя в дальнейшем перспектив более дешевого и динамичного развития своей системы в угоду минимизации трудозатрат, связанных с осовением интерфейса незнакомой ему системы управления контентом. Заказчик всегда прав, в конце концов он мог не огласить всех целей проекта, однако, функциональные требования должны оставаться функциональными, если конечно это не приведит к риску не достижения целей проекта.
