Как составить функциональные требования

Как писать функциональные требования

Время на прочтение
5 мин

Количество просмотров 120K

Привет, Хабр!

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

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

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

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

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

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

Функциональные требования: что это такое и зачем они нужны

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

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

Функциональные требования, как правило, состоят из:

  • User story — показывает, чего вы ожидаете от команды разработки
  • Use cases — показывают сценарии использования фичи
  • Wireframes — средство визуализации своей идеи

Сегодня мы сосредоточимся на User story и Use cases.

User story

User story описывает, что делает пользователь определенной роли для достижения результата, и что нужно сделать разработчику, чтобы воплотить эту задачу в жизнь.

Как правило используется шаблон:

As a/an <Название роли>, I want to <Цель, Действие>, so that <Ожидаемый результат>, to do <Что нужно сделать разработчику>

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

В Retail Rocket мы создаем User Stories в Google Docs, используя таблицы. Это помогает упростить процесс коммуникации между различными командами, поскольку каждый может оставить комментарии и дать фидбек.

Например, так выглядит задача об отслеживании NPS для интернет-магазина:

Благодаря такой визуализации взаимодействия задача пользователя плавно и логично переходит в задачу для разработчиков. Затем наступает очередь use case’ов.

Use cases

Use cases описывает поведение пользователя по шагам при взаимодействии с разрабатываемым продуктом.

Задача пользователя — это то, что делает пользователь для достижения краткосрочных целей.

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

Рассмотрим на примере нашей недавно выпущенной фичи — Галерее изображений и шрифтов для массовых рассылок.

Цель пользователя в том, чтобы хранить изображения в нашей платформе и использовать их для создания email-кампаний.

Задачи пользователя:

  • Загружать изображения
  • Вставлять изображения в шаблон письма
  • Удалять изображения

Для каждой задачи нужно написать свой use case — описание того, как пользователь взаимодействует с интерфейсом.

Примеры use case’ов:

Загрузка изображений:

  • Email-маркетолог заходит в свой личный кабинет Retail Rocket
  • Email-маркетолог открывает раздел «Галерея»
  • Email-маркетолог загружает изображения через drag&drop или с помощью клика по кнопке «Выбрать файлы»
  • Изображения загружаются
  • Пользователь видит уведомление об успешной загрузке изображений

Удаление изображений:

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

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

Почему функциональные требования так важны

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

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

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

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

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

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

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

А как вы подходите к постановке задач разработчикам?

Директор по продукту Гульфия Курмангалеева

Источник

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

Что такое функциональные требования? Этот вопрос часто ставит в тупик как владельцев бизнеса, так и разработчиков. Функциональное требование можно рассматривать как особенность продукта, которую обнаруживает пользователь. Это может быть очевидная функция, например, большая кнопка «Добавить в корзину». Но это также может быть и менее очевидная функция, например, правильный расчет налога с продаж для онлайн-покупки пользователя. В этом полном руководстве мы разобьем функциональные требования на их простейшие формы и приведем примеры каждого типа. Мы также определим, что каждый тип требований означает для вашего бизнеса и как их создать.

Что такое функциональные требования?

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

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

Типы функциональных требований

Вот наиболее распространенные типы функциональных требований:

  • Деловые правила
  • Сертификационные требования
  • Требования к отчетности
  • Административные функции
  • Уровни авторизации
  • Отслеживание аудита
  • Внешние интерфейсы
  • Управление данными
  • Правовые и нормативные требования

Создание функциональных требований:

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

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

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

Примеры:

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

Пример # 1

: Пользователь должен иметь возможность войти в систему, используя свое имя пользователя и пароль.

В этом примере функция — «вход», а поведение — «Система должна позволять пользователю входить в систему, используя свое имя пользователя и пароль».

Пример # 2

: Система рассчитывает налог с продаж для покупки пользователя.

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

Пример # 3

: система отправляет пользователю электронное письмо с подтверждением после того, как он успешно разместил заказ.

В этом примере функция — «отправить электронное письмо с подтверждением», а поведение — «система должна отправить электронное письмо с подтверждением пользователю после того, как он успешно разместил заказ».

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

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

Чем функциональные требования отличаются от нефункциональных требований?

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

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

  • Пользовательский интерфейс
  • Надежность 
  • Безопасность
  • Производительность
  • Обслуживание
  • Стандартный 

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

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

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

Вывод:

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

Источник

{«id»:13973,»url»:»/distributions/13973/click?bit=1&hash=36e9dbe09585049bc2ad336719ba618e3527cc649329f2e6c7a26974041cd061″,»title»:»u041au0430u043a u0440u0430u0437u043du044bu0435 u0441u043fu043eu0441u043eu0431u044b u0434u043eu0441u0442u0430u0432u043au0438 u043cu043eu0433u0443u0442 u0441u0442u0438u043cu0443u043bu0438u0440u043eu0432u0430u0442u044c u043fu0440u043eu0434u0430u0436u0438″,»buttonText»:»u0412u044bu044fu0441u043du0438u0442u044c»,»imageUuid»:»fb0a50bc-0a7b-535f-b137-b58b2208d639″}

