Техническое задание — это исходный документ для разработки любого программного продукта. Оно устанавливает его основное назначение, характеристики и показатели качества.
Поэтому техническое задание в первую очередь должно содержать основные технические требования к разрабатываемому программному продукту и отвечать на вопрос, что он должен делать, как работать и при каких условиях.
Содержание технического задания на разработку программного продукта регламентируется ГОСТами. В настоящее время следование им не является строго обязательным. Но, в тоже время, необходимость корректной формулировки решаемой задачи так или иначе сохранилась.
Это вполне естественно. Любой заказчик желает получить именно то, что ему нужно и за что он заплатил деньги. Аналогично, любой исполнитель желает знать, что именно от него требуется сделать в рамках выполнения работ по тому или иному проекту. Однако заказчик и исполнитель разные люди и суть одной и той же задачи они могут понимать совершенно по-разному.
По этой причине техническое задание лучше всего всё-таки составлять. Тем более, что, как правило, в письменной форме люди чётко формулируют необходимую задачу.
При этом не обязательно оформлять техническое задание по ГОСТу (как уже было сказано выше в настоящее время это не обязательно). Главное ясно описать суть той задачи, которую предстоит решить.
Для этого, при составлении технического задания, необходимо следовать четырём принципа
• Полнота описания.
Решаемая задача должна быть описана настолько подробно, насколько это необходимо для её правильного понимания.
• Точность описания.
Все характеристики и весь функционал должны быть описаны чётко и однозначно, а не подразумеваться в абстрактных и субъективных формулировках. Например, в техническом задании совершенно неуместны такие определения как: «красиво», «быстро», «эстетично», «хорошо» и им подобные;
• Отсутствие разночтений.
Требования, изложенные в техническом задании, не должны допускать разночтений. В противном случае у заказчика и исполнителя может сложиться различное представление о конечном результате разработки;
• Отсутствие противоречий.
Требования, изложенные в техническом задании, не должны противоречить друг другу. Иначе, такое задание будет просто невозможно выполнить.
Ниже приведён перечень того, что должно включать в себя техническое задание.
1. Общие сведения.
- Название программного продукта;
- Вид программного продукта (программа для Windows или Android, сайт, скрипт, модуль, разработка на платформе 1С );
- Основание для разработки (почему решено разрабатывать этот программный продукт);
- Назначение и область применения программного продукта;
- Общая характеристика пользователей для которых разрабатывается программный продукт.
2. Требования к программному продукту.
- Системные требования (например, характеристики компьютера, на котором будет запущенна программа, операционная система, CMS для сайта, версия СУБД для базы данных и т.д.);
- Пользовательские задачи, которые будет решать программный продукт;
- Требования к функционалу;
- Требования к интерфейсу пользователя;
- Подготовленный к вёрстке дизайн-макет в слоях (актуально в первую очередь для web разработки);
- Требования к интерфейсу передачи данных (если требуется передача каких-либо данных средствами программного продукта (например, отправка e-mail пользователю для подтверждения заказа));
- Требования к безопасности;
- Требования к производительности;
- Особые требования (языки программирования, стандартные или сторонние библиотеки, или компоненты, которые необходимо или наоборот не допускается использовать, необходимость использования определённых методов, подходов или технологий, наличие программы установки (инсталлятора) и т.д.);
- Дополнительные материалы (различные графики, схемы, примеры и т.д.).
3. Требования к документации (какая документация по программному продукту должна быть составлена (руководство пользователя, администратора и т.д.)).
4. Стадии и этапы разработки;
5. Порядок контроля и приёмки (включает критерии оценки качества программного продукта);
6. Дополнительная информация (ссылки на источники информации, которая может быть полезной для разработки (документация и т.д.)).
Всё это – минимум, который необходим для того, чтобы правильно понять постановку задачи, а также оценить сложность и объём работ по её выполнению.
Также будет неплохо, если в техническом задании будут присутствовать такие пункты как основание и цели разработки.
Основание разработки позволяет обозначить причины, которые привели к тому, что необходимо создавать новый программный продукт.
Цели разработки призваны формализовать ключевые задачи, которые программный продукт должен решить.
Очень часто путают цели и назначение разработки. На самом деле, это разные вещи.
Назначение разработки, это для чего программа предназначена буквально. Например, «ведение, базы данных поставщиков» – это всего лишь назначение программы, а «повышение эффективности работы отдела закупок» – это уже цель.
Многие нередко забывают и такой важный момент, как передача программы заказчику. То есть, в каком виде и каким образом заказчик должен получить результаты работы.
Кому-то это кажется очевидным. Но, тем не менее, спорные ситуации в данном вопросе не редкость.
Лучше сразу оговорить формат поставки заказчику готовой работы. Будет ли это оптический носитель или флешка с инсталлятором или достаточно разместить файлы где-нибудь на файловом хостинге и переслать заказчику ссылку. Исполнитель обязан привести диск с программой лично или возможна почтовая, или курьерская доставка. И т. д.
Возможно, на первый взгляд у кого-то об всём этом сложится впечатление подхода к работе по аналогии с выпуском «Фитиля» «По всей форме». Только в данном случае лучше вспомнить цитату из Шерлока Холмса — «нет ничего важнее мелочей!».
К сожалению, за рамками этой статьи остаётся немало нюансов. Ведь по сути составление технического задания, это настоящее искусство, которому посвящают книги и которым можно полностью достаточно овладеть лишь с опытом работы. Тем более, каждый проект индивидуален.
Но, основной «каркас» технического задания включает именно те составляющие, что перечислены в этой статье.
Добавить комментарий