Скачать чеклист

Можно тут

АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1. Модель процесса

2. Модель данных

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

4. CRUD LSHAX

ВЗГЛЯД СО СТОРОНЫ ПОЛЬЗОВАТЕЛЯ

5. Контекстный анализ

6. Варианты использования

7. Интерфейс

ЖИЗНЕННЫЙ ЦИКЛ, РЕЖИМЫ РАБОТЫ, МОНИТОРИНГ

8. Жизненный цикл и режимы работы

9. Отчёты и мониторинг

10. Администрирование

Вместо введения

Как нет этой функции? А мы думали, она будет! Разве о ней нужно было отдельно говорить?

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

В этой статье я опишу примеры подобных ситуаций и расскажу о техниках, позволяющих задать нужные вопросы, выявить максимальное количество требований на ранних этапах анализа, обсудить со стейкхолдерами нужность этих требований и их приоритеты. Как правило, после применения всех техник в 1,5−2 раза возрастает объём требований и юзкейсов для обсуждения — и это одна из основных задач аналитика: задать все вопросы и выяснить все детали до начала проектирования и разработки системы.

Возможно, многие подходы вы уже применяете, а о некоторых даже не слышали; я попробую свести их в единую систему.

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

Требования не меняются

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

Обратите внимание, что я не использую термин «меняются», который означает изменение уже существующих требований. Такие изменения возможны, но чаще дело всё-таки в другом. По моему опыту, основная проблема в работе с требованиями и их «внезапном изменении», а также появлении «новых хотелок» у заказчика, заключается в том, что требования не выявлены в полном объёме на самом раннем этапе. То есть мы, аналитики, не задали вопросы, которые позволяли бы как можно раньше понять, насколько велика будущая система, и что она будет автоматизировать.

В этой статье я расскажу, какие вопросы стоит задавать, чтобы убедиться, что мы ничего не забыли, а в процессе приёмки системы заказчик не ожидал функциональности раза в 3−4 больше, чем мы ему поставили.

Повторю ключевой тезис:

Требования не меняются

Но почему же тогда мы так часто сталкиваемся с изменениями? Давайте рассмотрим основные причины «изменений» требований и подумаем, как эти «изменения» можно было бы предупредить.

Автоматизируемый процесс не определён или всё время меняется

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

Чтобы не допустить подобной ситуации, нужно досконально изучить бизнес-проблему клиента, которую он пытается решить. Как? Сделать шаг назад и сперва разобраться с деятельностью, то есть спроектировать и отладить процесс. Это классическая задача для бизнес-аналитика, но требования к программному обеспечению на этом этапе выдвигать и фиксировать ещё рано.

Выявлены не все ключевые стейкхолдеры и их цели

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

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

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

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

Не определены границы системы

Любая система имеет свои границы, поэтому далеко не все объекты и субъекты предметной области войдут в контур автоматизации.

Например, кадровому агентству нужна система для парсинга сайтов с вакансиями и мэтчинга с резюме кандидатов в автоматическом режиме. При этом учёт взаимодействия с кандидатом и статуса найма ведётся в CRM, которая у агентства уже есть. То есть, мы можем изолировать требуемую функциональность в отдельной системе, предусмотрев способы интеграции.

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

По мере работы над проектом стейкхолдеры хотят реализовать в системе всё больше и больше функциональности, часть которой, как выясняется, и не должна входить в границы нашей системы. Но как мы узнаём об этом, если никаких границ системы не зафиксировано?

Поэтому крайне важно определить, где заканчивается проектируемая система, и та часть предметной области, которую она автоматизирует. Ключевые вопросы для выявления границ: эта подсистема изменяется, создаётся или закупается в ходе нашего проекта? Этот процесс происходит в нашей системе, или вне её? Нужно ли нам хранить данные об этом объекте и могут ли они измениться в нашей системе?

Изменились внешние требования

Не стоит путать внешние требования с бизнес-правилами и процессами организации.