Как писать функциональные требования к ПО

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

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

1. Начинайте с описания бизнес-задачи

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

2. Сформулируйте требования точно и четко

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

3. Помните о совместимости

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

4. Не забывайте об использовании программы

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

5. Не забывайте о интерфейсах пользователя

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

Итог

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

Источник

Анна Вичугова | Анна Гасраталиева

Существуют разные формы представления функциональных требований: пользовательская история (user story), каноническая форма с привязкой к CRUDL-операциям и модели данных (классический формат описания требований), а также описание сценариев использования (Use Case).

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

В официальной литературе на русский язык Use Case принято переводить как вариант использования (сокращённо ВИ), хотя в разговорной речи и проектных документах достаточно часто употребляется ещё и транслитерация термина Use Case, то есть говорят и пишут юскейс.

В связке с понятием варианта использования идёт термин Use case scenario, который переводится как сценарий варианта использования или пользовательский сценарий.

Технически, разница есть, то есть Use case это не тоже самое, что Use case scenario. Например, «Купить Товар» — Use case, и у него есть Use case scenario (пошаговое описание того, как именно купить товар: 1. Выбрать товар, 2. Добавить в корзину, 3. Оплатить).

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

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

Итак, Use case (UC) — это популярная форма представления функциональных требований к ПО в виде пошагового сценария взаимодействия актора (пользователя или внешнего сервиса) с проектируемой системой, включая описание метаданных этого взаимодействия: области применения, предусловия, триггеры, постусловия, релевантные бизнес-правила и пр.

Давайте рассмотрим на примере, как описать UC и избежать ошибок в работе с этим методом.

Воркшоп «Use Case: основы»

Воркшоп будет полезен начинающим системным аналитикам, которые хотят:

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

Алгоритм описания функциональных требований к системе

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

  1. Определить Акторов — тех, кто взаимодействует с системой
  2. Выявить и составить список UC — задач, которые стейкхолдеры смогут решить с помощью системы
  3. Для каждого юскейса определить приоритет — важность UC по отношению к другим вариантам использования
  4. Для каждого важного юскейса определить контекст применения, конечную цель и результат
  5. Описать основной поток каждого UC с высоким приоритетом в виде последовательности шагов, которая приведёт к достижению его цели — пользовательского сценария (use case scenario)
  6. Дополнить основной поток расширениями, исключениями и циклами
  7. Собрать воедино результаты шагов 4−6, детально описав каждый юскейс с высоким приоритетом как алгоритм взаимодействия пользователя с системой

Теперь давайте рассмотрим каждый шаг поподробнее.

1. Определить акторов, которые взаимодействуют с системой

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

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

2. Для каждого актора составить список задач, которые он сможет решить с помощью системы

Мы советуем делать это в виде реестра юскейсов — единой таблицы, показывающей распределение юскейсов по акторам.

Рекомендуем называть UC в формате «Инфинитив + Объект», где «Инфинитив» — это инфинитив глагол в совершенного вида с большой буквы, а «Объект» — это существительное, обозначающее объект управления с большой буквы.

Из названия вариант использования должно быть сразу понятно, какую именно задачу пользователя он решает. Например, «Подписать Документ», «Оформить Заказ», «Оплатить Товар», «Сделать Звонок» и так далее.

Для повышения наглядности можно сделать это в табличном виде или UML-диаграммы вариантов использования (она же Use case diagram, диаграмма прецедентов).

Обычно для продуктов и проектов в сфере B2C исходные данные для этого извлекаются из изучения интересов, потребностей и пользовательского опыта людей (клиентов, экспертов предметной области) и конкурентного анализа, а также CJM-карты.

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

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

Юскейсы «Поиграть в казуальную Игру» и «Посмотреть фотографии» относятся к потребности «Скоротать время».

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

3. Для каждого UC определить его приоритет

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

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

Самым простым методом приоритизации, который часто применяется на практике, считается метод MoSCoW. Он получил своё название не в честь российской столицы, а как сокращение следующих 4 категорий:

  • Must — то, что необходимо сделать в любом случае. Считается, что без реализации этих требований решение не будет работать или при отсутствии этих фич продукт не будет нужен потребителям. Чаще всего этот приоритет называется 1-я очередь и обозначается цифрой 1
  • Should — требования 2-ой очереди, которые должны быть реализованы после тех, что отнесены к группе Must. Это приоритет номер 2
  • Could — желательные требования, которые можно сделать, если останется время и будут ресурсы. Это приоритет номер 3
  • Would — требования, которые хотелось бы реализовать, но пока их можно проигнорировать или перенести на следующие итерации без вреда для продукта. Это приоритет номер 4

