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

PRO код для аналитика 💻

Нужно ли системному аналитику уметь писать код?
Нет. 🙅‍♂

Но я убеждён, что опыт кодирования сильно повышает компетентность системного аналитика. 🚀

Я начал программировать ещё в школе и это был Pascal. Потом в университете были C, C++, ассемблеры для RISC и CISC, программировал микроконтроллеры, писал прошивки и драйверы.

После университета писал программы для диссертации на MATLAB и C#, делал прошивки для DSP-процессоров, писал на PHP, Java, HTML, CSS. Делал Excel-макросы, собственные программы и инструменты для компании (например, написал систему управления рабочим временем), дорабатывал Redmine под наши процессы.

Сейчас чаще всего пишу на Python. Правда, значительную часть кода теперь пишут за меня нейросети. 🤖

Но дело не в количестве языков.

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

Ты понимаешь, что недостаточно спроектировать решение, которое работает сегодня.

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

Постоянно нужно учитывать:

✔️Что произойдёт, если изменится бизнес-правило?
✔️ Появится новый сценарий?
✔️ Потребуется подключить ещё одну систему?
✔️Изменится существующий процесс?

Системный аналитик уровня senior, на мой взгляд , точно должен учитывать эти моменты.

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

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

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

А если вы пока только присматриваетесь к профессии системного аналитика, сейчас есть хороший способ попробовать её на практике.

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

Кстати спасибо за отзывы 🤝! На их основе улучшается бот)

Но это не предел.

Мы сделали небольшой 🆓 мини-практикум по интервью с заказчиком. 🎤

В нём можно самостоятельно пройти часть работы аналитика и посмотреть, насколько вам вообще близок такой способ мышления.

Начать можно здесь:
[ссылка на бота] 🐭

Это не лекция о профессии, а немного предметной теории и возможность попрактиковаться.

----

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