Значимые изменения внешней среды компании происходят обычно реже, чем внутренних процессов, но область их действия шире. Внешние требования влияют не столько на отдельную организацию, сколько на деятельность всех организаций этой отрасли в целом. Это могут быть решения регуляторов, постановления Правительства, внешние события на рынке и у поставщиков, изменения интерфейсов внешних систем. Всё это в значительной степени может повлиять на модели данных, формулы расчёта, решения системы или жизненные циклы объектов. Изменение внешних требований — не ежедневная ситуация в работе аналитика, однако стоит предусмотреть способы их отслеживания или даже варианты изменения соответствующих частей системы путём настройки, а не переписывания кода.

Требования дополняются

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

Уточнение процесса

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

Обработка исключительных ситуаций и частных случаев

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

Улучшение удобства использования и дизайна

Потребность в доработке UX и UI — достаточно частая история, с которой сталкивается любой аналитик. Как правило, в процессе внедрения системы у пользователей появляются новые требования к дизайну и удобству использования.

Расширение границ системы

Граница системы определяется субъективно и основывается на целях и функциональности, необходимой стейкхолдерам. При расширении списка целей появляются дополнительные требования к функциональности системы — продукт автоматизирует новые деятельности организации, расширяя границы своего применения (если, конечно, продукт в принципе востребован и удобен).

---

Способы работы с требованиями: выявляем и проверяем на полноту:

Предварительный этап

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

Я составил чек-лист предварительного этапа и использую его до старта работ. Выявление всех заинтересованных сторон — это первый шаг на пути системного анализа. Следующий этап — сформировать понимание целей стейкхолдеров, степень их заинтересованности и влияния на проект. Жизненно важно на старте проекта установить, какие критерии работы системы стейкхолдеры примут в качестве успешных, достижение каких показателей будет достаточным для запуска системы в эксплуатацию. Предварительный этап обезопасит аналитика от неопределённостей при сдаче проекта.

• Выявлены и представлены все стейкхолдеры

• Их цели ясны, их влияние на проект — вес целей — определено и согласовано

• Согласованы и определены цели создания системы и критерии успешности

• Собраны первичные требования

По завершении предварительного этапа нужно удостовериться, что все основные вопросы заданы, а все основные решения приняты. Кроме того, аналитик, менеджер проекта и любой член команды, работающий с требованиям, должны научиться понимать язык, на котором говорят заказчики.

Обычно я оформляю самостоятельно или обсуждаю с коллегами итоговый чек-лист о принятых решениях по процессу и границам системы, полному списку объектов, субъектов и процессов автоматизации, экранным и отчётным формам. Затем мы убеждаемся в полноте требований к режимам работы, инструментам мониторинга, администрирования и обслуживания продукта. Именно здесь, в точках расширения, чаще всего возникают новые требования. Для детального выявления каждого аспекта системы применяются свои техники, о которых я подробнее расскажу ниже. Но самое главное — посмотреть на систему с разных точек зрения.

Анализ предметной области

Работа с требованиями начинается с анализа предметной области. Предметная область — это реальный мир. Она существует, даже если нашей системы нет. И мы можем более или менее формально описать её, не привязываясь к конкретной реализации.

Предметную область условно делят на три компонента:

• Специфичные термины и язык людей, которые работают в предметной области

• Объекты и понятия предметной области — сущности

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

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

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

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

1. Модель процесса

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

Мы же преследуем практическую цель — минимальными усилиями извлечь максимум информации о будущей системе. Для этого подойдёт облегчённый вариант моделирования — User story map.

User story map

Обычно User story map (USM) вспоминают применительно к agile-подходам как технику, которая позволяет выявить элементы бэклога и распланировать их по релизам в рамках. Я же хочу отметить, что USM полезно использовать при любой методологии, рассматривая хребет («бэкбон») карты, как набор активностей в системе, который отражает порядок действий наших пользователей — то есть, по сути, основной процесс.

