Карьера в IT. Системный аналитик, часть 2. Use cases\User stories

Всем привет.

Продолжим наше погружение в теоретические знания, необходимые системному аналитику (это применимо также и для бизнес-аналитика, первые три части моих лекций - точно).

Use cases

В первую очередь поговорим про Use case (далее используются термины «варианты использования», «сценарии», «юзкейсы»).

Use case описывает сценарий взаимодействия участников (как правило — пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система. С помощью Use Case может быть описано и пользовательское требование, и требование к взаимодействию систем, и описание взаимодействия людей и компаний в реальной жизни.

Чтобы ответить на вопрос “как их писать” - приведу пример, после которого всё станет понятно. Допустим, разберем простейший сценарии самой стандартной авторизации пользователя в систему:

Сам по себе UC должен описывать только успешный сценарий. Если же есть какие-то ответвления от него, то они описываются отдельно в расширениях - как в данном примере. Также, если альтернативный сценарий слишком большой - то он описывается отдельным сценарием использования, как, например, для варианта с "Напомнить пароль". Потому что по сути, это отдельный и самостоятельный сценарий, который еще даже больше текущего.

Т.к. варианты использования является набором требований более высокого уровня абстракции, чем набор отдельных функциональных требований - только с помощью них глубокий системный анализ провести невозможно. Но для некоторых проектов (где системный аналитик, или просто аналитик не глубоко погружен в технические дебри) и компаний - очень даже подходит, когда нужно описать для разработчиков верхнеувровневые требования.

И кроме этого, UC это естественный способ описывать диалог, он понятен человеку без подготовки и поэтому с помощью них очень удобно согласовывать задачу с заказчиком, без необходимости показывать всё своё сложное и большое ТЗ.

User stories

User Story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.

Особенности:

• Не являются детальным описанием требований, а представляют собой обсуждаемое намерение (нужно сделать что-то, вроде этого); 

• Короткие, легко читаемые и понятные всем (как разработчикам, так и пользователям); 

• Описывают небольшую часть функциональности, которая может быть реализована за короткий промежуток времени; 

• Не занимают больших, громоздких документов. Как правило сгруппированы в списки.

Структура - Как, <роль/персонаж пользователя>, я <что-то хочу получить>, <с такой-то целью> .

Примеры:

• Как пользователь, я хочу иметь возможность добавить комментарий к заявке для предоставления дополнительной информации;

• Как сотрудник поддержки, я хочу иметь возможность перевести заявку в статус "Отложено";

• Как пользователь, я хочу видеть все заявки, созданные мной, чтобы отслеживать их статус.

В этих пожеланиях есть один actor, одно действие и одна ценность (value, impact).

C актером все более-менее просто. Вы выделили персонажей, или у вас есть роли, и вы легко их вписываете в начало истории.

Действие

Наверное, здесь сложно ошибиться - это суть истории, “что нужно сделать”. Что можно улучшить. Действие должно быть одно - основное. Нет смысла описывать “авторизуется и выполняется поиск”. Укажите то действие, что вам действительно нужно.

Важно описывать историю на уровне “ЧТО?” делает, а не “КАК?” Это главное в истории. Опишите проблему, а не ее решение. То, "Как" сделать - вы потом опишите в других документах, в том же ТЗ или постановке.

Ценность

Главная проблема с User Story. Вы всегда знаете первую часть истории,но всегда сложно указать для чего это делается. Но, все должно быть указано как User story согласно шаблону, и потому вы пишите “чтобы …” и какую-то чушь, в которую сами не верите.

Уберите эту часть из истории. Если ничего не потеряли - значит формализация ценности в истории была бесполезна. Что же можно сделать?

Отказаться от формулировки “чтобы”. Это корень зла. Да, для каких-то историй можно указать ценность истории в таком формате, но не для большинства.

Также можно перейти с понятия ценности (value) на влияние (impact). Ваша история не обязательна должна иметь ценность, но обязательно должна оказывать влияние на того актера, что указан в истории. А уже это влияние ведет в конечном итоге к цели, которая имеет для вас ценность.

Кроме этого, есть хороший инструмент оценки пользовательских историй - INVEST (лично мне, импонируют люди, которые придумывают такие зашифрованные вещи в словах. Сразу вспоминается система S.P.E.C.I.A.L и подобные ей):

P.S.: Удивлен, что пост с практическим пояснением лекционного материала зашел хуже, чем сама лекция) Дайте фидбэк - нужны вам вообще практика с примерами?)

P.P.S: Уже по традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.

P.P.P.S: Если я не путаю - Пикабу мне в самом начале предлагал создать пост-опрос для пикабушников. Но сейчас я в упор не вижу этого функционала. Тыкните носом в него, пожалуйста (если мне не померещилось) - есть хорошая идея для опроса)