В нашем примере с мобильным телефоном приоритизировать юскейсы можно так, как показано в таблице 2.

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

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

4. Для каждого высокоприоритетного (Must или Should) UC определить контекст применения, конечную цель и результат

Это можно оформить в виде списка или таблицы, например в Notion:

5. Раскрыть содержание основного потока каждого юскейса высокого приоритета в виде пользовательского сценария

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

Основную часть пользовательского сценария составляет так называемый happy path (основной поток), который представляет собой пошаговый алгоритм выполнения сценария без логических операторов XOR (исключающее или), используемых для ветвления потока управления в результате проверки каких-либо условий.

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

1. Пользователь даёт команду совершить звонок
2. Система запрашивает номер телефона вызываемого абонента
3. Пользователь сообщает номер абонента
4. Система убеждается в корректности указанного номера телефона
5. Система вызывает абонента с указанным номером телефона
6. Система убеждается, что звонок начался
7. Система передаёт голос собеседников в ходе разговора

Для наглядности можно нарисовать эту линейную последовательность шагов в виде простого процесса в нотациях EPC, BPMN (рис.1), UML activity или sequence, а также блок-схемы алгоритма по ГОСТ 19.701−90.

Последовательность шагов в виде BPMN-диаграммы

Воркшоп «BPMN для людей:

основы самой популярной нотации

для описания бизнес-процессов»

Воркшоп для ИТ-специалистов, которые хотят научиться описывать логику выполнения бизнес-процессов с помощью формальной нотации — BPMN. Читателями таких диаграмм будут люди, а не сервисы.

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

6. Дополнить линейную последовательность основного потока в описании UC расширениями, исключениями и циклами

На этом этапе аналитик усложняет ранее полученный happy path, включая в схему различные ветвления с помощью логического оператора XOR.

Вместо BPMN для отображения логики сценария нашего юскейса можно использовать любую другую нотацию (EPC, UML activity diagram, IDEF3 или даже простого текстового алгоритма).

Расширенная BPMN-диаграмма юскейса с исключениями и альтернативными потоками

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

На этом этапе у каждого юскейса появляется описание, структура которого всегда примерно такая:

  • Имя
  • Приоритет
  • Область действия
  • Контекст
  • Актор
  • Цель
  • Предусловия
  • Результат (постусловие)
  • Основной поток
  • Расширения или альтернативные потоки
  • Бизнес-правила

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

Эту структуру можно представить в текстовом виде или, для наглядности, в виде таблицы. Давайте завершим описание этого юскейса так, как мы делаем это на реальных проектах, то есть полностью опишем happy path и альтернативные сценарии.

Пример 1. UC «Сделать Звонок»

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

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

Как структурировать UC из набора
исходных ФТ

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

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

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

  • FRQ1 Система должна предоставить пользователю с ролью «Клиент» возможность заключить договор на участие в одном или нескольких обучающих курсах
  • FRQ2 Система должна предоставить пользователю с ролью «Клиент» возможность добавить курсы к договору
  • FRQ2 Система должна предоставить пользователю с ролью «Клиент» возможность удалить курсы из договора
  • FRQ4 Система должна предоставить пользователю с ролью «Клиент» оплатить сумму по заключенному договору через шлюз онлайн-оплаты
  • FRQ5 Система должна предоставить пользователю с ролью «Клиент» снизить сумму по заключенному договору с применением промо-кода на скидку

Формируем описание в формате UC, применяя алгоритм:

Шаг 1. Определяем акторов. Судя по требованиям, с системой взаимодействует клиент и шлюз оплаты.

Шаг 2. Сформируем реестр юскейсов. Для этого мы можем, например, представить имеющийся набор функциональных требований в виде UML-диаграммы вариантов использования (UML Use case diagram).

Исходная UML-диаграмма use case

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

Упрощённая UML-диаграмма use case

Давайте также сопоставим получившиеся юскейсы и функциональные требования в таблице ниже.

При формировании реестра юскейсов для пользователя мобильного телефона мы можем выделить такие функциональные возможности как «Сделать Звонок» и «Отправить СМС». Оба этих юскейса отражают непосредственное взаимодействие актора с системой, направленное на достижение определённой бизнес-цели, это системный юскейс.

Функциональные возможности «Сделать звонок» и «Отправить СМС» относятся к одной потребности пользователя «связаться с другим человеком», которая будет состоять из двух системных юскейсов: «Позвонить Человеку» и «Отправить СМС». Показать эту трассировку (связь) можно с помощью реестра вариантов использования.

Реестр вариантов использования:

Шаг 3. Определить приоритеты системных юскейсов

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

