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

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

Что делает требования хорошими? 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 относится и к одним, и к другим, чего, скорей всего, автор не добивался;
• когда новый бизнес-аналитик на проекте упустил/не знал про какие-то детали реализации, особенно, когда они не описаны или их сложно отследить в системе управления требованиями;
• когда требования изменили, а дизайнеру сказать забыли.

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

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

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

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

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

Related posts:

How to write Software Requirement Specification

The Ultimate Guide to Product Owner Duties: A Blueprint for Success in 2023

How to become a Certified Scrum Product Owner?