Что нужно назвать требованиями, которые «предполагаются» /«невидимыми» /«очень очевидными»,

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

В понимании клиента они думают о требованиях к заголовку, в основных историях пользователей, таких как «Мне нужно иметь возможность просматривать состояние всего оборудования» и «Мне нужно автоматически получать сбой любого оборудования». Но временами мирские есть, но клиент никогда не упоминает их, пока результат не будет отличаться от его невысказанных ожиданий: «Ну, конечно, пользователь должен иметь возможность изменить свой пароль» и « Конечно, сеанс пользователя должен истечь через 30 минут "

Любая команда разработчиков может предвидеть, что может понадобиться, но есть ли название для этой категории требований? Очевидные /инфраструктурные /скучные /детали?

6 голосов | спросил djnz0feh 16 +04002013-10-16T19:21:41+04:00312013bEurope/MoscowWed, 16 Oct 2013 19:21:41 +0400 2013, 19:21:41

4 ответа


13

Детали инфраструктуры называются «нефункциональными» требованиями. Это странный термин, описывающий те требования, которые не видны конечному пользователю, но по-прежнему необходимы для правильной работы приложения.

Однако

  

Приложение должно предоставить механизм, позволяющий пользователю изменять свой пароль

и

  

Пользовательский сеанс должен истечь через 30 минут

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

ответил Robert Harvey 16 +04002013-10-16T19:30:02+04:00312013bEurope/MoscowWed, 16 Oct 2013 19:30:02 +0400 2013, 19:30:02
12

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

ответил TMN 16 +04002013-10-16T19:31:16+04:00312013bEurope/MoscowWed, 16 Oct 2013 19:31:16 +0400 2013, 19:31:16
8

Я думаю, что самое близкое, о чем я могу думать, было бы «производным требованием». Это требования, которые генерирует команда разработчиков, основанная на ряде источников, таких как регулирующие органы, корпоративные руководящие принципы и опыт прошлых лет по аналогичным проектам.

Однако даже после получения дополнительных требований от требований клиента /пользователя важно проверить их с клиентом /пользователем, чтобы убедиться, что они верны. После их проверки вы отслеживаете их так же, как и все остальные требования. Обратите внимание, что только потому, что некоторые рекомендации или опыт подсказывают, что требование не означает, что клиент этого хочет. Фактически, это может противоречить ожидаемому из системы.

ответил Thomas Owens 16 +04002013-10-16T20:44:17+04:00312013bEurope/MoscowWed, 16 Oct 2013 20:44:17 +0400 2013, 20:44:17
6

Я бы просто пошел с assumptions (или, unwritten assumptions, если это будет более точно).

Implicit, из другого ответа, не совсем работает, потому что запрошенное не обязательно полагается на них. Например, user must be able to change their password не является неявным, если другое требование не делает ссылку на пользователя, изменяющего свой пароль, с предположением, что он уже работает.

Very obvious, на самом деле тоже не работает. Это может легко быть чем-то, что только очевидно для кого-то с соответствующими знаниями домена или работает очень тесно с продуктом. Или, чтобы использовать пример пароля, может быть, пользователи не должны изменять свои пароли, и могут только администраторы.

То, что вы описываете, это вещи, которые будут выполняться клиентом assumed.

ответил Izkata 17 +04002013-10-17T00:46:06+04:00312013bEurope/MoscowThu, 17 Oct 2013 00:46:06 +0400 2013, 00:46:06

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132