Как задокументировать нефункциональные требования (NFR) в истории/функции?

Q1: Да, определенно могут. Взгляните на эту статью, описывающую обработку нефункциональных требований. в историях пользователей.

Q2. С моей точки зрения, если вы можете их создать, их действительно стоит хранить и отслеживать таким образом. Но ссылка на эту статью

Не существует волшебной agile-практики, которая поможет вам раскрыть NFR. Первый шаг – взять на себя ответственность. NFR можно представить в виде пользовательских историй, если команда считает, что это помогает сохранить их видимыми. Однако имейте в виду, что появление таких историй может создать проблемы, связанные с приоритетом проделанной над ними работы по сравнению с более очевидными функциями.

Q3. Взгляните на упомянутую статью из Q1.

Я дам ответ, проработав пример.

Допустим, ваша команда уже реализовала следующую историю:

Scenario: User can log in to the website
   Given I have entered my login credentials
   When I submit these credentials
   Then I get navigated to my home screen

Чтобы ответить на вопрос 1) – Можно ли указать нефункциональное требование в виде истории?

Заинтересованные стороны проекта предоставили вам NFR, который гласит:

Для всех действий на сайте пользователь должен ждать ответа не более пяти секунд.

Вы можете создать историю для этого следующим образом:

Scenario: User can log in to the website in a timely fashion
   Given I have entered my login credentials
   When I submit these credentials
   Then I get navigated to my home screen
   And I should have to wait no longer than the maximum acceptable wait time

Обратите внимание, что вместо обязательного указания «5» секунд я оставил сценарий декларативным и вместо этого указал «подождать не дольше максимально допустимого времени ожидания».

Чтобы ответить на вопрос 2) – Следует ли указывать нефункциональное требование в виде истории?

NFR должны определенно указываться как история.

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

Следовательно, в моем надуманном примере команда уже внедрила код для входа в систему, но затем они определили, как реализовать требование о том, что вход в систему должен занимать не более 5 секунд. Вы также позволите иметь возможность исследуйте обратную сторону этой проблемы, то есть что произойдет, если для входа в систему потребуется более пяти секунд? например

Scenario: User encounters a delay when logging in to the website
       Given I have entered my login credentials
       When I submit these credentials
       And I wait for over the the maximum acceptable wait time
       Then the Production team is informed
       And the problem is logged
       And I get navigated to my home screen

И, наконец, относительно вопроса 3) — Как будет выглядеть история?

Я подробно описал, как будут выглядеть истории в ответах 1) и 2)

Я думаю, что границы НФО до сих пор не все полностью согласованы. Рассмотрим историю, в которой говорится: «Как менеджер, мой сотрудник должен получить все ответы в течение 5 секунд, чтобы избежать найма второго лица, вводящего данные, и увеличения расходов на заработную плату на 50 000 долларов». Я считаю это полнофункциональным бизнес-требованием, наряду с любыми требованиями к производительности, ориентированными на взаимодействие с конечным пользователем.

Я отношу к «традиционным» NFR истории, в которых пострадавшее лицо не входит в организацию конечного пользователя или заинтересованного лица. «Как сотруднику службы поддержки мне нужны журналы трафика веб-сайта, чтобы помочь мне в устранении неполадок» или «Как специалисту по сопровождению программного обеспечения, мне нужна блок-схема архитектуры, чтобы помочь мне вносить изменения». Включение роли, как и в любой пользовательской истории, помогает расставить приоритеты. Это также помогает определить заинтересованное лицо для этого NFR, если у вас возникнут какие-либо вопросы по этому поводу.

NFR могут включать некоторые аспекты производительности, по крайней мере те, которые не влияют на конечного пользователя. «Как системный администратор я хочу выделить для базы данных не более 10 ГБ дискового пространства, чтобы использовать SQL Express и избежать дорогостоящих лицензий SQL Server».

Рассмотрим типичный NFR, в котором может быть указано только «Базы данных ограничены 10 ГБ». Это произвольное число, не имеющее смысла или обоснования, и нет никакого способа подвергнуть его сомнению. Роль, похожая на историю, и объяснение помогают всем понять, что для NFR есть веская причина, поэтому, когда вы расставляете приоритеты, вы можете задавать умные вопросы. Они приводят к разговорам типа «Мне нужно расширить табличное пространство до 20 ГБ, но у системного администратора есть этот NFR о размере базы данных. Сколько на самом деле стоят ему лицензии SQL Server? и сэкономьте несколько ГБ, чтобы поместить его туда».

Как показывают и @bensmith, и @siemic, да, вы можете запечатлеть NFR в виде историй.

Следует ли снимать их таким образом?

Я не думаю, что вы хотите запечатлеть NFR как часть обычных тематических статей.

Большинство NFR применимы более чем к одной истории. «Система должна быть отзывчивой» означает, что каждая история должна определять максимальное время ожидания. «Система не должна занимать более 10 ГБ дискового пространства» означает, что каждая история должна учитывать дисковое пространство. Список «и» в рассказе становится неуправляемым даже в тривиальных случаях.

Вы можете зафиксировать NFR как независимые истории, если владелец продукта и команда согласны с этим.

Например:

Given I have a PC with at least a dual core processor 
  and 8GB of RAM
  and a gigabit connection to the system
when I interact with the system
then I never have to wait more than 5 seconds for a response
 and 90% of attempts respond within 1 second

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

Я думаю, вам нужно обратить внимание на несколько моментов: NFR должны соответствовать сроку службы приложения, программного обеспечения, продукта и т. д. Необходимо регулярно рассматривать сценарии резервного копирования и восстановления, проверки безопасности и производительность следует измерять как в процессе производства, так и в процессе разработки. Многие NFR нуждаются в проверке со стороны команд, не входящих в группу разработчиков, поэтому не ожидается, что для проверки будет написан сценарий или код. Таким образом, очевидно, что безопасность, производительность, масштабируемость, отказоустойчивость и т. д. могут и должны быть протестированы на этапе разработки или до того, как код будет запущен в работу. Большинство NFR можно изложить в виде историй, но, как я уже сказал, я не думаю, что все они нуждаются в усилиях разработчиков, чтобы охватить их. с уважением Мартин