Этапы создания технического задания. Техническое задание

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс , найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

ГОСТ 34
ГОСТ 19
IEEE STD 830-1998
ISO/IEC/ IEEE 29148-2011
RUP
SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

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

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” - это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 - IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:

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

Согласно стандарту техническое задание должно включать следующие разделы:

1. Введение

• 1. Назначение
• 2. Область действия
• 3. Определения, акронимы и сокращения
• 4. Ссылки
• 5. Краткий обзор

2. Общее описание

• 1. Взаимодействие продукта (с другими продуктами и компонентами)
• 2. Функции продукта (краткое описание)
• 3. Характеристики пользователя
• 4. Ограничения
• 5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)

• 1. Требования к внешним интерфейсам
  • 1. Интерфейсы пользователя
  • 2. Интерфейсы аппаратного обеспечения
  • 3. Интерфейсы программного обеспечения
  • 4. Интерфейсы взаимодействия
• 2. Функциональные требования
• 3. Требования к производительности
• 4. Проектные ограничения (и ссылки на стандарты)
• 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
• 6. Другие требования

4. Приложения
5. Алфавитный указатель

На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который . , правда, на англ. языке.

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

• Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях .
• Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований .
• Правила составления Software requirements specification (читать вместе с комментариями)
• Примеры ТЗ и другой документации по разработке АС для МЭР
• ГОСТ-овский стиль управления . Статья Gaperton по правильной работе с ТЗ по ГОСТ
• Шаблоны документов для бизнес-аналитиков из

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

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

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

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

• разработке приложений;
• проектировании дома;
• написании текстов и другие.

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

Как составить техническое задание: структура ТЗ на сайт

Прежде чем приступать к работе:

• Определитесь, кто будет составлять техническое задание
• Разъясните термины
• Откажитесь от субъективных терминов

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

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

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

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

Опишите сайт

Расскажите, какой тип сайта нужен, кем он будет использоваться, для чего он вообще создается. Например, напишите, что вам нужен интернет-магазин, лендинг для продажи товара или сайт-визитка с 10 страницами. Укажите ориентировочное количество страниц, если не знаете точного числа.

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

Расскажите о структуре

Без представления о структуре невозможно разработать нормальный сайт. Распишите, какие страницы будут на сайте, и покажите уровни их вложенности. Сделать это можно разными способами:

• Схемой
• Таблицей
• Списком

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

Пример простейшей структуры в виде блок-схемы

Опишите, что будет на каждой из страниц

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

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

Пример прототипа главной страницы сайта: все просто, удобно, понятно

Выдвините требования к дизайну

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

• Укажите, какие корпоративные цвета можно использовать в дизайне, а какие оттенки - категорически нет
• Предоставьте логотип, который обязательно должен присутствовать в шапке сайта
• Укажите шрифты, которые желательно использовать для оформления страниц, меню, футера, контента

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

Опишите требования к инструментам, коду, хостингу, домену

Это нужно, чтобы заранее знать, с какими инструментами можно работать, а с какими - нет. Опишите отдельным блоком:

• На какой должен находиться сайт - Вордпресс, Джумла, Модэкс и так далее
• Какой язык программирования можно использовать - PHP, JavaScript, HTML, другие
• На каком хостинге и в какой доменной зоне должен располагаться сайт, какое доменное имя можно использовать
• Какую программную платформу можно использовать - .NET, OpenGL, DirectX
• И так далее

Если клиент не понимает ничего в используемых терминах - объясните, чем отличается Вордпресс от Модэкса, PHP от HTML, домен в зоне.ru от домена в зоне.com. Вместе составьте требования так, чтобы они устроили клиента.

Уточните требования к работе сайта

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

• Приемлемую для вас скорость загрузки сайтов или стандартное значение - 1–5 секунд
• Кроссбраузерность - распишите, в каких браузерах сайт должен открываться
• Адаптивность - укажите размеры экранов, под которые должен подстраиваться дизайн, и используемые устройства
• Устойчивость к нагрузкам - сколько человек должно находиться на сайте одновременно, чтобы он не «лег»
• Устойчивость к хакерским и dDos-атакам: сайт должен выдержать небольшие атаки

