Этот материал — третья часть гайда для системного аналитика, в котором я рассказываю про управление требованиями на разных этапах жизненного цикла проекта. В предыдущих статьях были описаны фазы инициации, планирования и исполнения. В этой статье мы разберём фазу контроля: продолжим работу над учебным проектом «Общий счёт», рассмотрим инструменты проверки качества требований и детализируем требования, описанные при составлении плана проекта.
Содержание
В отличие от ранее рассмотренных этапов, контролю не свойственны ни последовательность, ни цикличность. Фаза контроля начинается с момента инициации проекта и заканчивается вместе с завершением проекта.
В масштабе проекта основным участником фазы контроля является менеджер или руководитель проекта. Он формулирует и отслеживает контрольные точки, составляет и актуализирует план проекта, решает оперативные проблемы, отслеживает бюджет и сроки. Менеджер контролирует работу с требованиями так же, как и другие этапы работы. Аналитик не может напрямую влиять на все составляющие проектного треугольника , но может контролировать качество требований.
Как понять, что требования достаточно хороши?
Карл Вигерс в своей книге «Разработка требований к программному обеспечению» детально описал «характеристики превосходных требований». К ним относятся полнота, корректность, осуществимость, недвусмысленность, согласованность и другие. Кажется, что идеальные требования должны соответствовать всем этим характеристикам. Но опыт подсказывает, что сколько требования ни переписывай, они всё равно останутся неполными, противоречивыми, изменчивыми. А осуществимость требований зависит не только от их качества, но и от уровня компетенции реализующего их разработчика. Сам Вигерс заканчивает главу о характеристиках превосходных требований следующей фразой: «Как уже говорилось ранее, вы никогда не сможете создать идеальные требования. Но опытный аналитик может практически всегда помочь сделать требования лучше».
Одним из самых распространённых инструментов проверки качества требований является рецензирование — вычитка задокументированных требований участниками команды проекта.
На практике рецензирование обычно сводится к проверке соответствия требований формальным критериям:
соответствие документации шаблонам;
соблюдение нотаций моделирования;
отсутствие орфографических и пунктуационных ошибок;
отсутствие очевидных логических противоречий.
Такую проверку может провести только специалист, который знаком с используемыми шаблонами и нотациями на том же или более высоком уровне, что и автор требований. То есть другой аналитик. Прежде чем начинать искать коллег, обладающих достаточной компетенцией и мотивацией для проверки качества требований, стоит задуматься, а действительно ли соответствие требований формальным критериям может повлиять на качество создаваемого продукта и поможет достичь цели проекта?
Как ни крути, документы с требованиями — это не художественная литература. Аналитик не может использовать креативный стиль и резкие повороты сюжета, чтобы удержать внимание читателя. Поэтому чтение требований — это всегда очень скучное занятие. Тут хочется вспомнить известные постулаты Agile: «Работающий продукт гораздо важнее исчерпывающей документации к нему. Люди и их взаимодействие важнее процессов и инструментов». Если наличие исчерпывающей документации не очень важно, то зачем тратить время на проверку соответствия документации формальным критериям? В целом наличие документа с требованиями не представляет ценности для проекта, пока эти требования не будут донесены до команды и реализованы.
Мысленно переформулируем «рецензирование требований» на «предоставление знаний о требованиях» и рассмотрим альтернативы классической вычитке требований.
В гибких методологиях используются ритуалы, которые могут выступить альтернативой классическому подходу с рецензированием и согласованием. В прошлых частях гайда мы выявили пользовательские требования и детализировали их до функциональных требований. А функциональные требования отдали командам разработки для обсуждения на планингах и грумингах. Так мы заменили долгое чтение многостраничных спецификаций устным обсуждением небольшого набора историй и также оперативно оценили полноту, реализуемость и тестируемость требований. Так как набор требований небольшой, при обнаружении ошибок или неточностей правки в них можно будет внести достаточно быстро.
Но есть нюанс. Исходные данные учебного проекта предполагают, что разработкой, настройкой и сопровождением каждой подсистемы занимается отдельная команда. Для реализации требований одного Epic’a или истории потребуется доработка или настройка нескольких подсистем. То есть, обсуждая на груминге ограниченное количество требований, команда разработки не сможет оценить, насколько предполагаемое решение покрывает пользовательские требования, не говоря уже о бизнес-требованиях. Также, не видя полной картины, нельзя проверить полноту списка альтернативных сценариев и требований к информационной безопасности.
Не отменяя важности оценки реализуемости и тестируемости атомарных требований, рассмотрим инструменты оценки качества наборов требований.
Проверка требований через прототип
Независимо от того, насколько качественно описаны требования, спроектирована и реализована система, цели проекта будут достигнуты, только если гипотезы, выдвинутые бизнес-заказчиком, были верны. Проверяя верность гипотез после реализации, мы можем потратить время на создание ненужного пользователям функционала. Чтобы минимизировать риски, нужно как можно раньше привлекать бизнес-заказчика и конечных пользователей к работе с требованиями. Крайне маловероятно, что у даже очень лояльно настроенных пользователей будет мотивация для чтения больших документов с описанием требований. Пользователи охотнее согласятся поэкспериментировать с прототипом.
Учебный проект «Общий счёт» не предполагает разработки каких-либо инновационных технических решений, поэтому для проверки гипотез можно использовать прототип пользовательского интерфейса. Из исходных данных проекта мы знаем, что в команде проекта будет дизайнер, который создаст макеты веб-приложения «Личный кабинет ФЛ».
Современные инструменты создания макетов, такие как Figma и Sketch, позволяют лёгким движением руки превращать макеты в кликабельные прототипы. Такой прототип можно показать как бизнес-заказчику, так и группе потенциальных пользователей, что позволит нам на ранних этапах получить первый фидбэк и проверить корректность гипотез, сформулированных при составлении карты пользовательских историй.
Кроме того, создавая макеты на основании вариантов использования, дизайнер проверит полноту и непротиворечивость функциональных требований.
Предусловия помогут определить стартовые экраны сценария.
Основной сценарий определит последовательность переходов между экранами.
Описание типов данных, вводимых пользователем, определит типы элементов интерфейса.
Альтернативные сценарии лягут в основу сообщений об ошибках.
Но всё хорошо в меру. Описывая варианты использования, аналитик должен помнить, что по умолчанию, пока не доказано обратное, дизайнер обладает большей компетенцией в UX (User Experience) и UI (User Interface). Поэтому не следует использовать в описании требования наименования экранов и элементов интерфейса, чтобы не навязывать дизайнеру возможное решение. И чтобы не тратить много времени на актуализацию требований, если дизайнер придумает другие названия элементам или изменит пользовательский путь. Варианты использования должны описывать, что пользователям необходимо выполнить с помощью системы, а не то, как это будет выглядеть на экране.
Техники тест-дизайна и описание требований
Во второй части гайда мы выяснили, что используемый нами шаблон описания вариантов использования включает атрибуты сценариев и критериев приёмки.
Предусловия варианта использования — предусловия тест-кейса.
Действия пользователя — шаги проверки.
Отклики системы — ожидаемый результат.
Эти три атрибута служат основой для создания других документов, используемых в процессе тестирования:
сценарий демонстрации — содержит сценарии из историй, реализованных в рамках одной итерации;
программа и методика испытаний (ПМИ) — объединяет сценарии Epic’ов и их дочерних историй, относящихся к определённому этапу проекта;
план модульного тестирования — базируется на сценариях историй, отфильтрованных по подсистемам (компонентам).
Список историй, описанных по шаблону вариантов использования, в сочетании с архитектурным решением и спецификацией API-контрактов может служить основой для создания плана интеграционного тестирования и структуры автоматических тестов.
Тестировщики могут сэкономить время, повторно используя сценарии и критерии приёмки при разработке планов тестирования. Это позволит им сосредоточиться на подготовке тестовых данных, изучении архитектуры системы и выборе подходящих инструментов для тестирования. Таким образом, разделы wiki, содержащие описание требований, становятся единым источником правды на проекте. Мы ссылаемся на них при описании задач для разработчиков и составлении планов тестирования. Когда требования изменятся (не «если», а именно «когда»), нам нужно будет актуализировать только wiki.
Чтобы обеспечить возможность повторного использования описания требований в процессе создания артефактов тестирования, необходимо убедиться, что требования содержат не только основные сценарии (когда всё идет по плану), но и альтернативные (если что-то пошло не так). В случае отсутствия каких-либо сценариев в требованиях их необходимо дополнить.
«Что-то пошло не так» — это абстрактная формулировка. Систематизировать знания о том, что может пойти не так, и проверить полноту описанных альтернативных сценариев помогут классические техники тест-дизайна.
Разбиение на классы эквивалентности
Анализ классов эквивалентности — это метод тестирования, позволяющий сократить количество тестовых сценариев, не снижая при этом уровень покрытия. Его суть заключается в разделении всех возможных входных данных на группы, которые считаются эквивалентными, и в выборе как минимум одного представителя из каждой группы для тестирования.
Классы эквивалентности можно использовать не только для сокращения списка тестовых сценариев, но и для сокращения списка вариантов использования. Так, на стадии инициации мы использовали классы эквивалентности, чтобы определить границы проекта. Мы предполагали, что у пользователей с определённой ролью будут одинаковые пользовательские требования, они будут пользоваться одним и тем же функционалом и их операции должны будут проходить схожие проверки. При этом мы последовательно декомпозировали выявленные классы по мере детализации списка входных данных. Можно сказать, что декомпозиция требований на Epic’и и истории была произведена на основании выявленных на стадии первичного анализа классов эквивалентности.
Вернёмся к альтернативным сценариям. После того как требования были декомпозированы до историй, нам нужно составить список альтернативных сценариев для каждой из них. Для этого нужно подумать, какие классы эквивалентности могут быть выделены на основании входных данных одной истории.
Возьмём для примера вариант использования «Списание с общего счёта». Выделим классы эквивалентности на основании роли пользователя, типа операции и точки старта сценария.
Роль пользователя: владелец счёта, пользователь счёта.
Тип операции: снятие наличных, оплата картой, перевод по номеру телефона, перевод по номеру счёта, перевод по номеру карты, перевод по QR-коду.
Точка старта: банкомат, касса в отделении банка, перевод в веб-приложении, ввод данных карты в стороннем приложении.
Выделенные классы эквивалентности позволяют нам разделить один сценарий «Списание с общего счёта» на множество сценариев для каждого класса и (или) сочетания классов. В отличие от тестировщика, аналитик может не только выделить классы эквивалентности на основании уже описанных требований, но и сократить их количество, добавив ограничения на выполнение каких-либо операций. Например, для владельца счёта доступны все типы операций списания.
А вот для пользователя счёта следует установить ограничения на снятие наличных. Мы не просто так ограничиваем список операций пользователя, чтобы описывать меньше требований, — а обосновываем ограничения бизнес-правилами и (или) пользовательскими требованиями. В первой части гайда мы выделили список персон и описали причины, по которым они могут использовать общий счёт. Одной из причин была возможность отслеживания, на что тратятся деньги. Если снять наличные со счёта, его владелец не узнает, на что были потрачены деньги, и у него пропадёт необходимость в использовании функционала.
После декомпозиции основного сценария на основании классов эквивалентности проработаем детально один атомарный сценарий «Оплата по номеру телефона владельцем счёта». Когда определены шаги основного сценария, нужно последовательно определить граничные значения для каждого шага.
Анализ граничных значений
Граничные значения — это точки, где один класс эквивалентности переходит в другой. Они находятся на границе допустимого диапазона входных данных.
Лучше всего принцип работы с граничными значениями виден в точках ввода данных. Например, чтобы списать средства со счёта, владелец должен указать сумму операции. Очевидно, что сумма не может быть отрицательным числом или нулём, а также что она не должна превышать остаток на счёте на момент списания. Так у нас появляются три класса эквивалентности, выделенные на основании здравого смысла.
Ноль и сумма остатка на счёте — это граничные значения. На основании этой информации мы можем выделить три альтернативных сценария.
Альтернативный сценарий №1
Владелец указывает сумму списания от минус бесконечности до нуля.
Система не позволяет ввести отрицательное число. Операция списания недоступна.
Альтернативный сценарий №2
Владелец не изменяет значение суммы по умолчанию (равно нулю) и инициирует отправку средств.
Система отображает сообщение о том, что необходимо указать сумму списания. Операция списания недоступна.
Альтернативный сценарий №3
Владелец указывает сумму списания, превышающую остаток на счёте.
Система отображает сообщение о том, что на счету недостаточно средств. Операция списания недоступна.
Помимо проверки того, что введённое пользователем значение не выходит за пределы диапазона допустимых значений, следует подумать, накладывает ли бизнес-логика дополнительные ограничения на возможные значения поля. В нашем примере операция осуществляется с участием сторонней системы — системы быстрых платежей (СБП). В СБП установлены месячные лимиты на сумму операций без комиссии: до 100 тысяч рублей в месяц можно переводить бесплатно. Если этот лимит исчерпан, берётся комиссия за перевод. Так у нас появляется ещё два класса эквивалентности в разрезе владельца счёта: исчерпавший месячный лимит СБП и не исчерпавший месячный лимит СБП. А при проверке допустимых значений суммы списания нам нужно будет учитывать, что сумма операции вместе с размером комиссии не превышает сумму остатка на счёте.
С одной стороны, объединение описания требований и тестовых сценариев в одном месте может создать дополнительную нагрузку на аналитика и привести к размытию границы зон ответственности между ролями аналитика и тестировщика. С другой стороны, применение методов тест-дизайна в процессе описания требований позволяет аналитикам выявлять неочевидные функциональные требования и создавать список возможных ошибок, который будет полезен как при разработке макетов, так и при проектировании API.
Проверка архитектурного решения через API-контракты
До этого момента мы описывали варианты использования в разрезе пользователя, который, взаимодействуя с пользовательским интерфейсом, отправляет системе входные данные. Система обрабатывает данные, выполняет операции и возвращает пользователю результат на выходе. При этом система рассматривалась как чёрный ящик, внутреннее устройство и механизм работы которого неизвестны и (или) не важны для общего понимания функциональных требований. Такой подход позволил нам сосредоточиться на детальной проработке функциональных требований, не отвлекаясь на особенности технической реализации.
Несмотря на то что у нас уже получился довольно внушительный список вариантов использования, этих данных может оказаться недостаточно. Из архитектурного решения и плана проекта мы знаем, что наша система состоит из множества подсистем. Кроме действий пользователя на результат выполнения операции в конкретной подсистеме также влияет формат взаимодействия между подсистемами и места хранения данных. Особенности реализации не видны пользователю, но разработчик должен о них знать. Даже у разработчиков, которым передали исчерпывающее описание вариантов использования, часто возникает много вопросов. Чтобы у нас было достаточно времени на реализацию, нужно как можно раньше получить список таких вопросов. Одним из способов уменьшения доли неопределённости является создание спецификации API (контракта).
Оставляем в стороне пользовательский интерфейс и переходим на новый уровень абстракции. Следующим шагом детализации требований будет описание взаимодействия между подсистемами через программный интерфейс приложений (API — Application Programming Interface).
Проектируя взаимодействие между подсистемами, учитываем, что по умолчанию, пока не доказано обратное, разработчик обладает более развитыми техническими навыками, чем аналитик. Технические ограничения могут быть наложены архитектором или специалистом по информационной безопасности, но не аналитиком.
Чтобы аналитик не навязывал разработчикам вариант реализации, его работа должна быть ограничена описанием функциональных требований и определением подсистем, участвующих в каждом бизнес-процессе. Затем эти функциональные требования передаются разработчикам, которые на их основе создают API-контракты.
Независимо от того, какой формат взаимодействия между подсистемами используется, API-контракты включают в себя несколько ключевых разделов.
Общая информация: название, описание, URL инстансов, версии API, и тип API.
Общие правила обработки технических ошибок.
Список операций. Информация по всем доступным операциям, включая: название операции, входные параметры, выходные параметры, обработку ошибок бизнес-логики.
Нефункциональные требования. Меры безопасности, применяемые в API (аутентификация, авторизация, SSL/TLS), логирование, мониторинг.
Для различных типов API существуют общепринятые шаблоны описания контрактов и инструменты, облегчающие их создание. По сути, разработчику необходимо описать те же входные и выходные данные, которые были определены в вариантах использования, но для этого он должен использовать не естественный язык, а специальный формат, соответствующий типу API.
Тип API | Формат описания контракта |
REST | OpenAPI‑спецификация |
SOAP | WSDL-файл |
gRPC | Proto-файл |
GraphQL | GraphQL-схема |
После того как разработчики создадут API-контракты для своих подсистем, аналитик сможет детально проработать диаграммы последовательности, которые были определены на этапе планирования, вплоть до названий методов. Это позволит ему убедиться, что во всех подсистемах, вовлечённых в конкретный процесс, имеется достаточно данных для корректного выполнения операций.
Именно в такой последовательности разработчик сначала изучает архитектурное решение и функциональные требования, затем создаёт API-контракты и отправляет описание взаимодействия между системами на проверку аналитику.
Этот подход известен как Contract First — «контракт сначала». Чтобы составить контракт, разработчику необходимо тщательно изучить требования и наладить тесное взаимодействие с командами, которые будут использовать API. Кроме того, наличие API-контрактов позволяет заниматься параллельно разработкой нескольких подсистем. В том числе параллельно с разработкой сервисов могут писаться автоматические тесты. В оптимистичном сценарии к моменту завершения разработки у нас уже будут готовы:
план ручного тестирования, составленный на основании макетов пользовательского интерфейса и вариантов использования;
план интеграционного тестирования, составленный на основании API-контрактов и вариантов использования;
автотесты для модульного тестирования, разработанные на основе API-контрактов.
Заключение
Не существует единственно верного способа написания идеальных требований. Также как не существует идеальных требований. Формат описания, уровень детализации и методы контроля качества зависят от множества факторов. Это и особенности предметной области, и уровень квалификации участников команды, и, конечно, ограничения проектного треугольника.
В этом гайде мы рассматриваем довольно сложный пример. Может показаться, что описанные методы контроля качества требований излишни, поскольку требуют много времени. Однако особенности предметной области учебного проекта позволяют нам убедительно обосновать необходимость затрат ресурсов на контроль качества. Ошибки, выявленные на этапе контроля требований, стоят меньше всего. Их исправление не требует больших усилий. Однако если ошибка, возникшая на уровне требований, «доживёт» до этапа тестирования, её устранение будет стоить очень дорого. Ведь потребуется внести изменения не только в код, но и, возможно, в архитектуру, макеты и тестовую документацию. Если стадия контроля будет пропущена и ошибки дойдут до конечных пользователей, банк будет в буквальном смысле терять деньги — причём не только из-за стоимости исправления кода и даже не из-за репутационных рисков и потери клиентов. А из-за действий злоумышленников, которые могут воспользоваться уязвимостями в продукте и вывести деньги со счетов клиентов банка. Ошибки в финтех-приложениях стоят очень дорого. Более серьёзные последствия могут быть только в случае с медицинскими системами, где на кону стоят здоровье и даже жизни людей.
Но всё хорошо в меру. Лучший способ определить достаточный для конкретного проекта уровень качества требований — это конструктивная критика требований участниками команды проекта и другими заинтересованными лицами. Проверка качества требований — это длительный и энергозатратный процесс. Стоит подумать заранее, есть ли у стейкхолдеров достаточная мотивация для участия в этом процессе.
Совмещая процесс рецензирования требований с созданием артефактов, используемых стейкхолдерами в своей работе, мы получаем следующие преимущества:
Работа с требованиями не отвлекает участников проекта от их основных задач. Нам не нужно придумывать сложные объяснения для дизайнера, почему создаются макеты. Тестировщик осознаёт важность тест-планов, а разработчик в любом случае пишет API-контракт — если не в начале, то в конце выполнения задачи.
В процессе устного обсуждения требований легко потерять нить разговора и отвлечься от сути. Создание производных артефактов на основе описания требований позволяет сконцентрироваться и при необходимости вернуться к местам, которые вызывают сложности.
Отдавая на рецензию ранние версии описания требований, аналитик морально готов, что в них нужно будет вносить правки. Готовность к изменениям повышает вовлечённость команды проекта и стимулирует креативность.
Проверка качества требований всеми членами команды проекта не является гарантией того, что они не будут меняться. Напротив, когда мы предоставляем требования для рецензирования одновременно бизнес-заказчику, дизайнеру, тестировщику и разработчикам, мы ожидаем большое количество замечаний на первых этапах проверки.
Тем не менее такой подход позволяет нам выявить противоречия в требованиях различных заинтересованных сторон на ранних стадиях. Если необходимо, мы можем внести изменения в описание требований, архитектурное решение и план проекта. Таким образом, мы сможем управлять рисками и ожиданиями стейкхолдеров. Гораздо проще избежать конфликта с заказчиком, если мы сообщим ему о том, что требование нереализуемо или его реализация потребует больше времени и ресурсов, в начале проекта, а не на приёмке.
Есть у такого подхода и свои недостатки. Описание требований и создание производных артефактов требует времени. Пока команда проекта занимается созданием документации, никто не пишет код. Для проектов, проверка гипотез в которых требует проверки работоспособности сложных алгоритмов или технических решений, нет необходимости создавать высокоточные макеты и планы ручного тестирования. Если гипотеза окажется неверной, то такая документация не будет иметь практической ценности. В таких случаях проверить верность гипотезы и качество требований можно при создании технических прототипов.
