Реестр требований как фундамент проекта. Как работу с реестром требований превратить в управление требованиями?

Реестр требований – это фундамент будущего проекта. Если у нас фундамент с дефектами, то и в самом проекте будут трещины. И чем дальше, тем больше они могут разрастаться.

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

Если на проекте нет управления требованиями, появляется несогласованность, рассинхрон, и весь проект в итоге может превратиться в монстра Франкенштейна, который стоит на костылях.

Потом придется закрывать множество несогласованностей, и это будет больно и печально. А в итоге к концу проекта «мыши плакали, кололись, но продолжали жрать кактус», который вначале сами к себе и притащили.

Иерархия требований. Какие еще требования бывают, кроме функциональных

Кратко пройдемся по иерархии требований.

• В основе всего лежат бизнес-требования – именно они и порождают проект, для их исполнения проект и создается. Это требования от топ-менеджеров, от акционеров. Примером бизнес-требования может быть: «Сокращение закрытия МСФО с 10 до 5 дней». Это такие укрупненные требования, из которых потом формируются дальнейшие требования.

• Затем идут требования пользователей – это требования в терминах предметной области, которые формируют пользователи. Пример такого требования: «Максимально автоматизировать формирование Заявки на оплату». Это еще не формализованные требования, но уже более конкретные.

• И, наконец, функциональные требования – это обработанные требования, формализованные, которые формулируются в терминах системы, с ними мы в дальнейшем и работаем.

Также требования делятся на функциональные и нефункциональные.

• Функциональные требования – это те, которые описывают действия и поведение системы. Именно они составляют реестр требований, и они отвечают на вопрос, что должна делать система.

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

Первичный сбор требований, создание реестра требований. Откуда возникают требования?

Собираемые в реестре требования должны соответствовать основным свойствам требований, таким как:

• Полнота;

• Ясность;

• Непротиворечивость;

• Упорядоченность по важности;

• Осуществимость;

• Необходимость;

• Трассируемость;

• Верифицируемость;

• Измеримость – это свойство я сам притащил сюда из SMART’а, считаю его важным, и в дальнейшем будет видно, почему.

На слайде – таблица с примером реестра требований.

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

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

Атрибуты требований. Какие необходимые и достаточные колонки включать в реестр требований.

Каждое требование состоит из определенных атрибутов.

• Есть основные атрибуты, которые существуют в каждом проекте.

• И есть атрибуты, которые включаются в реестр для конкретного проекта. Например, здесь для реестра введены поля о необходимости доработки и оценки для двух систем: для ERP и ERP.УХ. Эти поля были нужны на конкретном проекте, чтобы затем выбрать систему для реализации. Такие плавающие атрибуты всегда бывают в проектах. Допустим, если проект по нескольким организациям, то в проект еще может добавиться атрибут «Организация», чтобы разделить требования по разным организациям.

Переход от реестра требований к управлению. Как работу с реестром требований превратить в управление требованиями?

Реестр требований – это не 10 заповедей, которые выбиты в камне, это живой документ

• Требования могут меняться на всей протяженности проекта.

• Это непрерывный процесс – обратная связь с процессом управления требованиями происходит на каждом этапе проекта.

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

• добавляться;

• исключаться;

• декомпозироваться;

• объединяться;

• уточняться;

• переформулироваться;

• менять приоритеты;

• менять оценку;

• менять связи.

Можно поддерживать все эти изменения требований вручную, но это достаточно сложно, поэтому:

• Для управления требованиями должна быть проектная технология – набор процессов, договоренностей и правил.

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

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

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

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

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

В идеальном случае, как в песне известной группы: «Нажми на кнопку – получишь результат»: если процесс максимально автоматизирован, если эти изменения отслеживаются в автоматическом режиме, наша жизнь значительно упрощается.

Процессы управления требованиями

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

Первый процесс – это совместная работа с требованиями.

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

• Для работы с требованиями должна поддерживаться совместная работа – один и тот же документ должен правиться в онлайне несколькими участниками.

• И желательно, чтобы было версионирование – чтобы в случае каких-то накладок, можно было откатиться к предыдущим версиям документов.

Следующий процесс – это первичный сбор и определение требований.

У нас источниками требования служат:

• опросники;

• протоколы;

• различные нормативные документы;

• схемы бизнес-процессов;

• и анализ существующих систем.

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

Также важным процессом является отслеживание состояния (статуса) требований.

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

Список статусов должен быть регламентирован, закреплен и един.

Следующий процесс – это группирование и упорядочивание требований. Он служит для того, чтобы структурировать весь наш реестр.

• Первичная группировка у нас производится по функциональным областям. Есть регламентированный список функциональных областей, и каждое из требований прикрепляется к определенной функциональной области. Причем на проектах всегда возникают кросс-функциональные требования, когда сразу несколько отделов из разных областей выдвигают одно и то же требование, может быть немного отличающиеся по формулировке. Для таких требований надо обязательно сделать приоритизацию – придумать правило, по которому требование однозначно относится к какой-то функциональной области. Допустим, где начало процесса возникает, туда мы и относим. Если пакет документов печатает склад – значит, это относится к функциональной области «Склад». Если бухгалтерия – значит, к регучету.

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

Переходим к процессу разрешения проблем с требованиями.

Это очень важный процесс. Если мы обработаем все требования и решим ряд проблем в реестре – мы получим меньше проблем на следующих этапах проекта, нам там не будет больно, и переделывать придется меньше.

Типичные проблемы в реестре требований – это:

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

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

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

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

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

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

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

Например, реальное требование: «Максимально автоматизировать в 1С формирование и документооборот заявок на платеж (заявок на оплату)».