Ряды данных USM

• Первый ряд, или «позвоночник» (backbone) — шаги или этапы процесса. Расставляем по последовательности действий: то, что делается раньше — левее, более поздние шаги процесса — правее.

• Второй ряд — пользователи или акторы.

• Третий ряд — требования или сценарии. В agile это будут user stories. Карточки расставляются по приоритету: чем выше приоритет, тем выше карточка:

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

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

Рассмотрим User story map из реальной практики, из проекта по разработке краудсорсинговой платформы.

Краудсорсинг (от англ. crowd — «толпа» и sourcing — «использование ресурсов») — это передача каких-то функций кругу лиц без заключения договора, чтобы задействовать их их знания, опыт и творческие способности. То есть, речь идёт о перекладывании различных задач на плечи энтузиастов. Википедия — отличный пример системы краудсорсинга.

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

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

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

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

• Модель процесса

  • User Story Map

2. Модель данных

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

Один из способов структурировать информацию мы сейчас и рассмотрим. Я рекомендую проводить анализ именованных сущностей на корпусе текстов, полученных от стейкхолдеров: расшифровках интервью, регламентах процессов, шаблонах договоров с клиентами, инструкциях и других текстовых артефактах.

Основной смысл этой техники: выделение в текстах имён существительных и распределение их по группам. В текстах мы можем встретить следующие группы существительных:

• Названия объектов и их атрибутов

• Названия процессов

• Названия ролей действующих лиц и пользователей системы

• Названия смежных систем и подсистем

• Названия отчётов, указания на сообщения

• Указания на пользовательский интерфейс

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

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

Раскладываем слова на группы. Какие роли мы можем найти в тексте? Тьютор и модератор. Какие элементы интерфейса упоминаются? Страница учебной активности, основное меню, блок данных об активности, кнопки управления (оценить, редактировать, изменить статус) и выбор режима в зависимости от роли: модератор или тьютор.

Сразу можно обратить внимание, что упоминается некое «основное» меню. Что такое это «основное меню»? Важно задать все возникшие вопросы стейкхолдерам. Что вы понимаете под основным меню? Каким ролям, в каком виде и с каким набором инструментов оно будет доступно?

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

Концептуальная модель данных

После того, как мы составили перечень объектов, процессов, ролей и элементов интерфейса, можно приступить к подготовке примера модели данных. Это может быть ER-диаграмма — диаграмма «сущность-связь». Следует отметить, что ER-диаграмма нужна как на этапе бизнес-моделирования, так и на этапе проектирования системы. На этапе анализа мы говорим о концептуальной модели предметной области.

На этом этапе при установлении кратности связей часто появляются дополнительные требования. Мы можем обнаружить не только связи «один к одному» или «один ко многим».

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

Праздник может проходить «в одном и только одном помещении» или «одном или нескольких помещениях одновременно»?

В практике мы можем столкнуться со связями «один к трём», «один к двум или трём», «один к двум или к пяти, но не к четырём». Все это частные случаи связи «один ко многим», но в документах такие ограничения встретишь редко. О них нужно спрашивать у стейкхолдеров на понятном им языке и фиксировать в виде бизнес-требований.

На основании проведенного анализа заполняем чек-лист контроля полноты.

Модель данных

• Анализ именованных сущностей   

  • Названия объектов и их атрибутов   

  • Названия ролей пользователей 

  • Названия смежных систем / подсистем   

  • Названия отчётов, указания на сообщения   

  • Указания на пользовательский интерфейс   

  • Модель предметной области

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

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

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

Если в общении с заказчиком мы слышим слово «состояние» или «статус», нужно задать уточняющие вопросы и выяснить все возможные состояния и допустимые переходы между ними, а затем обязательно проверить — для всех ли переходов описаны сценарии или пользовательские истории.

Например, для диаграммы состояния, приведенной на рисунке выше, стоило бы задать уточняющие вопросы заказчику.

1. Какие состояния или статусы объекта бывают?

