В чем разница между нефункциональным требованием и качественным признаком?

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

Вы можете найти набор атрибутов качества в стандарте ISO9126.

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

Если я говорю, что система не может занять более 1 секунды, чтобы ответить, я говорю об ограничении.

Так, где понятие нефункциональных требований вступает в силу? Они определены пользователями? Как я могу их идентифицировать?

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

Пользователь ДОЛЖЕН быть в состоянии войти через веб-интерфейс. Технически это функциональное требование.

Система ДОЛЖНА отвечать на запросы входа в систему в течение 1 секунды. Технически, это нефункциональное требование.

В любом случае они оба одинаково важны независимо от конкретной классификации.

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

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

Правило простое и понятное.

Функциональные требования - это то, что делает система .

Нефункциональные требования - это качественные атрибуты или аспекты того, как система спроектирована, построена или реализована.

• Производительность (1 секунда)
• Ремонтопригодность
• адаптируемость
• Стоимость
• безопасность
• удобство использования (что является свойством системы в целом)
• способность быть свидетелем в суде
• масштабируемость

Прочитайте это. Это очень ясно. http://en.wikipedia.org/wiki/Non-functional_requirement

Нефункциональные требования проявляются так же, как и функциональные требования. Пользователи. Контекст, в котором будет внедрена система. Много мест. Управление. Другие организации. Сетевые администраторы, системные администраторы, администраторы баз данных. Каждый, кто является заинтересованным лицом или просто сторонним наблюдателем, будет вносить нефункциональные требования.

Рассматривая «документы с требованиями» за последние 30 лет, я могу сказать следующее. Многие документы с требованиями, написанные крупными внутренними ИТ-организациями, представляют собой политические заявления, в которых, возможно, 80% нефункциональных требований и менее 20% функциональных требований.

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

Нефункциональные требования и атрибуты качества - это одно и то же

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

Система из 5 компонентов должна обработать запрос за 10 мс. Если один компонент имеет дефект, требующий 5 мс для участия в обработке, это повлияет на производительность системы в целом.

Точно так же, как безопасность - это не только вход в систему, и когда он затрагивается, он влияет на всю систему.

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

Вот интересная ссылка о том, как их идентифицировать структурированным образом:

• «Мастерская качества атрибутов», ГЭИ, 2003

И книга о том, как их документировать и правильно определять:

• «Архитектурные программы для интенсивных систем: руководство для практиков», Энтони Дж. Латтанзе, 2008 г.