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

Как правило, этапу составления технического задания предшествует проведение обследования предметной области, которое завершается созданием аналитического отчета. Именно аналитический отчет (или аналитическая записка) ложится в основу документа Техническое задание.

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

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

Руководствующими стандартами при написании технического задания являются ГОСТ 34.602.89 «Техническое задание на создание автоматизированной системы» и ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению» . Первый стандарт предназначен для разработчиков автоматизированных систем, второй для программных средств (разницу между данными сериями мы обсуждали в статье «Что такое ГОСТ»).

Итак, ниже мы представляем список и описание разделов, которые должно содержать техническое задание согласно ГОСТам.

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

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

• Общие сведения о системе (программе);
• Назначение, цели и задачи системы (программы);
• Требования к системе (функциональные требования, пользовательские требования, требования к системе в целом и тд);
• Требования к видам обеспечения;
• Требования к документированию;
• Стадии и этапы разработки;
• Порядок контроля и приемки системы (программы).

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

Пример:

«В данном документе создаваемая информационная система называется «Единое окно доступа к образовательным ресурсам», сокращенно ЕО.
Систему Единое окно доступа к образовательным ресурсам далее в настоящем документе допускается именовать Единое окно или Система.»

Также сюда следует включить подразделы сообщающие реквизиты организаций участвующих в разработке (Заказчика и Исполнителя).

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

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

Термины и сокращения располагаются в алфавитном порядке. В первую очередь принято давать расшифровку русскоязычным терминам и сокращениям, потом англоязычным.

Назначение и цели создания системы

Данный раздел документа Техническое задание должен содержать назначение и цели создания системы.

Пример:

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

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

Создание информационной системы «Единое окно» должно обеспечить:

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

Создание Системы позволит сократить эксплуатационные затраты в результате повышения эффективности работы ведомства.»

Требования к системе

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

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

Пример:

«4.1 Бизнес-процесс «Предоставление информации об образовательных учреждениях Российской Федерации

В данном бизнес-процессе выделяются следующие участники:

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

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

4.1.1 Регистрация образовательного учреждения в Системе

Регистрация образовательного учреждения Российской Федерации осуществляется ответственным сотрудником учреждения («Постановление Правительства …»).

Процесс регистрации образовательного учреждения включает следующие шаги:

• Автор создает запись об организации;
• Автор заносит данные организации;
• Система проверяет наличие лицензии для данной организации

• Если лицензия существует в базе данных, Система отправляет Автору сообщение об успешной регистрации;
• Если лицензия не найдена в базе данных, Система отправляет сообщение Автору об отсутствии лицензии для данной организации.»

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

Требования к системе в целом включают раскрытие ее архитектуры с описанием всех подсистем. В данной части Технического задания следует описать требования к интеграции системы с другими продуктами (если таковые имеются). Далее в техническое задание должны быть включены:

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

Требованиям к видам обеспечения

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

Требования к документированию

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

Данный раздел технического задания также важен, как и описание функциональных требований, поэтому не следует ограничиваться фразой «Заказчику должна быть предоставлена вся документация согласно ГОСТ 34». Это означает, что вы должны предоставить весь пакет документов включая «Формуляр», «Паспорт» и т.п. Большинство документов из списка, указанного в ГОСТ 34.201-89 не нужны ни вам, ни заказчику, поэтому лучше сразу согласовать список на этапе разработки документа Техническое задание.

Минимальный пакет документов обычно включает:

• Техническое задание;
• Ведомость эскизного (технического) проекта;
• Пояснительная записка к Техническому проекту;
• Описание организации информационной базы;
• Руководство пользователя;
• Руководство администратора;
• Программа и методика испытаний;
• Протокол приемочных испытаний;
• Акт выполненных работ

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

Стадии и этапы разработки

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

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

Порядок контроля и приемки системы

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

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

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

Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р

Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978 г. № 3351 срок введения установлен

с 01.01. 1980 г.

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

Стандарт полностью соответствует СТ СЭВ 1627-79.

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом.

