UseCasesMethods.png
Последние пара советов по юз кейсам (ВИ, варианты использования) из области не очень очевидных — на этот раз даже с картинками 🙂
5. Осознанная “игра” UI в сценариях юз кейсов. Периодически вижу безапелляционную рекомендацию не затрагивать UI в формулировке шагов юз кейсов. Мне это кажется слишком ограничивающим, и больше по душе два варианта: “интерфейсозависимые” (это когда мы оперируем нашим UI в шагах и иных параметрах ВИ) и “интерфейсонезависимые” (когда сознательно абстрагируемся от UI) юз кейсы. Термины, если что, собственные. По аналогии с User Stories это один из способов сделать юз кейсы negotiable, т. е. сознательно пожертвовать детализацией во имя благих целей.
Два ключевых фактора, которые влияют на выбор подхода: задачи, которые мы решаем с помощью ВИ, и зона ответственности аналитика (проще говоря, входит ли проработка UI в работу аналитика или нет). Обе эти вещи часто варьируются от проекта к проекту, в особенности при смене заказчика и команд. Примеры ситуаций:
1) Юз кейсы прорабатываются уже на этапе общения с пользователями, и мы хотим вначале постичь полную картину user requirements. В этом случае, дабы не привязываться ментально к на ходу спроектированному UI, а сфокусироваться на user flows, я использовал бы интерфейсонезависимые юз кейсы.
2) Юз кейсы — техника спецификации требований, и функциональные требования не описаны где-либо еще. В таком случае, добавив макеты, я однозначно пользовал бы UI в шагах таких юз кейсов. В комбинации получается вполне себе рабочий способ подачи требований.
3) Вариант, аналогичный предыдущему, но представим, что помимо юз кейсов мы документируем UI где-то еще — например, описываем контролы где-то отдельно. Тут я бы не использовал UI внутри юз кейсов, т. к. мы придем к дублированию информации и усложнению поддержки требований. Т. е. ВИ тут служили бы описанием user flows для понимания контекста, а описание UI — детальной спецификацией для команды.
4) Вариант, аналогичный предыдущим двум, но с дополнительным контекстом: UI — не на плечах аналитика, т. е. есть дизайнер, юиксер и иже с ними, чьи руки заточены под эту задачу. В этом случае во всех своих требованиях я осознанно абстрагировался бы от UI, чтобы не лезть не в свое дело и не налагать лишних ограничений на работу экспертов.
На картинке — пример одного и того же ВИ в обоих форматах.
5. Осознанная “игра” UI в сценариях юз кейсов. Периодически вижу безапелляционную рекомендацию не затрагивать UI в формулировке шагов юз кейсов. Мне это кажется слишком ограничивающим, и больше по душе два варианта: “интерфейсозависимые” (это когда мы оперируем нашим UI в шагах и иных параметрах ВИ) и “интерфейсонезависимые” (когда сознательно абстрагируемся от UI) юз кейсы. Термины, если что, собственные. По аналогии с User Stories это один из способов сделать юз кейсы negotiable, т. е. сознательно пожертвовать детализацией во имя благих целей.
Два ключевых фактора, которые влияют на выбор подхода: задачи, которые мы решаем с помощью ВИ, и зона ответственности аналитика (проще говоря, входит ли проработка UI в работу аналитика или нет). Обе эти вещи часто варьируются от проекта к проекту, в особенности при смене заказчика и команд. Примеры ситуаций:
1) Юз кейсы прорабатываются уже на этапе общения с пользователями, и мы хотим вначале постичь полную картину user requirements. В этом случае, дабы не привязываться ментально к на ходу спроектированному UI, а сфокусироваться на user flows, я использовал бы интерфейсонезависимые юз кейсы.
2) Юз кейсы — техника спецификации требований, и функциональные требования не описаны где-либо еще. В таком случае, добавив макеты, я однозначно пользовал бы UI в шагах таких юз кейсов. В комбинации получается вполне себе рабочий способ подачи требований.
3) Вариант, аналогичный предыдущему, но представим, что помимо юз кейсов мы документируем UI где-то еще — например, описываем контролы где-то отдельно. Тут я бы не использовал UI внутри юз кейсов, т. к. мы придем к дублированию информации и усложнению поддержки требований. Т. е. ВИ тут служили бы описанием user flows для понимания контекста, а описание UI — детальной спецификацией для команды.
4) Вариант, аналогичный предыдущим двум, но с дополнительным контекстом: UI — не на плечах аналитика, т. е. есть дизайнер, юиксер и иже с ними, чьи руки заточены под эту задачу. В этом случае во всех своих требованиях я осознанно абстрагировался бы от UI, чтобы не лезть не в свое дело и не налагать лишних ограничений на работу экспертов.
На картинке — пример одного и того же ВИ в обоих форматах.