Функциональное или нефункциональное требование?

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

Меня интересуют требования, которые не связаны с какими-либо действиями или имеют некоторые дополнительные условия, например:

1. В списке выбранных устройств устройство можно повторить.
2. База данных должна содержать не менее 100 наименований
3. Валюта некоторого значения должна быть в долларах США.
4. Устройство должно иметь имя и значение потребляемой мощности в ваттах.

эти требования являются функциональными или нефункциональными?

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

При оформлении нового заказа система отображает общую стоимость и требует подтверждения от пользователя. Это функциональное требование; это описывает функцию системы.

Обратитесь к Wikipedia: Функциональное требование для получения более подробной информации.

Нефункциональные требования - это любые требования, которые не описывают поведение системы ввода / вывода. Обратите внимание, что мы по-прежнему говорим о требованиях , а не о деталях реализации , поэтому просто потому, что мы используем фразу «нефункционально», не означает, что в этот раздел можно поместить что- то честное.

Наиболее распространенные типы нефункциональных требований, которые вы увидите, относятся к работе системы (доступность, непрерывность, аварийное восстановление), производительности (пропускная способность, задержка, емкость хранилища) и безопасности (аутентификация, авторизация, аудит, конфиденциальность).

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

Нефункциональные требования не являются субъективными или неубедительными, в отличие от того, что некоторые люди здесь, кажется, предлагают. На самом деле к ним должна быть прикреплена жесткая метрика (то есть время отклика не более 100 мс). Требования NF также не являются деталями реализации или задачами, такими как «обновление инфраструктуры ORM» - понятия не имею, где кто-то может получить эту идею.

Подробнее в Википедии: Нефункциональное требование .

Чтобы конкретно обратиться к примерам в вопросе:

1. В списке выбранных устройств устройство можно повторить.

   • Очевидно, функциональное требование. Описывает, как выглядит вывод системы.

2. База данных должна содержать не менее 100 наименований

   • Похоже, бизнес-правило, а также функциональное требование. Тем не менее, это кажется неполным. В чем причина этого правила? Что произойдет / должно произойти, если база данных содержит менее 100 элементов?

3. Валюта некоторого значения должна быть в долларах США.

   • Функциональное требование, но не совсем правильно сформулированное. Более полезная формулировка: система должна поддерживать одну валюту (доллары США). Очевидно, что это будет изменено, если потребуется поддержка более чем одной валюты, а затем требование должно будет включать информацию о конвертации валют и так далее.

4. Устройство должно иметь имя и значение потребляемой мощности в ваттах.

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

Aaronaught уже получил отличный ответ, но поскольку были и другие, уже удаленные ответы, которые были совершенно неверными в отношении того, что является нефункциональным требованием, я думаю, что было бы полезно добавить несколько объяснений, чтобы избежать ошибок в том, что нефункциональное требование есть.

Нефункциональное требование - это «качество или свойство, которым должен обладать продукт» ¹. Джеймс Тейлор говорит, что нефункциональное требование «[...] является [тем не менее] требованием, и оно важно для клиента - иногда даже важнее, чем функциональное требование» . Затем он приводит два примера: логотип продукта, а также точность и надежность оборудования. Оба эти примера очень хорошо показывают, что:

• Нефункциональные требования не похожи на маркетинговые jibber-jabber: «Интернет важен в наше время, и мы хотим иметь веб-сайт».
• Нефункциональные требования касаются клиентов, так как они могут сильно повлиять на их производительность и саму возможность использования продукта.
• Нефункциональные требования абсолютно объективны.

Последний пункт имеет важное значение. Если требование субъективно, оно не имеет ничего общего в списке требований. Было бы невозможно построить проверочные тесты из чего-то субъективного . Единственная цель списка требований состоит в том, чтобы перечислить недвусмысленные ожидания клиента. «Я хочу, чтобы этот квадрат был красным» - это требование. «Я хочу, чтобы этот квадрат был хорошего цвета» - это желание, которое требует объяснения.

Помните, что список требований подобен договору (и в большинстве случаев является частью договора). Он подписан заказчиком и компанией-разработчиком, и в случае судебного разбирательства он будет использоваться на законных основаниях для определения того, правильно ли вы выполнили свою работу. Что если я закажу вам программный продукт, укажите, что «продукт должен быть отличным», и откажитесь платить, когда продукт будет готов, потому что для меня то, что вы на самом деле сделали, не является отличным продуктом?

Итак, давайте посмотрим несколько примеров.

  1. Программный продукт реагирует на конечного пользователя.

Это не требование. Не функционал. Не нефункциональный. Это просто не требование. Вообще. Это имеет нулевое значение. Вы не можете проверить, соответствует ли система программного обеспечения этому требованию во время проверочного тестирования. Ни вы - отдел QA, ни заказчик.

  2. Перезагрузка пользовательской статистики выполняется 90% времени ниже 100 мс. при тестировании на машине с характеристиками, указанными в приложении G, часть 2, и нагрузкой на ЦП ниже 10%, для памяти ниже 50% и без активных операций чтения / записи диска.

