Стандарты и шаблоны для ТЗ на разработку ПО
Введение
Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…
И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или 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
Описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и приводится несколько шаблонов SRS. Данная рекомендуемая методика имеет своей целью установление требований к разрабатываемому программному обеспечению, но также может применяться, чтобы помочь в выборе собственных и коммерческих программных изделий.
Согласно стандарту техническое задание должно включать следующие разделы:
На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который легко найти в Интернете. Как и примеры, правда, на англ. языке.
Мне же больше нравится адаптированный шаблон Карла Вигерса, который я использую при разработки ТЗ для коммерческих компаний. И вообще дедушка Вигерс предоставляет множество полезных рекомендаций по работе с требованиями (куда идут деньги при покупке этих рекомендаций, читайте в начале красным). Ну а его книжку вы уже несколько раз, надеюсь, перечитали.
ISO/IEC/ IEEE 29148-2011
Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.
Данный стандарт содержит два шаблона спецификации требований:
• System requirements specification (SyRS)
• Software requirements specification (SRS)
System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека. Она определяет высокоуровневые требования к системе с точки зрения предметной области, а также информацию об общей цели системы, ее целевой среде и ограничениях, допущениях и нефункциональных требованиях. Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 34.
SyRS может содержать следующие разделы:
3. Системные требования
SRS может содержать следующие разделы:
3. Детальные требования
Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.
Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:
• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт.
• Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):
SWEBOK, BABOK и пр.
SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.
Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.
А как же Agile?
Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.
Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.
Заключение
Как говорится, каждому проекту свое техническое задание. При правильном использовании любого из вышеперечисленных стандартов можно брать эти шаблоны для написания ТЗ, естественно адаптируя их под себя.
Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.
Ну а кто дочитал до конца — тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).
Также рекомендую ознакомиться со следующими материалами:
Как составить ТЗ для программиста
Бывает, что сайт уже готов, но нужно добавить на него какую-нибудь программу:
Или вы хотите создать какой-то уникальный сервис для пользователей.
В таких случая не всегда получается воспользоваться готовыми решениями и приходится нанимать программиста.
Составление вакансии и ТЗ для программиста
Чтобы оставить объявление о поиске программиста-фрилансера, нужно сузить круг поиска. Для этого пишется объявление такого вида:
Требуется программист, чтобы добавить функцию X на готовый сайт на WordPress.
Из объявления фрилансер понимает, что от него требуется и сможет ли он это сделать. Но из него не ясно, какие плагины или наработки уже используются, поэтому нельзя сразу выявить уязвимости.
Когда вы определитесь с выбором исполнителя и обговорите все важные моменты, можно отправлять ТЗ. В нем должно быть:
Первые три пункта стандартны для любого договора подряда, а вот последние три можно разобрать подробно.
Желаемый результат
Чтобы при принятии готовой программы не было разногласий, лучше подробно описать, что вы хотите получить.
Допустим, вам нужен сервис проверки орфографии. Опишите все ваши представления:
Такая скрупулезность может показаться муторной или даже излишней, но она обезопасит и вас и программиста.
Техническая информация
Вы должны предоставить техническую информацию, которая необходима для выполнения этой конкретной программы, но не более. Это легко, если ваш сайт создан на каком-нибудь распространенном движке – вы просто указываете название движка и плагины, с которыми должна взаимодействовать новая программа.
С самописными сайтами или движками сложнее. Тут вы можете либо не давать вообще никакой информации, кроме языка, чтобы программист составил только саму программу. А вы потом самостоятельно добавите ее на сайт, если разбираетесь в вопросе, но это чревато тем, что результат будет криво работать.
Идентификация сетевых ресурсов является важным подготовительным этапом перед осуществлением взлома. Если хакер знает, что ваш корпоративный портал работает под управлением IIS 7 под управлением Windows Server 2008, то ему необходимо найти уязвимости, которым подвержены данные программные продукты. Для этого проще всего поискать в базах уязвимостей. В случае если найти ничего не удалось, то особо продвинутый взломщик может попытаться самостоятельно найти «лазейку», собрав у себя точную копию взламываемой системы и попытавшись самостоятельно проанализировать код. «Информационная безопасность: защита и нападение», Бирюков А. А.
Если хотите, чтобы новый сервис сразу был добавлен на сайт, можете указать данные об используемых файлах, базе данных, языке, библиотеках и названиях функций. Вот пример:
Программа должна отображаться на странице page.php, а исполнительный файл в файле core.php. Взаимодействие между файлами с помощью ajax. Все обработанные данные нужно записывать в таблицу data_table (My_SQL) со столбцами id, name и url.
Нельзя создавать функции и переменные с названиями: generate, crop и analyze. Иначе возможен конфликт.
Стандарты оформления кода
Разные люди по-разному пишут. Хороший пример – наш блог. В нем несколько авторов, у каждого из которых свой стиль. То же самое и с программистами.
Я спросил Ольгу Безматерных, руководителя отдела продаж «Текстерры», что она думает по поводу работы с чужим кодом. Она ответила, что он замедляет выполнение задач, а один раз в ее практике был случай, когда работать с кодом было невозможно – пришлось вернуть деньги.
Поэтому если над проектом работает несколько человек, нужно составить стандарты оформления кода – что-то вроде редполитики для программистов.
Поэтому, чтобы потом эту программу легко мог исправить любой другой программист, нужно чтобы у нее был какой-то стандартизированный вид. Доверить составление стандартов можно первому программисту, с которым вы работали.
Подключение и тестирование
Перед подключением программы лучше проверить код на наличие лазеек – предумышленных или нет. Если их нет, можно подключать. Дальше идет тестирование и открытие доступа для всех пользователей.
Заключение
Составление технического задания для программистов должно быть предельно точным. Это не тот случай, когда можно надеяться на взаимопонимание. Также лучше продумать все с самого начала, потому что постоянные изменения вектора не только не ускоряют путь к цели, но и делают его дороже.
В Google и «Яндексе», соцсетях, рассылках, на видеоплатформах, у блогеров
Как грамотно составить ТЗ программисту на доработку сайта?
Что такое техническое задание (ТЗ)?
Техническим заданием называется служебный документ с описанием правил выполнения работы и требований к исполнителю.
Почему важно зафиксировать весь процесс работы в виде технической документации?
Если одна из сторон хочет сотрудничать без техзадания
Это может означать следующее:
Заказчик не устанавливает четких требований специально, чтобы затем получить часть работ бесплатно, либо он не уверен/не знает/не решил/не понимает, что ему надо.
Разработчик надеется на постоянное продолжение работ за счет заказчика, аргументируя это некой неопределенностью.
В такой ситуации противоположная сторона должна обязательно настоять на создании технического задания с четкими границами и определением задач. Без этого сторонам будет трудно доказать, что работы были сделаны, или, наоборот, не сделаны должным образом.
Участники проекта
| Заказчик | Менеджер проекта | Разработчики |
|---|---|---|
| Ставит задачу | Ставит задачу разработчикам | Выполняют задание в соответствии с ТЗ |
| Согласовывает ТЗ | Контролирует ход работы и расставляет приоритеты | |
| Принимает работу | Осуществляет взаимодействие с заказчиком и разработчиком | |
| Тестирует выполненную работу (если нет тестировщиков) |
Если проект большой, дополнительно могут добавиться участники:
Если проект маленький, то заказчик и исполнитель, как правило, работают напрямую. В этом случае тестирование берёт на себя заказчик, а разработчик сам контролирует сроки и ставит приоритеты.
Что дает сторонам каждый раздел ТЗ:
Раздел ТЗ
+ Для Заказчика
+ Для Разработчика
Осознание задач, которые решает проект или его доработка
Понимание сути задачи
Представление о том, каким будет готовый продукт
Уверенность в правильном понимании конечного результата
Ориентирование в сроках работ и получения планируемых результатов
Оценка трудозатрат и потребности в ресурсах
Определение более-менее точной суммы затрат и планирование бюджета
Согласованный учет всех работ проекта
Подробное описание работ и каждого этапа реализации проекта
Ведение работ по установленной технологии. Возможность отказаться от работ, не предусмотренных заданием, либо включить их в ТЗ за доплату
Оценка результата работ
Проверка работы проекта по программе тестирования на соответствие требованиям задания
Возможность удостовериться в бесперебойной работе проекта и в его соответствии требованиям ТЗ
Планирование затрат на обслуживание и представление о дальнейшей поддержке проекта
Выполнение работ с учетом обслуживания проекта в перспективе
Планируемые доработки проекта
Доработка в соответствии с новыми потребностями
Последствия составления некачественного задания
Программист или команда разработчиков действуют «вслепую», несогласованно, не имея четкого представления о конечном результате проекта. Итогом будут зря потраченные время и деньги, испорченные отношения с заказчиком.
Результат проекта не соответствует ожиданиям заказчика. Потребуется дополнительный бюджет и время на доработки.
Обычно разработке качественного ТЗ мешают следующие моменты:
Заказчик не готов платить до 40% от стоимости проекта только за разработку задания. Например, можно еще до начала проектирования написать все тест-кейсы и заложить в ТЗ. Но в этом случае стоимость задания с тест-кейсами может превысить стоимость разработки, а его составление займет не один месяц. Зато это полностью снимает вопрос с ошибками в работе и упрощает приёмку.
Заказчик не знает всех деталей проекта до начала эксплуатации уже готового результата.
Исполнитель не готов без должной оплаты тратить больше ресурсов на разработку ТЗ.
Исполнитель и заказчик не могут предвидеть заранее все возможные проблемы. Опытные участники проекта с обоих сторон могут заранее предусмотреть ряд типовых и уникальных проблем, но это не гарантирует, что вся работа над проектом пройдет гладко.
Например, забыли прописать в техзадании наличие одной кнопки, а после сдачи проекта оказалось, что без неё полноценно пользоваться системой нельзя. Для добавления же кнопки требуется переделать половину внутренней архитектуры базы данных, а значит и часть программного кода переписывать. Кто из сторон виноват в этой ситуации?
Стороны должны понимать, что большинство проектов выполняется с большой долей неопределённости, и заранее договариваться, как будут взаимодействовать в случае возникновения проблем.
Техзадание должно отвечать на вопросы:
Основные рекомендации и пояснения по написанию ТЗ
7 типовых ошибок
Пример правильного технического задания на доработку проекта
Задача:
Разместить на сайт www.site.name.ru новую страницу, где будут размещены контакты и фотографии продавцов-консультантов, а также онлайн чат.
Описание:
Если работы выполняются для целей SEO – не забывайте закладывать все необходимые элементы на странице.
Также внизу разместить форму заказа.
PS. Стоимость и сроки исполнения, как правило, указываются отдельно в приложении к договору. Исполнитель выставит стоимость работ, исходя из прописанных в техзадании задач. Чем больше пожеланий – тем больше будет стоимость.
Задачи по SEO без недопонимания: как правильно составить ТЗ для программиста
В рамках SEO-продвижения иногда необходимо добавить на сайт какой-либо функционал, который ранее отсутствовал. Например, разработать онлайн-калькулятор, продумать программу рассылки, сделать страницу благодарности после оформления заказа.
Техническое задание (сокращенно ТЗ) – это документ, в котором подробно описываются конкретные работы, которые должны быть выполнены. Оно пригодится, когда нет готового решения задачи и все нужно продумывать самому. Тогда вам понадобится помощь программиста. И в этом случае как раз необходимо разработать ТЗ для этого специалиста.
Зачем вообще ТЗ
Многие не понимают, зачем вообще нужно тратить время на составление технического задания для программиста, если можно просто объяснить все исполнителю в письме в нескольких предложениях.
К сожалению, не все задачи получится объяснить простыми словами. Иногда программисты просто не понимают, что от них нужно. Либо бывают ситуации, когда исполнитель считает, что все очевидно, выполняет задачу, а потом выясняется, что заказчик хотел другого.
Например, в нашей практике был случай, когда мы сделали форму заказа расчета, а клиент начал возмущаться, что там не было возможности прикрепить файл с неограниченным размером. Для него это было само собой разумеющееся, но для нашего исполнителя подобной задачи не стояло, поэтому вышла такая ситуация.
И вот здесь возникает конфликт, где, по сути, каждый по-своему прав: заказчик не получил то, чего ожидал, исполнитель же сделал все в точности с заказом, а остальные пожелания в стоимость уже не заложены. Решиться этот конфликт может несколькими способами: либо заказчик примет то, что есть, либо программист доделает все бесплатно, либо обе стороны придут к компромиссу. В любом случае будут пострадавшие.
Вот тут как раз и пригодится техническое задание для программиста. Любые более-менее масштабные нетипичные доработки сайта по SEO (для которых нет готового решения) нужно сопровождать ТЗ. Можно сказать, что это просто формальность, но, к сожалению, программисты не экстрасенсы (пока еще) и не всегда четко понимают, что необходимо клиенту. Как раз для этого и составляются четкие задачи, а также оговариваются для них сроки и методы выполнения. В будущем техническое задание поможет решить возможные спорные моменты и избежать недопонимания. Если работать без ТЗ, есть опасение, что вы получите совсем не то, чего ожидаете.
Составление технического задания для программиста – это:
Чем подробнее вы опишите, что необходимо сделать, тем быстрее это сможет выполнить специалист, так как ему не нужно будет тратить время на уточнения
способ понять, что конкретно надо
Главная цель технического задания – убедиться, что клиент и исполнитель правильно поняли друг друга. ТЗ позволяет выразить свои идеи, сделать их понятными для окружающих и получить в итоге именно то, что нужно. С помощью технического задания мы можем упорядочить мысли, правильно поставить задачу и увидеть противоречия на самых ранних этапах.
фиксирование принятых решений
Благодаря ТЗ исполнитель будет застрахован от множества корректировок и доработок. А клиент будет уверен, что все задуманное им и прописанное в ТЗ реализуется. Если после или во время выполнения работ клиент начнет требовать от вас то, что вы изначально не оговаривали и что не прописано в ТЗ – вы всегда сможете сослаться на документ. В таком случае правда на вашей стороне.
Кто должен составлять ТЗ для программиста
Вообще нет разницы, кто будет заниматься составлением технического задания – это можете сделать вы, а может клиент. Главное – после этого показать его специалисту, программисту, чтобы оценить, все ли четко и понятно.
Каким должно быть ТЗ для программиста
Конкретным, а не абстрактным и расплывчатым
Не нужно использовать абстрактные фразы, например «должна быть удобная навигация». Это все субъективные признаки – одним удобно, другим нет, поэтому понять, выполнен ли данный пункт, будет сложно, и в случае спора не удастся установить, кто прав. Рекомендуем обойтись без качественных прилагательных: красивый, приятный, современный. Их нельзя понять однозначно. У каждого свои понятия красоты. Формулируйте свои мысли четко и просто.
Структурированным
Желательно оформлять техническое задание списком, а не сплошным текстом, с использованием пунктов и подпунктов. Можно выделять жирным значимые ключевые фразы, чтобы было удобней находить информацию. Структурированное ТЗ позволит облегчить понимание задачи, как для клиента, так и для программиста.
Полным
Идеальное техническое задание для программиста должно быть подробным и полным, чтобы у него не возникло дополнительных вопросов. Чем точнее и продуманнее ТЗ, тем лучше как для заказчика, так и для исполнителя.
Что должно быть в ТЗ для программиста
Как написать ТЗ для программиста для решения задач по SEO
Разберем, как правильно составить ТЗ для программиста для решения задач по SEO на примере некой ситуации. Следует отметить, что универсальной формы ТЗ на все случаи жизни не существует. Мы предлагаем свое видение, но вы можете дорабатывать техническое задание на свое усмотрение.
Чтобы получить от клиента четкое ТЗ, вы можете задать ему наводящие вопросы, ответы на которые помогут вам понять, что конкретно требуется. Часто клиенты не разбираются в проблеме вообще никак, они только ставят задачу, которую надо решить.
В таком случае ваша цель – предложить клиенту варианты решения задачи, описать какие-то идеи и задать наводящие вопросы. Вам нужно максимально уточнить пожелания клиента. Для этого узнайте как можно больше информации, которая поможет в работе. Не стоит додумывать за клиента даже мелкие детали. Постарайтесь понять, как в итоге заказчик видит вашу работу. Что конкретно он хочет получить? Определите перечень задач, стоящих перед вами как исполнителем.
После того, как получите ответы на все вопросы, можно приступать к составлению ТЗ для программиста. В первую очередь прописываем цель, затем – полное описание решения задачи.
Допустим, клиенту нужно проработать SEO умного фильтра на самописной CMS, чтобы продвигать сайт по низко- и среднечастотным запросам. В цели прописываем: «Необходимо сделать на сайте индексируемый фильтр». В дальнейшем это предложение нужно раскрыть более подробно. Указываем, что конкретно требуется от исполнителя. Например:
Чтобы сделать фильтр индексируемым, необходимо:
Как вы видите, мы подробно расписываем все по пунктам: какие ЧПУ должны быть, необходима ли возможность добавления тегов на сайт; указываем, что страницы нужно добавить в sitemap и т.д.
После составления технического задания для программиста нужно показать его заказчику, чтобы убедиться, что он имел в виду именно то, что вы описали. И только после этого можно отдавать его программисту. В свою очередь, если ему что-то будет непонятно из составленного ТЗ, нужно будет уточнить информацию у клиента.
Вывод
Несомненно, составленное техническое задание для программиста не избавит вас от всех проблем при выполнении задачи, но оно позволит с самого начала оговорить все требования, обойтись без повторных обсуждений и зафиксировать принятые решения. ТЗ избавит вас от ряда проблем и ненужных вопросов. Главное правило при составлении технического задания – знать и понимать задачу, которую ставишь, и расписывать ее более детально, учитывая все возможные нюансы.
В рамках SEO-сопровождения нам часто приходится разрабатывать ТЗ для программистов, чтобы внедрить на сайт какой-нибудь функционал. Если у вас не хватает компетенции, чтобы самостоятельно составить техническое задание – обратитесь к нам, поможем!