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

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

Что делает требования хорошими? BABOK 3.0 предоставляет девять характеристик качества требований к ПО, можно использовать их, как чек-лист при написании или тестировании требований:

• Атомарность
• Полнота
• Краткость
• Консистентность
• Выполнимость
• Приоритизированность
• Тестируемость
• Недвусмысленность
• Понятность

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

Атомарность

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

Почему важно, чтобы требования к программному обеспечению были атомарными? Чтобы:

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

Полнота

Полнота - очень важная характеристика качества требований, которая достойна отдельной статьи.

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

Набор требований является полным тогда и только тогда, когда он описывает все важные требования, интересующие пользователя, в том числе требования, связанные с функциональными возможностями, производительностью, ограничениями проектирования, атрибутами или внешними интерфейсами (IEEE 830-1993, § 4.3.3, 1994).

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

• система не будет целостной (например, определенное поле, из-за ненадобности, убрали по всей системе, кроме пары страниц, или, наоборот, что-то добавили, а в экспорт данных добавить забыли);
• команда не реализует специфический кейс и система "упадет" во время его выполнения;
• команда реализует кейс не так, как хотелось бы клиенту/вам/было бы правильно для продукта ("додумает" требование сама);
• возникновение множества вопросов у команды (во время реализации и тестирования);
• какие-то нефункциональные требования будут не учтены, и, например, сервер упадет, когда 100 человек одновременно зайдут на сайт.

Добиться полноты требований помогают:

• понимание нефункциональных требований (какие вообще есть, какие применимы к вашему проекту/продукту/юзер стори);
• прототипирование (когда продумываешь интерфейс, начинаешь рассматривать фичу под другим углом);
• диаграммы (будь то активити диаграмма (UML), BPMN, обычный флоучарт или даже ERD (UML) (список можно продолжать) - они все заставляют подумать о различных аспектах требований и дополнить их);
• декомпозиция (когда разбиваешь эпик на истории и пишешь критерии, есть возможность "выловить" что-то еще);
• трассирование требований (или перелинковка в системе управления требованиями - когда есть трассирование, тогда знаешь, что изменения в части А затронут часть Б и требования к системе будут полнее);
• конечно, командная работа - брейншторминги с командой, груминги, обсуждения с UX командой - все это заполняет пробелы и наталкивает на интересные мысли;
• фоллоу-апы звонков и правильные цепочки переписок с клиентами - правильная организация значительно снижает шансы упустить важные детали или забыть, что что-то уже изменилось;
• ревью требований другими аналитиками;
• тестирование требований (QA пишут кейсы/чеклисты тестирования на стори, которые вы считаете готовыми, и находят пробелы).

Хорошие требования - это такие требования, которые не нужно уточнять, то есть, есть все необходимые детали (но без излишней детализации).

Однозначность

Хорошее требование = однозначное требование.

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

Любой человек, читающий требование, должен понимать его так же, как и тот, кто его писал.

Представьте кофе. Представили?

Кто-то представил эспрессо, кто-то американо, кто-то пьет с молоком и представляет латте, а кому-то жарко и хочется освежиться айс латте.

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

• команда реализует не то, что нужно и это уйдет на прод/на демо (менее критично, чем на прод, но = потери времени и порча репутации);
• команда реализует не то, что нужно, но QA отловят, и заставят переделать (потери времени);
• начнутся споры, а как же должно работать, у каждого будет свое мнение, и хорошо, если БА работает на проекте и может разъяснить, а не написал свои юзер стори и ушел на другой проект;
• потери от неоднозначно описанных нефункциональных требований могут быть гораздо больше. Например, в требованиях можно написать "система должна быть секьюрной", имея в виду учет первых трех угроз из списка OWASP, а клиент может ожидать совершенно другого подхода к безопасности, на 100000 $ "серьезнее")

Acceptance criteria (приемочные критерии к юзер стори) типа "система работает быстро", или "интерфейс понятен пользователям" - не измерить, поэтому они неоднозначные. У каждого свое "быстро" и "понятно".

К "неоднозначным" моментам можно также отнести следующие моменты (если они не описаны - реализация может вас удивить):

• значения по умолчанию;
• формат полей;
• допустимые символы;
• реакцию системы на негативные сценарии.

Неоднозначность можно отловить:

• самостоятельно, читая требования через пару дней после написания (перечитывать, "выпав" из контекста);
• проговорив требования с клиентом/продакт оунером;
• обсуждая юзер стори (например) с командой;
• попросив поревьюить требования;
• на демо, когда клиент говорит "ЧТО ВЫ ТАКОЕ СДЕЛАЛИ, Я НЕ ЭТО ПРОСИЛ?!?!".

То есть: качественные требования должны быть понятны всем одинаково.

Выполнимость/осуществимость

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

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

- Это невозможно сделать! - сказал мой молодой коллега.

- Ну почему же, это вполне возможно, - возразил более опытный разработчик. - Нужен примерно год.

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

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

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

Например, если в dаta dictionary отмечено, что поле Имя - обязательное, а в user story написано, что оно опционально - требования к системе неконсистентны (не непротиворечивы).

Такое обычно происходит, когда:

• бизнес-аналитик забывает, что что-то уже продумал/описал и делает это по-новой в другом месте;
• когда требование меняется, но бизнес-аналитик изменяет его не везде, где оно описано;
• когда бизнес-аналитик невнимателен к граничным значениям - например, приемочные критерии (acceptance criteria) противоречат друг другу - в одном, возраст<= 14 лет - детский, а >=14 - уже подростковый. То есть, 14 относится и к одним, и к другим, чего, скорей всего, автор не добивался;
• когда новый бизнес-аналитик на проекте упустил/не знал про какие-то детали реализации, особенно, когда они не описаны или их сложно отследить в системе управления требованиями;
• когда требования изменили, а дизайнеру сказать забыли.

Также, требования не должны противоречить "вышестоящим" требованиям - например, функциональные требования должны быть консистентны с требованиями пользователя, требования пользователя - с бизнес-требованиями.

Проверить требования на непротиворечивость можно с помощью ревью - собственного/ревью командой.

Вывод:
Для того, чтобы проверить, насколько хороши требования (ваши или БА на вашем проекте) - воспользуйтесь критериями качества требований, которые я описала выше.

Что еще должен уметь бизнес-аналитик - читайте в статье.

И подписывайтесь, чтобы не пропустить новые статьи о бизнес-анализе.