Продолжение цикла статей о проектировании информационных систем.

Все статьи:

• Введение

• Видение системы

В этой части рассмотрим сущности Use Case и User Story

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

Для этого нам потребуется составить функциональные требования - артефакт, описывающий функции системы и её поведение. Для описания функциональных требований следует использовать два основных инструмента - user story и use case.

User story - короткое описание актора, действия и цели, на достижение которой это действие направлено. Распространённая формула user story: "Я, как <кто?>, хочу <что сделать>, чтобы <зачем?>".

Если обращаться к упомянутому ранее примеру системы управления командировками, то user story может выглядеть так:

• Я, как сотрудник, хочу создать заявку, чтобы оформить командировку

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

• Я, как сотрудник, вернувшийся из командировки, хочу написать отчёт о результатах командировки для отправки его руководителю

Стоит уделить существенное внимание проработке user story, так как они могут дать довольно много информации о будущей системе. Всего три утверждения, указанные в примере, позволяют нам понять, что:

• Система должна позволять любому внутреннему сотруднику компании создавать заявки на командировки

• Сотрудники классифицируются на три вида - командируемые, вернувшиеся и все остальные

• Сотрудникам даётся возможность выбора из нескольких билетов

• Информацию о билетах нужно где-то брать

• Сотрудники, вернувшиеся из командировки, должны получать возможность заполнить отчёт, который в будущем должен быть маршрутизован

• Вероятно, отчёт должен быть рассмотрен и согласован, либо отправлен на доработку

• Вероятно, нужен способ получения информации о организационно-штатной структуре

Каждая user story должна быть конечной; для неё должен быть сформирован критерий её успешного завершения. Для истории "Я, как пользователь, хочу фильтровать билеты по стоимости для того, чтобы выбрать наиболее выгодные" таким критерием, очевидно, будет такое состояние системы, при котором в пользовательский интерфейс выводится список, из которого исключены билеты, не соответствующие ранее заданному пользователем фильтру.

Можно ли выкинуть из формулы "ненужные" слова? Лучше этого не делать, так как в таком случае можно ненароком сместить фокус с первопричины действия (пользовательская потребность) на происходящие события.

User story - достаточно простая концепция, но как быть с теми случаями, когда пользователь отсутствует? Например, когда взаимодействуют две системы.

Тут можно пойти двумя путями. Первый - просто считать систему своего рода пользователем. Данный способ имеет один минус - есть риск уйти в сторону от концепции полезности. "Я, как система управления командировками, хочу получить доступные билеты с ресурса РЖД для того, чтобы показать их пользователю" - а зачем? нужно ли это пользователю? требуется ли это по бизнес-процессу? В примере не учтена итоговая цель, поэтому можно пойти другим путём - "Я, как пользователь, хочу, чтобы система управления командировками получила доступные билеты с ресурса РЖД для того, чтобы я мог с ними ознакомиться".

Use case это, фактически, последовательность действий, которую пользователь совершает для достижения определённой цели.

Кейсы не связаны с историями напрямую; user story может как состоять из цепочки use case, так и быть их составляющей частью.

Пример структуры use case:

1. Определение начальной точки (начальное состояние пользователя и системы)

2. Описание последовательности шагов

3. Возможные отклонения и условия ошибок

4. Итоговое состояние системы после успешного выполнения сценария

Use case не раскрывают детали технической реализации и могут содержать много неопределённостей; стоит отказываться от излишней детализации при проработке функциональных требований и в целом от "протекания" технической информации в бизнес-логику.

В UML есть сперциальный инструмент для описания кейсов - use case diagram.

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

Резюмируем:

• User story формулирует частные случаи получения полезности

• Use case описывает алгоритмы достижения этой полезности