Товар может быть не зарегистрирован, на регистрации, зарегистрирован. У товара может быть просрочена регистрация, и товар может быть снят продажи.

Нужно убедиться, что состояния взаимоисключающие, то есть объекты могут находиться в один момент времени только в одном из этих состояний. Также стоит уточнить — насколько долго объекты могут находиться в каждом состоянии? Нужны ли автоматические проверки объектов, «зависших» в каком-либо состоянии?

2. Как объект переходит из одного состояния в другое?

После просрочки регистрации товар может быть снят с продажи или снова направлен на регистрацию

Стоит проверить, что на каждый переход написан сценарий, рассмотрены все бизнес-правила и ограничения. Из-за пропущенных сценариев и вариантов использования часто возникают дополнительные требования на более поздних этапах разработки. В приведённом примере можно уточнить, может ли товар быть снят с продажи, если он не зарегистрирован. Если да, то на диаграмме нужно отразить дополнительный переход.

3. Что меняется в системе при смене состояния объекта?

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

Важно убедиться, что мы описали, какое поведение ожидаем от системы при смене состояния объекта. Для анализа интересов различных стейкхолдеров можно построить матрицу RACI для каждой смены статуса: выполняющий действие, приводящее к смене статуса (responsible), ответственный или контролирующий (accountable), консультирующий (consulted), информируемый (informed). Заполнение такой матрицы позволит выявить пропущенные требования различных стейкхолдеров.

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

Заполняем чек-лист:

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

• На каждый переход описан сценарий, бизнес-правила и ограничения

• Состояния взаимоисключающие, по одному основанию

• Определено, что меняется в системе при смене состояния

• Определены стейкхолдеры и роля, для которых меняется состояние

4. CRUD LSHAX

CRUD

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

• Create — создать

• Read — прочесть

• Update — изменить

• Delete — удалить

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

• Кто имеет право на совершение это действия?

• При каких условиях (в каких состояниях системы или объекта допустимо производить это действие)? Какие проверки должны быть выполнены?

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

• Кто должен быть извещён о действии?

• Требуется ли дополнительное подтверждение (например, пользователем с другой ролью)?

• Можно ли отменить действие и в течение какого времени?

• Требуется ли журналирование действия и какую информацию сохранять в журнале?

Результат можно представить в виде таблицы. Давайте рассмотрим в качестве примера объект Клиент.

Хотя CRUD считается исчерпывающим списком действий для API, при сборе требований к системе я рекомендую не ограничиваться этим набором. Лично я использую для проверки полноты дополнительный набор действий, которые могут потребоваться в системе, при этом заказчик может ожидать их наличия «по умолчанию») — LSHAX.

LSHAX

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

Соберите полученные ответы в матрицу, где на пересечении объекта и правила укажите сценарии использования — юзкейсы, в которых описаны эти действия. Проанализируйте выявленные пробелы — актуальны ли эти действия для вашей системы? Этих действий не должно быть в системе или эти требования пропущены при анализе?

На примере рисунка, представленного выше, выясняем у заказчика:

• Результаты студента должны выводиться списком?

• Нужно ли студенту получать список записей на курс?

• Мы как аналитики можем об этом не знать. Но самое интересное, что и стейкхолдеры могли об этом не задумываться до начала обсуждения. И здесь каждый следующий ответ «да» увеличивает объём системы.

Поэтому так важно тщательно изучить все аспекты работы с объектами по правилам CRUD (LSHAX).

CRUD (LSHAX)

• CRUD. Получены ответы на вопросы   

  • Кто имеет право?   

  • При каких условиях?   

  • Что должно измениться в других частях системы?   

  • Кто должен быть извещен о действии?   

  • Требуется ли подтверждение?   

  • Можно ли отменить и когда?   

  • Требуется ли журналирование?

• List. Вывод списком / карочками.   

  • Поля?   

  • Сортировка?   

  • Пагинация?   

  • Фильтрация?   

  • Сохранение фильтров?