Что такое «максимально автоматизировать»? Это крайне неконкретно. Наверняка вам пользователь потом столько напихает под это, что не обрадуетесь.

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

Допустим, у нас принято, что требование всегда должно начинаться с фразы «система должна обеспечить». Если аналитик не может начать требование с этой фразы, то, в 99% случаев, это нефункциональное требование и его надо либо выносить в другой документ, а не в реестр, либо переформулировать в соответствии со стандартной структурой требования.

Я уже ранее говорил, что притащил из SMART’а измеримость требований, потому что бесконечные открытые требования – это большая проблема. Если такое требование утвердить в реестре, затем 100% будут проблемы.

Пример такого требования: «Формировать подчиненные планы, основанные на прогнозе продаж (план производства, план закупок и т.д.)».

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

И второе – это неявные требования.

Тоже реальное требование: «Оперативные отчеты должны содержать информацию по списанным ТМЦ и работам/услугам – количество и стоимость».

Здесь ключевой триггер – это «оперативные отчеты». Какие это отчеты? Это один отчет, два или сто? Всегда должен быть список. Если архитектор видит такие требования, он должен возвращать их аналитику. А аналитик должен обязательно спросить у пользователя и сделать закрытый список.

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

• На основании оцененных требований мы считаем бюджет проекта и показываем заказчику «как космические корабли бороздят Большой театр».

• После этого заказчик часто говорит: «Вы че, охренели?! Это в три раза больше, чем я планировал бюджет!» Поэтому мы проводим анализ требований и совместно с заказчиком приоритизируемся – назначаем требованиям приоритеты.

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

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

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

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

• позволяет как можно быстрее получить продукт, который можно уже показать, это хорошо для отчетности топов – они уже видят, что что-то работает;

• плюс в процессе внедрения выявляются какие-то требования, которые до этого не были учтены – не было еще ни одного проекта, где не выявилось бы дополнительных требований в процессе внедрения;

• то, что мы порезали объем, снижает наши риски – доработок гораздо меньше, рисков меньше;

• когда мы внедрили первую очередь и клиент доволен, и он говорит: «Все, приступаем ко второй очереди, потом к третьей». Это основа долгосрочного сотрудничества с клиентом.

Ремарка: MVP обязательно должен работать. Это продукт, который работает. Если мы что-то сделали, а это не приносит никакой пользы – это не MVP, такое решение надо пересматривать.

Следующий процесс – это обработка требований и связь со следующими этапами.

• На основе реестра требований мы формируем документы следующих этапов (модельный пример, проектное решение и т.д.).

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

Следующий процесс – это управление зависимостями:

• Мы указываем в явном виде зависимость требования и документов следующих этапов.

• И еще есть взаимозависимые требования, которые зависят одно от другого. В этом случае мы также должны в явном виде указать связи между требованиями.

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

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

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

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

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

• Процесс совместной работы с требованиями формирует такие свойства, как ясность, непротиворечивость, полноту.

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

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

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

Инструменты управления требованиями

Чтобы все это работало не в ручном режиме, у нас должны быть какие-то инструменты управления требованиями, которые должны поддерживать:

• все процессы, которые до этого были рассмотрены;

• импорт/экспорт данных из других систем – как минимум из Excel, потому что реестр требований часто ведется в Excel;

• безопасность и конфиденциальность информации – авторизацию и все с этим связанное.

Инструменты управления требованиями встроены практически во все современные ALM-системы (Application Lifecycle Management).

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

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

Поэтому в настоящее время у нас разрабатывается еще и связь Confluence с СППР, чтобы с реестром требований работать более удобно и более быстро.

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

Использованные источники

• Брукс Ф. Мифический человеко-месяц, или Как создаются программные системы; [пер. с англ.]. СПб: СимволПлюс, 2007. 304 с.

• Вигерс Карл Разработка требований к программному обеспечению/Пер, с англ. — М.:Издательско-торговый дом «Русская Редакция», 2004. —576с.

• IEEE Standard 830-1998, «IEEE Recommended Practice for Software Requirements Specifications»

• Орлик С., Булуй Ю. Введение в программную инженерию и управление жизненным циклом ПО Программная инженерия. Программные требования. Copyright © Сергей Орлик, 2004-2005.

• Engineering Lifecycle Management. https://www.ibm.com/docs/ru/elm/7.0.2?topic=engineering-requirements-management-doors-next

• https://www.technosolutions.com/topteam_requirements_management.html

• Инструменты управления требованиями. (RM) https://visuresolutions.com/ru/requirements-management-rm-tools/

Вопросы и ответы

Я так понял, что вы ведете реестр требований в Confluence, а задачи у вас в Jira. Чем задачи от требований отличаются?

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

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

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

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

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

Если заказчик не готов работать в нашем Confluence, у нас разработан шаблон выгрузки – все выгружается в Excel и Word.

У вас там есть ограничения по правам, чтобы пользователь не пришел и ничего не подрихтовал?

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

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

Да, работа с требованиями ведется постоянно. Предварительно аналитик прикидывает – будет доработка или не будет. И дает предварительную оценку. А на моделировании эта оценка может поменяться – в зависимости от того, типовая будет реализация или не типовая. Потому что часто мы думаем: «А, это типовое», а потом показываем пользователю, и он говорит: «Нет, тут должно быть вообще не так». И оценка меняется.

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

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

Получается, что потом вы в требование цепляете задачку в Jira с постановкой на разработку?

Да, когда требование уже оценено, мы в Jira ставим в качестве планируемой оценки ту, которая у нас есть. А фактическая оценка уже получается по факту.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.