В рамках своей работы и ведения подкаста по бизнес-анализу (ссылка на подкаст), я часто получаю вопросы от бизнес-аналитиков. И один из самых частых - как задокументировать нефункциональные требования, если на проекте принят стандарт написания пользовательских историй? Сегодня, я хотела бы поделиться переводом статьи Майка Кона, о том, как описать нефункциональные требования с помощью пользовательских историй. Ссылка на оригинал на английском.

Поехали!

Распространенной проблемой при написании пользовательских историй является то, как справиться с нефункциональными требованиями к продукту. Это требования, которые касаются не конкретной функциональности («Как пользователь текстового редактора, я хочу вставить таблицу в свой документ»), а скорее атрибута или характеристики системы. Примеры включают надежность, доступность, переносимость, масштабируемость, удобство использования, ремонтопригодность.

Примечание: В оригинале статьи дается подсказка, что в английском языке большинство нефункциональных требований заканчиваются на "-ility" с несколькими исключениями. Для тех, кто работает на любом другом языке, эта подсказка не подходит. Для себя я выделила простое правило: все, что описывает, какие функции пользователь может выполнять в системе - это функциональные требования. Все, что описывает то, как быстро, безопасно или в какой среде эти функции выполняются - нефункциональные требования. Но далее, Майк Кон поделится своей шпаргалкой, как он понимает нефункциональные требования.

Вспоминая темные века, я могу вспомнить, когда впервые прочитал о «нефункциональных требованиях». Этот термин поставил меня в тупик. Если это нефункционально, то почему меня это волнует? Я уверен, что автор этой книги разъяснил мне это на странице позже, но этот термин всегда казался мне странным. Я предпочитаю думать о нефункциональных требованиях как об ограничениях, которые мы накладываем на систему. Когда владелец продукта (Product owner) говорит, что «система должна адекватно работать, когда в ней одновременно находятся 100 000 пользователей», владелец продукта налагает ограничения на команду разработчиков.

https://habr.com/ru/post/684264/?utm_source=habrahabr&utm_medium=rss&utm_campaign=684264