1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78 .

Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.

1.3. Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.

1.4. Техническое задание должно содержать следующие разделы:

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

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

2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

(Измененная редакция, Изм. № 1)

2.2. В разделе «Основания для разработки» должны быть указаны:

• документ (документы), на основании которых ведется разработка;
• организация, утвердившая этот документ, и дата его утверждения;
• наименование и (или) условное обозначение темы разработки.

(Измененная редакция, Изм. № 1)

2.3. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

2.4. Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:

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

(Измененная редакция, Изм. № 1)

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

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

2.4.3. В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.

2.4.4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

2.4.5. В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой.

При необходимости должна обеспечиваться защита информации и программ.

(Измененная редакция, Изм. № 1)

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

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

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

(Введен дополнительно, Изм. № 1).

2.5. В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.

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

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

2.8. В приложениях к техническому заданию, при необходимости, приводят:

• перечень научно-исследовательских и других работ, обосновывающих разработку;
• схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
• другие источники разработки.

Переиздание (Ноябрь 1987 г.) с Изменением № 1, утвержденным в июле 1981 г (ИУС 7-81)

Понятие ТЗ

Техническое задание - исходный документ на проектирование технического объекта. ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования.
Задание как исходный документ на создание чего-то нового существует во всех областях деятельности, различаясь по названию, содержанию, порядку оформления и т. п. (например, проектное задание в строительстве, боевое задание, домашнее задание, договор на литературное произведение и т. д.).

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

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

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

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

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

Место ТЗ в структуре проектирования

Проектирование - это процесс (разработки проекта), который обладает определённой структурой , то есть последовательностью и составом стадий и этапов, совокупностью процедур и привлекаемых технических средств, взаимодействием участников процесса.

Стадии проектирования регламентированы стандартами. Это следующая последовательность:

• Техническое задание (по ГОСТ 2.103-68 к стадиям разработки не относится),
• Эскизный проект,
• Стадии рабочего проекта.

Решение любой задачи начинается с её осмысления и уточнения исходных данных. Те (технические) требования, которые выдаются заказчиком, формулируются на языке потребителя-неспециалиста и не всегда бывают технически четкими и исчерпывающими. Перевести требования на язык предметной области, сформулировать задачу максимально полно и грамотно, обосновать необходимость её решения, это и есть главная цель ТЗ, обязательный этап работы. Исполнитель выполняет его в тесном контакте с заказчиком. Фактически это означает, что работа исполнителя над проектом уже началась.
В машиностроении этот этап иногда называют внешним проектированием .

Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования.

Частные технические задания

В процессе проектирования сложного объекта (системы), требующего участия нескольких разработчиков, создаются частные технические задания на подсистемы .

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

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

По завершении этапа распределения ТЗ разработчики системы и её подсистем приступают к выполнению стадии эскизного проекта. Проработка структуры на этой стадии ведется при тесном взаимодействии всех разработчиков. В процессе такой работы увязываются между собой отдельные части, согласовываются основные параметры проектируемого объекта. Качество проектирования зависит от широты видения разработчиком проблемы, то есть от его кругозора и способности учесть все связи рассматриваемого объекта, и наличия у него знаний, захватывающих смежные области. В процессе эскизного проектирования и согласования частных решений с общим возможна корректировка ТЗ.

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

Необходимость ТЗ

Исходное задание выдаётся заказчиком. Основными причинами, заставляющими его обратиться к разработчику, являются отсутствие у заказчика соответствующих специальных знаний либо ограниченность его ресурсов (нехватка времени на решение задачи, необходимого количества людей, оборудования).

Задание может быть чётко определено, например, когда всю работу ведет один человек, либо оно выдано авторитетным специалистом, либо не может быть подвергнуто сомнению (госзаказ). Но чаще оно формулируется в общих чертах на языке потребителя-неспециалиста, далёким от языка разработчика и терминов предметной области. Неопределенные требования вызывают неуверенность у всех участников работ, так как допускают различное толкование требований и не позволят объективно оценить качество разработанного изделия. Также, разработчик должен понимать, что заказчик может не знать (или знает частично) специальных требований, что не снимает с разработчика ответственности и обязательности выполнения требований надзорных органов независимо от их наличия в задании. Таким образом, не только заказчик, но и разработчик (исполнитель) являются ответственными за постановку целей разработки и полезность ее результата.

