Привет!

Возник такой вот вопрос: приходилось ли кому-нибудь на практике документировать требования к SOA-сервисам в виде пользовательских историй?

Возьмем пример:

High level business story
AS a prepaid customer with monthly payment tariff
I WANT to change my tariff to pay&go
SO THAT I can optimize my cashflow

Examples
GIVEN Jack who is prepaid customer with monthly payment tariff
AND he has enough money on his balance
WHEN he is changing his tariff to pay&go
THEN his tariff is changed to Pay&Go within 5 minutes and his balance is down by €5
....
Это в кратце описывает некую бизнес-функциональность и бизнес-требование и вообщем-то понятно, что от системы требуется. Теперь идем дальше и предположим у нас есть некий SOA Layer который реализует всю бизнес-логику и нам соответственно надо сделать дополнительный сервис который будет менять тариф по запросу, при этом на проекте трудится две команды, одна делает Presentation Layer – веб сайт к примеру через который пользователи будут запрашивать изменение тарифа, а другая команда у нас делает именно бизнес-логику в SOA. В итоге мы имеем требования к SOA-сервисам от нескольких стейкхолдеров:
1. от команды которая делает Presentation Layer
2. от SOA Governance guys
3. и к примеру от Support Operations guys
Требования эти сводятся вообщем к тому, что нужен сервис для смены тарифа, сервис должен выдерживать Х смен тарифа в секунду и иметь такой-то интерфейс, что бы его можно было реюзать в других бизнес-процессах.

Сейчас это все дело документируется в виде набора табличек и plain text descriptions в составе дизайн документов. Проблема с таким подходом в том, что описание очень хаотичное и трудно понимаемое, там переплетено все на свете, не понятно кто и почему это просит и как это связанно с бизнес-требованиями, не до конца понятен Acceptance Criteria.

Понятное дело, что решение этой проблемы не зависит от выбранной техники: Use Cases/User Stories/whatever, а главное просто структурировать информацию и включить в нее все необходимые детали. Просто на мой взгляд  User Stories дают хороший фреймворк/гайд лайн для того что бы правильно задокументировать нужную информацию.

Вообщем я вижу это в каком-то таком вот виде:
==============================
Story
AS Presentation Layer Tech Lead
I WANT SOA service "AccountManagement.changeBalance" which will change user balance
SO THAT I can change user balance from Web-site

Example
GIVEN Jack who is prepayment customer  with monthly payment tariff
WHEN I call "AccountManagement.changeBalance" service with following parameters <...>
THEN I got following response <...>
AND Jack's tariff is changed

Story
AS SOA Governance guy
I WANT "AccountManagement.changeBalance" service to have following interface <...>
SO THAT it can integrate in enterprise SOA factory and be reused in different business cases

Story
AS Support Operations guy
I WANT "AccountManagement.changeBalance" service to comply with following performance requirements <..>
SO THAT We can support this service


================================

Что вы думаете о таком подходе? Приходилось ли его применять на практике? Идеи получше?

Заранее спасибо,
Костя

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

Но у меня возник вопрос - а для чего нужен именно такой документ? Если требования высокого уровня, то почему не подходит Vision? Там как раз все стэйкхолдеры перечисляются и их ключевые требования. И, в общем-то, документ всем знакомый и понятный.

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

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

Подход как подход, если команда понимает его - то в целом не хуже Use Cases.
Только кроме User Story нужно писать How to Demo и Acceptance Test.

Получается следующее: User Story короткая и без лишних деталей.
How to Demo - описание того, как показать в вашей системе данную User Story.
Acceptance Test - подробное и конкретное описание техники работы - алгоритма и т.п.