Яка різниця між нефункціональною вимогою та атрибутом якості?

Я намагаюся зрозуміти різницю між нефункціональними вимогами та атрибутами якості. Вони однакові?

Ви можете знайти набір атрибутів якості в стандарті ISO9126.

Я знаю, що кожна система визначається набором функціональних вимог і кожна з цих вимог пов'язана з одним або кількома атрибутами якості. Наприклад, припустимо, що у вас є вимога, яка описує функціональність входу в систему. Ви можете пов’язати з цією вимогою атрибути безпеки та продуктивності.

Якщо я скажу, що система не може зайняти більше 1 секунди для відповіді, я кажу про обмеження.

Отже, звідки виникає поняття нефункціональних вимог? Чи визначені вони користувачами? Як я можу їх визначити?

Я думаю, що ти занадто важко думаєш про це. Функціональна та нефункціональна вимога насправді не є настільки відокремленою, як ви пропонуєте. Візьмемо для прикладу вхід.

Користувач ДОЛЖЕН мати можливість увійти через веб-інтерфейс. Технічно це функціональна вимога.

Система ОБОВ'ЯЗКОВО відповідати на запити входу протягом 1 секунди. Технічно це нефункціональна вимога.

У будь-якому випадку вони обидва так само важливі незалежно від конкретної класифікації.

Вимоги можуть надходити з будь-якої кількості місць. Можливо, ви хочете мати кращі показники, ніж конкуренти. Замовник може мати конкретні потреби. Може виникнути запит від маркетингу чи продажу. Там не було одного місця, звідки вони родом. Хоча, можливо, ви могли б абстрагуватися від усіх різних джерел і відносити їх до них як до клієнтів. Зрештою, це вони.

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

Правило просте і зрозуміле.

Функціональні вимоги - це те, що робить система .

Нефункціональні вимоги - це атрибути якості або аспекти того, як система проектується, будується або впроваджується.

• Продуктивність (1 секунда)
• Технічне обслуговування
• Пристосованість
• Вартість
• безпека
• зручність використання (що є властивістю системи в цілому)
• заповітність
• масштабованість

Прочитай це. Це дуже зрозуміло. http://en.wikipedia.org/wiki/Non-functional_requirement

Нефункціональні вимоги відображаються так само, як і функціональні вимоги. Користувачі. Контекст, в якому буде впроваджена система. Багато місць. Управління. Інші організації. Мережеві адміністратори, системні адміністратори, адміністратори бази даних. Кожен, хто є зацікавленою стороною або просто стороною, висуває нефункціональні вимоги.

Переглядаючи "документи з вимогами" за останні 30 років, я можу це сказати. Багато документів з вимогами, написані великими внутрішніми ІТ-організаціями, - це політичні заяви з можливо 80% нефункціональними вимогами та менш ніж 20% функціональними вимогами.

Я прочитав одне, яке мало єдине речення, яке було функціональною вимогою. В іншому документі на 30 сторінках йшлося про платформу, підтримку, резервне копіювання та відновлення, операційні системи та базу даних, стандарти, операції та багато чого, що система не робила .

Нефункціональні вимоги та атрибути якості - одне і те ж

Ідея, що стоїть за зміною назви останнім часом, полягає в тому, що ці так звані нефункціональні вимоги - це насправді функціональність системи (або набір функціональних можливостей системи), що має поперечний вплив на систему. Це означає, що поперечний вплив, який має такий тип "особливої ​​функціональності" в системі, робить її атрибутом якості цієї системи. Як приклад:

Система з 5 компонентами повинна обробити запит через 10 мс. Якщо у одного компонента дефект займає 5 мс, щоб зробити свою участь у обробці, це вплине на продуктивність системи в цілому.

Так само, як безпека стосується не лише входу в систему, а при його впливі, це впливає на всю систему.

Підводячи підсумки, атрибути якості (тобто нефункціональні вимоги) стосуються функціональності, того, як ви щось реалізуєте та як ця реалізація впливає на ваші системи. Зазвичай відмінність від "нормальних вимог" полягає в її впливі, дальності та видимості.

Ось цікаве посилання про те, як їх структурно ідентифікувати:

• "Практикум з атрибутами якості", SEI, 2003

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

• "Архітектурне інтенсивне програмне забезпечення: Посібник для практиків", Ентоні Дж. Латтанце, 2008