Качество требований
Качество требования проверяется не по стилю формулировки, а по возможности использовать его дальше. Требование “система должна работать быстро” плохо не из-за разговорного слова, а потому что непроверяемо: неизвестно, какая операция, при какой нагрузке и какое время считаются приемлемыми.
Основные критерии качества:
- атомарность: требование описывает одну возможность или одно условие;
- проверяемость: можно понять, выполнено требование или нет;
- непротиворечивость: оно не конфликтует с другими требованиями и правилами;
- полнота: в нём достаточно информации для дальнейшего анализа;
- реализуемость: требование достижимо в рамках проекта и выбранных ограничений;
- трассируемость: понятно, откуда оно появилось и какими материалами покрывается.
Атомарность означает, что требование не должно соединять несколько задач в одну строку. Если в одном пункте записаны регистрация, авторизация и восстановление пароля, невозможно понять, какая часть реализована, протестирована или изменилась. Лучше разделить это на три требования.
Проверяемость требует конкретики. Формулировка “интерфейс должен быть удобным” не даёт критерия. Её можно уточнить через конкретные свойства: пользователь должен создать запись не более чем за три шага после выбора преподавателя; обязательные поля должны быть отмечены; ошибка занятости интервала должна показываться до подтверждения записи.
Непротиворечивость особенно важна в ИС с несколькими стейкхолдерами. Один участник может хотеть максимально подробный контроль, другой — минимальное число ручных согласований. Если противоречие не обнаружить на уровне требований, оно появится позже в сценариях и архитектуре.
Примеры исправления требований:
| Плохая формулировка | Проблема | Возможная правка |
|---|---|---|
| Система должна быть удобной | непроверяемо | Студент должен создать запись за один сценарий без обращения к администратору |
| Система должна быстро искать заявки | нет операции, нагрузки и времени | Поиск заявки по номеру должен выполняться не дольше 1 секунды при 50 одновременных пользователях |
| Система должна регистрировать пользователей и отправлять письма | две функции в одной | Разделить регистрацию пользователя и отправку письма подтверждения |
| Все данные должны быть защищены | слишком общее утверждение | Доступ к персональным данным должен предоставляться только авторизованным пользователям с ролью сотрудника |
| Система должна поддерживать все внешние сервисы | нереализуемо | Указать конкретные внешние системы и тип обмена данными |
Реализуемость особенно важна в учебном проекте. Можно описать систему с оплатой, распознаванием документов, интеграцией с государственными сервисами и мобильным приложением, но потом не получится построить осмысленную модель в рамках курса. Требование должно соответствовать масштабу работы.
Минимальная проверка перед использованием требования в дальнейшем проектировании такая: понятно ли, кто заинтересован в требовании; можно ли описать сценарий его выполнения; есть ли связанные правила; можно ли проверить результат; не противоречит ли оно границе системы. Если на эти вопросы нельзя ответить, требование ещё не готово.