Вопрос проверяет знание критериев качества требований (атрибутов хороших требований).
Хорошо написанные требования должны быть конкретными, однозначными, полными, непротиворечивыми, проверяемыми, осуществимыми и трассируемыми. Соблюдение этих характеристик гарантирует, что требования будут правильно поняты и реализованы всеми участниками проекта.
Качество требований определяется набором атрибутов, которые часто объединяют в аббревиатуру SMART или используют более детализированные критерии.
Ключевые характеристики хорошо написанных требований:
Корректность (Correct) и Однозначность (Unambiguous):
Требование должно иметь только одно возможное толкование.
Плохой пример: "Система должна быть удобной."
Хороший пример: "Новый пользователь должен иметь возможность зарегистрироваться в системе менее чем за 3 минуты."
Полнота (Complete):
Требование должно описывать все необходимые условия и сценарии.
Пример: Требование к авторизации должно учитывать сценарии: успешный вход, неверный пароль, заблокированный аккаунт, восстановление доступа.
Непротиворечивость (Consistent):
Требования не должны конфликтовать друг с другом.
Пример конфликта: Одно требование говорит "Пароль должен быть не менее 6 символов", а другое — "Пароль должен быть ровно 5 символов".
Приоритезированность (Prioritized):
Каждое требование должно иметь уровень важности (например, High, Medium, Low).
Это помогает команде фокусироваться на самом ценном функционале.
Проверяемость (Verifiable):
Должна существовать объективная возможность проверить, что требование выполнено.
Непроверяемое: "Интерфейс должен быть современным."
Проверяемое: "95% протестированных пользователей должны подтвердить, что интерфейс интуитивно понятен."
Осуществимость (Feasible):
Требование должно быть реализуемо в рамках ограничений проекта (бюджет, время, технологии).
Пример неосуществимого: "Система должна предсказывать точные продажи на следующий месяц с вероятностью 99,9%."
Трассируемость (Traceable):
У требования должен быть уникальный идентификатор, и должна быть видна его связь с бизнес-целями и тест-кейсами.
Пример: Требование FUNC-123 связано с бизнес-целью BIZ-45 и тест-кейсом TEST-567.
Вывод:
Использование этого набора характеристик в качестве чек-листа при написании и ревью требований значительно повышает их качество и, как следствие, шансы на успех проекта.
