2learn

Ревью и трассировка требований

Что это такое

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

Почему это важно

Дефекты в спецификации дешевле всего исправить, однако увидеть их труднее всего: они живут в том, чего нет, — в случае, который никто не рассмотрел, в двух требованиях, противоречащих друг другу, в числе, изменившемся в одном разделе и уцелевшем в другом. Ревью находит их намеренно, а трассировка доказывает, что между соглашением и релизом ничего не потерялось. Там, где замешаны контракт или регулятор, трассировка к тому же служит доказательством, что согласованное и есть поставленное.

Ключевые идеи

Ревьюируйте по четырём типам дефектов, по порядку

Отсутствующее  нет требования о том, что происходит при сбое пакета
Неоднозначное  «разумное время» встречается трижды без определения
Противоречивое раздел 4 требует email-подтверждения, раздел 7 его запрещает
Непроверяемое  «система должна быть надёжной под нагрузкой»

Просьба о «комментариях» даёт замечания о стиле, а четыре названные категории — дефекты: отсутствующее, неоднозначное, противоречивое и непроверяемое.

Используйте чек-лист и держите его коротким

Десятка вопросов к каждому требованию достаточна: назван ли субъект действия, указан ли триггер, есть ли число там, где стоит уточнение, покрыт ли случай сбоя, трассируется ли требование к тесту?

Дайте каждому требованию стабильный идентификатор

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

REQ-PAY-014  возвраты не должны превышать исходную сумму платежа
  тест      refund_of_more_than_paid_is_rejected
  код       payment/refund.ts:88
  изменение PR-2311

Трассируйте вперёд и назад перед релизом

Движение вперёд означает, что у каждого требования есть тест; движение назад — что каждый тест трассируется к требованию. Поэтому ничто не построено, чего никто не просил, и ничто не просили, чего никто не построил.

Осознанно перебазируйте, когда требования меняются

Считайте и датируйте изменения: документ, меняющийся молча, хуже устаревшего, потому что все ему верят.

Практика

Проведите структурированное ревью одного раздела

Возьмите один раздел и попросите трёх человек прочитать его по четырём категориям дефектов, затем сведите и классифицируйте находки.

Готово, когда: каждая находка помечена как отсутствующая, неоднозначная, противоречивая или непроверяемая, а непроверяемые переписаны.

Постройте таблицу трассировки для одной функции

Для одной функции перечислите каждое требование с его тестом и его изменением.

Готово, когда: ни одно требование не осталось без теста и ни один тест без требования, либо пробелы записаны с владельцем.

Частые ошибки

  • Просьба об общих комментариях — ревью выдаёт исправления опечаток; исправить: ревьюируйте по названным категориям дефектов.
  • Ревью в одиночку — автор читает то, что имел в виду; исправить: включите хотя бы одного человека, не видевшего документ.
  • Перенумерация требований — трассировки ломаются за считанные дни; исправить: присваивайте стабильные идентификаторы, которые никогда не меняются.
  • Трассировка только вперёд — работа, которую никто не просил, остаётся невидимой; исправить: трассируйте назад от тестов тоже.
  • Молчаливые изменения — все доверяют документу, который больше не соответствует соглашению; исправить: версионируйте и датируйте каждое изменение.

Что читать дальше

Разобранные примеры

Файлы cookie аналитики ставятся только с вашего согласия. До вашего выбора ничего не загружается и никуда не отправляется.