Распишите сценарии работы сайта

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

Пример простейшего сценария работы сайта

Уточните, кто занимается контентом.

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

• - не меньше 95% по Адвего, Текст.ру, Контент.Вотч
• Тошноте (заспамленности)- не более 10% по Адвего иди 65% по Текст.ру
• Баллам по Главреду - не менее 6,5 или 7 баллов

Конечно, разные сервисы - не панацея, но они минимизируют риск того, что он будет «водянистым» или переспамленным. Кроме того, так появляются точные критерии оценки качества текстов.

Укажите сроки

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

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

Запомните: в каждом ТЗ должны быть несколько основных блоков:

• Цели и задачи - о том, для чего вообще вы создали ТЗ, что хотите сделать с продуктом
• Каким должен быть продукт - описание в общих чертах
• Технические требования - площадь дома, объем текста, функционал приложения и так далее
• Сроки - они важны, чтобы исключить споры.

Пример составления ТЗ на программное обеспечение

Нужно создать ПО. Технические требования - ниже.

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

Что должно делать ПО: после ввода ключевого слова находит статьи на сайтах, которые внесены заранее в качестве авторитетных источников, выводит список совпадений в таком формате:

• Линк
• Название статьи
• Лид-абзац

Если больше 10 совпадений, нужно разделить на страницы - по 10 на каждой.

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

Сроки : до 15.09.2018.

Естественно, это ТЗ можно улучшить - мы предоставили его в качестве примера. А как вы считаете, как можно доработать техническое задание, чтобы оно стало еще понятнее, проще, удобнее?

Понятие ТЗ

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

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

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

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

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

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

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

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

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

• Техническое задание (по ГОСТ 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): Документ, используемый заказчиком в качестве средства для описания и определения задач, выполняемых при реализации договора.

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

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

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

По своему объему ТЗ может быть достаточно большим документом. Web-компании часто предлагают помощь по составлению ТЗ отдельной услугой, как правило 10-20% от стоимости всей разработки сайта.

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

Чем детализированнее ТЗ (в разумных пределах конечно), тем лучше для обеих сторон — как для клиента, так и для исполнителя работы. В выигрыше так сказать оба:
— клиент будет уверен, что все задуманное им в проекте четко прописано и должно быть реализовано в соответствии с ТЗ.
— исполнитель – застрахован от множества мелких или крупных корректировок и доработок, опять же опираясь на то самое ТЗ.

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

• Простая истина — чем сложнее проект, тем детализирование должно быть ТЗ.
• Среди возможных вариантов можно назвать ТЗ, описывающее главные страницы интерфейса со всей совокупностью элементов на ней и описанием их поведения. Или же это может быть лаконичное описание нескольких страниц для сайта-визитки и т.п.
• В ТЗ для программиста не должен упоминаться дизайн элементов или звучать пожелания по дизайну. Задание все-таки для программиста..
• Описания задач в отдельных частях ТЗ должны быть граничными. Что это значит? Нужно четко обозначать конец конкретного пункта задания. В ТЗ не должно быть абстрактных фраз типа «должна быть удобная навигация». Это все субъективные признаки – одним удобно, другим не удобно и понять выполнен ли данный пункт бывает сложно из-за нечеткости положений ТЗ. Т. е. это необходимо контролировать.
• Для несложных сайтов, где нужно описать какой-нибудь функциональный модуль, чтобы заново не изобретать велосипед, нужно проанализировать сайты с похожим функционалом, так сказать, провести анализ конкурентов; сохранить гиперссылки на страницы с требуемыми элементами интерфейса и функциями, и включить их в ТЗ с расширенными пояснениями о том, что именно делать. Также необходимо в обязательном порядке снять скриншоты с нужных страниц на случай, если сайт через время будет не доступен. При этом можно ставить свои пометки на изображениях (благо средств сейчас много для этого — Clip2net, Joxi, Awesome Screenshot и прочие).
• Если дизайна для страниц нету или он не так важен в рамках какого-то проекта, скажем, заказчик решил сэкономить на дизайне админ-панели сайта, в этом случае программист вполне может использовать прототипы.

