• телефонный разговор;
• разговор по видеосвязи;
• живая встреча;
• живая встреча с применением доски (фиксирование предложений и решений).
А. Коберн утверждал, что наиболее эффективная коммуникация – это живая встреча с использованием доски для записей.
Для аналитиков это важно; поскольку их работа строится на общении, им нужно знать, как в том или ином случае эффективнее коммуницировать с человеком.
Нужно стараться выбирать способы самой эффективной коммуникации
Пример
Если вы находитесь в одном офисе, самой эффективной коммуникацией будет живая встреча с использованием доски. Если команда распределена по разным офисам, самой эффективной будет видеоконференция.
Интервьюирование
Пожалуй, наиболее распространенный способ. В среднем на него приходится до 60 % информации, которую удается выявить по проекту. Вопреки расхожему заблуждению, интервьюирование – это более сложный процесс, чем присутствие на встрече с блокнотом и ручкой. Давайте рассмотрим его подробнее.
Этап 1. Подготовка
На этом этапе необходимо выполнить следующие шаги.
1. Понять тип интервьюируемого и ожидаемые виды требований. Вы можете интервьюировать заказчика, администратора или же пользователей системы только со стороны клиента. От типа зависят цели интервьюирования. Помимо целей вы также должны выявить основной вид требований. Если вы опрашиваете заказчика, то видом требований будут бизнес-цели, если администратора системы или процесса – пользовательские или функциональные требования. Это нужно понимать сразу, потому что на типе интервьюируемого и виде требований будет строиться вся ветка вашего интервью.
2. Экспресс-анализ контекста. На этом этапе вы уже должны понимать, о чем вас могут спросить, а также какой процесс, скорее всего, есть. Можно поискать метрики этого процесса, то есть попробовать понять, как он функционирует.
3. Предположение о желаемых целях. После проведения экспресс-анализа вы получаете общее представление о контексте, важности процесса и его особенностях. На данном этапе этого достаточно для того, чтобы предположить, каких целей вас попросят достичь.
4. Предположение о возможных функциях системы.
5. Предположения о встройке в текущую экосистему. Какие модули текущей экосистемы (информационной системы) можно состыковать, чтобы не создавать задвоения информации.
6. Экспресс-анализ подобных решений. Нужно посмотреть, какие популярные решения есть на рынке и каким функционалом они обладают.
7. Составление списка вопросов.
Этап 2. Проведение встречи
1. Подготовить материалы для себя и того, кого вы будете интервьюировать. Нужно распечатать списки вопросов, какую-то дополнительную информацию, которую вы считаете полезной для вас и вашего собеседника. Подготовить ручки, блокноты и все, что еще может пригодиться. Все это нужно сделать заранее, причем именно вам и никому другому. Также обязательно нужно проверить техническое оснащение: если вы подготовили презентацию, желательно либо принести с собой ноутбук, либо организовать встречу в переговорной комнате с большим экраном и т. д. Все это нужно проверить заранее и, если у вас есть доступ к помещению, отрепетировать встречу. Такие мелочи на самом деле очень важны.
2. Прийти вовремя. Лучше, если вы придете вовремя, а заказчик опоздает (очень частая история), чем наоборот. Педантичность в этой профессии – знак профессионализма.
3. Обозначить повестку. У вашего клиента эта встреча с бизнес-аналитиком может быть первой, или он может иметь какой-то свой особый план проведения встречи; чтобы ему было комфортно, вы должны задать тон всего интервьюирования. Для начала уточните, сколько времени ваш собеседник планирует потратить на встречу. Если она предполагается длительной, вы можете сказать, что каждые 40 минут будете делать пятиминутный перерыв, чтобы немного освежить мысли. После того как вы уточнили время, расскажите о плане встречи и регламенте. Например, попросите собеседника о том, чтобы он сразу уточнял непонятные моменты, а не дожидался конца интервьюирования. Если на встрече присутствует несколько человек, вы должны представить их друг другу, объяснить некоторые правила и определить приоритеты: кто ведет беседу и т. д. Если беседа будет записываться на диктофон, видео и т. д., обязательно предупредите об этом клиента.
4. Идти по вопросам, при необходимости углубляясь в ответы. Вы должны придерживаться подготовленного плана. При этом вопросник только задает линию, по которой вы ведете беседу. После ответа вашего собеседника вы можете копнуть глубже и спросить: «почему», «как» – это будут другие вопросы, но они тоже очень важны.
5. Фиксировать письменно или записывать на диктофон/видео. Это очень важно! Надеяться на память в этом вопросе нельзя.
6. Зачитать основные итоги и закрыть пробелы. Не пренебрегайте этим шагом: он позволит избежать множества лишних встреч для уточнений.
7. Назначьте следующий шаг, если это необходимо.
Этап 3. Действия после проведения интервью
1. Оформить чистовик документа по итогам встречи, причем сделать это в тот же день, и отправить его участникам встречи для подтверждений и уточнений. Также поставьте в копию своего руководителя, чтобы он был в курсе основных моментов, и того, что планируется разрабатывать/автоматизировать.
2. Проанализировать информацию, составить список уточняющих или новых вопросов, поскольку с большой долей вероятности, подготовленный вами список окажется неполным, особенно если у вас мало опыта.
3. При необходимости запросить уточнения.
4. Дополнить основные документы (черновики) по требованиям.
Не бойтесь отправлять участникам встречи документ с итогами встречи. Это необходимо для того, чтобы клиенты в дальнейшем не отказались от своих слов. Все должно быть письменно подтверждено. Это перестраховка для вас и для заказчика, гарантирующая, что вы не забудете внести в документы ту информацию, которую он вам дал.
Анализ требований
После завершения этапа сбора требований вы уже располагаете информацией о требованиях к будущей системе, но эта информация не систематизирована и часть ее дублируется. Для небольшого продукта это неважно: можно обойтись без большинства стадий анализа и быстро перейти к проектированию. Однако если продукт крупный, то такой подход приведет к возникновению большого количества ошибок в процессе проектирования и, как следствие, к увеличению бюджета и срока разработки. Чем больше продукт, тем важнее стадия анализа.
Основная цель анализа требований – систематизировать их и избавиться от дублирующихся данных. Это достигается за счет разделения пользовательских историй на отдельные пакеты по функциональному признаку и их иерархической структуризации. По окончании этапа анализа требований многостраничный документ, содержащий сотни пользовательских историй, разбивается на части. Каждая часть освещает только необходимую функциональность, а в ее основе стоит диаграмма вариантов использования, на основе которой можно легко увидеть все требуемые функции системы. Описание вариантов использования не дублируются, а дополняют друг друга.
Выделение пользовательских историй в отдельные пакеты
Первый этап анализа требования – выделение пользовательских историй в отдельные пакеты требований. Главная цель формирования пакетов – упростить доступ к нужным данным за счет расположения всех вариантов использования, относящихся к определенной функциональности, на одной странице (оглавление или диаграмма вариантов использования). В случае использования текстовых документов пакеты также существенно упростят автору процесс последующего редактирования – ему не придется блокировать весь документ на время редактирования, а пользователям документа будет легче узнать об изменениях (как правило, для этого используется секция «История изменений» в начале каждого документа). Пакеты формируются из пользовательских историй, которые описывают схожую деятельность или способ достижения схожего результата. Как правило, они подчинены всего одному бизнес-требованию. Для средних или крупных продуктов часто создают дополнительный пакет и включают в него множество историй, которые не имеют схожих признаков, но должны быть рассмотрены.
Работу над этапом анализа можно считать законченной, когда вы выделили все пользовательские истории в отдельные пакеты. Каждый пакет имеет понятное название, а описание содержит критерии, на основе которых в него попали или не попали пользовательские истории.
Описание требований с помощью вариантов использования
Я хотел сказать, что это новый формат описания требований, но понял, что ему уже двадцать лет. Этим и хороша профессия бизнес-аналитика: многие знания в ней фундаментальны и не устаревают годами и десятилетиями, в отличие от языков программирования и фреймворков.
Вариант использования (Use case) продукта описывает последовательность взаимодействия системы и внешнего действующего лица.
Действующее лицо (Actor) – это человек, другая система ПО или аппаратное устройство, взаимодействующее с системой для достижения некой цели. Еще одно название действующего лица – роль пользователя. Это роль, которую члены одного или нескольких классов пользователей могут играть по отношению к системе.
Примеры
Я как слушатель музыки хочу отметить музыкальный трек, присвоив ему статус любимого, чтобы иметь возможность быстро найти его для прослушивания и продемонстрировать свои музыкальные вкусы другим пользователям.
Я как родитель ребенка хочу просмотреть журнал его оценок за прошлую неделю, чтобы узнать о его успеваемости и понять, нужно ли мне вмешаться в учебный процесс.
Я как владелец компании хочу поместить ее логотип на каждой странице сайта компании, чтобы посетители видели и запоминали его.
Диаграммы вариантов использования (Use Case Diagrams) позволяют получить визуальное представление о требованиях пользователей.
Фрагмент диаграммы варианта использования Chemical Tracking System
На рисунке показан фрагмент диаграммы варианта использования в нотации UML. Прямоугольник показывает границы системы. Линии соединяют каждое действующее лицо (нарисованный человечек) с вариантами использования (эллипсами), с которыми это лицо взаимодействует. Прямоугольник отделяет некоторые внутренние элементы высокого уровня системы (варианты использования) от внешних действующих лиц.
Понятие «вариант использования» пришло из мира объектно-ориентированного программирования. Оно подходит и для проектов, где применяются любые приемы разработки, поскольку пользователям безразлично, как именно создается ПО.
Варианты использования меняют традиционный подход к сбору информации. Пользователей не спрашивают, что должна делать система с их точки зрения, а выясняют, какие задачи с ее помощью собирается решать пользователь.
Цель такого подхода – описать все подобные задачи. До включения каждого варианта использования в утвержденную версию требований заинтересованные в проекте лица проверяют, не выходит ли он за границы проекта. Теоретически в конечный набор вариантов использования должна входить вся желаемая функциональность системы. На практике же вряд ли удастся добиться стопроцентного результата. Однако варианты использования помогут решить эту задачу полнее, чем любой другой прием сбора информации.
Сценарий использования – отдельное независимое действие, которое действующее лицо может выполнить для получения определенного значимого результата.
Один вариант использования может охватывать несколько схожих задач с одинаковыми целями. Следовательно, это набор связанных между собой сценариев использования, где сценарий – это отдельный пример варианта использования.
Можно начать сбор требований с абстрактных вариантов использования, а затем на их основе создать конкретные сценарии. Или наоборот, перейти от сценария к более широкому варианту использования.
Важные элементы описания варианта использования следующие.
1. Уникальный идентификатор.
2. Имя, кратко описывающее задачи пользователи в формате «глагол + объект», например «разместить заказ».
3. Краткое текстовое описание на естественном языке.
4. Список предварительных условий, которые должны быть выполнены до начала разработки варианта использования.
5. Выходные условия, описывающие состояние системы после успешного завершения разработки варианта использования.
6. Пронумерованный список действий, иллюстрирующий последовательность этапов взаимодействия лица и системы от предварительных условий до выходных данных.
Нормальное направление варианта использования
Нормальное направление развития (Normal course) – это основное направление варианта использования, основной или главный успешный сценарий, благоприятный путь.
Нормальное направление для варианта использования «Запрос химиката» – запрос химиката, который есть на складе. UML-диаграмма иллюстрирует диалоговый поток при нормальном и альтернативном развитии вариантов использования.
Альтернативные направления варианта использования
Альтернативное направление (Alternative course) – это другой допустимый сценарий из варианта использования. Еще он может называться вторичным сценарием (secondary scenario).
Вторичные сценарии также удовлетворяют выходным условиям варианта использования и могут привести к успешному выполнению задания. Это вариации решения задачи или диалоговой последовательности, необходимой для решения задачи. В определенной точке принятия решений в диалоговой последовательности нормальное направление может перейти в альтернативное, а затем вернуться в нормальное. Хотя большинство вариантов использования можно описать простым языком, блок-схема или UML-диаграмма позволяет визуально представить логическое развитие сложного варианта использования, как показано на рисунке.
Блок-схемы и диаграммы взаимодействия показывают точку принятия решений и условия, при которых основное направление развития событий переходит в альтернативное.
Например, альтернативное направление для варианта использования «Заказать химикат» – это «Заказать химикат у поставщика». В обеих ситуациях конечная цель действующего лица одна и та же – запрос химиката, поэтому оба сценария входят в один вариант использования. Некоторые этапы альтернативного направления аналогичны этапам нормального направления, но для завершения альтернативного направления необходимо выполнить особые действия.
В данном случае пользователь может искать необходимый химикат по каталогам поставщиков. Если альтернативное направление – само по себе автономный вариант использования, то можно расширить нормальное направление, включив этот отдельный вариант в нормальный поток. На диаграмме вариант использования «Запросить химикат» был расширен вариантом использования «Выполнить поиск по каталогам поставщика». Кроме того, сотрудники склада химикатов используют «Поиск по каталогам поставщиков» как отдельный вариант.
Иногда несколько вариантов использования имеют общие наборы этапов. Чтобы избежать их повторения в каждом варианте использования, следует выделить отдельный вариант с общей функциональностью и указать, что он включен в другие варианты использования как подвариант. Эта процедура аналогична вызову общей подпрограммы в компьютерной программе.
Исключения вариантов использования
Исключение (Exception) – это условие, препятствующее успешному завершению варианта использования.
Для варианта использования «Запросить химикат» существует одно исключение – «Химиката нет в продаже».
Если в процессе сбора информации не указано, каким образом должны быть обработаны исключения, то возможны два пути.
1. Разработчики предложат лучший, по их мнению, способ обработки исключений.
2. При генерации пользователем неверного условия произойдет сбой системы, так как никто не предусмотрел такой ситуации.
Но сбои системы не входят в список требований пользователей.
Иногда исключения рассматриваются как тип альтернативного направления, однако эти понятия следует разделять. Необязательно реализовывать каждое альтернативное направление для варианта использования. Можно отложить его реализацию до следующего выпуска.
Однако крайне важно реализовать исключения, из-за которых завершение сценариев может оказаться неуспешным. Любой, кто когда-либо занимался программированием, знает, что часто именно на исключения приходится большая часть работы. Многие недостатки конечного продукта присущи именно обработчикам исключений или появляются из-за их отсутствия. Указать условия исключений в ходе сбора информации по требованиям – верный способ создать устойчивые к сбоям продукты.
Последовательность вариантов использования
После каждого варианта использования система должна находиться в таком состоянии, чтобы пользователь мог сразу же приступить к следующему варианту использования. То есть выходные условия одного варианта использования должны удовлетворять предварительным условиям следующего за ним варианта.
Например, в приложении обработки транзакций каждый вариант использования должен оставлять систему в состоянии готовности к следующей транзакции. Предварительные условия и выходные условия каждой транзакции варианта использования должны вставать в один ряд.
Для коммерческого веб-сайта предлагаются варианты использования «Поиск по каталогу», «Добавить товар в корзину» и «Оплатить товары в корзине». Если можно выполнить все эти действия по отдельности, то все они считаются независимыми вариантами использования. Кроме того, можно выполнить все три указанные операции подряд, назвав этот один большой вариант использования «Приобрести товар», как показано на рисунке:
Предварительные условия и выходные условия определяют границы отдельных вариантов использования, которые можно связать в цепочку для выполнения объемной задачи.
Выявление вариантов использования
Можно выявить варианты использования несколькими способами:
• сначала определить действующих лиц, а затем бизнес-процессы, в которых участвует каждое лицо;
• выразить бизнес-процессы в терминах определенных сценариев, обобщить сценарии в варианты использования и определить действующих лиц для каждого варианта;
• определить внешние события, на которые система должна реагировать, а затем соотнести эти события с действующими лицами и определенными вариантами использования;
• определить вероятные варианты использования на основе функциональных требований;
• если какие-либо требования невозможно проследить до какого-либо варианта использования, необходимо определить, нужны ли они.
Название варианта использования должно указывать на решаемую задачу, поэтому при формулировке названий необходимо использовать глагол. Что клиент хочет: просмотреть, напечатать, заказать, отправить по электронной почте, исправить, удалить или создать данные по безопасному хранению материала?
Иногда предложенный вариант использования – это всего лишь одно действие, которое выполняется как часть варианта использования, например «сканировать штрихкод». Аналитик должен выяснить, какую цель ставил перед собой пользователь, когда предлагал вариант использования. Например, спросить: «Для чего вы сканируете штрихкод на контейнере с химикатами?» Предположим, в ответ он услышит: «Это необходимо, чтобы я мог отправить этот химикат в свою лабораторию». Следовательно, настоящий вариант использования – «Отправить химикат в лабораторию». Сканирование штрихкода – это только один из этапов взаимодействия действующего лица с системой, передающей химикат в лабораторию.
Преимущества применения вариантов использования
Способ с применением вариантов использования облегчает определение приоритетов требований. Высшим приоритетом обладают те функциональные требования, которые созданы на основе вариантов использования с высшим приоритетом.
Высший приоритет назначается по следующим причинам:
• варианты использования описывают один из основных бизнес-процессов, активируемых системой;
• многие пользователи часто обращаются к ним;
• их запросил привилегированный класс пользователей;
• они предоставляют возможности, необходимые для соответствия требованиям;
• функции других систем зависят от их наличия.
С помощью варианта использования можно выявить важные объекты предметной области и взаимоотношения между ними. Разработчики, использующие объектно-ориентированные методы дизайна, могут преобразовать варианты использования в объектные модели, такие как диаграммы классов и диаграммы последовательностей.
Но не стоит тратить много времени на обсуждение деталей вариантов использования, которые не будут реализованы в ближайшие месяцы или годы. Вероятнее всего, они изменятся еще до начала сборки информационной системы (ИС). По мере изменения бизнес-процессов с течением времени, уточняются задачи, реализуемые посредством определенных вариантов использования. Если проследить функциональные требования, дизайн, код и тесты вплоть до их истоков – пожеланий клиента, будет легче внести эти изменения бизнес-процессов во всю систему.
Риски и ошибки при применении вариантов использования
Слишком много вариантов использования. В данном случае вряд ли удастся записать каждый из них на соответствующем уровне абстракции. Не стоит создавать отдельный вариант использования для каждого возможного сценария. Лучше включить в один вариант использования нормальное направление развития, альтернативные направления и исключения в виде сценариев. Как правило, количество вариантов использования превышает количество бизнес-требований и функций, однако функциональных требований обычно бывает намного больше, чем вариантов использования.
Очень сложные варианты использования. Создавать длинные описания – не лучшее решение. Нужно выбрать один успешный способ выполнения варианта использования с одной комбинацией правильных и ложных значений для различных логических решений и назвать его нормальным направлением. Другие успешные логические ответвления необходимо определить как альтернативные направления и назначить исключения для обработки неудачных ответвлений. Альтернативных направлений может быть много, однако каждое из них должно быть кратким и понятным.
Включение пользовательского интерфейса в варианты использования. Варианты использования должны описывать действия, которые пользователям необходимо выполнить с помощью системы, а не то, как это будет выглядеть на экране. Правильная формулировка на этой стадии – «система предоставляет выбор», а не «система отображает раскрывающийся список». Наброски экрана и карты диалогов (диаграммы архитектуры интерфейса) стоит применять для визуального представления взаимодействия исполнителя и системы, а не для утверждения дизайна.
Включение определений данных в варианты использования. Определения элементов данных и структур трудно отыскать, когда они включены в описание вариантов использования. Возможны повторы определений и рассинхронизация, когда один экземпляр изменяется, а остальные – нет. Лучше собрать их в словарь данных, созданный для всего проекта.
Варианты использования, которые непонятны пользователям. Если пользователи не видят связи описания вариантов использования со своими бизнес-процессами или задачами, то варианты использования следует откорректировать. Их нужно составлять с точки зрения клиентов, а не системы. Следует попросить клиентов проверить варианты использования. Излишне сложные варианты использования, скорее всего, говорят о том, что они не нужны.
Новые бизнес-процессы. Пользователям трудно придумывать новые варианты использования, если ПО создается для поддержки процесса, которого еще нет. В этом случае сбор информации по требованиям – это изобретение нового бизнес-процесса. Рискованно ожидать, что с помощью новой информационной системы будет создан эффективный бизнес-процесс. Необходимо выполнить модернизацию бизнес-процесса перед описанием новой информационной системы.