Составление ТЗ - сложная и ответственная задача: многие данные ещё не известны, но то, как задание будет поставлено, способно облегчить или затруднить последующее проектирование (образно говоря, «как корабль назовешь, так он и поплывет»).

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

Академик А. Н. Крылов рассказывал. На одной фабрике установили новую машину, но никак не могли её запустить. Тогда обратились за помощью к профессору университета. Приехав на фабрику, он долго ходил вокруг машины, внимательно что-то высматривая и к чему-то прислушиваясь. Затем, взяв молоток, ударил по её корпусу. И машина заработала. За свою помощь профессор запросил у правления фабрики 100 рублей (дело было в начале 20 века). Но правление фабрики посчитало, что за один удар молотком это слишком большая плата. На что профессор ответил, что сам удар стоит один рубль, а вот то, куда ударить - 99 рублей. Замечено, что если стоимость исправления проектной ошибки, допущенной на этапе технического проектирования принять за 1, то стоимость её исправления возрастает приблизительно в 10, 100 и 1000 раз, если ошибка была допущена соответственно на этапах эскизного проектирования, технического предложения и ТЗ!

Как инструмент коммуникации в связке общения заказчик-исполнитель, ТЗ позволяет:

• Обеим сторонам:
  • представить (вообразить) готовый продукт,
  • выполнить попунктную проверку готового продукта (приёмочное тестирование - проведение испытаний ),
  • уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний ).
• Заказчику:
  • осознать, что именно ему нужно,
    • в том числе, опираясь на существующие на данный момент технические возможности и свои ресурсы,
  • требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ.
• Исполнителю:
  • понять суть задачи, показать заказчику «технический облик» будущего изделия, программного продукта или автоматизированной системы,
  • спланировать выполнение проекта и работать по намеченному плану,
  • отказаться от выполнения работ, не указанных в ТЗ.

Регламентированное ТЗ

Несмотря на свою важность, содержание ТЗ мало регламентировано нормативными документами (ГОСТ , ОСТ).

В части выполнения научно-исследовательских работ ТЗ регламентируется следующими документами:

Разделы ТЗ по ГОСТ 34.602-89 (пример)

Для конкретизации целей и требований, заданных нечётко либо качественно, применяют метод декомпозиции.

Стоит отметить, что приведённые в условии данные - это номинальные параметры, но было бы более правильно приводить нормированные значения этих параметров, задаваемые своими предельно-допустимыми значениями (например, масса изделия 9,8…10,1 кг). То есть то, что считают условиями, на практике являются ограничениями в виде двусторонних неравенств. Ширина диапазона является следствием величины допуска на этот параметр.

При формировании системы требований обязателен анализ следующих источников:

• Доступность ресурсов, находящихся в распоряжении заказчика и разработчика: финансовые, производственные, людские, временные. Все ресурсы взаимосвязаны, например, за счет увеличения финансирования проекта можно добиться сокращения периода разработки. Следствием степени доступности является введение ограничений на методы и точность решения проектной задачи, что, в свою очередь, влияет на вид выбираемой модели . Так, при ограниченности времени ведут оценочные расчеты упрощенными методами или используют готовое программное обеспечение, стандартные методики, типовое оборудование, стандартные и покупные детали и узлы и т. д. В то же время модель, метод и точность решения должны обеспечивать исполнение требований ТЗ, даже если они и высоки.
• Учет требований надзорных и лицензионных органов при проектировании, например, технологических комплексов (производств). В соответствии с законами Российской Федерации любое производство требует получения региональной лицензии на эксплуатацию. Помимо этого многие производства лицензируются надзорными органами и подлежат с их стороны контролю. Наиболее часто контролирующими являются региональные органы Ростехнадзора , Росстандарта, Минрегион России (бывш. Госстрой), Роспотребнадзора , Росприроднадзора , ГПС , МВД России , Роструда .
• Жизненная среда проектируемой системы. Она задает требования, характеризующие взаимное влияние спроектированной системы и окружающих её живых и неживых объектов и внешней среды. Основные указания на нее приводятся в технических требованиях в условиях потребления будущей продукции. Эти условия могут быть охарактеризованы достаточно обобщенно и нуждаться в конкретизации.

