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