×

Секретные техники проработки требований. Часть 2

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

Объектно ориентированная модель

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

Случай из жизни

В одном проекте я работал с начинающим бизнес-аналитиком. Попросил в документ с требованиями добавить объектно ориентированную модель. Моя просьба поставила аналитика в тупик, у нас получился следующий диалог:


Аналитик: Это все очень сложно и непонятно.
Я: В каком смысле сложно и непонятно?
Аналитик: Я не знаю, с какой стороны подойти к этому вопросу.


Я: Ок, давай рассмотрим твою семью как некую целостную систему, в которой есть объекты — члены твоей семьи. Перечисли их, пожалуйста.
Аналитик: Папа, мама, я, брат и сестра.
Я: Теперь давай определим взаимосвязи. Ты с папой связан как сын, у тебя есть брат и сестра, они также связаны с твоим папой. Верно?
Аналитик: Да, верно.


Я: Ок, тогда мы можем назвать эту связь родительской. Связь твоего отца с детьми — один ко многим. Точно такая же связь у вас с мамой. Верно?
Аналитик: Да, все верно.
Я: Теперь давай рассмотрим связь отца с мамой. Они связаны как муж и жена. Вопрос: может ли у твоего отца жен быть больше, чем одна?
Аналитик: Нет.


Я: Какая в этом случае связь между родителями?
Аналитик: Один к одному.
Я: Верно. Какие еще могут быть связи?
Аналитик: К примеру, у меня нет детей, и в теории их может не быть — связь ноль ко многим.


Я: Верно. Пример, конечно, не очень, но надеюсь, что детки у тебя будут :)
Аналитик: И в то же время у меня может быть только один отец и одна мама.
Я: Эта связь — обязательно один экземпляр.
Аналитик: У меня еще кот есть, и он как бы тоже член семьи. Какая у него будет связь с нашей семьей?


Я: Давай порассуждаем. У тебя может быть больше одного кота?
Аналитик: Да, конечно.
Я: Соответственно, у кота также более одного хозяина — ты, брат, сестра, мама, папа?
Аналитик: Верно.


Я: Тогда связь — многие ко многим.
Аналитик: Ага, понял.
Я: Также у каждого объекта есть параметры. Вот какие параметры ты сможешь перечислить?
Аналитик: Имя, фамилия, отчество, возраст...
Я: Верно, все, что интересно о человеке в рамках определенной ситуации. Также следует учитывать и контекст возможных ситуаций. К примеру, если ваша семья переедет в восточные государства, где разрешено многоженство, твоему отцу можно будет иметь более одной жены, и связь уже будет один ко многим.

Далее мы определили объекты будущей системы и описали их. С помощью UML (Unified Modeling Language), используя диаграмму классов, мы визуализировали связи между объектами.

Для описания атрибутов объекта я использую на практике следующий шаблон.

Название атрибутаТип атрибутаВалидацияКомментарий
1IDЧислоУникальный идентификатор. Генерируется системой. Начальное значение — 1. Каждое следующее значение на 1 больше предыдущего
2ФИОТекстЗаполняется пользователем в момент создания
3Дата рожденияДатаdd.mm.yyyyЗаполняется пользователем в момент создания
4Дата созданияДатаdd.mm.yyyyЗаполняется системой
5ФИО автораТекстЗаполняется системой. Источник данных — справочник «Пользователи системы» (см. раздел «Справочники»). Указывается ФИО пользователя, инициировавшего создание карточки

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

Такая техника разработчикам поможет спроектировать систему, а заказчику — понять, с какими объектами ему предстоит работать. К примеру, ему нужно будет наполнять справочники. Встает вопрос: как их поддерживать в актуальном состоянии, если в справочнике могут быть тысячи или десятки тысяч значений? Возможно, понадобится мастер-система для интеграции.

Диаграмма состояний

Моя дочь учится в 3-м классе, в один из вечеров она подошла ко мне и спросила: «Папа, сегодня в школе нам рассказывали, в каких состояниях может быть вода. Зачем вообще мне нужно знать о состояниях воды? Как мне это поможет?»

Я: Чтобы понять, как использовать воду в зависимости от ее состояния. Вода может быть в трех состояниях: жидком, твердом и газообразном. Как мы можем использовать воду в жидком состоянии?
Дочь: Пить, плавать, варить в ней еду...


Я: Супер. А еще строят гидроэлектростанции, которые вырабатывают электричество, — вот, смотри на картинку в учебнике. Теперь давай разберемся, как мы можем использовать воду в твердом состоянии.
Дочь: Кататься на коньках, охладить колу...


Я: Верно, молодец! Лед очень важен в нашей жизни, его еще используют в медицине и в природе. В горах есть ледники, это природный накопитель пресной воды. Когда они тают, образуется река. А в газообразном какая вода? Можешь привести пример?
Дочь: Тучки, из которых идет дождь. Он поливает цветы, траву и деревья.


Я: А еще в промышленности. Там до сих пор используют паровые двигатели. Теперь ты понимаешь, зачем знать о состояниях воды?
Дочь: Да, спасибо.

Собственно, так же важно понимать, какие формы может принимать объект. Это очень полезно при описании требований к автоматизации бизнес-процессов. Рассмотрим пример автоматизации процесса согласования отпуска. У нашего объекта «Заявка на отпуск» будет такой жизненный цикл:

  • создание;
  • согласование;
  • выполнение;
  • архивирование.

