Здравствуйте коллеги, мы с вами продолжаем изучать область знания под названием Анализ требований определения дизайна свода знаний по бизнес-анализу BABOK версии 3.0. На предыдущих занятиях мы с вами рассмотрели подробно задачи 7.1 и 7.2.
7.1 - это Специфицирование и моделирование требований, задача 7.2 - Верификация требований. Напомню еще раз, что BABOK разделяет два важных действия, которые надо сделать с требованиями, после того как вы их каким-то сформулировали в ходе задачи 7.1. Их необходимо верифицировать, то есть проверить на корректность и требования к качеству, формальное или по сути, и так далее и валидировать, то есть проверить на то, что оно нужно и приносит ценность.
Если 7.2 Верификации требований больше формальный аспект, что требование корректное по форме, в нем нет ошибок, то 7.3 Валидация требований - это уже более творческая задача о том, что данные требования должны приносить ценность заинтересованным сторонам, достаточную, чтобы работать с ним дальше.
Давайте посмотрим, как BABOK подходит к решению данной задачи 7.3 Валидация требований. Назначение задачи - удостовериться что все требования и дизайн решений соответствует бизнес требованиям и обеспечивают необходимую ценность. Я уже говорил о том, что все требования заинтересованных сторон лежат ниже наших бизнес требований и тоже должны быть в рамках наших бизнес требований. Не должно быть требований заинтересованных сторон, которые каким-то образом не привязаны к бизнес требованиям. Данное требование тогда не пройдет валидацию. Это один из шагов, которые вам необходимо сделать в этой задаче.
Давайте посмотрим на окружение данной задачи. 7.3 Валидация требований на вход поступает выход задачи 7.1 Специфицирование и моделирование требований. Если вы вспомните задачу 7.2 Верификация требований, то там тоже на вход подавался результат выполнения Спецификации моделирования - это означает, что задачи по верификации и валидации можно выполнять параллельно, если требования и там и там на вход поступают одинаковые.
Далее - бизнес-цели. Здесь я уже говорил о том, что назначение задач – удостовериться, что все требования соответствуют бизнес-требованиям и обеспечить необходимую ценность. Для этого нужно обязательно понимать бизнес-цели. Какие у нас могут быть будущие состояния и потенциальная ценность. Эти три элемента тоже помогут нам при валидации наших требований и, безусловно определят границы решения.
После выполнения задачи 7.3 Валидация требований, требования считаются валидированы. Давайте посмотрим какие у нас есть элементы:
Первый пункт — это ожидания заинтересованных сторон. Задача валидации должна быть формализована, но на практике она выполняется по какому-то чек-листу. Просто, когда заинтересованные лица в ходе беседы каким-то образом доказывают, что это требование принесет заявленную ценность, корректно в рамках верификации и с ним можно продолжать дальнейшую работу. Поэтому очень важно при выполнении данной задачи, понимать, каковы ожидания заинтересованных сторон.
При этом получается, что заинтересованные стороны – все. И, давайте подумаем - по каким причинам требование может не пройти валидацию. Самое простое, если вспомнить наш с вами проект по внедрению информационной системы. В начале проекта мы собирали требования к информационной системе и смотрели на наш рынок и так далее. За это время могло выйти новое положение в бухгалтерском учете, который меняет порядок расчета, или меняет отражение, или меняет ставку налога. Таким образом, несмотря на то что мы с вами верифицировали данное требование и определили, что оно правильно и корректно, и так далее, но оно не прошло валидацию. И, у каждой группы заинтересованных сторон, возможно, будут свои причины, которые затруднят валидацию того или иного требования. У регулятора это могут быть какие-то внутренние нормативы. То есть требование хорошее, но по каким-то причинам конфликтует с нашими внутренними правилами. Из-за этого оно проходит верификацию, но не проходит внутреннюю валидацию. Отдел внутреннего аудита возражает против реализации данного требования.
Необходимы измеримые критерии оценки, потому что с верификацией легче, а при валидации то, что мы считаем валидированным требованием, а что нет - бывает трудно определить. Допустим, что для конечного пользователя важна скорость работы системы и требование может не пройти верификацию, потому что не представляет для него той ценности, на которую он рассчитывает. Он говорит, что «ваша система работает медленно. Да вы написали хорошие требования, но оно работает не так как я ожидал».
Поговорим о границах решения, которые мы при валидации должны учитывать, потому что часто заказчики просят чего-то, что выходит за границы решения. И здесь мы это должны либо четко отсекать, либо изменить границы нашего решения. Это зависит от вашей стратегии. Если мы вначале собираем требования, а после этого их реализуем - это один подход. При этом для нас любое изменение требований является проблемой. А если у нас с вами гибкий подход и соответствующее финансирование, для нас любое изменение требований - норма жизни, поэтому все зависит от того, как организовано у нас управление проектом.
Давайте посмотрим, какие же у нас методы бизнес-анализа могут нам помочь при валидации наших требований.
-
Финансовый анализ — это тоже очень важный метод, потому что мы любое наше решение должны подкреплять финансовым анализом. Если мы пускаем требования в дальнейшую работу, мы должны подтвердить, что от их реализации будет какой-то финансовый результат. Это у нас финансовый анализ.
-
Анализ управления рисками. Допустим требования у нас хорошее, оно прошло верификацию, но не прошло валидацию из-за того, что оно слишком рискованно и его реализация не является приемлемой с точки зрения риска. Соответствующая заинтересованная сторона — это будет риск-менеджер, не дает добро, потому что уровень риска превышает допустимый для данной организации.
-
Отслеживание элементов. В ходе валидации возникают вопросы и пожелания, корректировки и так далее. Эти все элементы необходимо отслеживать каким-то образом и, чтобы ничего из этого не терялось. Это отдельная тема – отслеживание и управление изменениями. Не всегда изменения можно отслеживать документально. На это необходимо обратить внимание, потому что при валидации это особенно важно. Заинтересованная сторона не всегда готова быстро валидировать требование, поэтому отслеживать эти открытые вопросы в ходе валидации очень важно.
Давайте подведем какой-то итог по валидации. Что является результатом? Результатом являются валидированные требования и дизайн. Это означает что они могут принести ценность для заинтересованных сторон, они соответствуют бизнес-целям и задачам изменения, которому, собственно, посвящена наша инициатива бизнес-анализа.
Таким образом мы с вами подробно рассмотрели задачу 7.3 Валидация требований. Она посвящена тому, чтобы подтвердить ценность наших требований, и чтобы их можно было использовать в дальнейшей работе. Если верификация - это такая формальная проверка на корректность, формулировку, соответствие шаблону, лаконичность, то валидация требований - это проверка на бизнес-ценность, соответствию бизнес-целям, соответствию ожиданиям заинтересованных сторон, необходимый уровень возможной выгоды и так далее. На этом по задаче 7.3 все. Следующая задача у нас будет посвящена определению архитектуры требований. На этом я с вами прощаюсь, всего доброго, до свидания.
В лекции рассматривается задача 7.3 «Валидация требований» из BABOK.
Спикер напоминает, что после формулировки требований (7.1) с ними нужно сделать два действия: проверить форму (верификация, 7.2) и проверить ценность (валидация, 7.3). Верификация — это формальный процесс поиска ошибок, а валидация — творческий процесс подтверждения полезности.
На вход задачи поступают специфицированные требования из задачи 7.1. На выходе мы получаем валидированные требования, готовые к дальнейшей работе.
Чтобы требование считалось валидным, оно должно соответствовать:
• Бизнес-целям проекта;
• Ожиданиям заинтересованных сторон;
• Находиться в рамках границ решения.
Лектор приводит примеры, почему требование может не пройти валидацию:
1. Изменение внешней среды (например, вышел новый закон).
2. Внутренние ограничения (отдел аудита запретил).
3. Неудовлетворенность пользователя (низкая скорость работы).
4. Высокие риски.
5. Выход за границы проекта (заказчик просит то, что не входит в рамки решения).
Для успешной валидации используются методы: финансовый анализ (оценка выгоды), анализ рисков (оценка угроз) и отслеживание элементов (учет замечаний и открытых вопросов).
1. Валидация требований является критическим этапом, отсеивающим бесполезные или устаревшие требования перед их реализацией.
2. В отличие от верификации (проверка «сделали ли мы продукт правильно»), валидация отвечает на вопрос «сделали ли мы правильный продукт».
3. Процесс валидации не может быть полностью формальным; он требует вовлечения всех заинтересованных сторон и учета их субъективных ожиданий ценности.
4. Результат валидации напрямую зависит от контекста проекта (жесткий или гибкий подход к управлению изменениями) и актуальности бизнес-целей.
1. В чем ключевое различие между задачами 7.2 (Верификация требований) и 7.3 (Валидация требований)?
2. Какие элементы (входные данные) необходимы для того, чтобы провести валидацию требований?
3. Назовите три возможные причины, по которым корректно составленное требование может не пройти валидацию.
4. Какие методы бизнес-анализа рекомендуются для оценки ценности требований в ходе валидации?
5. Что является итоговым результатом успешного выполнения задачи 7.3?
