Классификация требований к ПО в контексте онтологических ворнок - Towareesh/OntoC4Designer GitHub Wiki
1. Функциональные Требования (Functional Requirements - F/FR)
Что это: Описывают ЧТО должна делать система, ее конкретные функции, возможности и поведение. Отвечают на вопрос: "Какую задачу решает система?"
Примеры:
F/FR:Пользователь может авторизоваться по email и паролю.F/FR:Система должна рассчитывать ежемесячный платеж по ипотеке на основе суммы кредита, срока и процентной ставки.F/FR:При нажатии кнопки "Купить" товар добавляется в корзину.F/FR:Администратор может блокировать пользовательские аккаунты.
2. Нефункциональные Требования (Non-Functional Requirements - NFR)
Что это: Описывают КАК система должна выполнять свои функции. Характеризуют атрибуты качества, ограничения и свойства системы в целом. Отвечают на вопросы: "Насколько хорошо?", "С какими ограничениями?", "Как ведет себя под нагрузкой/атакой?"
Категории NFR с примерами:
| Категория NFR | Что описывает? | Примеры требований |
|---|---|---|
| Availability (A) | Доступность системы для использования. | A: Система должна быть доступна 99.9% времени в рабочее время (9:00-18:00). A: Время восстановления после сбоя (RTO) не должно превышать 15 минут. |
| Fault Tolerance (FT) | Устойчивость к сбоям. Способность продолжать работу при частичных отказах. | FT: Отказ одного сервера приложения не должен приводить к недоступности системы. FT: При сбое оплаты через основной шлюз система автоматически пробует резервный. |
| Legal (L) | Соответствие законам, нормативным актам, стандартам. | L: Система должна соответствовать GDPR (защита персональных данных ЕС). L: Финансовые отчеты должны генерироваться по стандарту XBRL. |
| Look & Feel (LF) | Внешний вид, стиль, визуальное восприятие интерфейса. | LF: Интерфейс должен соответствовать корпоративному стилевому гайду (цвета, шрифты, логотипы). LF: Анимации элементов должны быть плавными. |
| Maintainability (MN) | Удобство внесения изменений, исправления ошибок, тестирования. | MN: Внесение изменения в модуль расчета не должно занимать более 5 человеко-дней. MN: Код должен сопровождаться юнит-тестами с покрытием >80%. |
| Operational (O) | Требования к процессам эксплуатации, администрирования, поддержки. | O: Резервное копирование БД должно выполняться автоматически каждые 24 часа. O: Мониторинг состояния системы должен быть доступен в единой панели. |
| Performance (PE) | Скорость работы, время отклика, потребление ресурсов. | PE: Время загрузки главной страницы должно быть ≤ 2 секунд при 1000 одновременных пользователей. PE: Обработка платежа должна занимать ≤ 1 секунды. |
| Portability (PO) | Легкость переноса системы на другую платформу (ОС, железо, облако). | PO: Приложение должно работать как на Windows Server, так и на Linux (Ubuntu). PO: Система должна быть развертываема в AWS, Azure и GCP. |
| Scalability (SC) | Способность системы обрабатывать возрастающую нагрузку. | SC: Система должна поддерживать горизонтальное масштабирование веб-серверов при увеличении нагрузки на 50%. SC: База данных должна выдерживать рост объема данных на 20% в год. |
| Security (SE) | Защита системы и данных от несанкционированного доступа, атак. | SE: Все передаваемые данные должны шифроваться по протоколу TLS 1.3. SE: Доступ к админ-панели возможен только по 2FA. SE: Уязвимости уровня OWASP Top 10 должны отсутствовать. |
| Usability (US) | Удобство, простота и эффективность использования (User Experience - UX). | US: Основные задачи пользователя (оформление заказа) должны выполняться за ≤ 3 клика. US: Ошибки ввода должны сопровождаться четкими подсказками. US: Интерфейс должен проходить юзабилити-тестирование с оценкой ≥ 85%. |
Ключевые различия F/FR vs NFR
| Характеристика | Функциональные (F/FR) | Нефункциональные (NFR) |
|---|---|---|
| Фокус | Что делает система? (Features, Behavior) | Как она это делает? (Quality, Constraints) |
| Тестирование | Функциональные тесты (e.g., "Кнопка X делает Y") | Тесты производительности, безопасности, UX и т.д. |
| Измеряемость | Часто бинарно (Работает/Не работает) | Часто количественно (время, %, уровень) |
| Влияние | На отдельные функции | На систему в целом |
| Пример в онтологии | AuthenticationService должен иметь метод login() |
login() должен выполняться ≤ 500мс, использовать HTTPS |
Как это связано с "онтологической воронкой"?
-
FR (Селекторы функций): Выбираются на уровнях Компонентов (C4 Components) и Кода (C4 Code).
Пример: Выбор компонентаPaymentProcessorс методомprocessCreditCard(). -
NFR (Селекторы качества/ограничений):
- Привязываются к любому уровню C4 (Контекст, Контейнеры, Компоненты, Код).
- Активируют правила в онтологии:
- Выбор
SE: PCI-DSS Compliance→ автоматически требуетFT(избыточность) для компонентов оплаты и запрещаетPO(хранение данных карт на клиенте). - Выбор
PE: High Throughput→ исключает контейнеры с технологиями, не поддерживающими горизонтальное масштабирование (SC).
- Выбор
- "Сужение воронки": Выбор NFR (например,
US: WCAG AA) немедленно фильтрует варианты интерфейсов, не соответствующих стандарту доступности.
**Итог: это отличная основа для построения субонтологий NFR, которые будут управлять "воронкой" проектирования, гарантируя, что выбранные функциональные компоненты (FR) не конфликтуют с требованиями к качеству и ограничениям (NFR). Именно в этом взаимодействии FR и NFR через правила онтологии и рождается архитектурная целостность.