Корректность (correctness
101
) и
проверяемость (verifiability
102
). Фактически
эти свойства вытекают из соблюдения всех вышеперечисленных (или можно ска-
зать, что они не выполняются, если нарушено хотя бы одно из вышеперечислен-
ных). В дополнение можно отметить, что проверяемость подразумевает возмож-
ность создания объективного тест-кейса (тест-кейсов), однозначно показывающего,
что требование реализовано верно и поведение приложения в точности соответ-
ствует требованию.
К типичным проблемам с корректностью также можно отнести:
•
опечатки (особенно опасны опечатки в аббревиатурах, превращающие одну
осмысленную аббревиатуру в другую также осмысленную, но не имеющую
отношения к некоему контексту; такие опечатки крайне сложно заметить);
•
наличие неаргументированных требований к дизайну и архитектуре;
•
плохое оформление текста и сопутствующей графической информации,
грамматические, пунктуационные и иные ошибки в тексте;
•
неверный уровень детализации (например, слишком глубокая детализация
требования на уровне бизнес-требований или недостаточная детализация на
уровне требований к продукту);
•
требования к пользователю, а не к приложению (например: «пользователь
должен быть в состоянии отправить сообщение» — увы, мы не можем влиять
на состояние пользователя).
Способы обнаружения проблем
Способы устранения проблем
Поскольку здесь мы имеем дело с
«интегральной» проблемой, обнару-
живается она с использованием ра-
нее описанных способов. Отдель-
ных уникальных методик здесь нет.
Внесение в требования необходи-
мых изменений – от элементарной
правки обнаруженной опечатки, до
глобальной
переработки
всего
набора требований.
Хорошее краткое руководство по написанию качественных требований
представлено в статье «Writing Good Requirements — The Big Ten
Rules
»
103
.
101
Each requirement must accurately describe a capability that will meet some stakeholder’s need and must clearly describe the
functionality to be built. [
«Software Requirements (3rd edition)», Karl Wiegers and Joy Beatty]
102
If a requirement isn’t verifiable, deciding whether it was correctly implemented becomes a matter of opinion, not objective analysis.
Requirements that are incomplete, inconsistent, infeasible, or ambiguous are also unverifiable. [
«Software Requirements (3rd
edition)
», Karl Wiegers and Joy Beatty]
103
«Writing Good Requirements — The Big Ten Rules», Tyner Blain [
http://tynerblain.com/blog/2006/05/25/writing-good-require-
ments-the-big-ten-rules/
]