• Search. Поиск   

  • По каким полям?   

  • Насколько точные совпадения?  

  • В каком виде вывод результатов?   

  • Совмещен ли с фильтрами?   

  • Что показываем, когда ничего не нашлось?

• History. История изменений   

  • Храним ли и что?   

  • Как показываем?   

  • Можно ли сравнивать версии?   

  • Можно ли искать в истории?

• Archive. Архив   

  • Как храним?   

  • Когда удаляем?   

  • Кому показываем?   

  • Можно ли восстановить?

• eXecute. Исполнение / запуск / публикация   

  • Кому разрешено?   

  • Можно ли прервать / приостановить / перемотать / воспроизвести пошагово?   

  • Исполнить разные версии?

---

Взгляд со стороны пользователя

5. Контекстный анализ

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

И снова каждый пустой квадрат выявляет новую группу требований. Это значит, что пора задать уточняющие вопросы будущему потребителю продукта.

• Пользователь осуществляет поиск в каталоге курсов, чтобы получить что? Ищет нужный ему курс.

• Для чего он ищет курс? Не просто чтобы найти, а изучить описание и, возможно, записаться самому. Или найти детские образовательные кружки и записать ребенка. Или найти подходящий курс, о котором спрашивал друг, и поделиться курсом с другом.

• Когда? и Где? Это важные вопросы с точки зрения пользователя. Порой жесткие требования по времени внесения сведений продиктованы внутренними регламентами заказчика. В то же время, социальные приложения, рассчитанные на широкий круг потребителей, должны думать об удобстве пользователя. Например, продукт по ведению расходов может иметь пользовательское расписание для напоминания о внесении расходов. Или напоминание может срабатывать по локации, когда пользователь вернулся домой.

• Вопросы «С кем?» и «Кто рядом?» бывают важны для систем, где получатель ценности не является пользователем системы. Например, операционист банка или сотрудник МФЦ работает в специализированном ПО, а перед ним сидит клиент, который не общается с системой. При этом именно у клиента есть множество требований к работе системы, интерфейс которой он даже не видит.

• Группа вопросов Сколько? Как? и Какой? необходима для любой системы. Как минимум, для вопроса «Сколько?» стоит рассмотреть три случая — ноль, один и много, а лучше — выяснить характерное число рассматриваемых объектов. В вопросе «Как?» мы выясняем — а как сейчас это делают пользователи? А в вопросе «Какой?» уточняем важные для пользователя характеристики объекта.

• На забываем про обратные действия. В примере — как отписаться от курса?

• Головная боль пользователя — часто повторяющиеся действия. Если пользователь изо дня в день настраивает группу фильтров, дайте возможность сохранять избранные настройки фильтрации. Предлагайте действия «создать на основе».

• Контекстный анализ  

  • Кто?  

  • Для чего? (Что дальше?)   

  • Когда? (В какой ситуации? Как часто?)   

  • Где? (Что вокруг? Какое устройство?)   

  • С кем? (Кто рядом? Для кого это делается?)   

  • Сколько? (Чего-нибудь…)  

  • Как? (Как конкретно. И что в процессе важно?)  

  • Какой? (Мы что-то делаем с объектами; с какими?)   

  • Обратное действие  

  • Повторяющееся действие (Запомнить результат/настройки?) 

6. Варианты использования

Этот метод я использую в практике уже больше пятнадцати лет. Я считаю, что любое описание (от ТЗ до User story) можно представить в виде кристалла требований, и проверить на полноту — через проверку связей между разными его вершинами.

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

• Не может быть вариантов использования без экранной формы. Это явная ошибка проектирования

• Не может существовать отчёта без варианта использования, описывающего шаги для его формирования или задание параметров работы для регулярного формирования.

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

Каждый юзкейс или сценарий использования содержит описание последовательности действий, которые может осуществлять система в ответ на внешние воздействия пользователей или других программных систем.