Шаги 4−7. Эти шаги (описать основной поток и расширения для каждого из приоритетных юскейсов) мы представим в виде примера описания одного из юскейсов (UC «Оплатить Договор», см. ниже). По аналогии будет описан и UC «Заключить Договор».

Пример 2. UC «Оплатить Договор»

Для нашего примера вариант использования «Оплатить Договор» может выглядеть так:

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

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

Рассмотренная табличная форма описания UC является не единственной возможной. Бывают ещё и другие форматы, например, таблица в две колонки, юскейс в стиле RUP и так далее.

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

Пример 3. UC «Обновить Анкету»

Достоинства и недостатки UC как формы представления требований

Основными преимуществами UC являются следующие:

  • Нисходящая и восходящая трассировка (от системного уровня к бизнесу) улучшает понятность требований для Заказчика и команды реализации: UC несёт конечную бизнес-ценность, детально описывает структуры данных и бизнес-логику их обработки, позволяет убедиться в реализации
  • Вариант использования можно использовать как единицу поставки при планировании, реализации, тестировании и приёмке работ;
  • Набор связанных друг с другом вариантов использования позволяет обеспечить полноту функциональных требований, следующих из потребностей пользователей
  • Детальный шаблон представления UC позволяет полностью описать взаимодействие актора с системой, включая контекст, предшествующие, сопутствующие и результирующие события, а также ссылки к бизнес-правилам и нефункциональным требованиям (ограничения и некоторые атрибуты качества)
  • UC — отличная база для формирования тестовых сценариев (test cases) для проверки того, работает ли реализованная система как ожидалось

Обратной стороной этих достоинств являются следующие недостатки:

  • Плохо подходят для документирования требований, основанных не на взаимодействии с системой, а на выполнении расчётов и преобразованиях уже имеющихся в системе данных. Например, построение графиков и отчётов, вычисления, описание математических алгоритмов
  • Субъективность: качество изложения как самого UC, так и их реестра (ширина, глубина детализации уровней абстракции) зависит от навыков аналитика
  • На детальную проработку каждого UC уходит много времени. Например, у меня это занимает в среднем от 30 минут; добиться существенного повышения скорости работы можно за счёт повторного использования типовых юскейсов (опытный аналитик или отдел могут создать библиотеку своих юскейсов)
  • Проектирование системы только по UC исключает другие потенциально ценные методики документирования и анализа требований, такие как каноническая форма представления функциональных требований с привязкой с CRUD-операциям или популярная в Agile-проектах форма User Story по INVEST с критериям приёмки (Acceptance Criteria)

Откуда взялся такой формат как Use Case

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

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

  • FRQ1 Система должна предоставить пользователю с ролью «Клиент» возможность заключить договор на участие в одном или нескольких обучающих курсах
  • FRQ2 Система должна предоставить пользователю с ролью «Клиент» возможность добавить курсы к договору

В 1986 году Ивар Якобсон (шведский учёный, который вместе с Гради Бучем и Джеймсом Рамбо стоял у истоков ООП и UML) предложил альтернативную форму представления функциональных возможностей системы. Вместо описания функциональных требований к системе в виде отдельных функций Якобсон предложил объединить их по контексту, а затем превратить в набор вариантов использования (ВИ), который будет обеспечивать полноту и неизбыточность требований.

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

В 2001 году Алистер Коберн, эксперт в разработке ПО, расширил и уточнил идеи Якобсона, выпустив книгу «Современные методы описания функциональных требований к системам» (Writing Effective Use Cases). Книга получилась достаточно подробной, содержащей множество примеров. Помимо техник описания самих UC, работа Коберна включает также связанные вопросы о контексте, границах и основных компонентах проектируемой системы, то есть так называемый scope системы.

Эти и другие аспекты работы с требованиями были изложены в книге ещё одного автора, широко известного в системном и бизнес-анализе. В 2003 году Карл Вигерс (Karl Wiegers) написал 2-е издание своей книги «Разработка требований к программному обеспечению» (Software Requirements), где рассмотрены не только техники разработки требований, но и вопросы управления ими, включая сбор, документирование, трассировку, работу с изменениями и анализ рисков. Эта книга почти вдвое объёмнее труда Коберна и больше подходит для начинающих аналитиков.

UC рассматривает проектируемое ПО как «чёрный ящик», описывая взаимодействие с системой с точки зрения внешнего наблюдателя: ЧТО система должна сделать, чтобы актор достиг своей цели, а НЕ КАК это должно быть сделано.

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

Несмотря на повсеместное распространение гибких методологий разработки ПО, UC как подход к описанию функциональных требований очень активно применяется на практике. В отличие от пользовательских историй (User Story), другой популярной формы представления требований, UC охотно принимают в реализацию — в основном благодаря структурированному формату и детальной проработке бизнес-логики с привязкой к модели данных.

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

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