На каждом этапе объект будет иметь свое состояние или статус.

Жизненный цикл и состояние объекта

Этап жизненного циклаСтатус
СозданиеЧерновик
СогласованиеСогласовано
СогласованиеОтклонено
ВыполнениеВ работе
АрхивированиеВыполнено

Далее я определяю, кто что может делать с объектом в разрезе его статусов.

Возможные операции с объектом в разрезе статусов

Этап жизненного циклаСтатусРольОперации
Создание ЧерновикАвторРедактирование
ЧерновикАвторУдаление
ЧерновикАдминистраторУдаление
Согласование СогласованоРуководитель автораСогласование
СогласованоАдминистраторУдаление
ОтклоненоРуководитель автораОтклонение
Выполнение В работеБухгалтерРасчет отпускных
В работеБухгалтерНачисление отпускных
В работеАдминистраторУдаление
Архивирование ВыполненоАдминистраторУдаление

Для визуализации состояний объекта я использую диаграмму состояний UML (Unified Modeling Language). Пример диаграммы состояния — на рисунке.

Каждое состояние объекта должно быть описано. При описании не стоит забывать, что существуют ограничения в каждом состоянии. К примеру, в состоянии «Черновик» объект не должен никто видеть, кроме «Автора» и «Администратора», после согласования никто не может редактировать атрибуты объекта и так далее.

Также каждое состояние объекта может спровоцировать определенное событие в системе. При выполнении операции «Отклонить»:

  • «Руководитель автора» должен указать причину отказа — добавляется диалоговое окно для комментария;
  • система должна инициировать отправку уведомления «Автору» об отклонении заявки на отпуск. Возникают вопросы: от чьего имени должно приходить уведомление «Автору», какова тема уведомления, какой текст уведомления?

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

Техника CRUD

Аксиома в бизнес-анализе: если в системе возможно создать объект, то его можно просмотреть, отредактировать и удалить.

В переводе с английского слово crud имеет несколько весьма забавных значений. В ИТ аббревиатура CRUD означает названия четырех базовых операций с объектом:

  • create — создание;
  • read — чтение;
  • update — обновление;
  • delete — удаление.

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

Давайте рассмотрим прототип создания объекта «Служебная записка».

Как видите, при создании объекта пользователю предлагают заполнить 8 атрибутов. После выполнения операции «Сохранить» система дополняет объект системной или вычисляемой информацией, и в режиме просмотра (чтения) пользователю будет виден объект с 12 атрибутами.

А в режиме редактирования пользователь может изменить только 6 атрибутов.

При редактировании объекта не стоит забывать, что также могут быть ограничения в зависимости от ролевой модели и состояния объекта. К примеру, только «Бизнес-администратор» может изменить поле «Важность», и только в случае, если карточка в состоянии «В работе». Поля «Инициатор» и «Подписант» может редактировать только «Секретарь».

Важно помнить, что для операции «Удалить» необходимо предусмотреть диалоговое окно с подтверждением намерения удаления объекта из системы.

В большинстве случаев заказчики хотят иметь некое хранилище для удаленных объектов — «Корзину». Также могут быть требования ко времени хранения объектов в «Корзине».

Навигация

— Скажите, пожалуйста, куда мне отсюда идти? — спросила Алиса.
— Это во многом зависит от того, куда ты хочешь попасть, — ответил Кот.
— Да мне почти все равно... — начала Алиса.
— Тогда все равно, куда идти, — сказал Кот.

Льюис Кэрролл. Алиса в Стране чудес

В первой части мы рассматривали технику прототипирования, которая очень помогает продумать навигацию.

Для себя я выделяю следующие типы навигации:

  1. Ключевая — самая важная. Сюда я включаю главное меню системы или, если мы работаем над веб-приложением, хедер (Header). В хедер может входить главное меню сайта, языковая навигация, ссылка на стартовую страницу.
  2. Второстепенная — на втором месте после ключевой, однако не стоит забывать, что она также важна для пользователя.
  3. Рекламная — используется на внешних ресурсах.
  4. Тематическая — ссылки на близкие по тематике разделы. К примеру, тип новости (спорт, криминал), теги.
  5. Указательная — показывает пользователю, в какой части системы он находится.
  6. Контекстная — гиперссылки в отображаемых текстах.

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

  • Какая страница системы стартовая?
  • Как попасть на эту экранную форму или в этот режим работы?
  • Куда я могу перейти с этой экранной формы?
  • Как мне понять, где я сейчас нахожусь (какой шаг процесса, какой объект отображает экранная форма)?
  • Как вернуться назад?
  • Kак отменить предыдущее действие?

В итоге

Во второй части, в рамках обмена опытом, мы с вами рассмотрели еще четыре техники: объектно ориентированную модель, диаграмму состояний, CRUD, навигацию. У нас осталось три техники, которые я также довольно часто использую для проверки на практике.

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

До встречи на страницах ДОУ ☺

Часть 3

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному12
LinkedIn

Схожі статті




9 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Статья супер! спасибо за проделанный труд!

Дякую! Корисна стаття, в очікуванні 3 частини

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

Что? Может же быть много детей — от нуля и до 100500. А он, аналитик этот, при этом остаётся один. Значит связь один ко многим, а не ноль ко многим.

Да, неточности есть. Но статья определенно полезная.

Спасибо!

вкусовщина, но термин «сущность» / entity, имхо, подходит лучше термина «объект»

Cпасибо за статью, интересно!

Підписатись на коментарі