Составление списка требований ТЗ

Основная статья: Методы проектирования

Работа над ТЗ включает выполнение ряда этапов. А неопределенность, свойственная этой работе, вызывает прохождение их по несколько раз, итерационно, от более общей постановки задачи - к детальной её проработке (проектирование носит итерационный характер и то, что не учтено в начале, может быть учтено на последующих этапах).

Сначала приведем рассказ о том, как Эдисон ставил перед собой техническую задачу.

Прежде, чем приступить к разработке электрического освещения в быту, Эдисон провел исследования, при каких условиях оно выдержит конкуренцию в цене, яркости и удобстве с газовым освещением (рожком). Он до тонкостей изучил газовую промышленность, разработал план центральной электростанции и схему линий электропередач к домам и фабрикам. Затем подсчитал стоимость меди и других материалов, которые потребуются для изготовления ламп и добычи электроэнергии с помощью динамо-машины, движимой паром. Анализ данных определил не только размеры лампы, но и её конкурентоспособную цену, равнявшуюся 40 центам. И лишь когда Эдисон убедился, что сможет решить проблему электрического освещения, он принялся работать над лампой накаливания с угольной нитью, помещенной в стеклянный шар, из которого откачан воздух. В поисках материала нити он опробовал около 6 000 разновидностей растительного волокна.

Анализ задания заказчика

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

Следует выявлять и стараться избегать решения следующих задач:

• задачи, не соответствующие общественным потребностям - криминальные, аморальные, негуманные. Их решение - дело совести разработчика;
• технические псевдозадачи, с ошибочно выдвинутыми целями. Это - задачи, которые уже имеют решение, либо не имеют объективных предпосылок для своего решения (преждевременные задачи, но это нуждается в обосновании, чтобы отказ в решении не был следствием психологической инерции или других субъективных причин);
• химерические задачи. Это - задачи с ошибочно поставленной целью, достижение которой противоречит законам физики (например, создание устройства с КПД более 100 %, устройства мгновенного действия и т. п.), либо абстрактно выдвинутые задачи, принципиально не имеющие решения (типа философского камня).

При составлении ТЗ важно критически, без предрассудков подойти к исходным требованиям. Для этого необходимо:

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

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

Противоречие может быть декомпозировано, то есть представлено в виде элементарных проблем.

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

• либо забыть о его существовании и, отталкиваясь от исходной потребности, предложить возможные варианты с последующим выбором лучшего;
• либо усовершенствовать прообраз, воспользовавшись ИКР;
• либо локализовать потребность. Обычно неудовлетворительная работа связана с несовершенством только некоторых подсистем . С этой целью прообраз декомпозируют по функциональному признаку, а противоречие представляют в виде элементарных проблем. Соотнося элементарные проблемы с определенными подсистемами прообраза, выявляют «несовершенные» подсистемы. Таким образом, от решения общей и сложной задачи переходят к более простой частной задаче. Но степень улучшения свойств может оказаться невысокой, могут возникнуть проблемы по состыковке усовершенствованных подсистем с прежними.

Конкретизация целей проектирования

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

В процессе поиска наиболее полной и точной формулировки строится цепочка функций (дерево целей) - от первоначально предложенной до окончательно принятой. Этому помогает ответ на вопрос «Зачем это нужно?» (и другие вопросы метода контрольных вопросов). В большинстве случаев за приведенной в требованиях целью стоит необходимость выполнения (последовательно или одновременно) нескольких функций. Цепочка функций строится для каждой из них.

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

