FURPS+ и ISO/IEC 25010
Модели качества нужны аналитику как карта: пройдясь по всем категориям, вы не забудете важный класс требований. Ни одна модель не говорит, какие значения нужны именно вашей системе, — числа появляются только из разговора со стейкхолдерами, данных и рисков.
FURPS+
Модель предложил Роберт Грейди (Hewlett-Packard) в конце 1980-х. Знак «+» позже добавили в Rational Unified Process (IBM), чтобы учесть ограничения. FURPS+ простая и легко запоминается, поэтому её часто спрашивают на собеседованиях.
| Буква | Категория | Что входит | Пример требования |
|---|---|---|---|
| F | Functionality — функциональность | Набор функций и возможностей, общность решения, безопасность (в FURPS она относится сюда), аудит, лицензирование | Все действия администратора записываются в журнал аудита с указанием пользователя, времени и объекта |
| U | Usability — удобство | Эргономика, эстетика и единообразие интерфейса, обучаемость, справка и документация, доступность для людей с ограничениями | Новый оператор без обучения оформляет заказ быстрее чем за 3 минуты; интерфейс соответствует WCAG 2.1 уровня AA |
| R | Reliability — надёжность | Доступность, частота и тяжесть сбоев, отказоустойчивость, восстанавливаемость, точность вычислений, предсказуемость, MTBF | Доступность 99,9% в месяц; RTO — 1 час, RPO — 15 минут |
| P | Performance — производительность | Время отклика, пропускная способность, эффективность, потребление ресурсов, ёмкость, масштабируемость, время запуска | 95% запросов к каталогу выполняются быстрее 300 мс при 200 RPS |
| S | Supportability — сопровождаемость | Тестируемость, расширяемость, адаптируемость, сопровождаемость, совместимость, конфигурируемость, обслуживаемость, устанавливаемость, локализуемость | Новый способ оплаты подключается без изменения кода ядра, через конфигурацию и отдельный модуль |
| + | Ограничения | Проектные (выбор архитектуры, СУБД, фреймворка), реализационные (языки, стандарты кодирования, лицензии), интерфейсные (взаимодействие с внешними системами и форматы), физические (оборудование, размеры, вес, условия эксплуатации), юридические (законы, лицензии, сертификация) | Данные пользователей хранятся на серверах в РФ (152-ФЗ); используется только PostgreSQL 15+ |
ISO/IEC 25010
Международный стандарт модели качества систем и ПО из серии SQuaRE (ISO/IEC 25000). Заменил ISO/IEC 9126. Первая редакция — 2011 года, действующая — 2023 года. Стандарт описывает две модели:
- Модель качества продукта — свойства самой системы. Именно её используют для НФТ.
- Модель качества при использовании (quality in use) — что получает пользователь в реальной работе: результативность, эффективность, удовлетворённость, свобода от рисков, покрытие контекста. В редакции 2023 года её вынесли в отдельный стандарт ISO/IEC 25019.
Модель качества продукта: редакция 2023 года
| Характеристика | Подхарактеристики | Простыми словами |
|---|---|---|
| Функциональная пригодность (Functional suitability) | Функциональная полнота, корректность, уместность | Есть все нужные функции, они работают правильно и помогают решить задачу |
| Производительность (Performance efficiency) | Временные характеристики, использование ресурсов, ёмкость | Скорость ответа, потребление CPU, памяти и сети, предельные объёмы |
| Совместимость (Compatibility) | Сосуществование, интероперабельность | Не мешает другим системам рядом и умеет с ними обмениваться данными |
| Способность к взаимодействию (Interaction capability; в 2011 — Usability) | Узнаваемость назначения, обучаемость, управляемость, защита от ошибок пользователя, вовлечённость, инклюзивность, помощь пользователю, самоописательность | Понятно, зачем система, легко научиться, сложно ошибиться, удобно людям с разными возможностями |
| Надёжность (Reliability) | Безотказность (в 2011 — зрелость), доступность, отказоустойчивость, восстанавливаемость | Редко ломается, доступна, переживает сбои и быстро восстанавливается |
| Защищённость (Security) | Конфиденциальность, целостность, неотказуемость, отслеживаемость (accountability), подлинность, устойчивость к атакам (resistance — новая в 2023) | Данные видят только те, кому можно; их нельзя незаметно изменить; действия привязаны к пользователю |
| Сопровождаемость (Maintainability) | Модульность, повторное использование, анализируемость, модифицируемость, тестируемость | Легко найти причину проблемы, внести изменение и проверить его |
| Гибкость (Flexibility; в 2011 — Portability) | Адаптируемость, масштабируемость (новая в 2023), устанавливаемость, заменяемость | Переносится в другую среду, растёт под нагрузкой, легко ставится и заменяется |
| Безопасность для людей и среды (Safety — новая в 2023) | Операционные ограничения, идентификация рисков, безопасный отказ, предупреждение об опасности, безопасная интеграция | Система не причиняет вреда людям, имуществу и окружающей среде, при сбое переходит в безопасное состояние |
Что изменилось между 2011 и 2023
- Было 8 характеристик, стало 9: добавлена Safety.
- Usability переименована в Interaction capability; эстетику интерфейса заменила вовлечённость, доступность (accessibility) переросла в инклюзивность, добавлены помощь пользователю и самоописательность.
- Portability переименована в Flexibility, в неё добавлена масштабируемость.
- В надёжности «зрелость» стала «безотказностью», в защищённости появилась «устойчивость».
- Модель качества при использовании вынесена в ISO/IEC 25019.
FURPS+ и ISO 25010: соответствие
| FURPS+ | ISO/IEC 25010 |
|---|---|
| F — Functionality | Функциональная пригодность + Защищённость |
| U — Usability | Способность к взаимодействию (Usability) |
| R — Reliability | Надёжность |
| P — Performance | Производительность + масштабируемость (в 2023 — часть Гибкости) |
| S — Supportability | Сопровождаемость + Совместимость + Гибкость (переносимость) |
| + — ограничения | В модели качества нет; описываются отдельно как ограничения |
| — | Safety (только в ISO 2023) |
Когда что использовать. FURPS+ — для быстрого обзора на встрече и в небольших проектах. ISO 25010 — когда нужна полнота и формальность: госзаказ, банки, крупные интеграционные проекты, договорная разработка. На практике удобно взять категории ISO как оглавление раздела НФТ, а «+» из FURPS — как отдельный раздел ограничений.
Как сформулировать НФТ
Хорошее НФТ отвечает на четыре вопроса: что измеряем, какое значение нужно, при каких условиях, как проверим.
Плохо: Система должна быстро работать.
Хорошо: Время ответа API поиска товаров (что) не превышает 500 мс
для 95% запросов (значение) при 300 одновременных пользователях
и каталоге 100 тыс. товаров (условия). Проверяется нагрузочным
тестом в JMeter на стенде, аналогичном продакшену (проверка).
Для ключевых атрибутов полезно указывать два уровня: целевое значение и минимально допустимое. Например: целевая доступность — 99,95%, допустимая — 99,9%.
Типичные ошибки
- НФТ без чисел: «быстро», «надёжно», «удобно».
- Число без условий: «500 мс» — при какой нагрузке, для какой операции, для какого перцентиля?
- Требования, которые нельзя проверить на доступном стенде.
- Одинаковые жёсткие требования ко всем частям системы — платёжный модуль и страница «О компании» могут иметь разные SLA.
- Забытые требования эксплуатации: логи, мониторинг, бэкапы, обновление без простоя.
- Включение в свои НФТ задержек внешних систем, за которые команда не отвечает.
Конспекты статей о НФТ есть на странице «Требования».