Содержание курса

• ВВЕДЕНИЕ

• Введение в процесс формирования требований

• Инфраструктура (ландшафт) для организации проектной деятельности

• Управление целями заинтересованных лиц

• Формализация потребностей заказчика

• Выявление функции системы и управления границами проекта

• Инжиниринг бизнес-процессов заказчика

• Разработка логической структуры данных целевой Информационной системы(ИС)

• Моделирование поведения целевой системы. Моделирование процессов управления

• Формирование спецификаций требований на создание целевой ИС

• Управление изменениями требований и организация эффективного взаимодействия в команде производства ИТ продукта

• Организация процессов проектирования в производстве ИТ-продукта

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

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

1.    Онтология понятия потребности заинтересованных лиц

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

• Позиция – представление заказчика о том, что ему необходимо.

• Интерес – скрытые причины Позиции (мотив). Интерес можно выявить через определение получаемых заказчиком профитов от изменений.

• Потребность – то, что действительно необходимо заказчику.

  

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

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

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

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

• Конфликт интересов. Ожидания клиента могут не совпадать с возможностями компании или целями проекта.

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

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

• Личный интерес. Связан с карьерными или личными амбициями заказчика.

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

• Репутационный интерес. Связан с созданием положительного имиджа компании или продукта.

• Технологический интерес. Связан с желанием внедрить конкретные технологии для демонстрации инновационности компании.

• Контроль над процессами. Связан с желанием заказчика сохранить или усилить контроль над выполнением проекта.

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

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

• Эмоциональные потребности. Потребности, связанные с субъективными чувствами, комфортом и восприятием продукта. Они формируют восприятие бренда и уровень доверия к компании.

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

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

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

• Финансовые потребности. Потребности, связанные с экономией ресурсов клиента — денег, времени или энергии.

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

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

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

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

Чтобы лучше понять, структурировать и удовлетворить Потребности участников, как и в предыдущих частях, мы воспользовались приемом их классификации.

2.    Методы фиксации информации о потребностях заказчика.

Чем больше сторон проекта и сложнее сама разрабатываемая система — тем важнее использовать разные методы фиксации их потребностей. Такой подход позволит избежать искажений в процессе формирования требований к Информационной системе, на основании выявленных ранее потребностей. Ни один метод не даёт полной картины — только их комбинация обеспечивает точность, полноту и достоверность.

Рассмотрим наиболее популярные.

2.1.   Описание Прецедентов

Понятие Прецедента было предложено Иваром Якобсоном и популяризировано в методологии RUP (Rational Unified Process). Это гибкий и настраиваемый процесс разработки программного обеспечения, созданный компанией Rational (позже приобретённой IBM). Он представляет собой структурированную методологию, сочетающую лучшие практики разработки с акцентом на итеративность, управление рисками и архитектуру.

Упрощенно Прецедент можно представить в виде сценария, демонстрирующего то, как система должна вести себя при определённом запросе от пользователя. Оформляется он обычно в виде диаграммы прецедентов (Use Case Diagram) и текстового описания. Такой формат удобно использовать для анализа, проектирования и тестирования программного обеспечения.

Форма представления Прецедента должна предоставить возможность получить полное понимание о происходящем взаимодействии пользователя и системы и предоставить ответы на вопросы:

1)    Кто заинтересован в данном сценарии?

2)    Где будут применяться данный сценарии?

3)    Кто выигрывает от использования данного сценария?

4)    Кто обеспечивает сценарий информацией и применяет эту информацию, а также удаляет ее?

5)    Кто занимается поддержкой сценария?

6)    Использует ли сценарий внешние ресурсы?

7)    Выполняет ли один человек несколько ролей в сценарии?

8)    Выполняют ли несколько человек в сценарии одну и ту же роль?

9)    Взаимодействует ли сценарии с другими сценариями?

Чтобы удовлетворить эти запросы, основные элементы прецедента можно представить так:

