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

Характеристики качества требований
Что делает требования хорошими? BABOK 3.0 предоставляет девять характеристик качества требований к ПО, можно использовать их, как чек-лист при написании или тестировании требований:
- Атомарность
- Полнота
- Краткость
- Консистентность
- Выполнимость
- Приоритизированность
- Тестируемость
- Недвусмысленность
- Понятность
Давайте рассмотрим некоторые критерии качества требований подробнее, а также определим, как приблизиться к идеалу.
Атомарность
Атомарное требование - это такое требование, которое нельзя разбить на более детальные требования (которые при этом не потеряют завершенности - то есть, требование, что юзер может залогиниться, введя имейл и пароль, нельзя разбить на 3 юзер стори (пользовательские истории): про поле для имейла, поле для пароля и кнопку входа).
Почему важно, чтобы требования к программному обеспечению были атомарными? Чтобы:
- правильно приоритизировать (сложно приоритизировать юзер стори, которая включает в себя создание, редактирование и удаление поста. Но если разбить ее на 3, становится уже намного легче - из этого набора в МВП явно может входить не всё);
- трассировать (например, ставя зависимость от очень большого требования, в будущем возникает путаница - от какой именно части зависимость?);
- легче разрабатывать (меньше возможностей напутать/пропустить что-то, когда требование небольшое и простое);
- требование быстрее попадет в тестирование - да, это очень важно, QA меня поймут.
Полнота
Полнота - очень важная характеристика качества требований, которая достойна отдельной статьи.

Полнота/подробность требований зависит от нескольких факторов, например, от "взрослости" команды. Например, команда джуниоров может нуждаться в описании того, что такое "спецсимвол" и какие из них можно использовать в пароле. Или, например, что делать, если в поле юзернейм пользователь не ввел ничего, кроме нескольких пробелов: мы такое принимаем вообще, или нужно как-то пробелы обрезать и считать поле с одними пробелами незаполненным?
Набор требований является полным тогда и только тогда, когда он описывает все важные требования, интересующие пользователя, в том числе требования, связанные с функциональными возможностями, производительностью, ограничениями проектирования, атрибутами или внешними интерфейсами (IEEE 830-1993, § 4.3.3, 1994).
Возможные последствия неполных требований:
- система не будет целостной (например, определенное поле, из-за ненадобности, убрали по всей системе, кроме пары страниц, или, наоборот, что-то добавили, а в экспорт данных добавить забыли);
- команда не реализует специфический кейс и система "упадет" во время его выполнения;
- команда реализует кейс не так, как хотелось бы клиенту/вам/было бы правильно для продукта ("додумает" требование сама);
- возникновение множества вопросов у команды (во время реализации и тестирования);
- какие-то нефункциональные требования будут не учтены, и, например, сервер упадет, когда 100 человек одновременно зайдут на сайт.
Добиться полноты требований помогают:
- понимание нефункциональных требований (какие вообще есть, какие применимы к вашему проекту/продукту/юзер стори);
- прототипирование (когда продумываешь интерфейс, начинаешь рассматривать фичу под другим углом);
- диаграммы (будь то активити диаграмма (UML), BPMN, обычный флоучарт или даже ERD (UML) (список можно продолжать) - они все заставляют подумать о различных аспектах требований и дополнить их);
- декомпозиция (когда разбиваешь эпик на истории и пишешь критерии, есть возможность "выловить" что-то еще);
- трассирование требований (или перелинковка в системе управления требованиями - когда есть трассирование, тогда знаешь, что изменения в части А затронут часть Б и требования к системе будут полнее);
- конечно, командная работа - брейншторминги с командой, груминги, обсуждения с UX командой - все это заполняет пробелы и наталкивает на интересные мысли;
- фоллоу-апы звонков и правильные цепочки переписок с клиентами - правильная организация значительно снижает шансы упустить важные детали или забыть, что что-то уже изменилось;
- ревью требований другими аналитиками;
- тестирование требований (QA пишут кейсы/чеклисты тестирования на стори, которые вы считаете готовыми, и находят пробелы).
Хорошие требования - это такие требования, которые не нужно уточнять, то есть, есть все необходимые детали (но без излишней детализации).
Хотите стать бизнес-аналитиком?
Я готовлю онлайн-курс для тех, кто хочет войти в ИТ через БА или перейти в БА внутри ИТ. Когда он выйдет, я сразу оповещу вас!
Оставьте свой e-mailОднозначность
Хорошее требование = однозначное требование.
Однозначность - это важный и сложный критерий качества требований. У каждого человека свой опыт и свой набор знаний, что накладывает определенный отпечаток на восприятие информации. Поэтому требования к ПО нужно стараться писать так, чтобы они были максимально однозначными и понятными для любого человека (то есть, понятными не только аналитику :) ).
Любой человек, читающий требование, должен понимать его так же, как и тот, кто его писал.
Представьте кофе. Представили?
Кто-то представил эспрессо, кто-то американо, кто-то пьет с молоком и представляет латте, а кому-то жарко и хочется освежиться айс латте.

