PRO требования: EARS

Иногда требование выглядит вполне понятно для аналитика, но разработчик и тестировщик читают его по-разному.

Проблема часто не в формулировке, а в том, что в ней не хватает условия, при котором система должна что-то сделать.

Для таких случаев существует EARS (Easy Approach to Requirements Syntax) - подход к формулированию требований через несколько типовых конструкций.

Например:

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

Здесь явно указаны событие и ожидаемое поведение.

В EARS используются несколько основных шаблонов:
➖Всегда
➖При событии
➖При определённом состоянии
➖При нежелательном условии.
➖Для опционального поведения

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

По сути - это один из инструментов, который помогает превратить «системе нужно уметь...» в проверяемое системное требование.

--

✌️ ПРО СА|🆕 НСА 2.0

PRO стандарты интернета или Почему вилка не лезет в розетку, а сайт открывается везде

Обычная ситуация: прилетел в другую страну, достал зарядку, а вилка не лезет в розетку. Никто не виноват: когда-то просто не договорились, как эта вилка выглядит. Типов розеток в мире 15, и переходник ты покупаешь в аэропорту.

А вот с интернетом договорились. Любой сайт открывается в любом браузере, хоть в Токио, хоть в Твери, потому что правила записали заранее. Эти записанные правила и называются RFC.

Три вещи, которые экономят аналитику время:

1⃣ Статус написан в шапке. Не каждый RFC это стандарт. Internet Standard проверен годами и работающими реализациями, а Experimental и Informational ни к чему не обязывают, хотя выглядят точно так же.

2⃣ Документ не меняют. Нашли ошибку, выпускают новый номер, а в шапке старого появляется Obsoleted by. Поисковик легко отдаст отменённый: спецификация HTTP так переезжала дважды, из 2616 в 7230-7235, оттуда в 9110-9112.

3⃣ MUST, SHOULD, MAY. Готовая шкала обязательности: обязан, желательно, можно. Работает только запись заглавными, строчное must это обычный текст.

Чего не было в ролике: как сослаться на RFC в требовании

Формулировка, которая заканчивает спор на груминге:

«Сервис ДОЛЖЕН возвращать ошибки в формате RFC 9457 (Problem Details for HTTP APIs). Поля type и title обязательны, коды ошибок домена передаются в расширенных полях.»

Три правила такой ссылки:

➖ Номер, название и раздел: RFC 9110, §15.5.1, а не «по стандарту HTTP». Иначе разработчик и тестировщик прочитают её по-разному.
➖ Перед вставкой открой шапку и убедись, что документа не касается Obsoleted by. Ссылка на отменённый документ хуже, чем отсутствие ссылки: она выглядит обоснованной.
➖ Занеси решение в глоссарий проекта. Тогда второй раз этот спор не начнётся.

Шпаргалка: что искать по номеру

✔️ HTTP: 9110 (семантика, коды, заголовки), 9112 (HTTP/1.1)
✔️ JSON: 8259, точечные правки JSON Patch: 6902
✔️ Ссылки: 3986, дата и время: 3339
✔️ Авторизация: 6749 (OAuth 2.0), токены: 7519 (JWT)
✔️ Ошибки API: 9457, email-адрес: 5322, UUID: 9562

Где смотреть: rfc-editor.org (статус, Obsoleted by, errata) и datatracker.ietf.org (история правок и черновики).

А на какой стандарт чаще всего ссылаешься ты или все на экспертном мнении?

----

✌️ ПРО СА| 🆕 НСА 2.0