• Актор — кто взаимодействует с системой (например, пользователь, администратор).

• Система — объект, с которым взаимодействует актор.

• Цель — конечный результат, который хочет получить актор.

• Основной поток событий — последовательность шагов для достижения цели.

• Альтернативные потоки событий — возможные отклонения от основного сценария (например, ошибки, сбои).

• Исключения — события, которые приводят к невозможности выполнения задачи (например, неверный пароль).

Пример прецедента:

Название: Оформление заказа в интернет-магазине

Актор: Пользователь

Цель: Успешно оформить заказ

Основной поток:

Альтернативный поток:

5a.  Если пользователь выбирает оплату картой и карта не проходит, система предлагает другой способ оплаты.

Исключения:

3a.  Если товар недоступен на складе — система уведомляет пользователя и удаляет товар из корзины

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

Для снижения сложности Прецеденты принято структурировать, разбивая их на уровни представления:

1)    Высокоуровневые прецеденты

• Описывают общий сценарий на уровне бизнес-логики.

• Включают минимальное количество технических деталей.

2)    Подробные (детализированные) прецеденты

• Описывают сценарий с полным перечнем шагов.

• Указывают все возможные исключения и альтернативы.

3)    Технические прецеденты

• Описывают сценарий на уровне взаимодействия с интерфейсом или API.

• Учитывают конкретные детали реализации.

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

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

2.2.  Пользовательские истории

Использование инструмента «Пользовательские истории» помогает сформировать требования к системе с позиции конечного пользователя, фокусируясь на ценности и ожиданиях клиента. Они пишутся с целью разъяснить, как именно функциональная возможность принесет пользу клиенту.

Уникальная черта Agile-разработки ставить во главу угла - человека и пользовательские истории как раз подходят для того, чтобы в центре обсуждения всегда были фактические пользователи.

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

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

Как [тип пользователя], Я хочу [функциональность], Чтобы [получаемая ценность]

Пример:

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

Принципы хорошей «Пользовательской истории» INVEST.

Существуют еще несколько атрибутов, которые делают использование Пользовательских историй более удобным:

1)    уникальный номер;

2)    система тегов для всех элементов бэклога (упорядоченный список задач);

3)    критерии приёмки — фактическое описание того, что ожидается получить;

4)    зафиксированные даты: от попадания в бэклог до релиза по основным точкам;

5)    оценка работы — до начала работы над историей можно оценить бэклог;

6)    бизнес-ценность с точки зрения получения или потерь денег;

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

Определим Пользовательские истории учебного проекта «Библиотека».  

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

Цель: Зафиксировать в электронном виде данные о библиотечном фонде. Систематизировать его.

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

Цель: Обеспечить механизм быстрого поиска изданий по нужным характеристикам.

 US05. Как библиотекарь, я хочу вести учет оборота экземпляра издания.

Цель:. Зафиксировать в системе факты выдачи и возврата издания читателями.   Для анализа оборота изданий.

US06. Как библиотекарь, я хочу вести учет обращения читателей в библиотеку.

Цель: Фиксировать все факты обращений читателей в библиотеку с подробным описанием запросов. Для анализа потребностей читателей.

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

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

Жизненный цикл Пользовательской истории чаще всего включает следующие этапы пути:

1. Создание истории — Формулируется с участием заказчика и команды.

2. Оценка и приоритизация — История оценивается по сложности и важности.

3. Реализация — История реализуется в рамках спринта.

4. Тестирование — Выполнение проверяется по критериям приёмки.

5. Демонстрация — Показ результата заказчику.

6. Закрытие — История закрывается при успешном                                             тестировании.

Одно из преимуществ User Story заключается в том, что автор истории вынужден сосредоточиться на "ЧТО", а не на "КАК" — за последнее отвечает команда разработчиков.

Составьте свои Пользовательские истории для любой предметной области. Проверьте их качество, используя Принципы хорошей «Пользовательской истории» INVEST.

