Разработка и управление требованиями

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

Даня

А требования могут меняться в процессе?

Артём

Конечно, так обычно и происходит.

Даня

И как с этим быть?

Артём

Морально подготовиться 😅.

Системный аналитик должен не только разрабатывать требования, но и управлять ими. Сейчас объясню.

Инженерия требований

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

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

Системный аналитик пришёл на новый проект (команда создаёт сайт для онлайн-магазина), и ему нужно собрать требования с заказчиков (каким они хотят видеть сайт).
Системный аналитик пришёл на существующий проект (у онлайн-магазина уже есть действующий сайт, но заказчики хотят создать мобильное приложение), и ему нужно выяснить, какое именно приложение нужно заказчикам.

Управление требованиями — это работа с уже существующими требованиями. Например:

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

Разработка требований к ПО

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

Выявление требований — определение потребностей пользователей и изучение среды, в которой будет находиться разрабатываемое ПО. Выявление требований включает:

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

Среда ПО — это совокупность программ, библиотек и утилит, которые позволяют пользователям выполнять определённые задачи.

Анализ требований — получение более точного понимания всех требований и улучшение их качества. Анализ требований может включать:

Извлечение функциональных требований из требований других уровней и типов, бизнес-правил.
Анализ того, возможно ли реализовать требования.
Анализ взаимодействия ПО с внешними интерфейсами (например, анализ работы со смежными сервисами).
Создание прототипов ПО.
Распределение требований по компонентам ПО, определённым в системной архитектуре.
Приоритизацию требований.

Документирование требований — хранение требований хорошо организованным способом (подробнее о способах организации требований вы узнаете в следующих уроках). Документирование требований может включать:

Преобразование выявленных требований в документ текстового или графического формата.
Определение источников требований и назначение идентификаторов — требование № 1, № 2 и так далее.

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

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

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

Определите, к какому подразделу разработки требований (выявление, анализ, документирование, проверка) относится процесс.

Фиксирование требований в форме таблицы

Документирование требований

Это действие относится к преобразованию требований в документ

Опрос среди пользователей по поводу того, как улучшить продукт

Выявление требований

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

Совещание с пользователями для утверждения требований

Проверка требований

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

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

Анализ требований

Это действие относится к моделированию среды приложения и входит в анализ требований

Итеративно-инкрементальный процесс разработки требований к ПО

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

Разработка требований — это итеративный и инкрементальный процесс:

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

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

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

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

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

Выявление

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

Анализ

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

Документация

Документировать требования не имеет смысла, так как их надо сначала правильно сформулировать.

Проверка

Утверждать неправильные требования — заведомо провальная идея.

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

Выявление

Идентификаторы требований назначает аналитик, а значит, общение с пользователями не нужно.

Анализ

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

Документирование

Необходимо вернуться на этап документирования, чтобы отредактировать требования и привести к единому формату.

Проверка

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

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

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

Управление требованиями — это действия по работе с уже готовыми требованиями, которые выполняются в течение всего проекта:

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

Определите, какие процессы относятся к управлению требованиями.

Изучение бизнес-требований

Изучение бизнес-требований относится к выявлению требований

Изменение текущих требований в связи с добавлением новой бизнес-цели

Это управление изменениями готовых требований при изменении планов проекта, относится к управлению требованиями

Создание отчёта с версией требований

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

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

Это документирование требований

Как распределяются усилия по инженерии требований на проекте по разработке ПО

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

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

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

Гибкая

В гибкой модели нет чёткого плана, разработка происходит итерациями. Перед каждой итерацией команда выбирает наиболее важные задачи. За время одной итерации задача проходит полный цикл — от анализа до тестирования

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

Каскадная

В каскадной модели есть чёткий план действий со сроками. Разработка наступает только после того, как полностью завершён этап анализа

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

Метод набегающей волны

В методе набегающей волны есть примерный долгосрочный план и более детальный краткосрочный план

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

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

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

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

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

Аналитик занимается управлением требованиями на протяжении всего проекта

Каскадная

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

Набегающей волны

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

Гибкая

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

Аналитик больше задействован в разработке требований на начальном этапе проекта

Каскадная

В каскадной модели выявление требований приходится на начальный этап проекта

Набегающей волны

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

Гибкая

В данной модели выявление требований происходит на протяжении всего проекта

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

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

Разработку требований — работу над новыми требованиями.
Управление требованиями — работу над существующими требованиями.

Разработка требований — это итеративный и инкрементальный процесс, в который входят следующие роды деятельности:

Выявление.
Анализ.
Документирование.
Проверка.

Управление требованиями — действия, выполняемые в течение всего проекта, которые включают в себя приёмы работы с уже готовыми требованиями:

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

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