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

Question

В заявлении Specification By Example book указывается, что нефункциональные требования (обычно называемые NFR) могут быть указаны с использованием примеров.

Я также сообщил коллеге, что нефункциональные требования могут быть описаны с помощью истории SBE, используя формат:

Scenario: ... 
    Given ... 
    When ... 
    Then ... 

Ниже приведен пример функционального и нефункциональные требования приняты от wikipedia:

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

Вопрос 1: Может ли нефункциональные требования быть определены как история?

Вопрос 2: Должны ли нефункциональные требования быть указаны как история?

Вопрос 3: На что похожа история?

Answer 1

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

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

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

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

Answer 2

Я дам ответ, выполнив пример.

Будем говорить, что ваша команда уже реализовала следующую историю:

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) - Если нефункциональное требование должно быть указано как история?

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

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

Следовательно, в моем надуманном примере команда уже внедрила бы код для входа в систему, но затем они определяли, как реализовать требование о том, что для входа требуется не более 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)

Answer 3

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

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

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

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

Answer 4

Как и для @bensmith, так и для @siemic show, да, вы можете захватывать NFR как рассказы.

Должно ли вы их захватываете?

Я не думаю, что вы хотите захватить НФР как часть регулярных сюжетов.

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

You may хотите захватить 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 

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

Answer 5

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