Управление требованиями

В этом уроке вы узнаете, что делает системный аналитик в процессе управления требованиями, что такое трассировка требований, зачем она нужна и как отслеживать версии наборов требований к ПО.

Даня

Даже не верится, что мы закончили со спецификацией требований для новой версии Chatty!

Артём

Нууу, я бы не сказал, что мы закончили 😜

Даня

Как же так 🥲

Артём

Какие-то требования изменятся, какие-то — устареют, ещё и новые появятся — это нормально.

Даня

Как же не запутаться, и ничего не потерять, когда многое меняется?

Артём

Есть несколько приёмов, сейчас расскажу.

В процессе разработки требования неизбежно корректируются. Они могут устареть и стать ненужными, ведь на них влияет множество факторов: новые возможности на рынке, изменение бизнес-правил или потребностей заинтересованных лиц. В результате могут появиться новые требования, поэтому, как мы уже говорили, нужно учитывать такие изменения и готовиться к ним, а поможет в этом управление требованиями.

Что делает системный аналитик в процессе управления требованиями к ПО

Управление требованиями — деятельность, происходящая на протяжении всего проекта. Она включает в себя приёмы работы с уже готовыми требованиями.

Управление требованиями можно разделить на четыре категории:

Управление версиями.
Управление изменениями.
Отслеживание состояния требований.
Отслеживание связей требований.

Управление версиями

Как вы помните, после того, как мы выявили требования, нужно зафиксировать их в спецификации. Если бы мы жили в идеальном мире, спецификация сразу бы получалась безупречной. Но так не бывает, да и требования, как вы уже знаете, могут меняться. А вот отслеживать эти изменения и их причины поможет управление версиями.

Управление версиями — это уникальная идентификация разных версий каждого элемента. Это может быть как отдельное требование, так и набор требований, который обычно представляют в виде документа, то есть спецификации требований к ПО.

В начале проекта создаётся базовая версия требований.

Базовая версия — это согласованный заинтересованными лицами набор требований. Часто он определяет содержимое определённого выпуска или итерации разработки. Так, в гибкой методологии базовая версия может содержать согласованный набор пользовательских историй для одной итерации проекта.

Базовую версию из спецификации получают после этапа рецензирования и утверждения требований. После этого менять её можно только с помощью определённого в проекте процесса управления изменениями. Всем версиям спецификации требований нужно присваивать свои идентификаторы. Так вы избежите путаницы между нынешней версией и предыдущей.

Управление изменениями

Все требования к продукту невозможно определить в начале проекта (а жаль!). Эффективная команда разработки всегда быстро реагирует на необходимые изменения. Но перед тем как что-то менять в требованиях к продукту, нужно убедиться, что:

Предложенные изменения оценили (то есть взвесили «за» и «против»).
Об изменениях, которые одобрила команда разработки, сообщили заинтересованным лицам (и они их тоже одобрили).
Требования в проекте меняют одинаковым образом.

Почему всё это важно? Если разработчик реализует требование в программном коде без согласования с командой, это может привести к некоторым проблемам: дополнительной нагрузке в тестировании или будущим ошибкам, поскольку, меняя продукт, разработчик, скорее всего, не учёл, на что это повлияет.

Процесс управления изменениями помогает команде принять решение, нужно ли вносить изменения, — с максимальной пользой для заказчика и бизнеса, но без потери контроля над продуктом. Как только на вашем проекте утвердили базовую версию набора требований, придерживайтесь порядка ниже для того, чтобы внести изменения.

Порядок внесения изменений

Предложение внесения изменений.
Анализ влияния.
Принятие/отклонение изменения.
Обновление требований в спецификации.
Информирование заинтересованных лиц.

Процесс управления изменениями начинается с предложения — что требуется изменить? Часто оно исходит от заинтересованных лиц, поскольку меняется бизнес-потребность.

После того как команда получила предложение об изменении, начинается анализ влияния. Это основной аспект управления требованиями. Кажется очевидным, что анализировать нужно, если изменений много или они крупные. На самом деле к неожиданностям могут привести даже самые мелкие правки.

