Виды требований к ИС
Раздел 3. Анализ требований к ИС
Дисциплина «Проектирование информационных систем»
Зачем классифицировать требования?
Хочу интернет-магазин, чтобы он был быстрый, красивый и безопасный.
Проблема:
- «Быстрый» — 1 секунда или 100 миллисекунд?
- «Красивый» — дизайнер и заказчик понимают по-разному
- «Безопасный» — что защищаем? От кого?
Главное правило: требования должны быть конкретными, измеримыми и проверяемыми.
Пирамида требований
Бизнес-требования — ЗАЧЕМ?
Пользовательские требования — КТО и ЧТО хочет?
Функциональные требования — ЧТО делает?
Нефункциональные требования — КАК работает?
Требования к данным и UI
Бизнес-требования
Отвечают на вопрос: ЗАЧЕМ мы делаем эту систему?
Кто формулирует: заказчик, руководство
Примеры:
- Сократить время согласования документов с 5 дней до 1 дня
- Снизить затраты на бумагу на 40% за год
- Повысить удовлетворённость сотрудников на 20%
Бизнес-требования говорят чего достичь, а не как.
Пользовательские требования
Отвечают на вопрос: КТО и ЧТО хочет от системы?
Формат: User Stories, Use Cases
Примеры:
Как студент, я хочу подавать заявление онлайн, чтобы не стоять в очереди в деканате.
Библиотекарь выдаёт книгу: проверяет формуляр, сканирует штрих-код, фиксирует дату возврата.
Пишутся на языке пользователя, без технических деталей.
Функциональные требования
Отвечают на вопрос: ЧТО должна делать система?
Примеры:
| ID | Требование |
|---|
| FR-001 | Система должна позволять вводить промокод в корзине |
| FR-002 | Система должна рассчитывать сумму с учётом скидки |
| FR-003 | Система должна отправлять email после оформления заказа |
| FR-004 | Система должна блокировать аккаунт после 5 неудачных попыток входа |
Функции, а не решения. «Отправлять email» — функция. «Использовать SMTP Mailgun» — решение.
Нефункциональные требования (НФТ)
Отвечают на вопрос: КАК система должна работать?
Категории «-ilities»:
⚡ Производительность
Скорость, время отклика
📈 Масштабируемость
Рост при увеличении нагрузки
🛡️ Надёжность
Доступность, отказоустойчивость
🔒 Безопасность
Защита данных, аутентификация
🎯 Удобство (Usability)
UX, доступность
🔧 Сопровождаемость
Лёгкость изменений
Требования к данным
Отвечают на вопрос: Что система хранит и как?
Что входит:
- Сущности и атрибуты (пользователи, заказы, товары)
- Объёмы данных и скорость роста
- Жизненный цикл: сколько храним, когда удаляем
- Целостность, связи, ограничения
- Миграция из legacy-систем
- Резервное копирование
- Соответствие регуляторам (152-ФЗ, GDPR)
Требования к UI
Отвечают на вопрос: Как система выглядит и как с ней работать?
Что входит:
- Визуальный стиль (цвета, шрифты, брендбук)
- Структура экранов и навигация
- Адаптивность (desktop, tablet, mobile)
- Доступность (WCAG 2.1)
- Локализация (несколько языков)
- Обратная связь (уведомления, ошибки)
Связаны с дизайн-системой и адаптивностью макетов — вашими критериями оценки.
Сводная таблица
| Вид | Вопрос | Кто | Пример |
|---|
| Бизнес | ЗАЧЕМ? | Заказчик | «Снизить затраты на 40%» |
| Пользовательские | КТО и ЧТО? | Пользователи | «Как студент, я хочу...» |
| Функциональные | ЧТО делает? | Аналитик | «Отправлять email» |
| Нефункциональные | КАК работает? | Архитектор | «Загрузка ≤ 2 сек» |
| К данным | ЧТО храним? | DBA | «Хранить 5 лет» |
| К UI | КАК выглядит? | Дизайнер | «Адаптивный, WCAG» |
Пример: интернет-магазин одежды
Контекст: стартап, 100 000 посетителей/мес, пики в «Чёрную пятницу»
| Категория | Требование |
|---|
| Производительность | Главная ≤ 2 сек на 3G |
| Масштабируемость | 10-кратный рост в пик |
| Надёжность | 99.9% в 8:00–23:00 |
| Безопасность | Данные карт не хранятся (PCI DSS) |
| Удобство | Оформление ≤ 4 шагов |
| Портируемость | iOS 14+, Android 10+, 2 версии браузеров |
Пример: банковская ИС
Контекст: крупный банк, миллионы клиентов, регулирование ЦБ РФ
| Категория | Требование |
|---|
| Производительность | Транзакция ≤ 500 мс |
| Масштабируемость | 10 000 транзакций/сек |
| Надёжность | 99.99% (≤ 52 мин простоя/год) |
| Безопасность | 2FA для всех операций |
| Безопасность | AES-256 + TLS 1.3 |
| Аудируемость | Логи всех действий, хранение 5 лет |
В банке безопасность и надёжность важнее удобства. В магазине — наоборот.
Типичные ошибки НФТ
❌ Плохо
«Система должна быть быстрой»
✅ Хорошо
«Главная страница загружается ≤ 2 сек»
❌ Плохо
«Система должна быть безопасной»
✅ Хорошо
«Пароли в bcrypt, данные — AES-256»
Правило SMART: конкретные, измеримые, достижимые, релевантные, ограниченные по времени.
Матрица трассировки требований
RTM (Requirements Traceability Matrix) — карта связей между всеми требованиями и артефактами.
Зачем нужна:
- Не потерять требования
- Не сделать лишнего
- Проверить полноту покрытия бизнес-целей
- Упростить тестирование
- Облегчить изменения
Пример матрицы трассировки
| Бизнес | User Story | Функц. | Нефункц. | Модуль | Статус |
| BR-001: Рост продаж +20% | US-001: Оплата картой | FR-001, FR-002, FR-003 | NFR-001, NFR-002 | Модуль оплаты | ✅ Готово |
| BR-002: Меньше брошенных корзин | US-002: Сохранение корзины | FR-004, FR-005 | NFR-003 | Модуль корзины | 🔄 В работе |
| BR-003: Улучшить UX | US-003: Быстрое оформление | FR-006, FR-007 | NFR-004 | Checkout | ❌ Не начато |
Каждое функциональное требование должно иметь связь с бизнес-целью. Иначе — «золотая функция».