Точно так же и с функциональными и нефункциональными требованиями. Если их можно интерпретировать по-разному, команда так и сделает. Итоги могут быть разные:
- команда реализует не то, что нужно и это уйдет на прод/на демо (менее критично, чем на прод, но = потери времени и порча репутации);
- команда реализует не то, что нужно, но QA отловят, и заставят переделать (потери времени);
- начнутся споры, а как же должно работать, у каждого будет свое мнение, и хорошо, если БА работает на проекте и может разъяснить, а не написал свои юзер стори и ушел на другой проект;
- потери от неоднозначно описанных нефункциональных требований могут быть гораздо больше. Например, в требованиях можно написать "система должна быть секьюрной", имея в виду учет первых трех угроз из списка OWASP, а клиент может ожидать совершенно другого подхода к безопасности, на 100000 $ "серьезнее")
Acceptance criteria (приемочные критерии к юзер стори) типа "система работает быстро", или "интерфейс понятен пользователям" - не измерить, поэтому они неоднозначные. У каждого свое "быстро" и "понятно".
К "неоднозначным" моментам можно также отнести следующие моменты (если они не описаны - реализация может вас удивить):
- значения по умолчанию;
- формат полей;
- допустимые символы;
- реакцию системы на негативные сценарии.
Неоднозначность можно отловить:
- самостоятельно, читая требования через пару дней после написания (перечитывать, "выпав" из контекста);
- проговорив требования с клиентом/продакт оунером;
- обсуждая юзер стори (например) с командой;
- попросив поревьюить требования;
- на демо, когда клиент говорит "ЧТО ВЫ ТАКОЕ СДЕЛАЛИ, Я НЕ ЭТО ПРОСИЛ?!?!".
То есть: качественные требования должны быть понятны всем одинаково.
Выполнимость/осуществимость
Не все требования (как нефункциональные, так и функциональные) возможно выполнить. Некоторые требования невыполнимы, т.к. нелогичны. Некоторые - т.к. на данный момент нет инструментов, которые позволяли бы его выполнить с использованием адекватного количества ресурсов.
Когда-то на груминге мы с командой обсуждали добавление небольшой детальки, которая, казалось, важна для улучшения юзабилити.
- Это невозможно сделать! - сказал мой молодой коллега.
- Ну почему же, это вполне возможно, - возразил более опытный разработчик. - Нужен примерно год.
Иными словами, некоторые требования условно считаются невыполнимыми, т.к. баланс между ценностью и ресурсами является неразумным в данных условиях (у каждого эти условия свои).
Непротиворечивость
Консистентными являются требования, которые не противоречат другим требованиям проекта. Качественные требования не могут быть противоречивыми.
Например, если в dаta dictionary отмечено, что поле Имя - обязательное, а в user story написано, что оно опционально - требования к системе неконсистентны (не непротиворечивы).

Такое обычно происходит, когда:
- бизнес-аналитик забывает, что что-то уже продумал/описал и делает это по-новой в другом месте;
- когда требование меняется, но бизнес-аналитик изменяет его не везде, где оно описано;
- когда бизнес-аналитик невнимателен к граничным значениям - например, приемочные критерии (acceptance criteria) противоречат друг другу - в одном, возраст<= 14 лет - детский, а >=14 - уже подростковый. То есть, 14 относится и к одним, и к другим, чего, скорей всего, автор не добивался;
- когда новый бизнес-аналитик на проекте упустил/не знал про какие-то детали реализации, особенно, когда они не описаны или их сложно отследить в системе управления требованиями;
- когда требования изменили, а дизайнеру сказать забыли.
Также, требования не должны противоречить "вышестоящим" требованиям - например, функциональные требования должны быть консистентны с требованиями пользователя, требования пользователя - с бизнес-требованиями.
Проверить требования на непротиворечивость можно с помощью ревью - собственного/ревью командой.
Вывод:
Для того, чтобы проверить, насколько хороши требования (ваши или БА на вашем проекте) - воспользуйтесь критериями качества требований, которые я описала выше.
Что еще должен уметь бизнес-аналитик - читайте в статье.
И подписывайтесь, чтобы не пропустить новые статьи о бизнес-анализе.