Обработка собранной информации

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

Абстрагирование предназначено дать такую формулировку требованиям, чтобы избежать предопределения путей решения задачи (не создавать психологических барьеров). Для получения «сильных» решений рекомендуют проводить усиление системы требований и обострение противоречий путем формулирования ИКР.

2. Проверка на противоречивость.
При наличии нескольких функций часть их по своему действию может оказаться противоречивыми (например, вода должна быть горячей (для заварки), но не обжигать руки). Для разрешения противоречий эффективно применение эвристических методов . При этом устранение противоречий возможно как на этапе составления ТЗ (изменение формулировок функций, разнесение их действия во времени или в пространстве и т. д.), так и на последующих этапах проектирования.

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

3. Разграничение требований на условия, ограничения и показатели качества.
Представление требований в виде показателей позволяет получить решения с высокими характеристиками, но такая задача решается сложнее. В качестве показателей выбирают те, которые характеризуют наиболее важные свойства (с целью возможности получения наилучших значений). Для вводимых условий необходимо оценить величину разброса и необходимость указания предельных значений, то есть представления их в виде ограничений.

4. Параметризация.
Точность суждения и верность выбора зависят от степени конкретности исходных требований, представлены ли они в формализованном или неформализованном виде. Для однозначности выводов все требования должны быть переведены в формализованный вид, то есть указаны характеризующие их параметры, причем такие, которые можно измерить, проконтролировать, рассчитать. Это также позволит выделить дублирующие требования (те, которые характеризуются одними и теми же параметрами) и обобщить их (ввести обобщенные параметры с целью сокращения общего их числа, удельные характеристики).

При решении задачи оптимального проектирования рекомендуют показатели качества приводить к критериальному формализованному виду, то есть назначать им численную меру. Основной метод конкретизации формулировок - построение дерева целей (И или ИЛИ-деревья): исходный показатель декомпозируется до выявления элементарных понятий, однозначно характеризуемых наборами параметров.

Проблемами оценки качества посредством количественных показателей занимается наука «Квалиметрия».

5. Усечение списка требований.
Большой объем информации хотя и способен дать максимально полное представление о решаемой задаче, но труднее удерживается в голове, усложняет решение задачи. Для сокращения сведений до разумного объема (под способности каждого конкретного разработчика, соответствие его финансовым, организационно-техническим, временным ресурсам) можно воспользоваться их ранжированием или разделением на группы обязательных к учету, желательных и несущественных. К обязательным относятся те, неудовлетворение которых существенным образом влияет на выбор вариантов решений. Это - функциональные параметры, условия взаимосвязи систем и их частей и другие. Желательные требования позволяют различить варианты по степени качества.

Стоит принимать во внимание слова Ли Якокки : «… беда в том, что ты учился в Гарварде, где тебе вбили в голову, что нельзя предпринимать никаких действий, пока не соберёшь все факты. У тебя 95 % информации, а для того, чтобы собрать недостающие 5 %, тебе понадобится ещё шесть месяцев. За это время все факты устареют, потому что рынок развивается гораздо быстрее. Самое главное в жизни - всё делать вовремя. … главная задача состоит в том, чтобы собрать все важные факты и точки зрения, которые вам доступны. Но в какой-то момент надо начинать действовать решительно. Во-первых, потому, что даже самое правильное решение оказывается неверным, если оно принято слишком поздно. Во-вторых, потому, что в большинстве случаев не существует такой вещи, как полная уверенность. Вам никогда не удастся собрать все 100 % информации. К сожалению, жизнь не будет ждать, пока вы оцените все возможные просчеты и потери. Иногда надо просто двинуться вперед наудачу и исправлять ошибки по ходу движения». - — Тематики электросвязь, основные понятия EN expression of requirements … Справочник технического переводчика

ТЕХНИЧЕСКОЕ ЗАДАНИЕ - (ТЗ) исходный технический документ для проведения различных исследований и проектирования новых (см.) и сооружений. Как правило, в ТЗ указываются этапы проведения работ, разрабатываемая техническая документация, показатели качества и технико… … Большая политехническая энциклопедия

