Разложить пользовательскую историю на системные требования, каждое из которых называет компонент, действие, данные и условие и не забывает поведение при отказе.
Что делает системный аналитик с историей
Что делает системный аналитик с историей
В курсе «Бизнес- и системный анализ» (дальше — BA-курс) цепочка заканчивалась пользовательской историей и функциональным требованием: что делает система. Системный аналитик (SA) продолжает: какой именно компонент это делает, с какими данными, через какой интерфейс и что будет при отказе.
Кейс курса — «Ромашка», доставка продуктов из магазинов-партнёров. Наша система — сервис заказов. С ним работают клиентское приложение, платёжный провайдер, магазины, сервис курьеров, сервис уведомлений и аналитика.
Формула системного требования: компонент + действие + данные + условие. Пример: сервис заказов (компонент) запрашивает у провайдера возврат (действие) всей суммы (данные) при отмене оплаченного заказа (условие). В таблице ниже история об отмене разложена на пять требований. СТ-3 описывает отказ: без таких требований разбор неполон.
Порядок разбора: 1) участники и системы; 2) основной сценарий по шагам; 3) на каждом шаге — компонент и данные; 4) отказы и негативные сценарии; 5) проверка каждого требования по чек-листу качества из BA-курса.
В отличие от истории, системное требование называет компонент, проверяется тестом и не описывает ни кнопки, ни код. Из системных требований потом выводят контракт метода API.
Граница роли: SA описывает требования, контракты и модели. Технологии и разбиение на сервисы выбирает архитектор — с участием SA. Код пишет разработчик.
История об отмене → системные требования
История: «Как клиент, я хочу отменить заказ до передачи курьеру, чтобы не платить за ненужное».
| № | Системное требование | Что описывает |
|---|---|---|
| СТ-1 | Сервис заказов принимает отмену, если статус — created (создан), paid (оплачен) или assembling (в сборке) | условие, при котором действие разрешено |
| СТ-2 | При отмене оплаченного заказа сервис заказов запрашивает у платёжного провайдера возврат всей суммы | действие с данными |
| СТ-3 | В статусах in_delivery (в доставке) и delivered (доставлен) сервис заказов отказывает в отмене и сообщает текущий статус | отказ |
| СТ-4 | После отмены сервис заказов публикует событие OrderCancelled | сообщение другим системам |
| СТ-5 | Сервис уведомлений сообщает клиенту об отмене не позже 30 с | действие с порогом времени |
Цепочка от бизнеса к системе
- 1Бизнес-требование
Отмена без звонка в поддержку
- 2User story
«Хочу отменить заказ до курьера»
- 3Системное требование
СТ-1: отмена в created, paid, assembling
- 4Контракт метода API
POST /orders/{orderId}/cancel и коды ответа
- 5Реализация в коде
Обработчик отмены в сервисе заказов
Артефакты SA — и на какой вопрос они отвечают
| Артефакт | Вопрос | Где в курсе |
|---|---|---|
| Системные требования | что и при каком условии делает каждый компонент | этот урок |
| Контекстная диаграмма | с кем обмениваемся данными | урок 1.3 |
| Контракт API | какой запрос и какой ответ | юниты 2–3 |
| Описание событий | что и кому сообщаем асинхронно | юнит 4 |
| Sequence-диаграмма | в каком порядке вызовы | урок 5.1 |
| Диаграмма состояний | через какие статусы проходит объект | урок 5.2 |
| Модель данных | что храним и как связано | урок 5.3 |
Конспект урока
Что делает системный аналитик с историей
В курсе «Бизнес- и системный анализ» (дальше — BA-курс) цепочка заканчивалась пользовательской историей и функциональным требованием: что делает система. Системный аналитик (SA) продолжает: какой именно компонент это делает, с какими данными, через какой интерфейс и что будет при отказе.
Кейс курса — «Ромашка», доставка продуктов из магазинов-партнёров. Наша система — сервис заказов. С ним работают клиентское приложение, платёжный провайдер, магазины, сервис курьеров, сервис уведомлений и аналитика.
Формула системного требования: компонент + действие + данные + условие. Пример: сервис заказов (компонент) запрашивает у провайдера возврат (действие) всей суммы (данные) при отмене оплаченного заказа (условие). В таблице ниже история об отмене разложена на пять требований. СТ-3 описывает отказ: без таких требований разбор неполон.
Порядок разбора: 1) участники и системы; 2) основной сценарий по шагам; 3) на каждом шаге — компонент и данные; 4) отказы и негативные сценарии; 5) проверка каждого требования по чек-листу качества из BA-курса.
В отличие от истории, системное требование называет компонент, проверяется тестом и не описывает ни кнопки, ни код. Из системных требований потом выводят контракт метода API.
Граница роли: SA описывает требования, контракты и модели. Технологии и разбиение на сервисы выбирает архитектор — с участием SA. Код пишет разработчик.