Всем привет! Мой блог посвящен системному анализу в IT. Я уже далеко не первый год в этой сфере, но все еще не могу структурировать у себя и запомнить огромный пласт теории, который так или иначе нужно знать аналитику.
К сожалению, в этой сфере нет какого-то единого стандарта, списка тем, зная которые, ты будешь иметь определенный уровень на рынке. Своего рода IELTS в английском языке. Каждая компания спрашивает свое и оценивает по-своему. А интернет пестрит статьями из серии "Полный список вопросов на собеседование по системной аналитике".
Раньше с таким форматом "экзамена" я сталкивалась только на собеседованиях, а теперь пришлось отчитываться от и до и на аттестации. Я должна уметь развернуто рассказать обо всем, что прямо или косвенно касается аналитики. Честно, мне сложно легко и непринужденного рассказывать теорию на темы, которые в силу рабочих задач не поднимались уже кучу времени. Поэтому в своем блоге я разберу каждый вопрос, который встречается мне на собеседовании или аттестации.
Сразу оговорюсь, я не буду пояснять кто такой системный аналитик и чем он занимается. Договоримся, что эту информацию мы уже знаем.
Юз кейс - что это?
Да, англицизмы меня ставят в ступор, я работаю не в международной компании и говорим мы на русском языке. Но, комьюнити не видит велью говорить "Варианты использования" вместо "Юз кейс", поэтому с этой минуты говорим только Use Case и никак иначе.
Use case - вариант использования (сценарий использования), это методология. Если уж слово английское и автор зарубежный, вот вам первоисточник - описание на английском, автор Ивар Джейкобсон, придумана первоначальная версия в 1986г. Он же, кстати говоря, описал и процесс разработки программного обеспечения OOSE (object-oriented software engineering).
Первая версия Use-case была представлена на конференции OOPSLA 87, но широкое распространение методология получила в 1992г. после выхода книги "Object-Oriented Software Engineering—a Use-Case–Driven Approach", по словам самого автора.
Определений методологии Use case масса, и все они максимально абстрактные. Я прямо вижу, как словно молитву ведущий аналитик компании наизусть читает:
Use Case (вариант использования, ВИ, Прецедент, юскейс) — это сценарная техника описания взаимодействия. С помощью Use Case может быть описано и пользовательское требование, и требование к взаимодействию систем, и описание взаимодействия людей и компаний в реальной жизни, это способ описания того, как определённый пользователь или система взаимодействует с программным продуктом для достижения определенной цели.
Или так:
Use Case, сценарий использования, юзкейс — сценарная техника описания взаимодействия пользователей с продуктом, которое приведет к достижению конкретной цели. Сценарий использования описывает, кто и что может сделать с системой или что система может сделать с кем и чем.
Мне понравилось объяснение Юрия Дуброва в статье на хабре:
Юзкейс — это текст, описывающий сценарий (возможно, не один) взаимодействия (кого или чего?) с системой, приводящий (возможно, не приводящий) к значимому (для кого?) результату.
Когда писать use case?
Юз кейсы могут пригодиться на любом этапе проекта:
- На этапе сбора бизнес требований - для лучшего понимания процессов, чтобы ничего не упустить.
- В течение разработки проекта - если проект крупный (например, разработка CRM системы для юридических лиц с нуля), то сесть и написать все юз кейсы разом - тяжело. Можно писать их, например, итеративно - под каждую конкретную задачу.
- На этапе написания системной аналитики для разработчиков - поможет лучше понимать как работает система. После разработки юз кейсы пригодятся и тестировщикам также для понимания.
Для чего писать use case?
- Чтобы ничего не упустить, вовремя подумать о пользователе и просчитать все варианты.
- Чтобы вас поняли все, и поняли правильно: заказчики, разработчики, тестировщики, да даже коллеги из смежных команд.
- Чтобы сдать функционал заказчику - отличный вариант для приемо-сдаточных испытаний, или проще говоря, для проверки того, что вы сделали, заказчиком. Заказчик прошелся по всем кейсам в вашей системе, отметил их пройденными и подписал договор, что претензий более не имеет. Все остальное уже будет за дополнительную плату в ходе доработок.
Что пишет сам автор методологии?
The use cases of a business are the processes of the business; thus, the advantage of doing business modeling with use cases is that it leads directly to finding the use cases of the system to be developed to support the business. Moreover, use cases help in finding commonalities, which directs the architecture work to achieve software reuse
Ну и мой, возможно, топорный перевод:
Юз кейсы бизнеса — это бизнес-процессы; таким образом, преимущество бизнес-моделирования с использованием вариантов использования заключается в том, что оно напрямую ведет к поиску вариантов использования системы, которые требуется разработать. Более того, варианты использования помогают найти повторения, что дает архитектуре направление в переиспользовании кода.
Как написать use case?
Какие есть принципы написания юз кейсов? Опять же, тут нужно вставить слова самого автора. Да, они довольно нагруженные, а еще трудности перевода не добавляют приятного, но все же.
PRINCIPLES FOR USE-CASE ADOPTIONT
here are six basic principles at the heart of any successful application of use cases:
1. Keep it simple by telling stories.
2. Understand the big picture.
3. Focus on value.
4. Build the system in slices.
5. Deliver the system in increments.
6. Adapt to meet the team’s needs.
Я бы перевела это так:
1. Будь проще и люди к тебе потянутся при написании процессов
2. Понимай общую картину проекта
3. Фокусируйся для чего это нужно (ценность твоего приложения/системы для пользователя)
4. Разделяй систему (проект) на составляющие
5. Разделяй систему на этапы - релизь большой проект частями, делая при этом какую-то часть описанных юз кейсов
6. Адаптируй к потребностям команды
Для понимания общей картинки того, что вы разрабатываете, автор предлагает использовать use-case диаграммы, на которых с использованием человечков (актеров), облачков (действий) и стрелочек (связей) можно отобразить процессы в целом:
Также сам создатель 6 пунктом разрешил нам адаптировать юз кейсы под потребности команды. Мы можем сами выбрать, что нужно при описании, что не нужно. Какой формат привычнее заказчикам, если юз кейсы в первую очередь нацелены на них.
Ура, можем писать юз кейсы как хотим! Шучу, не можем. На аттестации или собеседовании вероятнее всего будут спрашивать про оформление классического текстового юз кейса, так что давайте рассмотрим его.
Итак, юз кейс состоит из:
- Заголовок - название варианта использования, отражающее суть сценария.
- Акторы (участники) - участники сценария. Участниками сценария могут быть не только люди/пользователи, но и системы.
- Предусловие - что должно быть с акторами до выполнения сценария.
- Триггер - что провоцирует вызов сценария.
- Результат - успешный результат сценария.
- Основной сценарий - хеппи пас, как дойти от триггера к результату.
- Альтернативный сценарий - негативный сценарий, описывается обычно отдельно как самостоятельный сценарий.
Лично я на практике не выделяю триггер в отдельный пункт, а указываю его как 1-ый шаг сценария. Почему? Потому что мне так кажется логичнее и приятнее, а также автор всея юз кейсов 6 пунктом мне разрешил.
Акторов я обычно выделяю в отдельный пункт. Может казаться, что это перегружает сценарий. Но, если вы пишете юз кейсы для большого проекта, который задействует множество систем, разрабатываемых разными командами, акторы ускоряют поиск нужных вам сценариев. Открыл небольшой документик на 100 страниц, выбрал поиском свою систему в качестве актора, работать становится куда приятнее.
Также лично мне приятнее писать результат после сценария, опять же, кому как удобнее.
Пример use case
Примером задачи, для которой можно написать use case, может стать что угодно. Буквально любой процесс из жизни.
Но, я не ищу легких путей, поэтому:
Дано: У нас небольшой виджет, в котором пользователь может, заполнив форму, подписаться на рассылку промокодов от сразу нескольких организаций. Состав организаций может меняться, с кем-то заключаем договор, с кем то расторгаем. Некоторые пользователи стали обращаться с жалобами, что они не давали согласие на рассылку от компании N. Удаление из списка рассылок их не устраивает, они обратились в суд и хотят взыскать моральный ущерб за нарушение закона о персональных данных, ведь их данные передали третьим лицам без соглашения.
Что делать: Нужно помочь единственному юристу в нашей компании, а именно, дать материал, кто, когда и на какой список компаний подписался. Список компаний примерно ежемесячно выдает нам начальник нашей небольшой конторы в файле, который и видят пользователи, когда жмут заветное "Подписаться".
Решение: Нужно реализовать версионирование для списков компаний. И записывать, на какой конкретно файл подписался пользователь. Лучше будет, если информация по всем версиям файлов будет в открытом доступе. Тогда в суде наш единственный юрист сможет получить выгрузку из нашей базы и указать, кто когда на что подписался и что все были предупреждены. Юрист наш малоопытный, подумал, что это лучше, чем ничего и одобрил задачу.
Какие тут можно написать юз кейсы?
ВИ-1 Подписка пользователя на рассылку
Акторы: Пользователь, Виджет
Предусловие: Пользователь находится на странице с виджетом. Фронт виджета имеет информацию о версии файла с компаниями
Триггер: Пользователь ввел данные в виджет и нажал "Подписаться" (я намеренно даю детали, т.к. интерфейс виджета в задаче уже предполагается реализованным)
Результат: Данные о подписке сохранены. Клиент видит, что он успешно подписался.
Основной сценарий:
1. Фронт виджета отправляет данные пользователя и версию файла на бек.
2. Бек виджета сохраняет данные о пользователе в зашифрованном виде в базу и версию документа с компаниями.
3. Бек возвращает успешный статус ответа метода.
4. Фронт отображает информацию клиенту о том, что он успешно подписался.
Альтернативным сценарием тут будет ошибка на беке.
Следующие сценарии я просто перечислю и для экономии места не буду описывать:
ВИ-2 Просмотр списка компаний пользователем
ВИ-3 Просмотр истории файлов пользователем
ВИ-4 Загрузка файла сотрудником компании
ВИ-5 Получение данные по запросу от юриста
Какие сценарии выделили ли бы вы?
Что с use case сегодня?
Методология придумана довольно давно. Сам автор утверждает, что она актуальна до сих пор, не смотря на все большую потребность в компаниях описывать сценарии именно через BPMN-схемы.
На практике я тоже часто использовала юз кейсы для описания. В основном при написании бизнес-требований, документов для приемо-сдаточных испытаний.
К сожалению, в моей практике первое столкновение с новой системой обычно берут на себя архитекторы. Они исследуют систему и описывают бизнес процессы. Иногда участвуют и системные аналитики. Так вот, архитекторы чаще текстовое описание заменяют на изображение сценария (процесса) в BPMN-схеме.
А вы используете юз кейсы? Расскажите, как у вас в компании этот процесс устроен.
