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

Поехали!

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

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

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

Владелец продукта, по сути, говорит: «Разрабатывайте это программное обеспечение любым удобным для вас способом, пока вы не достигнете адекватной работы приложения при 100 000 одновременных пользователей». Каждое ограничение, которое мы накладываем на систему, немного сужает выбор реализации, и называя это «ограничениями», а не «нефункциональными требованиями», мы помогаем себе помнить об этом.

Ограничения/нефункциональные требования можно легко обрабатывать как пользовательские истории. Вот несколько примеров:

1. Как клиент, я хочу иметь возможность запускать систему во всех версиях Windows, начиная с Windows 95.

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

3. Как пользователь, я хочу, чтобы сайт был доступен 99,999% времени, когда я пытаюсь получить к нему доступ, чтобы я не расстраивался и не искал другой сайт для использования.

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

5. Как пользователь, я хочу, чтобы маршруты проезда были оптимальными в 90% случаев.

Как вы можете видеть из примеров, я легко смог придерживаться шаблона «Как, я хочу, так что», который я предпочитаю для большинства пользовательских историй. Я делаю это по нескольким причинам, но хочу прокомментировать здесь только одну из них. Рассмотрим пример №2, когда технический директор ограничивает команду использованием существующей базы данных заказов. Это была реальная ситуация: команда рассматривала вторую базу данных заказов, которая будет синхронизироваться ночью. Технический директор услышал это и сказал: «Нет!».

Если бы мы написали это требование просто: «Должна использоваться существующая база данных заказов», вполне возможно, что через несколько месяцев мы бы не вспомнили, почему мы ограничили себя таким образом. 

Написание ограничений/нефункциональных требований от имени человека, который чего-то хочет, может быть очень полезным. Но вы должны быть осторожны, чтобы не зацикливаться на этом шаблоне. Это всего лишь инструмент мышления. Попытка написать ограничение/нефункциональное требование в этот шаблон — хорошее упражнение, поскольку оно помогает убедиться, что вы понимаете, кто и что хочет, и главное - с какой целью. Но если вы в конечном итоге сформулируете запутанное утверждение - отбросьте шаблон. Если вы не можете найти способ сформулировать ограничение, просто напишите ограничение так, как вам кажется будет понятно для команды.

Книги и статья Майка Кона, которые мне очень нравятся:

1. Книга "Пользовательские истории" ("User stories upplied") - для всех, кто хочет понять больше об использовании пользовательских историй. Описание доступно по ссылке.

2. Книга "Оценка и планирование проектов" ("Agile estimating and planning") - для всех, кто хочет разобраться, как же планировать и оценивать время на Agile проекты, в которых все уж очень непонятно. Описание доступно по ссылке.