Это требование. Если приложение G, часть 2, достаточно точное, я могу взять машину с аналогичным оборудованием и выполнить тест проверки в отделе контроля качества, и я всегда получу двоичный результат: пройден или не пройден.

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

Это нефункциональное требование? Это. Он определяет свойство, которое должен иметь продукт, то есть максимальное / среднее время отклика с учетом процентного порога.

  3. Приложение написано на C #.

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

  4. Кодовая база C # продукта соответствует минимальным рекомендуемым правилам Microsoft и правилам глобализации Microsoft.

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

  5. Главное окно приложения имеет синюю (# 00f) рамку размером 10px с розовыми (#fcc) заполненными кружками, причем эти кружки располагаются на внутреннем крае рамки и имеют диаметр 3px, отделенные друг от друга на 20px.

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

  6. Система слежения за транспортным средством измеряет скорость с точностью до ± 0,016 миль в час.

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

  7. Система слежения за транспортным средством измеряет скорость автомобиля.

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

  8. Страницы сайта занимают 850 мс. загружать.

Это не требование. Это пытается быть одним, но совершенно недействительным. Как бы вы это оценили? Какие страницы? Все? Протестировано через локальную сеть 1 Гбит / с на четырехъядерном клиентском компьютере и восьмиядерном сервере с твердотельными накопителями, используемыми на 2%, или через модем старого и дрянного ноутбука, пока веб-сайт размещается на небольшом сервере, используемом на 99%. ? Что означает «загрузить»? Это означает загрузку страницы? Загрузка и отображение? Отправлять запрос POST с некоторыми большими данными, затем загружать ответ и отображать его?

В заключение, нефункциональное требование - это всегда требование, которое означает, что оно описывает что-то абсолютно объективное и может быть проверено с помощью автоматического или ручного проверочного теста, но вместо того, чтобы рассказать, что делает система, оно объясняет, как система что-то делает или как сама система .

^{¹ Управление проектами в области информационных технологий: применение стратегий управления проектами к программным, аппаратным и интеграционным инициативам, Джеймс Тейлор, ISBN: 0814408117.}

Функциональное требование описывает результат взаимодействия с системой (что система делает в данной ситуации), в то время как нефункциональные требования , как правило , относятся к специфике производительности, мощности, время отклика, и т.д. ... вещи , которые не представляют функциональность, A процесс в системе, или результат взаимодействия.

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

- Пользовательский интерфейс не должен быть заблокирован во время анимации игры в кости.

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

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

Некоторые из них очень сложно определить и оценить. Тем не менее, они имеют значение. Если вы подписываетесь на них по контракту, вам следует избегать бессмысленных версий, написанных вручную, например: «Система должна быть защищена». Проблема с попыткой прибавить такие требования состоит в том, что люди склонны тяготеть к вещам, которые легко измеримы, а не к вещам, которые имеют значение (и требования вполне могут быть написаны людьми, которые не имеют никакого основания в соответствующих специальностях ). В результате вы, как правило, получаете системы, которые не являются ни безопасными, ни пригодными для использования, ни гибкими (доступность не так сложно определить и измерить, хотя она по-прежнему вызывает много головной боли).

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

И последнее: если вы не можете (пока) не придумать объективную меру «умения», это не значит, что клиенту это не нужно. Расплывчато! = Ненужно Однако это может означать, что нам необходимо разработать более эффективные способы измерения таких вещей, постепенно выявлять и уточнять нефункциональные требования или заключать контракты таким образом (Agile и т. Д.), Которые могут работать без предварительных объективных мер для всего.

Все эти комментарии очень хороши, но они излишне приготовлены и не предлагают четкого шаблона для работы. Не было бы ясно, чтобы указать это как:

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

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

Функциональный или нефункциональный? Я бы сказал, нет. Большинство, если не все перечисленные примеры выглядят для меня как бизнес-правила (с указанием связанных с процессами ограничений и правил принятия решений, которым должны следовать системные процессы).

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

Функциональное требование - это обычно то, что система может или будет делать. Это может быть выражено в результате действия (отрицательного результата). Необязательное требование - это то, о чем клиент / конечный пользователь не заботится и не влияет на результат - например, у
Windows будет синяя рамка с розовыми точками. - Программа будет написана на Java
- Все, что связано со стандартами, методами и процессами кодирования.

Однако следует помнить, что нефункциональные требования могут быть превращены потребителями в функциональные требования. Примеры могут быть - Программа будет написана на Erlang, потому что клиент прочитал статью в журнале и хочет, чтобы она была написана на Erlang. - Программа должна использовать DB 2. потому что клиент собирается запустить ее на своих существующих системах DB 2, имеет многолетний опыт работы и ИТ-команду, знакомую с этой платформой.
- Исходный код должен соответствовать всем рекомендациям MISRA.

Итак, если клиент заботится об этом, это функциональное требование, в противном случае это не функциональное требование или, возможно, даже не требование.

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