Привет! Хочу поделиться парой мыслей о представлении нефункциональных требований в формате User Story. Вы наверняка помните самый распространенный шаблон для историй. В шаблоне есть три части «кто», «хочет что», «чтобы что». Чтобы соблюдать такой формат, важно выделить действующие роли и цели для каждой истории. Для нефункциональных требований это бывает непросто и я часто думаю: «А нужно ли?».
Майк Кон в своем блоге пишет, что нефункциональные требования хорошо ложатся в стандартный шаблон пользовательской истории и что такой шаблон позволяет не забыть, почему это требование появилось. В статье «Нефункциональные требования как пользовательские истории» (Non-functional Requirements as User Stories) приведены кейсы, среди которых есть несколько «синтетические». Например, на мой вкус странно выглядит история вида «Как человек, говорящий на одном из латиноамериканских языков, я, возможно, когда-нибудь захочу запустить ваше программное обеспечение». Как работать с такой историей в бэклоге? Сможет ли команда адекватно ее декомпозировать на атомарные задачи?
Обычно бывает интересно почитать не только саму статью в блоге, но и комменты к ней. В комментариях к статье Майка Кона как раз есть похожие вопросы:
Как оценить таким образом сформулированное НФТ?
Как сформулировать пользовательскую историю, чтобы описать взаимодействие двух систем? Нужно ли ее формулировать в таком случае?
-
Правильно ли понимать, что пользовательские истории в случае НФТ нужны только для напоминания команде, но не для разработки?
Дополню эти вопросы парой наблюдений и вопросов, которые заметила из своего опыта
????Нефункциональные требования относятся к системе в целом, но не к конкретной функциональности. Возьмем к примеру требования к авторизации. Скажем, в приложении для он‑лайн бронирования авиабилетов, только авторизованные пользователи могут оформить бронирование. На мой взгляд, лучше всего показывают контекст требования истории вида «Я, как пользователь хочу иметь Личный кабинет, чтобы хранить данные для автоматического заполнения полей при бронировании» и «Я, как специалист по кибербезопасности хочу знать, кто имеет доступ к бронированию и персональными данным». Действительно, хорошо виден контекст, но есть важный нюанс...
При формулировке других историй будет важно учесть, что заявленный «кто» должен быть авторизованным пользователем и при просмотре результатов поиска, и при отображении действий для каждого билета и многих других действиях. Может выстроиться громоздкая и неочевидная структура, в которой почти все истории зависят от некоей «нефункциональной». Удобно ли работать с таким бэклогом?
????Часто записать НФТ в форме пользовательской истории означает — для уже сформулированного свойства решения определить, кто в нем может быть заинтересован и для чего. Получается, что к следствию нужно придумать причины. Обычно именно в таких случаях получаются формулировки с одушевлением систем: «Я, как Система хочу, чтобы пользователь указывал логин и пароль, чтобы правильно логировать действия пользователя». Еще могут получиться формулировки, где пользователю присваивается неестественное поведение «Я, как пользователь хочу войти в Систему, чтобы быстрее перейти к бронированию». Если человек действительно хочет скорее перейти к бронированию, то ввод логина и пароля будет восприниматься как помеха, а не как ожидаемая функция. В обоих вариантах формулировок получается искажение контекста.
Резюме. На мой взгляд любой инструмент, в том числе и пользовательские истории, имеет смысл выбирать под конкретные цели. Прежде чем формулировать нефункциональное требование в формате истории я бы посоветовала подумать как эта история будет использоваться командой? Формат отдельной истории для нефункционального требования полезен, только если история действительно нужна вашей команде как элемент бэклога. Иначе не нужно одушевлять системы или приписывать пользователям какие‑то хотелки. Вместо этого требование можно фиксировать вместе с другими нефункциональными требованиями короткой фразой. Например, «Доступ к функциям должен предоставляться на основании ролей пользователей и схемы разграничения прав доступа между ними». Будет достаточно сослаться на это требование в критериях приемки других историй и задач, где необходимо.