Анализ влияния позволяет точно понять предложенное изменение. Так команда сможет принять взвешенное решение о том, какое изменение нужно одобрить, сколько времени и сил займёт его реализация, что понадобится создать, изменить или отклонить.

Анализ влияния обычно состоит из:

Понимания возможных последствий изменения. Одно изменение может тянуть за собой изменения в других требованиях.
Определения всех требований и документов, которые, возможно, придётся изменить, если команда одобрит запрошенные изменения.
Оценки трудоёмкости изменения. Этот процесс позволяет понять, какие функциональные требования нужно реализовать для данного изменения, на сколько увеличится срок реализации продукта.

Когда анализ влияния завершён, команда разработки вместе с менеджером продукта и заинтересованными лицами принимают решение: какие из предложенных изменений принять, какие — отклонить.

Если решение в пользу предложенных изменений, нужно обновить требования в спецификации, изменив при этом версию документа. Вдруг вам понадобится вернуться к первоначальной версии набора требований. Так вы сможете отличить её от текущей.

Также вам нужно предупредить заинтересованных лиц и инициатора изменения. Важно обратить их внимание на возможные риски в связи с изменениями требований, например увеличение сроков разработки.

Отслеживание состояния требований

Отслеживание состояний требований включает в себя информацию о том, реализованы ли требования, а ещё хронологию изменений, версии, проблемы, с которыми столкнулась команда разработки и прочее.

Бывает так, что разработчики слишком оптимистично оценивают выполненную работу. Более трезво судить о готовности проекта помогает отслеживание состояния каждого функционального требования. Чтобы сделать этот процесс удобнее, нужно наделить каждое функциональное требование какой-то характеризующей его информацией — связанными с ним атрибутами.

В средствах управления требованиями есть множество определяющих атрибутов: дата создания требования, номер текущей версии, автор, приоритет, состояние, источник и так далее. С их помощью проще ориентироваться в существующих требованиях. Так, у атрибута «состояние» может быть одно из значений: «предложено», «разработка», «подготовлено», «одобрено», «реализовано», «проверено», «отложено», «удалено», «отклонено». Так можно понять, где сейчас находится требование, какие из требований уже реализованы, от каких мы отказались.

Отслеживание связей требований

Поскольку даже простые изменения часто влияют на многие элементы продукта, требуется менять и эти элементы. Сложно с ходу обнаружить все компоненты системы, которые могут быть затронуты. Но анализ влияния проводить проще, если вы знакомы с процессом отслеживания связей требований.

Такие связи отражают зависимости отдельных требований. Например, связь одного требования с другим или его связь с бизнес-правилом, дизайном, архитектурой, исходным кодом, тестами. Знание этих связей поможет вам в проведении анализа влияния.

А ещё отслеживание связей требований может помочь в:

Обнаружении пропущенных требований. Вы можете выяснить, что бизнес-требование, например, не связано ни с одним функциональным требованием, то есть вы пропустили его при анализе требований. Ведь на этом этапе из бизнес-требований выделяют пользовательские, а затем функциональные.
Обнаружении ненужных требований. Тут идём от обратного: вы можете найти функциональные требования, которые не связаны ни с одним бизнес-требованием.
Сертификации и выполнении нормативов. Мы сможем отслеживать выполнение всех необходимых требований к безопасности.
Поддержке и обслуживании. Например, при обновлении какого-то бизнес-правила вы сможете найти связанное с ним функциональное требование, что упростит внесение изменений.
Отслеживании хода разработки проекта. Вы сможете отследить, какие требования уже разработаны или протестированы, а какие ещё не реализованы.
Повторном использовании. Отслеживание связей требований упрощает переиспользование каких-то частей продукта.
Тестировании. Это помогает понять, покрывают ли все тест-кейсы необходимые функциональные требования или, наоборот, тест-кейсов слишком много.

Взгляните на список мероприятий, которые проводились в вашей команде за прошедшую неделю. Найдите все действия, которые относятся к управлению требованиями.

Провели анализ того, как добавление новой функциональности в спецификацию требований может повлиять на текущие требования

