Как писать хорошие требования

Главные идеи#

Два шаблона формулировок#

• С точки зрения системы (шаблон EARS, Easy Approach to Requirements Syntax — «простой подход к синтаксису требований», предложен Мейвином (Mavin) и коллегами): [необязательное предусловие] [необязательный триггер] система должна [ожидаемая реакция].
• С точки зрения пользователя (Александер и Стивенс, Alexander, Stevens): [класс пользователей] должен иметь возможность [действие] [объект] [условия или время отклика]. Называйте класс пользователей («Механик»), а не просто «пользователь».

Правила стиля от Вигерса и Битти#

• Одно модальное слово. Во всём документе пишите «должен» (shall). Читатели, особенно говорящие на разных языках, не уловят оттенков между «следует», «может», «будет» и «обязан». Приоритет записывайте в отдельном атрибуте: приоритеты меняются от итерации к итерации, а формулировка должна оставаться стабильной.
• Активный залог. «Статус будет изменён» скрывает, кто его меняет — система или человек.
• Разделяйте составные требования. Слова «и», «или», «также» и «и/или» обычно означают, что в одном предложении спрятано несколько требований. Если двум частям нужны разные тесты, это разные требования. «Если не» и «кроме» прячут вторую ветку: запишите основное правило и исключение отдельно.
• Утвердительные формулировки. Переписывайте двойные отрицания. Функциональность, сознательно исключённая из границ, относится к ограничениям и исключениям в документе концепции и границ, а не к отрицательному требованию в спецификации требований к ПО (SRS). Удалённые требования помечайте статусом, а не стирайте.
• Точные границы диапазонов. При «до 5 дней» и «от 5 до 10 дней» неясно, куда относится пятый день. Пишите «включительно» или «более».
• Никаких терминов вида «A/B». «Отдел доставки/исполнения» может означать синонимы, два отдела, «и» или «или». Выберите одно значение.
• Таблицы для вариантов. Много похожих требований (скажем, для каждого сочетания формата и региона) понятнее в виде таблицы с суффиксами в ID. Явная ячейка «неприменимо» показывает сознательный пропуск.

Нужный уровень детализации#

Пишите подробнее, когда работа ведётся для внешнего клиента, разработка или тестирование отданы на аутсорсинг, команда распределена, тесты пишут по требованиям, нужны точные оценки или требуется трассировка (traceability). Меньше деталей допустимо при внутренней работе с плотно вовлечёнными заказчиками, при опытных разработчиках, при прямом прецеденте, например замене существующей системы, или при готовом пакетном решении.

Быстрая проверка — посчитать, сколько тестов нужно требованию. Несколько похожих тестов — уровень верный. Много разных тестов — несколько требований слиплись в одно. Пример из книги — одна строка о голосовых командах, за которой скрывается целая подсистема распознавания речи.

Размытые слова и как их исправить#

Авторы делают и более общий вывод: наречия и оценочные прилагательные делают требование субъективным, а значит, неоднозначным, а значит, непроверяемым.

Быстрые проверки на скрытые пробелы#

• Симметрия. Сохранение предполагает загрузку, создание — удаление. Если одной половины пары нет, спросите почему.
• Сложная логика. Три условия «да/нет» дают восемь сочетаний. Перечислите их все в таблице решений.
• Исключения. У каждого «когда всё работает» должно быть своё «когда что-то не сработало».
• Абсурдное прочтение. Попробуйте найти нелепое, но буквальное прочтение. «Страница статуса должна обновляться с интервалом не менее 60 секунд» допускает обновление раз в год. Если абсурдное прочтение не противоречит тексту, перепишите требование.

Вигерс и Битти также предостерегают от паралича анализа: стремитесь к требованиям, которые достаточно хороши, чтобы двигаться дальше при приемлемом уровне риска.