Воркшоп «Use Case: основы»

Воркшоп будет полезен начинающим системным аналитикам, которые хотят:

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

Анна Вичугова

  • Кандидат технических наук (Системный анализ, управление и обработка информации, 2013)
  • Сертифицированный бизнес-аналитик (CBAP 2020, международная сертификация IIBA)
  • Сертифицированный специалист Business Studio (2010, 2012, 2013, 2018)
  • Сертифицированный специалист и администратор СЭД Directum (2011

Профессиональные интересы: системный анализ, бизнес-анализ, разработка и поддержка СМК, ССП (KPI), анализ и формализация бизнес-процессов (UML, IDEF, BPMN), Data Science, технологии Big Data, разработка технической документации (ТЗ по ГОСТам серии 19.***, 34.***, руководства пользователя и администратора, описание программных продуктов), управление продуктами и проектами.

Анна Гасраталиева

Системный аналитик, выпускающий редактор Systems. Education

Системный аналитик, выпускающий редактор Systems. Education

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

Источник

Фундаментальное описание требований к ПО и подходов к их выявлению и сбору от тестировщика Noveo Вадима: пост освещает все аспекты этой области знаний, структурирует информацию и не оставляет ни малейшего шанса недопониманиям и «темным» местам. Приятного прочтения!

Вадим

Вадим


Noveo Test Engineer

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

Цели этого поста заключаются в следующем:

  1. Определить, что такое требование, какие типы и уровни требований выделяют.
  2. Понять, какие существуют методы сбора и выявления требований.
  3. Предоставить почву для дальнейшего изучения сферы системного и бизнес-анализа.

Требования

Начнем с требований как таковых:

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

Определение требования

Прежде чем погрузиться в теорию разработки требований к ПО, попробуйте, основываясь на своих знаниях и опыте, ответить на вопрос: как вы определяете термин «требование»?

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

Требования к ПО — это спецификация того, что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они могут служить ограничениями в процессе разработки системы (Ian Sommerville и Pete Sawyer, 1997).

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

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

  • Спецификация — документ, устанавливающий требования.
  • Реализация — интерпретация требований в виде разработанной системы (одни и те же требования можно реализовать различными способами).
  • Описание поведения системы (то, как система должна работать при различных входных условиях).
  • Описание свойств / атрибутов / качеств системы.

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

Термин «требование» охватывает довольно широкую предметную область. Поэтому возникает вопрос типизации и классификации требований.

Уровни и типы требований

Требования к ПО состоят из трех уровней:

  1. Бизнес-требования.
  2. Пользовательские требования.
  3. Функциональные требования.

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

Бизнес-требования BRQ

Бизнес-требование (business requirements) — высокоуровневая бизнес-цель организации или заказчиков системы.

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

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

Если кратко, документ содержит определение следующих понятий:

  • Бизнес-возможности, бизнес-проблемы — факты и события, формирующие бизнес-цели, то есть грубо — причины инициации проекта.
  • Бизнес-цели — цели, которые должны быть решены разработкой и вводом в эксплуатацию системы. Являются критериями успеха проекта.
  • Концепция продукта (Vision) — сжато описывает конечный продукт, который достигнет заданных бизнес-целей.
  • Границы проекта (scope) — показывают, на какую часть конечной концепции продукта будет направлен текущий проект или итерация.

Примеры бизнес-требований:

Сократить время обработки заказа на 50% (цель) — система должна предоставить интерфейс, упрощающий создание заказа (концепция).

Увеличить клиентскую конверсию до 35% (цель) — в системе должны быть представлены механизмы побуждения клиента к заказу (концепция).

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

Источники бизнес-требований (где искать?):

  • Внутренняя документация компании (положения, инструкции, приказы).
  • Документация по предметной области (профильные литература и статьи, исследования).
  • Нормативная документация (законы и иные правовые акты, государственные стандарты).
  • Продукты конкурентов.

Стейкхолдеры (у кого спрашивать?):

  • Инициатор проекта.
  • Руководитель проекта (менеджер проекта).
  • Руководитель структурного подразделения заказчика (коммерческий директор, директор по маркетингу).
  • Бизнес-аналитик.

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

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

Пользовательские требования URQ

Пользовательские требования (user requirements) описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта, который в свою очередь должен приносить пользу кому-то. Область пользовательских требований также включает описания атрибутов или характеристик продукта, которые важны для удовлетворения пользователе (Карл Вигерс, «Разработка требований к программному обеспечению»).

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

Пользовательские требования также часто именуются фичами.

Фича (функциональность) — функционально обобщенные части системы, решающие отдельные задачи пользователей или интерпретирующие бизнес-процессы (и их артефакты), которые будут реализованы в рамках системы.

Исходя из вышеописанных определений, пользовательские требования содержат:

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

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

  • текстового описания,
  • вариантов использования, сценариев использования (Use Case),
  • пользовательских историй (User Story),
  • диаграммы вариантов использования.

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

Пользователь должен иметь возможность + {тезис}.

Пример пользовательского требования:

Пользователь должен иметь возможность добавить объект в избранное (функциональность).

Источники пользовательских требований требований (где искать?):

  • Анализ и декомпозиция бизнес-требований.
  • Описание бизнес-процессов.
  • Артефакты бизнес-процессов:
  • документы входные/выходные,
  • стандарты,
  • регламенты,
  • обрабатываемые данные,
  • иная информация, используемая и/или производимая в бизнес-процессе.
  • Отраслевые стандарты.
  • Реализованные проекты, проекты конкурентов.

Стейкхолдеры (у кого спрашивать?):

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

Этот уровень требований напрямую входит в круг обязанностей QA-инженера. В задачи QA на этом уровне входит:

  • Определение соответствия описания требований критериям качества.
  • Анализ требований для проработки сценариев тестирования.
  • При достаточном уровне компетенций в предметной области:
  • определение соответствия требований устоявшимся отраслевым стандартам (например: системе не достаёт фичи, которая в рамках предметной области системы является обязательной);
  • определение соответствия требований с утвержденными бизнес-требованиями. Ответ на вопрос: «Решает ли пользовательское требование бизнес-цели проекта и задачи пользователей?«.

Функциональные требования FRQ

Функциональные требования (functional requirements) — описание требуемого поведения системы в определенных условиях.

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

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

Пример функциональных требований:

Пользователь должен иметь возможность добавить объект в избранное (URQ):

FRQ 1 — Добавить в избранное.

FRQ 2 — Удалить из избранного.

FRQ 3 — Редактирование дополнительных атрибутов.

FRQ 4 — Обращение к объекту из меню избранного.

Источники требований (где искать?):

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

Стейкхолдеры (у кого спрашивать?):

  • Бизнес-Аналитик.
  • Системный аналитик.
  • Архитектор.
  • Менеджер проекта.
  • Разработчики.

Нефункциональные требования NFRQ

Нефункциональное требование (non-functional requirements) — описание свойства или особенности, которым должна обладать система, или ограничение, которое должна соблюдать система.

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

  1. Выявляются и формулируются на всех уровнях иерархии требований.
  2. Напрямую или косвенно влияют на формирование каждого уровня требований.

Совет: Чаще всего нефункциональные требования отвечают на вопрос «Как? Каким образом?».

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

С точки зрения разработки функциональный скоуп проекта не является уникальным:

  • смотреть контент,
  • предлагать ротацию контента на основе алгоритмов,
  • создавать контент.

Все эти фичи так или иначе были представлены в других проектах. Ключом успеха проекта в данном случае является его UI/UX. А UI/UX сам по себе не отвечает за функции системы, а отвечает за то, каким образом будут реализованы эти функции.

SRS

В конечном итоге все требования консолидируются в одном документе «Спецификации требований к системе». Выше вы можете видеть структуру документа SRS. Ни в коем случае нельзя воспринимать её как жесткий стандарт (хотя таковой имеется: ISO/IEC/IEEE 29148:2011). Я предлагаю вам использовать эту структуру как чек-лист для определения полноты описания системы. Стоит отметить, что внутренние стандарты документирования и полноты требований меняются от проекта к проекту, но набор типов требований всегда будет идентичен. Кто-то опускает бизнес-требования, для кого-то пользовательские требования тождественны функциональным. В конечном итоге все требования — лишь абстракция, и каждая команда подбирает под себя удовлетворительный уровень детализации этой абстракции.

Выявление требований

Выявление требований — итеративный процесс, состоящий из следующих этапов:

  1. Подготовка к выявлению.
  2. Выявление.
  3. Утверждение результатов.

Подготовка к выявлению требований

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

1. Что необходимо выяснить? — Анализируем имеющуюся информацию о системе:

а. Анализ текущего описания требований к системе.

b. Анализ текущей реализации системы.

c. Выявление недостающих и/или недостаточно описанных требований.

2. У кого? Где? — Определить источник требований:

а. Собрать список доступных источников, таких как:.

i. Документация.

ii. Артефакты бизнес-процессов и/или текущей реализации системы.

b. Определить список стейкхолдеров, которые могут выступать источником требований к системе.

3. Каким образом? — Выбрать оптимальный метод выявления требований.

Выявление требований. Интервью

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

Подготовка к интервью

Подготовка к интервью состоит из следующих этапов:

1. Собрать информацию о собеседнике(ах):

а. Роль в проекте?

b. За какие вопросы ответственен?

2. Подготовить вопросы:

a. Сформулировать проблематику интервью.

b. Сформулировать вопросы.

c. Подготовить дополнительные вопросы.

3. Определить тайминг встречи.

a. Нужно стараться уложиться в один час. Чаще всего человек начинает терять концентрацию после 40 минут непрерывной беседы.

b. Для каждого вопроса определить необходимое время на обсуждение.

c. Если вы не успеете задать все вопросы в рамках одной встречи, назначьте несколько встреч.

4. Согласовать календарь встреч.

a. Если предполагается несколько встреч — то не обходимо составить график встреч.

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

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

Протокол интервью

Проект:{}

Дата проведения:{}

Интервьюер: {Кто проводит интервью}

Интервьюируемый:{Кому задаём вопросы}

Проблематика:{Тема интервью}

Вопрос № 1:

Тайминг вопроса:

Текст вопроса:

Таймкод:

Ответы на вопрос:

Стейкхолдер 1 —

Стейкхолдер 2 —

Проведение Интервью

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

1. Всегда ведем запись встречи.

a. Спрашиваем собеседника, не против ли он вести запись разговора.

b. Включаем запись после согласия собеседника.

2. Small talk для разрядки.

a. Как настроение?

b. Как погода?

c. И т.д. и т.п.

d. Но не затягиваем, пара вопросов из вежливости, не более.

3. Начинаем с объявления проблематики.

4. Стараемся следовать плану встречи. Вопросы задаём последовательно.

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

6. Стараемся раскрывать вопросы дополнительными вопросами. Беседа должна быть живой, не должна скатываться в сухой формат вопрос-ответ, иначе проще отправить собеседнику опросник и не тратить его время на встречу.

7. В конце обсуждения не лишним будет подтвердить позицию собеседника закрытым типом вопроса.

a. Например: Я правильно вас понял, что необходимо реализовать функционал следующим образом {Тезис}?

Обработка результатов Интервью

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

1. Заполняем протокол встречи.

a. Читать краткий протокол встречи намного проще, чем смотреть часовую запись в поисках ответов.

2. Направляем участникам встречи результаты в формате «Вопрос — Зафиксированное решение».

b. Это необходимо для получения от заказчика письменного утверждения результатов встречи.

Плюсы и минусы метода

Плюсы метода:

  • Наиболее эффективный способ метод сбора требований.
  • Меньшая вероятность недопонимания между собеседниками.
  • Большая вероятность выявления «скрытых» требований.

Минусы метода:

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

Выявление требований. Анкетирование

Метод анкетирования подразумевает создание анкеты (списка вопросов) и её рассылку большому количеству опрашиваемых.

Подготовка

Подготовка к анкетированию состоит из следующих этапов:

1. Собрать контакты опрашиваемых стейкхолдеров.

2. Подтвердить готовность стейкхолдеров участвовать.

3. Подготовить анкету:

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

b. Задавать можно как открытые, так и закрытые вопросы.

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

Проведение

  1. Рассылаем анкету опрашиваемым.
  2. Контролируем сроки опроса (должен быть внутренний дедлайн).
  3. Ответы, по мере поступления, консолидируем в одном документе (каналы связи с опрашиваемыми могут быть разными, но место хранения требований всегда должно быть одно).

Обработка результатов

  1. Анализируем ответы.
  2. Фиксируем требования.
  3. Утверждаем требования с ответственными лицами.

Плюсы и минусы метода

Плюсы:

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

Минусы:

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

Выявление требований. Мозговой штурм

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

Подготовка

1. Формулируем проблематику:

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

b. Проблематика озвучивается экспертам заранее, чтобы у них было время «на подумать».

2. Подготавливаем дополнительные материалы для отработки идей — например, макеты системы.

3. Формируем группу экспертов.

4. Согласовываем дату и время.

Проведение

1. Ведем запись-протокол. Уведомляем участников о том, что ведется запись.

2. Озвучиваем регламент встречи:

a. Тема,

b. Тайминги,

c. Правила.

3. Эксперты озвучивают идеи по очереди.

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

5. Каждая идея фиксируется и обсуждается.

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

7. Коллективное комбинирование собранных идей.

Обработка результатов

  1. Анализируем идеи.
  2. Формализуем и описываем (то есть готовим развернутое описание).
  3. Утверждаем идеи с ответственными.

Плюсы и минусы метода

Плюсы:

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

Минусы:

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

Другие методы выявления требований

  • Анализ документации — изучение и анализ существующей документации, которая напрямую или косвенно касается разрабатываемой системы.
  • Анализ системных интерфейсов, API и базы данных — анализ систем, которые будут взаимодействовать с разрабатываемой системой.
  • Анализ пользовательского интерфейса — анализ интерфейсов, функционально похожих (или идентичных) на разрабатываемую систему (отраслевые стандарты UI/UX). Также к этому относится анализ интерфейсов систем, входящих в IT-экосистему заказчика.
  • Моделирование процессов, поведения системы и пользователей — моделирование процессов и схем данных помогает структурировать и упорядочивать информацию о проекте.
  • Повторное использование требований — многие элементы систем имеют стандарты исполнения. Например: регистрация — авторизация пользователей.
  • Вовлечение представителя заказчика в команду разработки — вовлечение заказчика в работу над проектом является одним из постулатов Agile. В целом наличие представителя заказчика в команде разработки экономит уйму времени на коммуникации.
  • Презентации, демо и т.п. — представление требований/реализации системы заказчику. Данный способ помогает уточнить требования, а также выявить скрытые и/или избыточные требования. Пример: демонстрация мокапов будущей системы пользователям.
  • Работа в «Поле» (наблюдение) — наблюдение за деятельностью и процессами будущих пользователей.
  • Обучение — процесс, в котором заказчик или любой другой человек из организации заказчика, знающий процесс, обучает аналитика по принципу «учитель — ученик».

Очевидный факт:

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

Материалы для самостоятельного изучения

Блоки знаний:

  • Бизнес-анализ — раздел знаний, отвечающий за описание и формализацию бизнес-процессов. Прежде чем интерпретировать бизнес-процессы в виде ПО, необходимо их «правильно» описать и формализовать.
  • Моделирование бизнес-процессов — изучение различных нотаций описания бизнес-процессов. Неразрывно связан с бизнес-анализом.
  • Системный-анализ — раздел знаний, отвечающий за анализ процессов непосредственно в самом ПО.
  • Моделирование систем — изучение нотаций описания систем ПО. Неразрывно связан с системным анализом.
  • Документирование требований — изучение различных сред документирования информации о проекте и системе.
  • Управление требованиями (согласование, управление изменениями, трассировка требований) — отдельный процесс в системе знаний об анализе в ИТ. Является одним из самых сложных процессов на долгосрочных проектах с большим количеством итераций.
  • Прототипирование — изучение различных инструментов для моделирования интерфейсов и архитектуры ПО. Например: Figma для верстки макетов интерфейсов.

Книги:

  • Вигерс, Карл: Разработка требований к программному обеспечению. 3-е издание, дополненное / Карл Вигерс, Джой Битти. — Санкт-Петербург : БХВ-Петербург, 2019. — 736 с.
  • Ильяхов М., Сарычева Л. Пиши, сокращай. Как создавать сильный текст — 2017.
  • Гэртнер, Маркус: ATDD — разработка программного обеспечения через приемочные тесты. — ДМК-Пресс, 2013. — ISBN 978-5-457-42706-8.
  • Gojko Adzic, David Evans — Fifty Quick Ideas to Improve Your User Stories — 2014.
  • Майкл Мескон, Майкл Альберт, Франклин Хедоури — Основы менеджмента
  • Хоп, Грегор Шаблоны интеграции корпоративных приложений (Signature Series) / Грегор Хоп, Бобби Вульф. — Москва : Вильямс, 2019. — 672 с.
  • Кон, Майк Пользовательские истории. Гибкая разработка программного обеспечения / Майк Кон. — Москва : Вильямс, 2018. — 256 с.
  • Паттон, Джефф Пользовательские истории. Искусство гибкой разработки ПО / Джефф Паттон — Санкт-Петербург : Питер, 2019. — 288 с.
  • Cockburn, Alistair Writing Effective Use Cases / Alistair Cockburn. — Addison-Wesley, 2001.
  • USE-CASE 2.0
  • Фаулер, Мартин UML. Основы. Краткое руководство по стандартному языку объектного моделирования / Мартин Фаулер. — Москва : Символ-Плюс, 2018. — 192 с.
  • Гойко, Аджич Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке / Аджич Гойко. — Москва : Альпина Паблишер, 2017. — 86 с.
  • Коберн, Алистер Быстрая разработка программного обеспечения/ Алистер Коберн. — Москва: Лори, 2002. — 336 с.
  • Корнипаев, Илья Требования для программного обеспечения: рекомендации по сбору и документированию / Илья Корнипаев. — Книга по требованию, 2013. — 118 с. Книга
  • Ми, Роберт Шаблоны корпоративных приложений / Роберт Ми, Мартин Фаулер. — Москва : Вильямс, 2018. — 544 с.
  • Мартин, Роберт Чистая архитектура. Искусство разработки программного обеспечения / Роберт Мартин. — Санкт-Петербург : Питер, 2018. — 352 с.
  • BABOK 3.0
  • SWEBOK 3.0
Источник

Понравилась статья? Поделить с друзьями:
  • Как найти ставку амортизации
  • Как найти напечатанный документ в принтере
  • Дом егеря как найти
  • Как исправить ошибки dpkg
  • Как найти графа дракулу