Справка

Прототип — это графическая схема размещения элементов интерфейса. Грубо говоря, нарисованная в специальной программе страница со всеми элементами.

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

Из популярных можно выделить:
— среди бесплатных: iPlotz, MockFlow, Mockup Builder, Cacoo;
— среди платных: Creately, ProtoShare, Adobe Fireworks,Axure . Возможностей в общем много - выбирай, осваивай, рисуй…

Общая структура ТЗ. От абстракции к конкретике

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

1. Общая информация о сайте.
2. Функциональное назначение сайта.
3. Понятия и термины
4. Описание модулей сайта
5. Функциональные характеристики
6. Описание страниц.
7. Резервирование и надежность.
8. Хостинг для сайта.

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

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

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

4. Описание модулей сайта
Этот раздел включает список модулей, которые используются на сайте. Это вполне например может быть упоминаемая выше форма обратной связи (ФОС). Но, что очень важно — нельзя просто писать «Должна присутствовать ФОС». Каждая сущность требует определения своих атрибутов! В данном случае атрибуты могут быть такими:

• Поле «Ваш имя»;
• Поле «Ваш е-mail»;
• Поле «Ваш вопрос»;
• Поле ввода капчи для защиты от спам-роботов.

И все это должно быть четко прописано, что бы потом не возникло вопросов: «…а где перечень выбора категории вопроса? » или что-то в этом роде.

5. Функциональные характеристики
Сюда можно отнести, например, список браузеров, где сайт должен корректно отображаться и работать. Например, некоторые заказчики могут требовать, что бы их сайт работал корректно и в небезызвестном Internet Explorer 6, что бы не терять хоть и небольшую, но долю возможных посетителей.
Если планируется делать высоконагруженный сайт – это тоже нужно указывать. Высоконагруженный сайт требует другого подхода при разработке и по настройке сервера.

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

6. Описание страниц сайта
Это довольно обширный пункт, где прорисовуются все страницы сайта и пишутся комментарии к их работе.
Также может приводиться общая структура страниц сайта. Так называемые «высокоуровневые» прототипы. Например, для простого сайта-каталога это может быть:

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

Остальные страницы

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

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

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

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

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

Удачных Вам проектов и человеческого взаимопонимания!

Одно из главных условий успешной закупки - правильно составленное техническое задание.

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

Оно несет пользу для обеих сторон.

Заказчику это поможет подробно описать объект закупки и приобрести именно те товары (работы, услуги), которые нужны.

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

Кто составляет

Техническое задание составляют сотрудники контрактной службы или контрактный управляющий в составе документации о закупке (п. 3 ч. 4 ст. 38 Федерального закона от 5 апреля 2013 г. № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд», далее - Закон № 44-ФЗ).

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

Как составить (форма и структура)

Техническое задание нужно составить отдельно для каждой конкретной закупки. Сделать это можно в произвольной форме .

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

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

Совет: Когда составляете техническое задание, имеет смысл руководствоваться:

• ГОСТами. Например, при создании автоматизированной системы - ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»;

• методическими указаниями (рекомендациями) учредителя. Например, Минкультуры России разработало Методические указания по порядку разработки технического задания при проведении закупок в рамках целевой программы «Культура России (2012-2018 годы)» (письмо Минкультуры России от 25 января 2013 г. № 446-01-56/10-НМ).

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

1. Общая информация о заказчике

В этом разделе стоит указать такие данные заказчика:

• наименование;

• место нахождения заказчика;

• график работы.

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

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

2. Общая информация о закупке

Здесь стоит указать:

• полное наименование объекта закупки,

• выбранный способ определения поставщика (подрядчика, исполнителя),

• источник финансирования.

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

Термины и сокращения

Определение

ПО

При этом заказчику при описании технических и качественных характеристик необходимо использовать стандартные показатели (требования, условные обозначения и терминологию). Для этого нужно руководствоваться обязательными требованиями, в частности, ГОСТами, СНиПами, гражданским законодательством (ст. 469, 721 ГК РФ). Например, требования к качеству пищевых продуктов установлены в Федеральном законе от 2 января 2000 г. № 29-ФЗ.