«Робот должен уверенно ехать» звучит как требование, но на самом деле это просьба о хороших новостях. Что значит «уверенно»? По какому покрытию, с какой массой, сколько раз, кто измеряет и что считать неудачей? Пока ответов нет, невозможно ни выбрать решение, ни честно сказать, что оно сработало.
Потребность, требование, решение и доказательство
Потребность отвечает на вопрос зачем: «доставить камеру к точке наблюдения». Требование описывает наблюдаемый результат. Решение — двигатель, редуктор, датчик или программа — появляется только после этого. Доказательство возникает ещё позже: из теста, расчёта, осмотра или демонстрации с зафиксированными условиями.
Полезная формула:
[версия / конфигурация] должна [одно действие] при [условиях]
с [метрикой и допуском]; проверка — [метод].Один учебный пример
Не «платформа должна ехать прямо», а: «Учебная конфигурация T‑01 должна завершить прямой маршрут 10 м на ровном сухом покрытии без полезной нагрузки в 10 из 10 запусков; боковое отклонение фиксируется внешней разметкой; проверка — test». Числа здесь — условия учебного примера, а не норма для «Зари 40» и не характеристика будущей платформы.
Из такой строки сразу видно, чего она не доказывает: движение на грунте, с грузом, на уклоне, ресурс и безопасность рядом с людьми требуют других требований и тестов.
Пять ловушек
- Несколько требований в одном: «быстро, безопасно и далеко» — это три разные проверки.
- Слово без метрики: «надёжно», «точно», «мощно».
- Решение вместо результата: «поставить мотор 500 W» не говорит, какая задача будет закрыта.
- Версия без условий: результат старой прошивки и другой массы нельзя молча переносить на новую конфигурацию.
- Придуманное число: если порог пока неизвестен, назовите его гипотезой и сначала спланируйте измерение.
Карточка требования
| Поле | Что записать |
|---|---|
| ID и версия | К чему относится утверждение |
| Потребность | Какую человеческую задачу оно обслуживает |
| Одно требование | Наблюдаемое действие без оценки «хорошо» |
| Условия | Среда, нагрузка, режим, конфигурация |
| Метрика и порог | Что измеряется и что считается pass/fail |
| Метод | test, analysis, inspection или demonstration |
| Стоп-условие | Когда проверку прекращают |
| Артефакт | Где останутся исходные данные |
| Граница вывода | Чего результат не доказывает |
NASA требует, чтобы требования были ясными, выполнимыми и проверяемыми. Здесь это не «сертификация по NASA», а полезная дисциплина: сначала сказать, как мы узнаем результат, и лишь затем обсуждать детали.
Практический шаг
Выберите одну идею и заполните только одну строку. Если не получается назвать метрику, не ищите магическую характеристику двигателя. Возможно, вы ещё формулируете потребность, а не требование — и это полезное открытие до покупки деталей.
Источники
- NASA, How to Write a Good Requirement — ясность и проверяемость требований.
- NASA, Technical Requirements Definition — трассируемость и выполнимость.
- Карточка версии прототипа — как связать требование с доказательством.
Дальше: как провести испытание, которое ответит на эту строку.