В процессе подготовки вариантов использования нужно проверить связи сценариев с ролями пользователей и с требованиями. Для этого можно построить очередную матрицу связей:

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

На примере рисунка 7 мы можем увидеть сценарии, не связанные с требованиями. В таком случае стоит проверить, имеет ли отношение к работе системы этот сценарий? Очевидно, что вариант «Студент» — «Выполнять задание в срок» требует ответа на вопрос, а как мы можем инструментами системы обеспечить успешного достижения этой цели? Ответ «никак» указывает, что сценарий выходит за границы системы, и не будет реализован.

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

Требования исключаются

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

Заполняем чек-лист:

• Варианты использования. Проверены связи   

  • Все ли операции над всеми объектами учтены?   

  • Все ли требования учтены?   

  • Связи с экранами, отчетами, внешними системами   

  • Все проверки, исключения и альтернативы описаны 

  • Сообщения пользователю описаны?

7. Интерфейс

Экраны

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

• Главное правило при проектировании экранной формы звучит так: «один экран — одно главное действие». При ответе на вопрос «Что мы хотим, чтобы пользователь здесь сделал?» мы выделяем несколько действий на форме, но главное действие должно быть одно.

• На следующем шаге нужно разобраться, какая информация наиболее важна на экране для осуществления этого действия. Нельзя удовлетворяться ответом «важно всё». Приоритезируем информацию и представляем её в виде блоков данных: заголовок, данные первого уровня, второго уровня и т. д.

• Умолчания — это то, что часто обходят вниманием аналитики, и разработчики реализуют вывод данных на своё усмотрение. Давайте заботиться о пользователе. Выясняем, что ему ценно увидеть сразу при открытии формы. Заполнив таблицу приоритетными данными, например, текущего года и выведя проекты с наибольшей прибылью в начало списка мы не усложним работу программиста дополнительной операцией order by, а получим счастливого пользователя.

• В 9 случаях из 10 требования об Обязательности и Зависимости одних полей от других выявляются при сдаче работ или на приемо-сдаточных испытаниях. Также как и необходимость вывода предупреждений и нотификаций об ошибках .

• При проектировании экранных форм стоит помнить, что пользователь хочет видеть дату и время, на которые актуальны данные, которые он просматривает. Хорошо продуманный интерфейс предупредит пользователя, что на основе отображаемых данных нельзя принимать решение, поскольку они устарели.

• Ещё одна интересная тема — граничные состояния. Что отражать на форме, если данных нет? Нули, пустую графу / график, сообщение «нет данных» или предложение с просьбой задать более широкий диапазон запроса? А если данных слишком много? И что сообщать пользователю, если пропала связь с сервером?

• Экраны. Для каждой экранной формы определено  

  • Главное действие пользователя   

  • Что наиболее важно на экране, что менее важно   

  • Умолчание: набор полей, сортировки, фильтры, значения по умолчанию   

  • Обязательность полей, действий   

  • Зависимости полей / режимы экрана   

  • Как показываем ошибки, предупрежденияе   

  • Актуальность отображаемых данных   

  • Форма отображаемых данных: таблица, карточки, карта 

  • Граничные состояния: нет объектов, очень много объектов

Навигация

Чтобы забыть как о кошмарном сне о вопросах из серии «Где я?», «Что от меня хотят?» и «Как всё вернуть как было?!», нужно тщательно проработать шаги, связанные с навигацией пользователя.

• Навигация. Получены ответы на вопросы  

  • С какого экрана всё начинается?  

  • Насколько часто пользователь попадает на этот экран?  

  • Действие на экране – целевое для системы или вспомогательное?   

  • Куда можно перейти с этого экрана?   

  • Как попасть на этот экран / в этот режим?  

  • Как понять, где ты сейчас находишься? (экран какого объекта, какой шаг процесса?)  

  • Как вернуться назад? Как вернуть всё, как было — в начальное состояние? 

---

Жизненный цикл, режимы работы, мониторинг

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