2.3.  Макетирование и прототипирование

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

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

Пример: Макет страницы авторизации, Прототип формы ввода данных.

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

Но использование метода очень удобно для согласования проектируемого решения с заказчиком, оно учитывает UX/UI требования. Ведь заказчик часто не может описать словами, чего он хочет, но понимает суть, увидев макет. Он может прочувствовать, чего не хватает в реализации или, что работать в реальном процессе не будет.

2.4.  Карта потребностей (Needs Canvas)

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

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

Когда удобно использовать Needs Canvas:

• На этапе сбора требований — чтобы быстро зафиксировать потребности пользователя.

• В процессе создания MVP — чтобы определить базовые функции продукта.

• При анализе пользовательского опыта (UX) — для фокусировки на ключевых задачах пользователя.

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

Когда НЕ целесообразно использовать Needs Canvas:

• Не подходит для сложных технических требований — канвас ориентирован на пользовательские задачи и опыт.

• Требует последующей детализации в виде функциональных требований или пользовательских историй.

• В сложных проектах канвас может охватывать только основные задачи и ожидания

2.5.  Job Stories

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

Job Stories идеально подходят для разработки интерфейсов (UX/UI), создания логики работы продукта и для понимания реальных мотивов пользователей.

Описание потребностей с учётом контекста использования:

Когда я… [контекст], Я хочу… [действие], Чтобы… [результат].

Пример:

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

Когда использовать Job Stories:

• При проектировании UX/UI — помогает сфокусироваться на потребностях пользователя в контексте использования.

• При разработке MVP — помогает выделить критически важные функции.

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

• В поведенческом анализе — помогает выявить реальные мотивы пользователя

Пример сравнение использования подходов User Story и Job Story:

1. User Story - Как зарегистрированный пользователь, я хочу восстановить пароль через email, чтобы войти в аккаунт.

2. Job Story - Когда я забыл пароль, я хочу получить код подтверждения на email, чтобы быстро восстановить доступ к системе.

2.6.  Карта пути пользователя (Customer Journey Map)

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

Этот метод особенно полезен, когда необходимо:

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

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

• Улучшить пользовательский опыт (UX).

• Упростить процесс адаптации пользователя.

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

При построении карт обычно используют следующие Ключевые элементы:

1. Персона (Persona): обобщенный образ пользователя с его целями, потребностями и болями.

2. Сценарий (Scenario): конкретная задача или цель, которую пользователь стремится достичь.

3. Этапы пути (Stages): ключевые шаги, которые пользователь проходит, взаимодействуя с продуктом.

4. Действия (Actions): конкретные действия пользователя на каждом этапе.

5. Эмоции (Emotions): чувства и переживания пользователя в процессе взаимодействия.

6. Точки контакта (Touchpoints): места взаимодействия пользователя с продуктом или компанией.

7. Болевые точки (Pain Points): проблемы или препятствия, с которыми сталкивается пользователь.

8. Возможности (Opportunities): идеи по улучшению пользовательского опыта

Этот инструмент идеально работает для визуальной демонстрации проблем заказчику или руководству, уверенному, что их сервис идеален и превосходно функционирует.

3.    Визуализация потребностей заказчика

Для более эффективного взаимодействия с заказчиком необходимо использовать прием «иллюзии восприятия».

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

Визуализация материала в виде изображений позволяет:

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

2. Упрощать восприятие. Скорость восприятия изображения гораздо выше, чем любого другого источника информации. Звук осмысливается человеком примерно половину секунды, слова – секунду. Картинка же воспринимается за десятую долю секунды.

3. Повышать доверие к излагаемому материалу в общем.

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

На рисунке наглядно представлены и процессы, и их последовательности, и локации (место применения), а также ресурсы, требуемые для выполнения.

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

4.    Итоги этапа фиксации Потребностей заинтересованных лиц

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

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

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