Здесь описано проведение анализа влияния. Это относится к управлению требованиями, а именно к управлению изменениями, помогает более чётко понять необходимое изменение.

Составили матрицу связи функциональных требований с пользовательскими

Здесь описано составление матрицы связей требований. Это относится к управлению требованиями, а именно к отслеживанию связей требований. Помогает отследить, какие требования мы могли упустить.

Команда экспертов провела экспертизу базовой версии спецификации требований

Эта техника относится к рецензированию, а именно к проверке требований.

После утверждения изменений системный аналитик написал новую версию спецификации к ПО

Здесь описано управление версиями. Относится к управлению требованиями, помогает фиксировать изменения в новой версии без потери старой.

Проведение интервью заинтересованных лиц для выяснения новых требований к системе

Это техника выявления требований. Не относится к управлению.

Трассировка требований

Даня

Получается, даже простое изменение в одном требовании может привести к большим изменениям?

Артём

Ага, поэтому так важно следить за связями требований.

Даня

И как же это делать?

Артём

Сейчас расскажу!

Трассировка требований — это способ представления связей между требованиями различного уровня, который помогает выявить зависимости, определить источник того или иного требования.

Самый частый способ представления связей между требованиями — матрица трассируемости. Рассмотрим, как строить матрицу трассируемости на примере взаимосвязи вариантов использования (Use Case — это пользовательские требования) и функциональных требований.

Для этого нам нужно заполнить таблицу. В столбцах будут располагаться варианты использования, а в строках — функциональные требования. При пересечении мы как раз увидим взаимосвязь.

Для построения матрицы можно использовать идентификаторы функциональных требований из вашей спецификации ПО. Это поможет визуально облегчить матрицу.

Для примера выделим следующие варианты использования:

UC - 1 — Просмотр истории заказов

UC - 2 — Оформление заказа

UC - 3 — Поиск товаров

UC - 4 — Просмотр избранных товаров

Теперь давайте выпишем функциональные требования:

FR - 1 — Авторизованный пользователь должен иметь возможность просматривать список ранее заказанных товаров с разбиением на заказы.

FR - 2 — При оформлении заказа система должна дать возможность выбора адреса доставки на карте.

FR - 3 — При оформлении заказа система должна дать возможность выбора времени доставки.

FR - 4 — При просмотре списка товаров система должна дать возможность отфильтровать товары по разным критериям.

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

Вариант использования (UC) /Функциональное требование (FR)	UC - 1	UC - 2	UC - 3	UC - 4
FR - 1	←
FR - 2		←
FR - 3		←
FR - 4			←	←

Как читать такую таблицу:

Требование FR-1 зависит от UC-1, а требования FR-2 и FR-3 — от UC-2. Так мы понимаем, что требования FR-2 и FR-3 используются в одном варианте использования — UC-2, а требование FR-4 повторно используется в UC-3 и UC-4. Так мы можем увидеть, что между требованиями и вариантами использования в матрице могут быть разные связи.

Связи отслеживания могут определяться такими отношениями:

Один к одному. Одно требование реализуется в одном варианте использования.
Один ко многим. Одно функциональное требование затрагивает множество вариантов использования.
Многие ко многим. Каждый вариант использования порождает множество функциональных требований.

Построение такой матрицы позволяет гарантировать, что при реализации функциональных требований ни один вариант использования не будет упущен и лишние требования не попадут в спецификацию.

Команда разработки, которая дорабатывает сайт гончарной мастерской, выделила два варианта использования (Use Case).

Пользователь сайта хочет:

UС-1. Записаться на мастер-классы

UС-2. Купить подарочный сертификат

Найдите среди утверждений ниже функциональные требования, которые трассируются с данными вариантами использования (Use Case).

Система должна отображать расписание мастер-классов

UС-1

Функциональное требование связано с UС-1. Требование связано с записью на мастер-класс.

Пользователь должен иметь возможность зайти в личный кабинет

Не связано с данными UС

Функциональное требование не связано с представленными вариантами использования. Не относится напрямую к записи на мастер-класс или покупке сертификата.