Некоторые стейкхолдеры ошибочно предполагают, что система живёт, обрастает данными и работает сама по себе. Задача аналитика — обратить внимание Заказчика на важность этого блока требований. Давайте рассмотрим технические аспекты работы системы и требования, которые они порождают.

8. Жизненный цикл и режимы работы

У любой системы есть стартовая точка: та точка, в которой данных ещё нет. Если у системы был предшественник, можно получить данные для загрузки от предыдущей системы (или систем). Иногда эта загрузка данных, которая называется миграцией, может по сложности вылиться в отдельный проект.

Здесь важно помнить, что данные практически никогда не загружаются однократно, а значит, нужно предусматривать сценарий очистки и повторной загрузки данных. Для системы, которая создаётся впервые, мы запрашиваем данные для первичного наполнения у стейкхолдеров (и, возможно, для их подготовки понадобится серьёзный объём ручной работы).

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

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

После получения тестовых данных и проведения испытаний на тестовом окружении система передаётся заказчику. Для запуска системы в эксплуатацию мы выходим в продуктовую среду в нулевом состоянии. Причём для каждого продукта нулевое состояние предполагает загрузку обновлённых версий ПО и справочников и различные варианты настроек.

Какие-то из них должны быть установлены по умолчанию, а какие-то сброшены. Особенно интересные кейсы здесь бывают у сайтов. Мы тестировали комментарии под статьями перед запуском и заводили тестовых пользователей? Неплохо бы их удалить.

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

• Жизненный цикл и режимы работы   

  • На каких данных тестируем?     

    • Откуда берём, как портим?   

  • Параллельная эксплуатация     

    • Как перенаправляем данные, как сверяем?   

  • Нулевое состояние     

    • Какие настройки и данные должны быть сброшены?     

    • Какие настройки и данные должны быть установлены?   

  • Обновление версии ПО / справочников   

  • Удаление / вывод из эксплуатации     

    • Что остаётся, когда системы уже нет?

9. Отчёты и мониторинг

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

• Сколько новых пользователей зарегистрировалось?

• Насколько активно пользователи используют сервис (и в чем это измерить — число просмотренных товаров, число созданных объектов и т. п.)?

• Сколько людей купило новый продукт?

• А сколько из них — новых покупателей?

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

Например, для продуктовых решений нужно заранее выяснить всё о продуктовых метриках и конверсии. Для внутренних систем — подготовить формы корпоративной отчётности. Отдельного внимания заслуживают формы строгой отчётности, имеющие юридическую силу. Заранее выясняем, куда должны направляться отчёты, потребуется ли ЭЦП и т. д.

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

Журналы и отчёты о входах в систему, создании учётных записей и выдачи полномочий будут интересовать службу безопасности.

А если в системе нет ни одного отчёта, и никто за ними не приходит, пора всерьез задуматься, нужна ли кому-то наша система?

• Отчёты и мониторинг   

  • Отчёты предметной области       

    • Регулярность + рассылки     

    • Внешний вид, утверждённые формы?     

    • Юридическая сила? (ЭЦП?)     

    • Хранение сформированных отчётов?   

  • Отчёты системы     

    • Продуктовые показатели         

      • Число пользователей, воронки конверсий, точки отказа          

      • Пиратские метрики     

    • Технические показатели         

      • Производительность, доступность, расход места/трафика и т.д.

10. Администрирование

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

И снова нам на помощь приходит чек-лист:

• Администрирование   

  • Управление объектами   

  • Управление учётными записями, ролями и полномочиями 

  • Архивирование / восстановление   

  • Журналирование 

  • Массовая загрузка данных – бывает ли? 

  • Настройки     

    • Режимы работы (какие есть и чем отличаются)     

    • Этапы и параметры процессов     

    • Проверки / ограничения (что настраивается?)

---

Вместо послесловия

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

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

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

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

Скачать чек-лист проверки требований на полноту вы можете по ссылке.