Как написать ТЗ, часть 2: еще раз про стандарты, представление требований и UML

автор
Как написать ТЗ, часть 2: еще раз про стандарты, представление требований и UML

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

Agile по-разгильдяйски или зачем нам ТЗ?

Российские ГОСТы по разработке ТЗ (34.602-89 и 19.201-78), а также зарубежные стандарты спецификации требований к ПО (ISO IEEE 29148-2018 и IEEE 830-1998), которые мы разбирали здесь – отличные шаблоны для составления технического задания, знать которые должен каждый аналитик. Однако, содержание любого предмета важнее его формы, поэтому давайте абстрагируемся от строгих рекомендаций и вспомним, зачем вообще нужно ТЗ и как его написать с максимальной пользой. Для этого ответим на 3 простых вопроса:

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

Хотя ответ на первый вопрос может с первого взгляда казаться очевидным, все не так просто. К сожалению, на практике часто бывает, что ТЗ на продукт разрабатывается уже ПОСЛЕ его реализации в каком-то виде и нужно только в качестве обязательной части комплекта проектной документации, чтобы Заказчик и Исполнитель подписали договоры и акты выполненных работ. Другой вариант этого нежелательного кейса – так называемое «ТЗ для галочки», когда структура технического задания на разработку АС/ПО/ИС полностью соответствует стандарту, например, ГОСТ 34.602-89 или 19.201-78, но содержание написано общими фразами и не содержит полного набора функциональных и нефункциональных требований к будущему продукту.

В обоих случаях команда реализации рискует сорвать сроки и/или поставить результат, не соответствующий ожиданиям Заказчика. Поэтому важна не форма представления ТЗ, а полнота его содержания, обеспечивающая возможность создать работающий продукт, решающий проблемы бизнеса. Но не стоит ожидать от бизнеса четкого формулирования его пожеланий в виде готовых требований к продукту и тем более, документированного ТЗ. Определение требований и написание технического задания – это работа профессионального аналитика, которая требует определенных знаний и навыков, а также занимает массу времени. Поэтому опытный разработчик первым делом спрашивает у Заказчика ТЗ и не поддается провокациям типа: «У нас все по Agile, сейчас я на словах быстренько расскажу, что нужно». Однако, ТЗ необходимо не только для разработчика и Заказчика, этот документ читают и другие участники команды, о чем мы поговорим далее.

Для кого аналитик пишет техническое задание?

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

  • Заказчик – стейкхолдеры со стороны бизнеса, проблемы которого должен решить продукт с помощью его функциональных возможностей в заданных условиях его использования;
  • Разработчик – к этой роли можно отнести как непосредственно программиста, пишущего программный код, так и архитектора ИТ-решения, а также тим/техлида и DevOps-инженера, т.е. всех непосредственных участников процесса реализации заявленных в ТЗ требований;
  • Тестировщик – который проверяет, что результат соответствует заявленным ожиданиям, трассируя требования в набор тестов;
  • Руководитель проекта – отвечая за бюджет и сроки поставки продукта, project manager должен понимать объем работы, который следует из контекста и набора требований к создаваемому продукту.

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

Можно ли написать ТЗ не по стандартам?

Как уже было отмечено, все российские и международные стандарты по разработке ТЗ и спецификации требований – это всего лишь шаблоны для создания документа «техническое задание». Поэтому, если вы не работает с госзаказчиками и нет необходимости четко следовать структуре и содержанию этих ГОСТ’ов, а ТЗ нужно для единого понимания требований к продукту у бизнеса и исполнителей, можно разработать этот документ самостоятельно. Например, я предлагаю вам следующую рабочую структуру ТЗ на основе SRS по ISO IEEE 29148-2018, исключив некоторые пункты, предписываемые стандартом. Курсивом отмечены мои комментарии по включению в данный документ иллюстраций в виде UML-диаграмм и экранных форм.

  • Введение
    • Краткое описание – зачем и кому нужен продукт, какие бизнес-задачи и проблемы он решает, т.е. каковы бизнес-требования с плановыми целями и показателями их достижения
    • Термины и сокращения
    • Категории и характеристики пользователей и их потребности относительно продукта, т.е. требования стейкхолдеров, которые можно наглядно показать в виде UML-диаграммы use case
    • Ограничения, бизнес-правила и стандарты
  • Функциональные требования
    • Функциональные требования – по каждому требованию:
      • Название и кодировка
      • Приоритет и трассировка с другими требованиями и/или бизнес-правилами
      • Детальное представление в виде вариантов (сценариев) использования, так называемых юз-кейсов (use case) с возможными иллюстрациями основных и альтернативных потоков, например, в виде UML-диаграммы деятельности, BPMN или EPC-схемы бизнес-процесса. Также здесь можно показать экранные формы, доступные для актора в данном варианте использования.
      • форматы и объем входных и выходных данных (результатов выполнения функции) – может входить в пункт Результат в описании вариантов использования
    • Системные (архитектурные) требования
      • Доменные сущности и связи между ними, что можно показать в виде UML-диаграммы классов или ER-схемы, описывающей таблицы базы данных
      • Среда развертывания (программное и аппаратное обеспечение, например, операционная система ПК или мобильного телефона) – можно показать с помощью UML-диаграммы развертывания и компонентов
      • Внешние компоненты (СУБД, браузер, сетевые подключения и пр.)
      • Программные интерфейсы
      • Интерфейсы оборудования
      • Интерфейсы связи и коммуникации
    • Нефункциональные требования
      • Производительность
      • Надежность и доступность
      • Информационная безопасность и сохранность данных
      • Удобство использования (пользовательские интерфейсы)
    • Прочие требования
      • К интеллектуальной собственности (патентная чистота)
      • Требования к документации

Предложенную структуру можно дополнять и изменять по своему усмотрению. Например, включить в состав нефункциональных требований некоторые характеристики качества ПО, регламентированные стандартом ГОСТ Р ИСО/МЭК 25010-2015 «Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов» (ISO/IEC 25010:2011). О том, что такое нефункциональные требования и чем, например, надежность отличается от доступности, а также как измерить удобство пользовательского интерфейса, мы поговорим в следующий раз, а сейчас предлагаем вам пройти открытый интерактивный тест на проверку знаний о стандартах и требованиях.

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

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

 

Комментировать