Пользователь должен иметь возможность записаться на мастер-класс на выбранную дату

UС-1

Функциональное требование связано с UС-1. Требование связано с записью на мастер-класс.

Пользователь должен иметь возможность оплатить подарочный сертификат на сайте

UС-2

Функциональное требование связано с UС-2. Требование связано с покупкой подарочного сертификата.

Пользователь должен иметь возможность посмотреть адрес мастерской на сайте

Не связано с данными UС

Отслеживание версий наборов требований к ПО

Предположим, у вас есть спецификация требований к ПО, которая досталась вам от другого системного аналитика. Команда не стоит на месте, и возникла необходимость внести новые требования, а заодно и изменить пару старых. Как вашей команде и заинтересованным лицам найти эти изменения? В этом вам поможет версионность. Вы можете взять существующую спецификацию версии 1.0, сохранить её в качестве новой версии с идентификатором 1.1 и внести необходимые изменения. Вот так просто.

Но есть и нюансы. При отслеживании версий наборов требований важно учитывать:

Доступ к редактированию вашей спецификации должен быть только у строго определённых лиц.
Идентификатор версий необходимо менять при каждом изменении требований.
Каждая версия должна содержать информацию об изменениях — суть внесённых изменений, дату, причины и имя автора, который внёс изменения.
У каждого члена команды и заинтересованных лиц должен быть доступ к актуальной версии требований.

Возникает вопрос: где тогда отслеживать версии спецификаций? Есть несколько инструментов, которые вы можете использовать.

MS Word

Чтобы отслеживать версии набора требований, некоторые команды используют обычную офисную программу — MS Word в режиме правки текста. Эта функция выделяет внесённую правку, зачёркивает удалённые фрагменты, подчёркивает добавленные и помечает вертикальными линиями на полях автора и время правки.

Сохраняя документ, важно указать новую версию спецификации требований и хранить её в общедоступном для команды месте. Иначе может возникнуть ситуация, при которой несколько аналитиков работают над одной функцией. Один может внести изменения в версию 1.1, создав при этом новую и назвав её 1.2, а другой аналитик через пару дней просто не заметит новую версию и также внесёт изменения в версию 1.1 и назовёт её 1.2, даже не подозревая о конфликте версий.

Confluence

Во многих компаниях вы можете познакомиться с Confluence — системой для хранения базы знаний команды. Там уже существует встроенный функционал, который включает такие возможности для управления версиями:

Просмотр истории страницы, где мы можем увидеть версию, автора и дату изменений.
Возврат к предыдущей версии и просмотр того, какие изменения были внесены в текст.
Сравнение двух версий спецификации требований.
Удаление ненужных версий.

Google Docs

Подходящим средством для отслеживания версий требований также считают Google Docs. Данная система обладает инструментом для просмотра истории версий документа. Чтобы найти её, нажмите «Файл», затем выберите «История версий».

Перейдя в пункт меню «Указать название текущей версии», вы можете указать название текущей версии вашего документа.
Перейдя в пункт меню «Смотреть историю версий» вы можете увидеть, какие изменения были внесены, кем и когда. Там же можно переключаться между версиями. И даже вернуть ваш документ к одной из прошлых версий.

Подведём итоги

В этом уроке вы узнали, как управлять требованиями. Управление требованиями состоит из:

Управления версиями — это идентификация уникальным образом разных версий каждого элемента, для работы только с актуальными требованиями к продукту. Вначале создаётся базовая версия спецификации требований, а затем каждой версии присваивается свой идентификатор. Отслеживать версии набора требований можно в MS Word, Confluence или Google Docs.
Управления изменениями. При внесении изменения важно придерживаться принятого порядка внесения изменений и проводить анализ влияния изменения на весь проект.
Отслеживания состояния требований. Для удобства отслеживания необходимо, чтобы у каждого функционального требования были атрибуты, которые отражают его актуальное состояние.
Отслеживания связей требований. В этом вам поможет трассировка требований — способ представления связей между требованиями различного уровня, помогающий выявить зависимости или определить источник того или иного требования. Для этого в проекте составляются матрицы трассируемости.