Секретные техники проработки требований. Часть 2
Мы уже рассмотрели в первой части следующие техники: stakeholder analysis, user story mapping, ролевая модель и сценарии использования, прототипирование. Во второй части я продолжу делиться с вами техниками, которые помогают мне проверять требования на полноту.
Объектно ориентированная модель
Как показывает мой опыт рецензирования документов с требованиями, аналитики зачастую упускают или недостаточно внимания уделяют именно этой технике. Однако она очень важна для понимания взаимосвязей между объектами и помогает корректно спроектировать будущую систему. Также она проясняет влияние новых требований на имеющийся функционал.
Случай из жизни
В одном проекте я работал с начинающим бизнес-аналитиком. Попросил в документ с требованиями добавить объектно ориентированную модель. Моя просьба поставила аналитика в тупик, у нас получился следующий диалог:
Аналитик: Это все очень сложно и непонятно.
Я: В каком смысле сложно и непонятно?
Аналитик: Я не знаю, с какой стороны подойти к этому вопросу.
Я: Ок, давай рассмотрим твою семью как некую целостную систему, в которой есть объекты — члены твоей семьи. Перечисли их, пожалуйста.
Аналитик: Папа, мама, я, брат и сестра.
Я: Теперь давай определим взаимосвязи. Ты с папой связан как сын, у тебя есть брат и сестра, они также связаны с твоим папой. Верно?
Аналитик: Да, верно.
Я: Ок, тогда мы можем назвать эту связь родительской. Связь твоего отца с детьми — один ко многим. Точно такая же связь у вас с мамой. Верно?
Аналитик: Да, все верно.
Я: Теперь давай рассмотрим связь отца с мамой. Они связаны как муж и жена. Вопрос: может ли у твоего отца жен быть больше, чем одна?
Аналитик: Нет.
Я: Какая в этом случае связь между родителями?
Аналитик: Один к одному.
Я: Верно. Какие еще могут быть связи?
Аналитик: К примеру, у меня нет детей, и в теории их может не быть — связь ноль ко многим.
Я: Верно. Пример, конечно, не очень, но надеюсь, что детки у тебя будут :)
Аналитик: И в то же время у меня может быть только один отец и одна мама.
Я: Эта связь — обязательно один экземпляр.
Аналитик: У меня еще кот есть, и он как бы тоже член семьи. Какая у него будет связь с нашей семьей?
Я: Давай порассуждаем. У тебя может быть больше одного кота?
Аналитик: Да, конечно.
Я: Соответственно, у кота также более одного хозяина — ты, брат, сестра, мама, папа?
Аналитик: Верно.
Я: Тогда связь — многие ко многим.
Аналитик: Ага, понял.
Я: Также у каждого объекта есть параметры. Вот какие параметры ты сможешь перечислить?
Аналитик: Имя, фамилия, отчество, возраст...
Я: Верно, все, что интересно о человеке в рамках определенной ситуации. Также следует учитывать и контекст возможных ситуаций. К примеру, если ваша семья переедет в восточные государства, где разрешено многоженство, твоему отцу можно будет иметь более одной жены, и связь уже будет один ко многим.
Далее мы определили объекты будущей системы и описали их. С помощью UML (Unified Modeling Language), используя диаграмму классов, мы визуализировали связи между объектами.
Для описания атрибутов объекта я использую на практике следующий шаблон.
| № | Название атрибута | Тип атрибута | Валидация | Комментарий |
| 1 | ID | Число | — | Уникальный идентификатор. Генерируется системой. Начальное значение — 1. Каждое следующее значение на 1 больше предыдущего |
| 2 | ФИО | Текст | — | Заполняется пользователем в момент создания |
| 3 | Дата рождения | Дата | dd.mm.yyyy | Заполняется пользователем в момент создания |
| 4 | Дата создания | Дата | dd.mm.yyyy | Заполняется системой |
| 5 | ФИО автора | Текст | — | Заполняется системой. Источник данных — справочник «Пользователи системы» (см. раздел «Справочники»). Указывается ФИО пользователя, инициировавшего создание карточки |
Если в комментариях вы ссылаетесь на какой-либо объект или справочник, обязательно указывайте, где он находится и какие данные содержит.
Такая техника разработчикам поможет спроектировать систему, а заказчику — понять, с какими объектами ему предстоит работать. К примеру, ему нужно будет наполнять справочники. Встает вопрос: как их поддерживать в актуальном состоянии, если в справочнике могут быть тысячи или десятки тысяч значений? Возможно, понадобится мастер-система для интеграции.
Диаграмма состояний
Моя дочь учится в
Я: Чтобы понять, как использовать воду в зависимости от ее состояния. Вода может быть в трех состояниях: жидком, твердом и газообразном. Как мы можем использовать воду в жидком состоянии?
Дочь: Пить, плавать, варить в ней еду...
Я: Супер. А еще строят гидроэлектростанции, которые вырабатывают электричество, — вот, смотри на картинку в учебнике. Теперь давай разберемся, как мы можем использовать воду в твердом состоянии.
Дочь: Кататься на коньках, охладить колу...
Я: Верно, молодец! Лед очень важен в нашей жизни, его еще используют в медицине и в природе. В горах есть ледники, это природный накопитель пресной воды. Когда они тают, образуется река. А в газообразном какая вода? Можешь привести пример?
Дочь: Тучки, из которых идет дождь. Он поливает цветы, траву и деревья.
Я: А еще в промышленности. Там до сих пор используют паровые двигатели. Теперь ты понимаешь, зачем знать о состояниях воды?
Дочь: Да, спасибо.
Собственно, так же важно понимать, какие формы может принимать объект. Это очень полезно при описании требований к автоматизации бизнес-процессов. Рассмотрим пример автоматизации процесса согласования отпуска. У нашего объекта «Заявка на отпуск» будет такой жизненный цикл:
- создание;
- согласование;
- выполнение;
- архивирование.
На каждом этапе объект будет иметь свое состояние или статус.
Жизненный цикл и состояние объекта
| Этап жизненного цикла | Статус |
| Создание | Черновик |
| Согласование | Согласовано |
| Согласование | Отклонено |
| Выполнение | В работе |
| Архивирование | Выполнено |
Далее я определяю, кто что может делать с объектом в разрезе его статусов.
Возможные операции с объектом в разрезе статусов
| Этап жизненного цикла | Статус | Роль | Операции |
| Создание | Черновик | Автор | Редактирование |
| Черновик | Автор | Удаление | |
| Черновик | Администратор | Удаление | |
| Согласование | Согласование | Руководитель автора | Согласование |
| Согласование | Администратор | Удаление | |
| Отклонено | Руководитель автора | Отклонение | |
| Выполнение | В работе | Бухгалтер | Расчет отпускных |
| В работе | Бухгалтер | Начисление отпускных | |
| В работе | Администратор | Удаление | |
| Архивирование | Выполнено | Администратор | Удаление |
Для визуализации состояний объекта я использую диаграмму состояний UML (Unified Modeling Language). Пример диаграммы состояния — на рисунке.
Каждое состояние объекта должно быть описано. При описании не стоит забывать, что существуют ограничения в каждом состоянии. К примеру, в состоянии «Черновик» объект не должен никто видеть, кроме «Автора» и «Администратора», после согласования никто не может редактировать атрибуты объекта и так далее.
Также каждое состояние объекта может спровоцировать определенное событие в системе. При выполнении операции «Отклонить»:
- «Руководитель автора» должен указать причину отказа — добавляется диалоговое окно для комментария;
- система должна инициировать отправку уведомления «Автору» об отклонении заявки на отпуск. Возникают вопросы: от чьего имени должно приходить уведомление «Автору», какова тема уведомления, какой текст уведомления?
Как видите, техника позволяет рассмотреть требования со стороны состояний объектов системы: какие операции можно выполнять в том или ином состоянии, какие должны быть учтены ограничения и какие действия могут быть спровоцированы при смене состояния или выполнении операций с объектом.
Техника CRUD
Аксиома в бизнес-анализе: если в системе возможно создать объект, то его можно просмотреть, отредактировать и удалить.
В переводе с английского слово crud имеет несколько весьма забавных значений. В ИТ аббревиатура CRUD означает названия четырех базовых операций с объектом:
- create — создание;
- read — чтение;
- update — обновление;
- delete — удаление.
При проработке требований следует учитывать, что набор атрибутов одного и того же объекта может отличаться в зависимости от операций с ним.
Давайте рассмотрим прототип создания объекта «Служебная записка».
Как видите, при создании объекта пользователю предлагают заполнить 8 атрибутов. После выполнения операции «Сохранить» система дополняет объект системной или вычисляемой информацией, и в режиме просмотра (чтения) пользователю будет виден объект с 12 атрибутами.
А в режиме редактирования пользователь может изменить только 6 атрибутов.
При редактировании объекта не стоит забывать, что также могут быть ограничения в зависимости от ролевой модели и состояния объекта. К примеру, только «Бизнес-администратор» может изменить поле «Важность», и только в случае, если карточка в состоянии «В работе». Поля «Инициатор» и «Подписант» может редактировать только «Секретарь».
Важно помнить, что для операции «Удалить» необходимо предусмотреть диалоговое окно с подтверждением намерения удаления объекта из системы.
В большинстве случаев заказчики хотят иметь некое хранилище для удаленных объектов — «Корзину». Также могут быть требования ко времени хранения объектов в «Корзине».
Навигация
— Скажите, пожалуйста, куда мне отсюда идти? — спросила Алиса.
— Это во многом зависит от того, куда ты хочешь попасть, — ответил Кот.
— Да мне почти все равно... — начала Алиса.
— Тогда все равно, куда идти, — сказал Кот.
Льюис Кэрролл. Алиса в Стране чудес
В первой части мы рассматривали технику прототипирования, которая очень помогает продумать навигацию.
Для себя я выделяю следующие типы навигации:
- Ключевая — самая важная. Сюда я включаю главное меню системы или, если мы работаем над веб-приложением, хедер (Header). В хедер может входить главное меню сайта, языковая навигация, ссылка на стартовую страницу.
- Второстепенная — на втором месте после ключевой, однако не стоит забывать, что она также важна для пользователя.
- Рекламная — используется на внешних ресурсах.
- Тематическая — ссылки на близкие по тематике разделы. К примеру, тип новости (спорт, криминал), теги.
- Указательная — показывает пользователю, в какой части системы он находится.
- Контекстная — гиперссылки в отображаемых текстах.
При проработке требований к навигации в первую очередь необходимо описать требования к главному навигационному меню. Далее важно прояснить, как пользователь попадет на ту или иную экранную форму, какая страница системы будет стартовой, куда с нее можно перейти. Чтобы максимально проработать требования к навигации, я задаю себе следующие вопросы:
- Какая страница системы стартовая?
- Как попасть на эту экранную форму или в этот режим работы?
- Куда я могу перейти с этой экранной формы?
- Как мне понять, где я сейчас нахожусь (какой шаг процесса, какой объект отображает экранная форма)?
- Как вернуться назад?
- Kак отменить предыдущее действие?
В итоге
Во второй части, в рамках обмена опытом, мы с вами рассмотрели еще четыре техники: объектно ориентированную модель, диаграмму состояний, CRUD, навигацию. У нас осталось три техники, которые я также довольно часто использую для проверки на практике.
Делитесь в комментариях своим опытом. Уверен, что у каждого из вас имеется бесценный багаж знаний, которые будут полезны не только мне, но и всем читателям. Ну а пока я убежал писать третью, заключительную, часть.
До встречи на страницах ДОУ ☺
