И сразу первая заметка: требования к внешним интерфейсам.
Контекст, в котором нам нужно жить:
- Наши решения часто взаимодействуют с внешними интерфейсами (т. е. точками входа во внешние программные и аппаратные системы).
- Бизнес-аналитик зачастую — это тот человек, на которого скинут проработку требований к сему делу. А на системного аналитика еще и взвалят проектирование технического подхода к этому.
- Это та часть, где аналитику надо собрать свои жалкие технические наработки в кулак и выкушать этот кактус. При нехватке оных — взять за шкирку девелопера и попросить его помочь расшифровать инопланетные скрижали.
В обучении аналитиков по опыту это одна из наиболее сложных тем. Краткие советы на примере работы с API (это типовой вариант общения с внешними интерфейсами, но далеко не единственный — однако общая концепция отсюда вполне себе реюзабельна и для иных их видов):
1) Главное, что нужно понять: в чем полезный скоуп вашей работы в этой части? Участие аналитика в проработке этих требований не стандартизировано. Т. е. идём к команде и выясняем, какого рода информация им необходима и полезна, а какая — избыточна или даже вредна своим наличием (вы можете принять неверные технические решения, если подобная работа — не на вас и вы будете делать это в одно лицо). После этого колбасим небольшой прототип документации по собранным советам и даем на ревью.
Если же полезный инпут сходу собрать сложно (”а хз, что нам надо — надо смотреть на то, что можешь предложить”), запросто берем шаблон из этой заметки.
2) Чеклист, который в среднем по больнице отлично подходит для этой задачи:
2.1) Что за внешние интерфейсы у нас есть (с чем решению нужно взаимодействовать)?
2.2) Каковы точки взаимодействия с каждым из них:
- методы API, которые нужно использовать
- описание обращения к ним в поведенческих требованиях
2.3) Как нужно общаться в рамках каждой точки взаимодействия:
- маппинг данных между данными решения и запросом/ответом для сторонней системы
- алгоритмы преобразования этих данных в процессе (если актуально)
2.4) Реакция системы на нестандартные ситуации:
- недоступность интерфейса
- отсутствующая информация в ответах
- ошибки, присылаемые внешней системой в ответах
Контекст, в котором нам нужно жить:
- Наши решения часто взаимодействуют с внешними интерфейсами (т. е. точками входа во внешние программные и аппаратные системы).
- Бизнес-аналитик зачастую — это тот человек, на которого скинут проработку требований к сему делу. А на системного аналитика еще и взвалят проектирование технического подхода к этому.
- Это та часть, где аналитику надо собрать свои жалкие технические наработки в кулак и выкушать этот кактус. При нехватке оных — взять за шкирку девелопера и попросить его помочь расшифровать инопланетные скрижали.
В обучении аналитиков по опыту это одна из наиболее сложных тем. Краткие советы на примере работы с API (это типовой вариант общения с внешними интерфейсами, но далеко не единственный — однако общая концепция отсюда вполне себе реюзабельна и для иных их видов):
1) Главное, что нужно понять: в чем полезный скоуп вашей работы в этой части? Участие аналитика в проработке этих требований не стандартизировано. Т. е. идём к команде и выясняем, какого рода информация им необходима и полезна, а какая — избыточна или даже вредна своим наличием (вы можете принять неверные технические решения, если подобная работа — не на вас и вы будете делать это в одно лицо). После этого колбасим небольшой прототип документации по собранным советам и даем на ревью.
Если же полезный инпут сходу собрать сложно (”а хз, что нам надо — надо смотреть на то, что можешь предложить”), запросто берем шаблон из этой заметки.
2) Чеклист, который в среднем по больнице отлично подходит для этой задачи:
2.1) Что за внешние интерфейсы у нас есть (с чем решению нужно взаимодействовать)?
2.2) Каковы точки взаимодействия с каждым из них:
- методы API, которые нужно использовать
- описание обращения к ним в поведенческих требованиях
2.3) Как нужно общаться в рамках каждой точки взаимодействия:
- маппинг данных между данными решения и запросом/ответом для сторонней системы
- алгоритмы преобразования этих данных в процессе (если актуально)
2.4) Реакция системы на нестандартные ситуации:
- недоступность интерфейса
- отсутствующая информация в ответах
- ошибки, присылаемые внешней системой в ответах