Вы описали не сценарий варианта использования, а целый бизнес-процесс. :)
В книге Вигерса (и примкнувшей к нему Джой Битти) метод вариантов использования, конечно же, полностью не описан.
Рекомендую книгу Коберна «Writing Effective Use Cases» (которой очень не повезло с русским переводом названия: то ли переводчик, то ли редактор выпендрился, и по-русски её назвали «Современные методы описания функциональных требований к системам»). Вот в ней этот метод описан, можно сказать, исчерпывающе.
Вообще-то от агрегатора должна приходить (и приходит) информация о двух транзакциях: о полной сумме оплаты и о снятой комиссии. И Эльба, и МоёДело в связке с агрегаторами или эквайерами всё считают корректно. Это у вас какая-то неправильная онлайн-бухгалтерия.
В статье фотография не из того КВИРТУ. В Киеве в 50-е было два училища с похожими названиями: КВИРТУ ВВС и КВИРТУ ПВО.
Судя по описанию, он успел поучиться в КВИРТУ ВВС, позже переименованном в КВВАИУ (Киевское высшее военное авиационное училище). Это оно было расположено на Воздухофлотском проспекте.
А КВИРТУ ПВО было создано только в 1953 году, так что в 52-м он никак не мог туда поступить.
Главное, что я вынес из книг Купера, который разработал этот метод: персоны нужны для того, чтобы запустить «встроенный механизм» эмпатии при анализе потребностей пользователей. Разработчики должны относиться к персонажу, как к реальному человеку. Для этого и придумывается имя, выбирается лицо и добавляются мелкие детали привычек и характера, которые напрямую никак не связаны с создаваемым продуктом. А исследование перед созданием персон необходимо для выявления поведенческих переменных, которые позволят создать портреты для кластеров, наиболее близких к реальным (и желаемым) потребителям.
У вас эмпатия почему-то упоминается только как случайный эффект, который может возникнуть у саппорта. Но это не так, ведь только ради неё всё и затевалось! Иначе вполне хватит обычных маркетинговых стереотипов (одинокая домохозяйка со средним доходом).
IMHO, кстати, как раз саппорту персоны не нужны, потому что он и так работает с реальными людьми. В отличие от разработчиков продукта, которые обычно изолированы от своего потребителя и нуждаются в его релевантной модели.
Так зачем нужны персоны?
«Гики, которые смотрят Теорию большого взрыва» — это тот самый стереотип, который почему-то категорически не рекомендуется использовать. Хотя он вполне соответствует критерию «отражать какую-то часть реальных пользователей». А если провести качественное исследование потребителей, то и стереотип будет качественным, отражающим не «какую-то», а существенную часть.
Зачем тогда все эти сложности — фотография, имя, особенности характера?
Можно ещё провести такой опрос среди финансовых аналитиков, биржевых аналитиков и химиков-аналитиков. Тыжаналитик, вот и проанализируй мне метрики продукта!
Но почему не использовать «плавательные дорожки» для участников процесса? Как это принято в BPMN и допускается в UML. Сейчас диаграмма процесса практически нечитаема (при том, что он довольно простой) из-за большого числа стрелок и забора из разделителей, не имеющих особого смысла. Размещение акторов на отдельных дорожках сразу уберёт половину стрелок, замусоривающих диаграмму.
Главная проблема диаграммы Гантта не в том, что она становится сложной и трудносопровождаемой, а в том, что она создаёт видимость чёткого плана там, где его нет, а часто и не может быть.
ГОСТ 34 устарел именно из-за того, что это стандарт для разработки автоматизированных систем. А большинство разрабатываемых сейчас систем выходит за рамки определения АС. К сожалению, на это определение внимательно никто не смотрит, и сплошь и рядом считают, что любой программный продукт можно подвести под это определение.
В первую очередь, он устарел как раз из-за того, что в АС люди считаются «персоналом» — винтиками системы. Это отношение к людям как к персоналу выводит на первый план потребности организации и реализацию необходимых только ей функций. Это было так, когда вычислительные машины были большими и дорогими, это перестало быть так с появленим персональных компьютеров, и стало совсем не так с массовым распространением интернета.
При попытке применить ГОСТовский подход к системам, предоставляющим какой-то сервис для людей, получается как в анекдоте про детскую коляску и автомат Калашникова. Это было очень хорошо видно по первой версии портала госуслуг, например. И по-прежнему видно по сайтам, разрабатываемым по заказам госорганизаций, где ГОСТ очень любят.
Устарела и сама концепция видов обеспечения. Люди упорно пишут в раздел требований к лингвистическому обеспечению что-то вроде "интерфейс пользователя должен быть на русском языке". И правильно делают, потому что проблема лингвистического обеспечения давно решена и опустилась с уровня бизнес-требований в самый низ, на уровень реализации.
Опасность ГОСТа в том, что он кажется со стороны полноценной и законченной методикой разработки требований. Но, во-первых, он ей не является. Стандарт описывает результаты работ по выявлению и описанию требований, но не говорит практически ничего об их содержании. А во-вторых, он токсичен. Начав работать по ГОСТу, вы всё больше погружаетесь в болото его концепций. Эти концепции очень трудно изжить. Если вы после этого перейдёте в проект разработки продукта, который не подходит под определение АС, то ГОСТовский образ мышления будет отравлять ваш продукт. Вы будете думать в первую очередь о функциях, и в последнюю о людях (лично я это постоянно вокруг себя наблюдаю).
Если вам всё же не повезло в этой жизни, и вы вынуждены работать по ГОСТу, то, кроме искреннего сочувствия, могу вам посоветовать изучить его предшественника: серию стандартов ГОСТ 24. Тогда речь шла даже не об АС, а об АСУ — автоматизированных системах управления. Сама концепция АСУ вам вряд ли пригодится, но вы, по крайней мере, лучше поймёте значение многих терминов, которые используются в ГОСТ 34. Разработчики ГОСТ 34 использовали эти термины в предположении, что их и так уже все знают, поэтому ГОСТ 34 очень (даже слишком) лаконичен.
Да, не всем. Но я им пользуюсь именно как платёжным агрегатором: с моего сайта для оплаты пользователь переходит на карточку товара на Маркете, там оплачивает и получает чек, а мой сайт тут же регистрирует оплату через api робомаркета.
Не указано самое важное отличие Робомаркета, связанное с 54-ФЗ: он является ещё и платёжным агентом. То есть сам выдаёт чеки покупателям: дополнительная интеграция с онлайн-кассой не нужна!
При подключении яндекс.кассы и робокассы вопрос с 54-ФЗ остаётся открытым. Да, они предлагают интеграцию с сервисом аренды онлайн-касс. А это, не считая затрат на саму интеграцию, ещё от ~3600 руб. в месяц.
imho самые лучшие термины — те, которые больше ни с чем не ассоциируются, и поэтому однозначно идентифицируют то, что означают. Термины «vision» и «usecase» лучше, чем «концепция» и «вариант использования».
В своё время usecase неграмотно перевели как «прецедент» (взяли из юридического словаря). Так этот вариант перевода, на мой взгляд, оказался самым удачным именно потому, что в айтишной лексике он больше ни к чему не привязан.
Не зря в Agile (тоже отличное иностранное слово) используют термины вроде «бэклог», «спринт» и т. п. — ни у кого не возникает ложных ассоциаций с другими сущностями.
А зачем разбирать терминологию из первого издания Вигерса, если вышло уже третье, в том числе в русском переводе? В котором уже нет ни «границ проекта», ни «документа о вариантах использования».
Война с призраками.
А на серверную часть вы требования не пишете? И на сценарии взаимодействия мобильного приложения с сервером?
А это какого года статья? Кажется, я её уже читал лет десять назад. И картинки знакомые: IE9, Safari 4, Opera 10...
<<Первый в истории телескоп был изобретен итальянским ученым и священником Галилео Галилеем в 1609 году.>>
Галилей был священником?! Инфа 100%?
В книге Вигерса (и примкнувшей к нему Джой Битти) метод вариантов использования, конечно же, полностью не описан.
Рекомендую книгу Коберна «Writing Effective Use Cases» (которой очень не повезло с русским переводом названия: то ли переводчик, то ли редактор выпендрился, и по-русски её назвали «Современные методы описания функциональных требований к системам»). Вот в ней этот метод описан, можно сказать, исчерпывающе.
Вообще-то от агрегатора должна приходить (и приходит) информация о двух транзакциях: о полной сумме оплаты и о снятой комиссии. И Эльба, и МоёДело в связке с агрегаторами или эквайерами всё считают корректно. Это у вас какая-то неправильная онлайн-бухгалтерия.
Судя по описанию, он успел поучиться в КВИРТУ ВВС, позже переименованном в КВВАИУ (Киевское высшее военное авиационное училище). Это оно было расположено на Воздухофлотском проспекте.
А КВИРТУ ПВО было создано только в 1953 году, так что в 52-м он никак не мог туда поступить.
У вас эмпатия почему-то упоминается только как случайный эффект, который может возникнуть у саппорта. Но это не так, ведь только ради неё всё и затевалось! Иначе вполне хватит обычных маркетинговых стереотипов (одинокая домохозяйка со средним доходом).
IMHO, кстати, как раз саппорту персоны не нужны, потому что он и так работает с реальными людьми. В отличие от разработчиков продукта, которые обычно изолированы от своего потребителя и нуждаются в его релевантной модели.
«Гики, которые смотрят Теорию большого взрыва» — это тот самый стереотип, который почему-то категорически не рекомендуется использовать. Хотя он вполне соответствует критерию «отражать какую-то часть реальных пользователей». А если провести качественное исследование потребителей, то и стереотип будет качественным, отражающим не «какую-то», а существенную часть.
Зачем тогда все эти сложности — фотография, имя, особенности характера?
Но почему не использовать «плавательные дорожки» для участников процесса? Как это принято в BPMN и допускается в UML. Сейчас диаграмма процесса практически нечитаема (при том, что он довольно простой) из-за большого числа стрелок и забора из разделителей, не имеющих особого смысла. Размещение акторов на отдельных дорожках сразу уберёт половину стрелок, замусоривающих диаграмму.
www.greesha.ru/livejournal/символ-несбывшихся-надежд
В первую очередь, он устарел как раз из-за того, что в АС люди считаются «персоналом» — винтиками системы. Это отношение к людям как к персоналу выводит на первый план потребности организации и реализацию необходимых только ей функций. Это было так, когда вычислительные машины были большими и дорогими, это перестало быть так с появленим персональных компьютеров, и стало совсем не так с массовым распространением интернета.
При попытке применить ГОСТовский подход к системам, предоставляющим какой-то сервис для людей, получается как в анекдоте про детскую коляску и автомат Калашникова. Это было очень хорошо видно по первой версии портала госуслуг, например. И по-прежнему видно по сайтам, разрабатываемым по заказам госорганизаций, где ГОСТ очень любят.
Устарела и сама концепция видов обеспечения. Люди упорно пишут в раздел требований к лингвистическому обеспечению что-то вроде "интерфейс пользователя должен быть на русском языке". И правильно делают, потому что проблема лингвистического обеспечения давно решена и опустилась с уровня бизнес-требований в самый низ, на уровень реализации.
Опасность ГОСТа в том, что он кажется со стороны полноценной и законченной методикой разработки требований. Но, во-первых, он ей не является. Стандарт описывает результаты работ по выявлению и описанию требований, но не говорит практически ничего об их содержании. А во-вторых, он токсичен. Начав работать по ГОСТу, вы всё больше погружаетесь в болото его концепций. Эти концепции очень трудно изжить. Если вы после этого перейдёте в проект разработки продукта, который не подходит под определение АС, то ГОСТовский образ мышления будет отравлять ваш продукт. Вы будете думать в первую очередь о функциях, и в последнюю о людях (лично я это постоянно вокруг себя наблюдаю).
Если вам всё же не повезло в этой жизни, и вы вынуждены работать по ГОСТу, то, кроме искреннего сочувствия, могу вам посоветовать изучить его предшественника: серию стандартов ГОСТ 24. Тогда речь шла даже не об АС, а об АСУ — автоматизированных системах управления. Сама концепция АСУ вам вряд ли пригодится, но вы, по крайней мере, лучше поймёте значение многих терминов, которые используются в ГОСТ 34. Разработчики ГОСТ 34 использовали эти термины в предположении, что их и так уже все знают, поэтому ГОСТ 34 очень (даже слишком) лаконичен.
При подключении яндекс.кассы и робокассы вопрос с 54-ФЗ остаётся открытым. Да, они предлагают интеграцию с сервисом аренды онлайн-касс. А это, не считая затрат на саму интеграцию, ещё от ~3600 руб. в месяц.
В своё время usecase неграмотно перевели как «прецедент» (взяли из юридического словаря). Так этот вариант перевода, на мой взгляд, оказался самым удачным именно потому, что в айтишной лексике он больше ни к чему не привязан.
Не зря в Agile (тоже отличное иностранное слово) используют термины вроде «бэклог», «спринт» и т. п. — ни у кого не возникает ложных ассоциаций с другими сущностями.
Война с призраками.