Недавно мы рассматривали шаблоны разработки технических заданий на автоматизированные и информационные системы, а также стандарты спецификации требований к ПО. Сегодня поговорим, можно ли практике обойтись без всех этих ГОСТов, как бизнес-аналитику написать ТЗ, понятное для разработчиков, тестировщиков и Заказчика, а также при чем здесь UML с Agile.
Agile по-разгильдяйски или зачем нам ТЗ?
Российские ГОСТы по разработке ТЗ (уже недействующий 34.602-89 и заменивший его с 01.01.2022 ГОСТ 34.602-2020, что мы рассматриваем в новой статье, а также 19.201-78), а также зарубежные стандарты спецификации требований к ПО (ISO IEEE 29148-2018 и IEEE 830-1998), которые мы разбирали здесь – отличные шаблоны для составления технического задания, знать которые должен каждый аналитик. Однако, содержание любого предмета важнее его формы, поэтому давайте абстрагируемся от строгих рекомендаций и вспомним, зачем вообще нужно ТЗ и как его написать с максимальной пользой. Для этого ответим на 3 простых вопроса:
- зачем нужен этот документ;
- кто и для чего будет использовать изложенную в ТЗ информацию;
- есть ли в проекте жесткие правила и ограничения насчет структуры и содержания ТЗ.
Хотя ответ на первый вопрос может с первого взгляда казаться очевидным, все не так просто. К сожалению, на практике часто бывает, что ТЗ на продукт разрабатывается уже ПОСЛЕ его реализации в каком-то виде и нужно только в качестве обязательной части комплекта проектной документации, чтобы Заказчик и Исполнитель подписали договоры и акты выполненных работ. Другой вариант этого нежелательного кейса – так называемое «ТЗ для галочки», когда структура технического задания на разработку АС/ПО/ИС полностью соответствует стандарту, например, ГОСТ 34.602-89 или 19.201-78, но содержание написано общими фразами и не содержит полного набора функциональных и нефункциональных требований к будущему продукту.
В обоих случаях команда реализации рискует сорвать сроки и/или поставить результат, не соответствующий ожиданиям Заказчика. Поэтому важна не форма представления ТЗ, а полнота его содержания, обеспечивающая возможность создать работающий продукт, решающий проблемы бизнеса. Но не стоит ожидать от бизнеса четкого формулирования его пожеланий в виде готовых требований к продукту и тем более, документированного ТЗ. Определение требований и написание технического задания – это работа профессионального аналитика, которая требует определенных знаний и навыков, а также занимает массу времени. Поэтому опытный разработчик первым делом спрашивает у Заказчика ТЗ и не поддается провокациям типа: «У нас все по Agile, сейчас я на словах быстренько расскажу, что нужно». Однако, ТЗ необходимо не только для разработчика и Заказчика, этот документ читают и другие участники команды, о чем мы поговорим далее.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
3 июня, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
Для кого аналитик пишет техническое задание?
Агрегируя набор требований к решению с кратким описанием контекста его практического использования, ТЗ является базисом для Заказчика и команды реализации (разработчиков, тестировщиков, руководителя проекта). Поэтому можно сказать, что аналитик пишет ТЗ для следующих читателей:
- Заказчик – стейкхолдеры со стороны бизнеса, проблемы которого должен решить продукт с помощью его функциональных возможностей в заданных условиях его использования;
- Разработчик – к этой роли можно отнести как непосредственно программиста, пишущего программный код, так и архитектора ИТ-решения, а также тим/техлида и DevOps-инженера, т.е. всех непосредственных участников процесса реализации заявленных в ТЗ требований;
- Тестировщик – который проверяет, что результат соответствует заявленным ожиданиям, трассируя требования в набор тестов;
- Руководитель проекта – отвечая за бюджет и сроки поставки продукта, project manager должен понимать объем работы, который следует из контекста и набора требований к создаваемому продукту.
Несмотря на такой «разношерстный» состав читателей ТЗ, оно создается с единой для всех целью: описать, ЧТО должна делать проектируемая система, а не КАК (каким образом). А описание в ТЗ ограничений, зависимостей, экранных форм, а также доменных сущностей и взаимоотношений позволяет показать это точнее и понятнее. Помните, что техническое задание – это, прежде всего, набор однозначных и проверяемых требований к продукту, а НЕ план проекта, НЕ бизнес-кейс с технико-экономическим обоснованием разработки для инвесторов и НЕ проектное решение (пошаговое руководство для разработчиков).
Можно ли написать ТЗ не по стандартам?
Как уже было отмечено, все российские и международные стандарты по разработке ТЗ и спецификации требований – это всего лишь шаблоны для создания документа «техническое задание». Поэтому, если вы не работает с госзаказчиками и нет необходимости четко следовать структуре и содержанию этих ГОСТ’ов, а ТЗ нужно для единого понимания требований к продукту у бизнеса и исполнителей, можно разработать этот документ самостоятельно. Например, я предлагаю вам следующую рабочую структуру ТЗ на основе SRS по ISO IEEE 29148-2018, исключив некоторые пункты, предписываемые стандартом. Курсивом отмечены мои комментарии по включению в данный документ иллюстраций в виде UML-диаграмм и экранных форм.
- Введение
- Краткое описание — зачем и кому нужен продукт, какие бизнес-задачи и проблемы он решает, т.е. каковы бизнес-требования с плановыми целями и показателями их достижения
- Термины и сокращения
- Категории и характеристики пользователей и их потребности относительно продукта, т.е. требования стейкхолдеров, которые можно наглядно показать в виде UML-диаграммы use case
- Ограничения, бизнес-правила и стандарты
- Функциональные требования
- Функциональные требования – по каждому требованию:
- Название и кодировка
- Приоритет и трассировка с другими требованиями и/или бизнес-правилами
- Детальное представление в виде вариантов (сценариев) использования, так называемых юз-кейсов (use case) с возможными иллюстрациями основных и альтернативных потоков, например, в виде UML-диаграммы деятельности, BPMN или EPC-схемы бизнес-процесса. Также здесь можно показать экранные формы, доступные для актора в данном варианте использования.
- форматы и объем входных и выходных данных (результатов выполнения функции) — может входить в пункт Результат в описании вариантов использования
- Системные (архитектурные) требования
- Доменные сущности и связи между ними, что можно показать в виде UML-диаграммы классов или ER-схемы, описывающей таблицы базы данных
- Среда развертывания (программное и аппаратное обеспечение, например, операционная система ПК или мобильного телефона) — можно показать с помощью UML-диаграммы развертывания и компонентов
- Внешние компоненты (СУБД, браузер, сетевые подключения и пр.)
- Программные интерфейсы
- Интерфейсы оборудования
- Интерфейсы связи и коммуникации
- Нефункциональные требования
- Производительность
- Надежность и доступность
- Информационная безопасность и сохранность данных
- Удобство использования (пользовательские интерфейсы)
- Прочие требования
- К интеллектуальной собственности (патентная чистота)
- Требования к документации
- Функциональные требования – по каждому требованию:
Предложенную структуру можно дополнять и изменять по своему усмотрению. Например, добавить RACI и CRUDL-матрицы или включить в состав нефункциональных требований некоторые характеристики качества ПО, регламентированные стандартом ГОСТ Р ИСО/МЭК 25010-2015 «Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов» (ISO/IEC 25010:2011). О том, что такое нефункциональные требования и чем, например, надежность отличается от доступности, а также как измерить удобство пользовательского интерфейса, мы поговорим в следующий раз, а сейчас предлагаем вам пройти открытый интерактивный тест на проверку знаний о стандартах и требованиях.
Требования и ТЗ: открытый тест по российским и зарубежным стандартам
В заключение отмечу, что наличие у каждого из требований атрибута «приоритет» в ТЗ поможет проранжировать их по относительной важности и гибко управлять бэклогом в лучших Agile-традициях, реализуя в первую очередь самые важные требования. А дополнять ТЗ по мере изменения потребностей бизнеса и роста запросов к продукту можно, выпуская новую версию этого документа или частное техническое задание на отдельные части системы. О том, что такое ЧТЗ и как его составить, смотрите здесь. А про ошибки, которые совершают начинающие системные и бизнес-аналитики при разработке требований и ТЗ чаще всего, читайте в новой статье.
Практически разобраться с видами и формами представления требований, включая их специфицирование в ТЗ, вы сможете на курсе «Разработка ТЗ на информационную систему» в нашей Школе прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве.
