Формулировка функциональных требований
Поскольку я слышал множество мнений о формулировках функциональных требований, я хотел спросить, всегда ли функциональные требования должны начинаться с
Система должна [...]
Пример (для кофемашины):
Система должна предлагать три разных типа кофе.
против
Пользователь должен иметь возможность выбирать между тремя различными типами кофе.
Оба эти функциональных требования действительны?
Заранее спасибо!
2 ответа
Существует ряд критериев качества требований: хорошее требование должно быть полным, непротиворечивым, элементарным, понятным, актуальным, недвусмысленным и проверяемым (обратите внимание, что этот список может немного отличаться в зависимости от того, на какой источник вы ссылаетесь).
Поэтому я согласен с тем, что оба ваших примера являются действительными функциональными требованиями.
Мне кажется, что ваш второй пример больше ориентирован на точку зрения пользователя и немного напоминает концепцию пользовательских историй, которые часто используются в гибкой разработке. Существует довольно много дискуссий о сходстве и различии требований и пользовательских историй (см. Здесь и здесь).
Также обратите внимание, что термины должен / должен, должен и может быть четко определены (см. RFC 2119) для указания уровня требований (например, обязательный, рекомендуемый или необязательный) и должны использоваться правильно.
Функциональное требование включает подробное описание процесса каждой функции с технической точки зрения, расчет, который определяет весь рабочий процесс системы.
Оба варианта работают, разница в том, что первый вариант основан на стороне системы, а другой - на стороне пользователя.
Если система не предоставит выбор, тогда у пользователя не будет возможности сделать выбор, поэтому оба варианта зависят друг от друга.