техническое задание - 3.29 техническое задание (statement of work): Документ, используемый заказчиком в качестве средства для описания и определения задач, выполняемых при реализации договора.

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

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

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

Кроме того, есть ряд ГОСТов, например, 19.201-78, в которых прописано, что и в каком виде должно содержаться в подобном документе.

Однако, как показывает практика, под заветной аббревиатурой «ТЗ» понимаются совершенно разные по сути, содержанию, оформлению и детализации документы. К сожалению, многие заказчики уверены, что, написав пару страниц требований к будущей системе, они получат от нас точную (максимум с дельтой в 10-20%) оценку с календарным планом работ. Получая в очередной раз на почту «ТЗ, по которому к завтрашнему дню надо дать оценку и выслать КП», я всегда морально готовлюсь увидеть очередное творение в стиле «система должна обмениваться с сайтом всей необходимой информацией».

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

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

Так как же составить ТЗ, по которому в итоге получится именно то, что было заложено его автором(-ами), а не то, что «умеет типовой функционал конфигурации»?

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

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

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

2. Больше визуализации . Чем больше в документе содержится макетов\скриншотов\мокапов\блок-схем, тем меньше вероятность получить выполняющую вроде бы нужные функции, но обладающую совершенно иной логикой\оформлением\интерфейсом систему

3. Usability. Из двух предыдущих пунктов есть простое следствие – понятная логика работы и максимальная визуализация будущей системы помогут в итоге заложить в ТЗ нужное количество примечаний\пунктов, касающихся удобства использования системы. Для систем, с которыми работают низкоквалифицированные сотрудники, это может стать решающим фактором успешности проекта (впрочем, этот параметр также крайне важен и для топ-менеджмента, не желающего иметь дела с «этими бухгалтерскими программами»). Например, в ТЗ на систему для розничных продаж не указали, что поиск артикула должен занимать не более трех секунд. Если бы систему реализовали через типовой поиск конфигурации, то это могло привести к критическим ситуациям в реальной эксплуатации, т.к. с учетом количества номенклатуры этот поиск занимал до 30 секунд, что недопустимо при работе с розничными покупателями, где каждая секунда на счету.

4. Ссылки на популярные решения . Зачастую, для всех, к примеру, менеджеров по продажам компании, фраза «функционал ведения сделок» означает примерно одно и то же, но для сотрудников подрядчика эта фраза не значит ровным счетом ничего. Но добавьте пару слов в эту фразу, и из варианта «карточка сделки, аналогичная таковой в Битрикс24(или 1С:CRM)» уже понятно, чего примерно ожидает от этой самой карточки Заказчик.

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

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

Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р

Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978 г. № 3351 срок введения установлен

с 01.01. 1980 г.

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

Стандарт полностью соответствует СТ СЭВ 1627-79.

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом.

1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78 .

Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.

1.3. Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.

1.4. Техническое задание должно содержать следующие разделы:

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

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

2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

(Измененная редакция, Изм. № 1)

2.2. В разделе «Основания для разработки» должны быть указаны:

• документ (документы), на основании которых ведется разработка;
• организация, утвердившая этот документ, и дата его утверждения;
• наименование и (или) условное обозначение темы разработки.

(Измененная редакция, Изм. № 1)

2.3. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

2.4. Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:

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

(Измененная редакция, Изм. № 1)

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

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

2.4.3. В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.

2.4.4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

2.4.5. В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой.

При необходимости должна обеспечиваться защита информации и программ.

(Измененная редакция, Изм. № 1)

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

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

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

(Введен дополнительно, Изм. № 1).

2.5. В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.

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

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

2.8. В приложениях к техническому заданию, при необходимости, приводят:

• перечень научно-исследовательских и других работ, обосновывающих разработку;
• схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
• другие источники разработки.

Переиздание (Ноябрь 1987 г.) с Изменением № 1, утвержденным в июле 1981 г (ИУС 7-81)