Бизнес требование к информационной системе пример

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

Целью нашей разработки было создание с нуля учетной системы для одной из крупных российских компаний. Система была призвана заменить текущую, написанную в конце 90-х. В результате были реализованы платформа и один из бизнес-модулей. В реализованной части было порядка 120 объектов, 180 таблиц, около 30 печатных форм.

Хочу оговориться, что подход, описанный ниже, не универсален для написания любого ПО. Он подходит для систем уровня предприятия, которые строятся на основе объектно-ориентированного подхода: учетных, CRM-, ERP-систем, систем документооборота и т.п.

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

  • Общая часть
    • Список терминов и определений
    • Описание бизнес-ролей
  • Требования
    • Бизнес-требования

    • Общие сценарии
    • Сценарии использования
    • Алгоритмы и проверки

    • Системные требования
    • Нефункциональные требования
    • Требования к интеграции
    • Требования к пользовательскому интерфейсу

  • Реализация
  • Тестирование
  • Руководства
  • Управление

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

Бизнес-требования описывали то, что необходимо бизнес-пользователям. Например, им вовсе не нужен объект системы Пользователь, но зато им нужно иметь возможность поменять стоимость товара в счете и распечатать его. Бизнес-требования состояли из общих сценариев, сценариев использования (use cases) и описания алгоритмов обработки данных. Подробно о разработке подобного рода требований можно узнать из книги Карла И. Вигерса и Джоя Битти Разработка требований к программному обеспечению.

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

Нефункциональных требований в данной статье мы касаться не будем. Могу лишь отослать вас к отличной книге Architecting Enterprise Solutions авторов Paul Dyson, Andrew Longshaw.

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

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

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

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

Список терминов и определений

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

Поясню это на примере термина Пользователь. Википедия дает такое определение:

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

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

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

Термины связаны друг с другом. В термине Пользователь используется «операция», поэтому приведу и ее определение:

Операция — совокупность действий, составляющих содержание одного акта бизнес-деятельности. Операция должна соответствовать требованиям ACID (Atomicity, Consistency, Isolation, Durability). Совокупность операций одного модуля представляет интерфейс взаимодействия клиент-сервер этого модуля.

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

Работа над списком терминов происходила постоянно. Мы поддерживали его полноту, т.е. старались, чтобы в документации не было термина, который бы не был определен в этом списке. Кроме того, были случаи, когда мы меняли термины. Например, по прошествии нескольких месяцев с начала написания требований мы решили заменить Контрагент на Компания. Причина была проста: оказалось, что никто не в состоянии в речи, при разговоре, использовать слово «контрагент». А если так, то он должен был быть заменен на что-то более благозвучное.

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

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

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

Описание бизнес-ролей

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

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

Пара примеров:

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

Одной из важных концепций, которую мы применяли при разработке требований, было разделение их на уровни. Алистер Коберн в книге Современные методы описания функциональных требований к системам выделяет 5 уровней. Мы использовали 4 – три уровня бизнес-требований плюс системные требования:

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

  1. Общие сценарии (соответствует уровню очень белого у Коберна)
  2. Сценарии использования (соответствует голубому)
  3. Алгоритмы и проверки (скорее черный)

4. Системные требования (нет прямого аналога, скорее черный)

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

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

На картинке ниже представлена часть нашей иерархии (о содержании речь пойдет дальше).

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

Интересен вопрос, кому в проектной команде какой из уровней нужен. Будущие пользователи могут читать общие сценарии. Но уже сценарии использования для них сложны, поэтому аналитик обычно обсуждает сценарии с пользователями, но не отдает их им для самостоятельного изучения. Программистам обычно нужны алгоритмы, проверки и системные требования. Вы однозначно можете уважать программиста, который читает сценарии использования. Тестировщикам (как и аналитикам) нужны все уровни требований, поскольку им приходится проверять систему на всех уровнях.

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

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

Общие сценарии

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

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

Некоторые другие цели общих сценариев:

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

Вот пример одного из общих сценариев:

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

Ссылка «Задание на печать», указывающая на описание объекта в системных требованиях, лишняя, поскольку никому не требуется перепрыгнуть на него из общего сценария. А вот ссылка «пакетная печать документов на груз» важна – она ведет на сценарий использования, формально описывающий действия пользователя и системы.

Наши сценарии использования имели следующий формат:

  • Заголовок со следующими полями:
    • статус (В работе | Готов к рецензированию | Согласован)
    • пользователи (по описанию бизнес-ролей)
    • цель
    • предусловия
    • гарантированный исход
    • успешный исход
    • ссылка на описание пользовательского интерфейса (разработанного проектировщиком интерфейсов)
    • ссылка на сценарий тестирования (заполнялось тестировщиками)
  • Основной сценарий
  • Расширения сценария

Сценарии использования

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

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

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

Алгоритмы и проверки

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

Например, рассмотрим простой алгоритм ниже.

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

Системные требования

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

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

Описание каждого объекта располагалось на одной wiki-странице и состояло из следующих частей:

  • Определение объекта (копия из списка терминов)
  • Описание свойств объекта
  • Описание операций и прав
  • Данные
  • Дополнительная информация

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

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

Название
Названием свойства оперирует как пользователь (например, «я изменил номер счета», Номер – свойство объекта Счет), так и проектная команда. Повсеместно в документации использовались ссылки на свойства в виде простой нотации Объект.Свойство, очевидной для любого участника проекта.

Тип
Мы использовали Datetime, Date, Time, GUID, String, Enum, Int, Money, BLOB, Array(), Float, Timezone, TimeSpan. Тип имел отражение на всех уровнях приложения: на уровне БД, сервера приложения, в пользовательском интерфейсе в виде кода и графического представления. Каждому типу было дано определение, чтобы их реализация не вызывала вопросов у программистов. Например, было дано такое определение типу Money: содержит вещественное число с точностью до 4-го знака после запятой, число может быть отрицательным и положительным; одновременно со значением система хранит валюту; валюта по умолчанию — российский рубль.

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

Признак наличия нуля
Да или Нет в зависимости от того, может ли поле не содержать значения. Например, поле типа Bool должно содержать одно из возможных значений, а поле типа String обычно может быть пустым (NULL). Это ограничение реализовывалось на уровне БД и на сервере приложения.

Признак уникальности
Да или Нет в зависимости от того, является ли это поле уникальным. Часто уникальность определяется на группе полей, в этом случае у всех полей в группе стояло Да+. Это ограничение реализовывалось на уровне БД (индекс) и на сервере приложения.

Комментарий
Описание поля: что означает, для чего нужно, как используется. Если значение свойства вычисляемое, то это указывается явно с описанием алгоритма расчета этого значения.

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

  • Название свойства объекта в программном интерфейсе.
  • Название поля в БД.

Оба этих поля не обязательные, поскольку, например, свойство объекта может не храниться в БД, а быть вычисляемым, как сумма счета.

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

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

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

Вот типичное описание свойств нашего объекта.

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

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

В этом разделе были также таблицы, описывающие переход по статусам.

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

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

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

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

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

Постановка задач программистам

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

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

  • создать структуры в БД (таблица, ключи, индексы, триггеры и т.д.);
  • реализовать доменный объект;
  • реализовать создание начальных данных.

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

Типовая задача 2
Заголовок: Реализовать такую-то операцию такого-то объекта и права на нее
Текст задачи — ссылка на страницу с системными требованиями к объекту.
Программист находит на странице название операции и права, а по ссылке в колонке Комментарий – алгоритмы, проверки, сценарий использования.

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

Инструмент для написания и управления требованиями

Как, возможно, многие догадались, для работы с требованиями мы использовали Atlassian Confluence. Хочу кратко перечислить достоинства этого продукта.

  • Удаленная работа. Собственно, как и у любой wiki.
  • Ссылки. Как вы видели выше, ссылки для нас – один из основных инструментов для связывания отдельных частей требований.
  • Возможность дробить требования на части (каждая часть – на своей странице).
  • Оповещения при изменении. Это одно из важнейших средств совместной работы. Например, получив такое оповещение по одному из сценариев, руководитель разработки может ставить задачи разработчикам, а тестировщики знает, что надо скорректировать сценарии тестирования.
  • Комментарии. Многие страницы требований у нас обрастали развесистыми иерархиями комментариев. В Confluence работать с ними достаточно удобно, поскольку иерархия не плоская, а в виде дерева. Кроме того есть возможность использовать полноценный редактор, а не просто текст.
  • Наличие мощного текстового редактора. Не буду здесь подробно останавливаться, отмечу лишь, что на всем протяжении нашей работы Atlassian совершенствовал редактор, и если вначале было достаточно много глюков, то затем подавляющее большинство из них было исправлено.
  • Хранение истории, сравнение разных версий страниц, возможность отката на старую версию.
  • Просмотр иерархии страниц в виде дерева.

Однако было и несколько проблем:

  • Поскольку все требования используют одни и те же названия объектов и их свойств, то было бы очень удобно иметь инструмент, который при изменении названия менял его во всей документации. А при удалении – находил все, уже недействительные, ссылки на него.
  • Не было возможности сбора статистики. Например, каждое требование имело статус, но мы не могли автоматически собирать статусы всех требований и иметь динамическую картину процесса разработки требований. Но, кажется, на данный момент что-то подобное в Confluence уже появилось.
  • Диаграммы приходилось рисовать в другой системе, сохранять в PNG и уже картинку помещать на страницу Confluence. При этом еще надо было приложить исходник, чтобы через пару месяцев его можно было найти и поправить.
  • Я не нашел способа экспортировать иерархию страниц в MS Word. Экспорт в XML и PDF очень часто глючил (возможно, дело в размере иерархии).

В конце хочу выразить благодарность Вадиму Лободе и Артему Каратееву за ценные советы и тщательное рецензирование данной статьи.

Антон Стасевич

Источник

Шпаргалка бизнес-аналитика. Бизнес-требования

Print Friendly, PDF & Email

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

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

Источник материала: https://systems.education/biz-req и https://systems.education/biz-req-dev

Роль Бизнес-требований (БТ)

  1. Бизнес-требования определяют смысл проекта и обосновывают его необходимость
  2. Бизнес-требования – это удобный инструмент договоренности: они объективны, компактны и понятны стейкхолдерам
  3. Из бизнес-требований вытекают критерии приемки проекта
  4. Бизнес-требования используются для определения рамок проекта
  5. Бизнес-требования помогают принимать решения о приоритетах
  6. В Scrum бизнес-требования являются (во всяком случае, так должно быть) основным инструментом владельца продукта для управления продуктовым бэклогом и для согласования его с другими стейкхолдерами

Требования в бизнес-анализе

Версия 3 BABOK Guide определяет требования таким образом:

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

Для формулирования требования потребность нужно поместить в какой-то контекст. Например потребность «Люди испытывают ежедневную потребность в пище» слишком общая. Если ее поместить в контекст морского путешествия, то требование становится уже более осмысленным: «Продукты питания, используемые в рационе моряков, должны сохранять пригодность для употребления в пищу в течение, как минимум, 30 дней при температуре до +30оС и высокой влажности, поскольку моряки длительное время вынуждены обходиться без поставок продовольствия».

Способы выполнения требования могут быть разными и они называются решениями.

Потребности, требования, решения, контекст

Потребности, требования, решения, контекст

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

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

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

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

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

Пример определения бизнес-требования на основе анализа потребности

Потребность — «Торговой компании необходимо постоянно иметь в наличии или оперативно получать нужные товары в нужном количестве.»

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

Для поддержания нужных товарных запасов на складах компании, их необходимо регулярно (BR-INV-01) пополнять через формирование заказов поставщикам.

Размер поддерживаемого запаса каждого товара должен определяться, исходя из оптимизации затрат и минимизации рисков упущенной прибыли (BR-INV-02).»

В тексте этого требования есть две ссылки: BR-INV-01 и BR-INV-02. Здесь BR означает «бизнес-правило» (Business Rule), а INV — Inventory (запас). Это ссылки на бизнес-правила, определяющие то, с какой именно регулярностью нужно пополнять запасы, и каков алгоритм расчета оптимального товарного запаса.

Бизнес-правило — один из типичных артефактов, сопровождающих бизнес-требования.

Артефакты бизнес-анализа, сопровождающие бизнес-требования

По мере определения бизнес-требований появляются:

  1. Доменные модели — высокоуровневые информационные модели предметной области.
  2. Глоссарий предметной области.
  3. Модели состояния объектов управления: на этом этапе мы определяем, какими объектами мы хотим управлять, и какие состояния нас интересуют (или какие состояния мы хотим отслеживать).
  4. Метрики и показатели этой деятельности, которые говорят нам о том, что важно для бизнеса и как мы оцениваем то, насколько хорошо или плохо, лучше или хуже выполняется его деятельность.
  5. Бизнес-правила: описания применяемых в данной компании алгоритмов, нормативов, ограничений, проверок, и политик.

 Немного слов про бизнес-правила

Как правильно описывать бизнес-правила?

  1. Бизнес-правило должно быть сформулировано на языке бизнеса. В описании бизнес-правил не должны использоваться технические термины. Язык написания бизнес-правил должен быть понятным представителю бизнеса, не являющимся IT-специалистом. После описания бизнес-правил, постарайтесь абстрагироваться от своих технических знаний, поставьте себя на место представителя бизнеса, руководителя компании, для который вы разрабатываете продукт. Понятен ли вам написанный документ? Не содержит ли документ технических терминов, указания систем и языков программирования?
  2. Бизнес-правило должно описывать правило бизнеса, а не работу системы. Описание бизнес-правил должно содержать те требования бизнеса, которые должна решить система, но без описания работы системы. Например, у бизнеса есть правило: «Отслеживать время прихода и ухода сотрудников на рабочее место». Бизнес-правило не должно содержать описания, как достичь соблюдения данного правила: будет ли сотрудник записываться в журнал прихода и ухода, или на входе будет стоять автоматическая пропускная система, которая будет фиксировать время.
  3. Бизнес-правило должно описывать ограничения: какие операции не могут быть выполнены. Ограничительные бизнес-правила могут определять ограничения пользователей. Например: “В полис ОСАГО страховщик может вписать не более 5-ти водителей”; «Оформить заказ-онлайн может только клиент компании».
  4. Бизнес-правило подчиняется бизнесу: принять, изменить, отменить. Представители бизнеса могут изменять бизнес-правила, вносить поправки или отменять.

Рассмотрим несколько примеров бизнес-правил и требований к системе

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

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

Пользователь, должен иметь возможность оформить заказ.

Заказ может быть оформлен:

с доставкой по указанному адресу;

с оплатой наличными при получении;

с оплатой банковской картой при получении.

Требования стейкхолдеров

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

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

Как специалисту, отвечающему за поддержание запасов, мне нужно иметь возможность:

  1. Автоматически рассчитывать заказ по каждому товару с использованием определенного алгоритма (здесь прозвучит то же самое бизнес-правило, которое упоминалось в бизнес-требовании). Почему автоматически? Потому что мне надо на 4 складах поддерживать 3000 товарных позиций, поступающих от 100 поставщиков — это невозможно или крайне сложно обрабатывать вручную.
  2. По любой позиции автоматически рассчитанного заказа видеть то, как именно была посчитано это значение и почему оно именно такое — алгоритм может не учитывает какие-то известные мне нюансы. Например, ожидаемое значительное повышение или снижение продаж.
  3. Менять количество в автоматически рассчитанном заказе — в конечном счете за заказ отвечаю я, а не система. Система не может учесть всё, и если я считаю нужным поменять заказанное количество, у меня должна быть возможность это сделать.
  4. Смотреть для проверки не на все 3000 позиций, а только на те, где расчеты системы могут быть вызвать сомнения. Например, недостаточная история продаж, высокая волатильность продаж или другие подобные факторы.

Примерно так будет рассказывать нам живой человек. «Пользовательская история» (User Story) — естественная форма представления требований стейкхолдеров, имеющая формат <роль> <задача> <нужная возможность>.

Например:

Как специалисту, отвечающему за поддержание запасов, для формирования заказов поставщикам мне нужно:

  1. Автоматически рассчитывать заказ по каждому товару с использованием BR-INV-02;
  2. по любой позиции заказа иметь возможность посмотреть детали расчета и
  3. вручную изменить заказываемое количество,
  4. видеть отдельно те позиции заказа, по которым, возможно, требуется моя корректировка (BR-INV-03)

Обычно требованиям стейкхолдеров сопутствуют дополнительные артефакты:

  • Карты стейкхолдеров (показывают, кто участвует в процессах)
  • Модели и другие описания процессов
  • Варианты использования (Use Cases)
  • Образцы данных, с которыми работают стейкхолдеры (помогают понять ситуацию и потребности стейкхолдеров)

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

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

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

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

модель выявления требований

Почему бизнес-требования так важны

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

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

Из БТ вытекают критерии приемки и именно на их основе производится оценка результатов разработки ИТ-решения.

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

Кроме того, бизнес-требования в Agile — это ключевой инструмент Product Owner для управления бэклогом продукта и ведения переговоров со стейкхолдерами.

Какие бывают бизнес-требования?

Согласно концепции Six Sigma, бизнес-требования — это критичные активности предприятия, подлежащие выполнению для достижения целей организации, вне зависимости от конкретного решения.

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

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

Ниже приведены примеры бизнес-требований по видам критичных активностей.

Вид БТ: Значимые характеристики продуктов или услуг

Примеры БТ:

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

Вид БТ: Распознавание и обработка событий

Примеры БТ:

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

Вид БТ: Принятие решений

Примеры БТ:

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

Вид БТ: Сбор, обработка, хранение и предоставление информации

Примеры БТ:

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

Вид БТ: Обеспечение возможности выполнения действий

Примеры БТ:

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

Вид БТ: Предотвращение возможности выполнения действий

Пример БТ:

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

 Проблемы в бизнес-требованиях

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

  • Неконкретность (слишком абстрактная формулировка)
  • Невозможность проверки (нет понимания, что является индикатором выполнения требования)
  • «Магические» числа (приведены какие-то необоснованные данные: «время обработки заявки 14 минут»)
  • Непонятная польза (не написано, для чего делаем то, что делаем; действительно ли это необходимо)
  • Избыточная детализация (зачастую делает требование слишком жестким и нечитаемым)
  • Невыполнимость (например, требование «обеспечить 100%-ую достоверность данных». Для чего это требование? Почему возникают недостоверности? С этой проблемой можно как-то бороться или это просто факт?)
  • Несогласованность (противоречивость; с одной стороны Покупатель хочет найти продукт с наилучшими качествами по наименьшей цене, а с другой — Продавец хочет стимулировать покупку продуктов, приносящих наибольшую прибыль)
  • Нерелевантность (приведено требование, которое вообще не понятно, какое отношение имеет к данному проекту)
  • Привязка к конкретному решению, в том числе — конкретный бизнес-процесс

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

Обеспечить высокое качество обслуживания — Как проверить, что качество обслуживания высокое?

  1. Сократить среднее время обработки заказа до 14 минут — Почему до 14 минут, чем это обосновано? А почему не до 1 минуты? Какую пользу принесет сокращение времени обработки заказа?
  2. Обеспечить 100% достоверность учетных данных — Как мы узнаем какая достоверность? Как можно определить, что данные достоверны? В результате чего возникает недостоверность? С этим реально можно что-то сделать? Выполнимо ли данное требование?
  3. Гарантировать правильность принимаемых решений — Что выступает гарантом? Это выполнимо?
  4. Внедрить ERP — Кому и зачем это нужно? В чем проблема?

Типовые ловушки аналитика

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

  • Формальность — «пишу, потому что надо здесь что-то написать».
  • Узкие рамки анализа — не рассматриваем ничего, что выходит за рамки проекта.
  • Превращение в аудит — выясняем все обо всем «на всякий случай».
  • Превращение метода в цель — строгое следование определенному шаблону с превращением средств в цель и потерей основной цели проекта.

Что можно сделать с каждой из этих ловушек?

Ловушка Описание Решение
Формальность «Пишу, потому что надо здесь что-то написать» Ставить себя на место читателя (необходимо понимать, что и для кого мы пишем).
Узкие рамки анализа Фокусировка только на том, что относится к проекту, т.е. не рассматриваем ничего, что выходит за рамки проекта Анализировать область шире, чем те рамки, которые хотим установить для проекта.
Превращение в аудит «На всякий случай» выясняем все обо всем Постоянно спрашивать себя: «как это связано с проектом?»
Превращение метода в цель Строгое следование определенному шаблону с превращением средств (канва бизнеса, бизнес-процессы, стейкхолдеры) в цель и потерей основной цели проекта Задать себе вопрос: «можно ли обойтись без э

Документирование бизнес-требований

В практике бизнес-аналитика присутствует два основных подхода документирования требований:
1. Монолитно

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

2. Дробно

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

Шаблон монолитного описания БТ

Карл Вигерс в своей книге «Разработка требований к программному обеспечению. Руководство» предлагает хороший шаблон описания БТ монолитом в рамках документа Scope and Vision (рамки и видение). В этом документе выделяется раздел Бизнес-требования, который включает в себя:

  • Контекст.
  • Описание возможности.
  • Бизнес-цели.
  • Метрики успешности.
  • Образ результата (Vision).
  • Деловые риски.
  • Предположения и зависимости бизнеса.

Советы Вигерса по описанию БТ

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

Шаблон дробного описания БТ

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

  • Уникальный идентификатор.
  • Краткое описание.

2. Определение, развернутое объяснение, что из себя представляет БТ.
3. Источник, откуда это требование взялось.
4. Зависимости, если они есть между другими требованиями.
5. Обоснование, краткое пояснение мотивации.
6. Комментарий, любые пояснения. В приведенном ниже примере представлено описание диаграммы состояний.

Источник

ГЕОРГИЙ САВЕЛЬЕВ

Как разработать
Бизнес-требования

Модель выявления требований

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

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

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

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

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

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

Модель выявления требований

Почему важно выявлять и документировать
бизнес-требования?

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

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

Из БТ вытекают критерии приемки и именно на их основе производится оценка результатов разработки ИТ-решения.

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

Кроме того, бизнес-требования в Agile — это ключевой инструмент Product Owner для управления бэклогом продукта и ведения переговоров со стейкхолдерами.

Программа переподготовки

«Business Analyst Bootcamp»

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

Какие бывают бизнес-требования?

Согласно концепции Six Sigma, бизнес-требования — это критичные активности предприятия, подлежащие выполнению для достижения целей организации, вне зависимости от конкретного решения.

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

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

      Ниже приведены примеры бизнес-требований по видам критичных активностей.

      Вид БТ: Значимые характеристики продуктов или услуг

      Примеры БТ:

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

      Вид БТ: Распознавание и обработка событий

      Примеры БТ:

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

      Вид БТ: Принятие решений

      Примеры БТ:

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

      Вид БТ: Сбор, обработка, хранение и предоставление информации

      Примеры БТ:

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

      Вид БТ: Обеспечение возможности выполнения действий

      Примеры БТ:

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

      Вид БТ: Предотвращение возможности выполнения действий

      Пример БТ:

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

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

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

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

      Признаки проблем в бизнес-требованих

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

      • Неконкретность (слишком абстрактная формулировка)
      • Невозможность проверки (нет понимания, что является индикатором выполнения требования)
      • «Магические» числа (приведены какие-то необоснованные данные: «время обработки заявки 14 минут»)
      • Непонятная польза (не написано, для чего делаем то, что делаем; действительно ли это необходимо)
      • Избыточная детализация (зачастую делает требование слишком жестким и нечитаемым)
      • Невыполнимость (например, требование «обеспечить 100%-ую достоверность данных». Для чего это требование? Почему возникают недостоверности? С этой проблемой можно как-то бороться или это просто факт?)
      • Несогласованность (противоречивость; с одной стороны Покупатель хочет найти продукт с наилучшими качествами по наименьшей цене, а с другой — Продавец хочет стимулировать покупку продуктов, приносящих наибольшую прибыль)
      • Нерелевантность (приведено требование, которое вообще не понятно, какое отношение имеет к данному проекту)
      • Привязка к конкретному решению, в том числе — конкретный бизнес-процесс

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

      Работа с «магическими» числами

      Чтобы проверить требование на наличие данной проблемы, можно определить чувствительность (столбец «чуть-чуть» в таблице) требования и его границы (столбец «гораздо» в таблице).

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

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

      Любое число (разместим его в центральном круге) проверяется на чувствительность (на рисунке это столбец «чуть-чуть»). Что будет, если число будет немного больше? Есть ли какие-то последствия в таком случае для системы, стейкхолдеров? А если число будет чуть-чуть меньше?

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

      Расмотрим пример требования, которое содержит «магическое» число:

      “

      Требование: Сократить среднее время обработки заявки до 14 минут

      Проверим это требование на чувствительность. Для этого зададим вопросы:

      1. Что будет, если время обработки заявки будет не 14, а 12 минут?
      2. Что, если увеличить до 14,5 мин? Насколько это критично?

      В процессе проверки может выясниться, что обработка заявки может занимать даже 30 минут, не принося никакого ущерба бизнесу.

      Проверим границы требования, ответив на вопросы:

      1. Может быть, целесообразно сократить время обработки до 0 минут, т. е. не обрабатывать заявки и перевести клиента на самообслуживание?
      2. Что будет, если одна заявка будет обрабатываться день? Это плохо? Как это скажется на бизнесе?

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

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

      Попробуем переформулировать требование на примере:

      “

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

      Новое требование:
      Задержка в оповещении не должна приводить к задержке выполнения определенного действия получателем этого сообщения.

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

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

      1. Обеспечить высокое качество обслуживания — Как проверить, что качество обслуживания высокое?
      2. Сократить среднее время обработки заказа до 14 минут — Почему до 14 минут, чем это обосновано? А почему не до 1 минуты? Какую пользу принесет сокращение времени обработки заказа?
      3. Обеспечить 100% достоверность учетных данных — Как мы узнаем какая достоверность? Как можно определить, что данные достоверны? В результате чего возникает недостоверность? С этим реально можно что-то сделать? Выполнимо ли данное требование?
      4. Гарантировать правильность принимаемых решений — Что выступает гарантом? Это выполнимо?
      5. Внедрить ERP — Кому и зачем это нужно? В чем проблема?

        Типовые ловушки аналитика

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

        • Формальность — «пишу, потому что надо здесь что-то написать».
        • Узкие рамки анализа — не рассматриваем ничего, что выходит за рамки проекта.
        • Превращение в аудит — выясняем все обо всем «на всякий случай».
        • Превращение метода в цель — строгое следование определенному шаблону с превращением средств в цель и потерей основной цели проекта.

        Что можно сделать с каждой из этих ловушек?

        Как документируются бизнес-требования?

        В практике бизнес-аналитика присутствует два основных подхода документирования требований:

        1. Монолитно

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

        2. Дробно

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

        Ниже будет приведен шаблон для каждого из этих видов документирования.

        Где документируются бизнес-требования?

        Стандартом ISO предполагается, что бизнес требования будут отражены монолитно в Спецификации требований стейкхолдеров (StRS). Для этого предусмотрен отдельный раздел Introduction, который включает в себя Business Purpose (цели), Business Scope (границы), Business Overview (обзор бизнеса).

        В ГОСТе 34.602−89 предполагается, что бизнес-требования будут описаны также, монолитом, в техническом задании на создание автоматизированной системы. в разделе Назначение и цели создания системы и Характеристика объектов автоматизации.

        Если говорить о дробном документировании, то чаще всего это подходы, подразумевающие использование Спецификации бизнес-требований (BRD).

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

        Шаблон монолитного описания БТ

        Карл Вигерс в своей книге «Разработка требований к программному обеспечению. Руководство» предлагает хороший шаблон описания БТ монолитом в рамках документа Scope and Vision (рамки и видение). В этом документе выделяется раздел Бизнес-требования, который включает в себя:

        • Контекст.
        • Описание возможности.
        • Бизнес-цели.
        • Метрики успешности.
        • Образ результата (Vision).
        • Деловые риски.
        • Предположения и зависимости бизнеса.

        Советы Вигерса по описанию БТ

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

          Шаблон дробного описания БТ

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

          • Уникальный идентификатор.
          • Краткое описание.

          2. Определение, развернутое объяснение, что из себя представляет БТ.
          3. Источник, откуда это требование взялось.
          4. Зависимости, если они есть между другими требованиями.
          5. Обоснование, краткое пояснение мотивации.
          6. Комментарий, любые пояснения. В приведенном ниже примере представлено описание диаграммы состояний.

            Шаблон дробного описания БТ

            Как документировать —
            объединять или дробить?

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

            1. Нет нужды документировать, если:

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

            2. Объединяем, если:

            • Компактный проект с узкими целями.
            • Узкая предметная область.
            • Бизнес-требования умещаются на паре страниц.

            3. Дробим, если:

            • Много бизнес-требований.
            • Сложные бизнес-требования.
            • Могут реализовываться по отдельности.
            • Высокая степень неопределенности.

            Что делать с отсутствующими или плохими БТ?

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

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

            Полученную информацию необходимо задокументировать одним из нескольких способов:
            1. Создать отдельный документ. Например, «Каталог целей» с дробным документированием бизнес-требований, на которые будем ссылаться.

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

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

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

            Программа переподготовки

            «Business Analyst Bootcamp»

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

            • Что делать, если, помимо ТЗ, есть еще и пользовательские требования?

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

            • Вопрос:

              Имеет ли смысл создание промежуточных документов таких как VSD (Vsion & ScopeDocument) и BRD (Business Requirement Document)?

              С точки зрения Agile практик, бизнес-требования — это епархия Product Owner. Следовательно, работать нужно так, как удобно, и не создавать лишних документов для соблюдения формального протокола. Чем документов меньше, чем они компактнее и проще, тем эффективнее.

            • Должны ли в описание БТ быть включены требования к описанию «хотелок» в части User Interface?

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

            • Обязательно ли современному аналитику владеть навыками программирования?

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

            • Должен ли аналитик просматривать баги проекта и принимать решения о их важности?

              Иногда аналитик должен просматривать баги, а иногда — нет. Зависит от договоренностей в рамках проекта и распределения ролей в команде.

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

            • Должен ли аналитик проводить тестирование и валидацию продукта?

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

            • Что является объектом требований вида «Должна собираться информация о недоступности банкомата» — к чему это бизнес требование? К организации? Подразделению? К бизнес-процессу?

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

            • Что делать с функциями, если они не мапятся на конкретное БТ или мапятся сразу на два (при этом функция должна быть в скоупе)?

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

            Георгий Савельев

            Эксперт по бизнес-анализу, член Международного института бизнес-анализа (IIBA), первый CBAP в России. Соавтор BABOK v.3. Вице-президент IIBA Russian Chapter.

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

            Участвовал в реализации более 50 проектов по разработке, внедрению и совершенствованию программного обеспечения.

            С 1990 года занимается проведением тренингов и деловых игр для руководителей и специалистов. Автор статей по бизнес-анализу.

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

            Участник профессиональных ассоциаций IASA, ABPMP Russian Chapter.

            Подписаться на новые статьи

            Источник

            Фундаментальное описание требований к ПО и подходов к их выявлению и сбору от тестировщика 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
            Источник

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

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

            Что такое бизнес-требования

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

            Что входит в бизнес-требования

            • Данные компании. Область бизнеса, продукт, портрет покупателя, конкурентные преимущества.
            • Целевая аудитория. Местоположение, пол, возраст, хобби потенциальных посетителей магазина. Важно осознавать, зачем люди посещают магазин. К примеру, приобрести продукт, узнать стоимость услуги или ознакомиться с новостями.
            • Анализ конкурентов
            • Цель запуска проекта. Выйти на новый рынок. Стать монополистом в нише. Перевести бизнес в онлайн.
            • Конкретизированная цель. Например, система должна обеспечить доставку в Израиль. Увеличить товарооборот (в цифрах) . Ускорить обработку заказов через автоматизацию работы менеджеров.
            • Планируемые метрики. Увеличить трафик вдвое за первый год запуска проекта. Увеличить коэффициент конверсии трафика с 0,8% до 1,1%. Втрое увеличить количество вендоров. Поднять прямые онлайн-продажи без похода в магазин на 30% за полгода.
            • Пользовательские требования, то есть какую задачу должен решить пользователь на сайте. Купить шампунь, если речь идет о покупателе на сайте. Организовать доставку в другую страну, если пользователь — другая компания. Увеличить заработок для вендора. Иметь доступ только к заказам для менеджера по продажам и так далее.

            Как бизнес-требования влияют на итоговый продукт?

            Часто бизнес-требования влияют на способ реализации продукта. Рассмотрим несколько примеров.

            • Требование А. Чтобы привлечь вендоров, владелец маркетплейса может предложить продавцам продолжать работать в собственных системах, интегрировав эти системы в маркетплейс. Вендорам не придется изучать интерфейс новой для себя системы, а владелец будет иметь все необходимые данные на своей платформе. Таким образом, способом реализации продукта станет интеграция с сервисами вендора по API.
            • Требование Б. По условию франшизы за определённой территорией может быть закреплен только один продавец / территориальный представитель, который будет работать с заказами покупателей из данного региона. Продажа товаров на данной территории другими представителями бренда запрещена по условиям договора. Способ реализации: определение геолокации покупателя, сортировка товаров и отображение актуальных остатков для конкретной локации, привязка покупателя к продавцу для дальнейших заказов.
            • Требование В. Владелец сайта-каталога (где можно просматривать товары, но нельзя покупать их) хочет создать интернет-магазин без перехода на новую платформу. В связи с этим, требуется внедрить функционал оформления заказа из платформы CS-Cart таким образом, чтобы для покупателя это выглядело «бесшовно», как будто он и не покидал существующий сайт. Способ реализации: интеграция технологии единого входа — SSO — при которой пользователь переходит из одной системы в другую без повторной аутентификации.

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

            Четкое формулирование бизнес-требований:

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

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

            • Опишите ваш продукт / услугу. Что будет являться товаром? Какие его характеристики? Как будет считаться его стоимость?
            • Роли пользователей (администратор, продавец покупатель) и какие действия может выполнять каждый из них? Есть ли какие-либо зависимости / ограничения?
            • CJM (путь покупателя по сайту) : какими будут действия покупателя по приобретению вашего продукта? Какие соответствующие действия должен будет выполнять продавец / администратор?
            • Регистрация пользователей: какие данные должны предоставить пользователи для регистрации?
            • Как будет выглядеть личный кабинет (профиль) покупателя для пользования услугой? Какие действия он сможет выполнять?
            • Понадобится ли интеграция со сторонними системами? Какими?

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

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

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

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

            Нефункциональные требования. Важные особенности

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

            Нефункциональных требований очень много. Вот некоторые из них.

            • Дизайн, UX/UI. Добавить дополнительную кнопку на чекауте. При переходе на страницу продукта пользователь видит все вариации продукта.
            • Требования к коду: cделать модификацию на JS, работа в репозитории клиента, использовать указанные заказчиком библиотеки при реализации модификации.
            • Настройка процессов непрерывной доставки и улучшения кода. CI и CD процессы призваны автоматизировать проверку и доставку разработанного ПО заинтересованным лицам.
            • Адаптация готовых решений. Вы можете выбрать готовые модули на маркетплейсе и с его помощью быстро закрыть какое-то функциональное требование, например, с помощью модуля Google Analytics Enhanced Ecommerce следить за событиями покупки на сайте прямо в админке платформы. Но бывают случаи, когда модули приходится дорабатывать под нужды конкретного проекта.
            • Контент. На продуктовые страницы добавить ссылки на юридические документы. Такое требование часто озвучивают владельцы немецких маркетплейсов.
            • Производительность сайта. Магазин должен выдерживать нагрузку в 1000 посетителей онлайн одновременно.

            Кто собирает требования?

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

            ✔ Стороннее агентство, нанятое заказчиком

            ✔ Штатный аналитик заказчика

            ✔ Наша команда в рамках услуги “Проектирование”

            Как происходит сбор требований?

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

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

            Кто участвует в сборе требований?

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

            • Вендоры и отдел привлечения вендоров (для маркетплейсов)
            • Бухгалтерия (чтобы понимать, какие отчеты нужны, как проводить платежи)
            • Юридический отдел (если есть юридические ограничения, которые нужно учесть при создании интернет-магазина) .
            • Маркетинг (для реализации механики промо акций)
            • IT-отдел (при наличии, поскольку ему придется поддерживать готовую систему после сдачи работ)
            • Специалисты по безопасности
            • Сторонние эксперты

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

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

            • Примеры конкурентов и реализации желаемого функционала
            • Блок-схема с описанием бизнес-процессов, функциональности
            • CJM-карта
            • Архитектурная диаграмма
            • Документ с описанием проекта (общее описание того, что будет представлено на панелях администратора, вендора и пользователя)
            • Дизайн-макеты
            • План развития проекта, например, нагрузка на сайт, способы монетизации проекта, планы по ROI и т. п.
            • Список ролей участников проекта и схема принятия решения
            • User-cases (описание сценариев работы при определенной ситуации, например, что происходит при регистрации пользователя) .

            Какие ошибки допускают заказчики в ходе сбора информации?

            • Выбор изначально неподходящего стороннего сервиса. Так происходит, когда заказчик не оговаривает цель, а просит подключить сервис на свой выбор. После интеграции сервиса, оказывается, что отсутствует дополнительный функционал, необходимый магазину. Опыт разработчика может помочь при выборе оптимального решения для интеграции, отвечающего процессам и целям магазина.
            • Выбор неподходящей платформы. Клиент сам выбирает вариант платформы без понимания ее особенностей. Например, бизнес ведется по модели маркетплейса (Multi-Vendor) , но клиент покупает лицензию однопользовательского интернет-магазина (CS-Cart) . До покупки лицензии лучше обратиться к исполнителю и дать описание бизнес-модели и бизнес-процессов компании. Так, исполнитель сможет подсказать, какой вариант платформы подходит лучше всего.
            • Неверно сформированный запрос. Например, заказчик просит исправить код для улучшения показателей SEO, но на самом деле проблема не в коде, а в сервере, который плохо выдерживает нагрузку. Здесь помогло бы четкое описание проблемы и желаемого результата. Исполнитель сможет подобрать комплексное решение, помогающее оптимально достичь цели.

            Насколько детализированными должны быть требования?

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

            • Пример 1. Форма для регистрации интуитивно понятна.

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

            • Пример 2. Магазин не должен тормозить.

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

            Рекомендации заказчику, пишущему требования

            Желательно, чтобы заказчик, формирующий требования, писал максимально просто с четким наименование объектов (покупатель, вендор, администратор сайта) и результата. Лучше всего, в формате пользовательских сценариев. При этом, функциональные требования будут выглядеть как совокупность функций, объединенных по смыслу. Например, кейс «Зарегистрировать визит пациента в зубной кабинет» будет состоять из совокупности функций:

            • Просмотр истории визитов;
            • Добавление еще одного визита;
            • Выбор посещения зубного кабинета;
            • Просмотр деталей визита (число, время, кабинет, лечащий врач) ;
            • Редактирование информации о визите;
            • Удаление визита.

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

            • Анкетирование. Сюда можно отнести “Бриф на разработку сайта”. Это анкета со списком основных требований к сайту.
            • Интервью. Такой способ используется в основном для получения уточнений по конкретному вопросу или требованию.
            • Мозговой штурм. Участники генерируют множество идей и вариантов решений, развивая.
            • Запустить голосование
            • Привлечь эксперта

            Выводы

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

            Сбор и анализ требований

            Первые 90% работы отнимают
            10% времени, а последние 10%
            — оставшиеся 90% времени.
            Правило 90/90

            Все требования к проектируемой системе предлагается размещать на нескольких иерархических уровнях. На самом нижнем уровне располагаются требования, которые одинаково подходят для автоматизации технологических процессов в целом без учета особенностей конкретной прикладной области. Здесь необходимо обратиться к ГОСТам и другим нормативным документам. Далее следует уровень требований к автоматизированной системе определенного (заданного) класса с учетом соответствующих нормативных документов, определяющих порядок и описание заданного технологического процесса. И наконец, третий уровень составляют требования к конкретной системе. Кроме того, в стандарте IEEE 830-1993 Спецификация требований к ПО (Software Requirements Specification – SRS) проведено деление всех требований на две группы. Первая группа документирует потребности заказчика и записывается на языке, понятном заказчику – это т.н. С-требования. Вторая группа документирует требования в специальной, структурированной форме. Этот документ называют требованиями разработчика, или D-требованиями.

            В ГОСТ 24.103-84 «Автоматизированные системы управления. Основные положения» перечислены общесистемные принципы, которые необходимо соблюдать при создании АСОИУ:

            1. системность – заключается в том, что при создании, функционировании и развитии АСУ должны быть установлены и сохранены связи между структурными элементами, обеспечивающие ее целостность;
            2. развитие – заключается в том, что АСУ должна создаваться с учетом возможности пополнения и обновления функций и видов ее обеспечения путем доработки программных и (или) технических средств или настройкой имеющихся средств;
            3. совместимость – заключается в обеспечении способности взаимодействия АСУ различных видов и уровней в процессе их совместного функционирования;
            4. стандартизация и унификация – заключается в рациональном применении типовых, унифицированных и стандартизованных элементов при создании и развитии АСУ;
            5. эффективность – заключается в достижении рационального соотношения между затратами на создание АСУ и целевыми эффектами, получаемыми при ее функционировании.

            Кроме того, в п.3.4. ГОСТ 24.103-84 при создании АСУ рекомендуется максимально использовать типовые проектные решения, пакеты прикладных программ, унифицированные пакеты а также применять для новых объектов управления ранее созданные проекты АСУ. Это положение полностью соответствует принципам инженерии ПО, в особенности, концепции повторного использования компонентов.
            ГОСТ 24.104-85 «Автоматизированные системы управления. Общие требования» устанавливает требования к каждому виду обеспечения отдельно. Перечислим те из них, на которые нужно обратить внимание.

            Требования к программному обеспечению:

            1. В АСУ должны быть преимущественно использованы системы управления базами данных (СУБД), зарегистрированные в установленном порядке.
            2. Программное обеспечения АСУ должно иметь средства диагностики технических средств АСУ и контроля на достоверность входной информации.
            3. В программном обеспечении АСУ должны быть реализованы меры по защите от ошибок при вводе и обработке информации, обеспечивающие заданное качество выполнения функций АСУ.

            Требования к информационному обеспечения АСУ

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

            Требования безопасности

            1. Неправильные действия персонала АСУ не должны приводить к аварийной ситуации.

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

            Кроме сбора требований особое значение имеет процесс управления требованиями. В технологии Rational Unified Process определяются пять уровней зрелости процесса управления требованиями:

            1. требования записаны в согласованном формате;
            2. требования организованы, используются стандартные форматы и метаданные о требованиях, поддерживается контроль версий;
            3. требования структурированы в соответствии со своими типами (функциональными и нефункциональными);
            4. требования отслеживаются в соответствии с их типом;
            5. требования интегрируются с процессами управления изменениями, моделирования, кодирования и т.д.

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

            Хорошую спецификацию отличают следующие элементы:

            1. Акцент на деталях и их четкое определение.
            2. Забота о недопущении неверного толкования.
            3. Непротиворечивость внутри данной спецификации и другими спеками.
            4. Логическая взаимосвязь компонентов.
            5. Полнота охвата предмета.
            6. Соответствие нормативным актам.
            7. Соответствие деловой практике.

            С-Требования

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

            Перед проведением интервью:

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

            Во время интервью:

            • задокументировать требования;
            • составить эскиз графического интерфейса;
            • спланировать следующую встречу.

            После интервью:

            • составить черновик С-требований SRS с использованием CASE-инструментов;
            • определить конфигурацию оборудования;
            • передать черновик С-требований заказчику для получения его замечаний.

            Рисунок – Порядок составления С-требований
            Порядок составления С-требований

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

            • Методология SADT;
            • Диаграммы вариантов использования (use case) UML.
            • Диаграммы последовательности (sequence diagram) UML.
            • Диаграммы состояний (statechart diagram) UML.
            • Прототипирование дизайна пользовательского интерфейса входит в фазу проектирования программного обеспечения, однако его также можно считать и частью фазы формирования требований.

            Порядок анализа требований заказчика включает следующие шаги:
            1. Если требование простое и не имеет связей с другими требованиями, его выражают четкими предложениями в соответствующем разделе SRS.
            2. Если требование представляет собой взаимодействие пользователя и приложения, то его, как правило, выражают с помощью варианта использования. Для этого:
            2.1. Задают имена вариантам использования;
            2.2. Определяют действующие лица;
            2.3. Записывают последовательность действий пользователя и приложения;
            2.4. Минимизируют ветвление.
            3. Если требование затрагивает элементы обработки, каждый из которых получает и выдает данные, используют диаграмму потоков данных (DFD). При этом:
            3.1. Определяют элементы обработки (обычно высокого уровня);
            3.2. Определяют хранилища данных;
            3.3. Показывают пути передачи данных между обрабатывающими элементами. Указывают типы данных, передаваемых в каждом случае.
            4. Если требование затрагивает состояния, в которых может находиться программа (или части программы), строят диаграмму состояний в следующей последовательности:
            4.1. Определяют состояния (каждое состояние обычно определяют отглагольным существительным, например «Ожидание»);
            4.2. Указывают исходное и конечное состояние.
            4.3. Определяют события, происходящие вне рассматриваемой части системы, и приводящие к переходу между состояниями;
            4.4. Определяют вложенные состояния.

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

            D-Требования

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

            Рисунок – Порядок получения D-требований
            Порядок получения D-требований

            Существуют несколько типов D-требований:
            1. Функциональные требования – определяют работу, которую должно выполнять проектируемая система (например, «приложение будет вычислять стоимость портфеля акций пользователя»).
            2. Нефункциональные требования.
            2.1. Производительность. Требования к производительности определяют временные ограничения, которые должны быть выполнены в программе. Заказчики и разработчики обсуждают ограничения по времени вычислений, использованию оперативной памяти, объему запоминающих устройств и т. д.
            2.2. Надежность и безопасность. Требования надежности определяют надежность в измеряемых величинах. Требования такого типа предполагают вероятность неидеальной работы программы и ограничивают область ее несовершенства. Особое внимание в ПЗ необходимо уделить вопросам обеспечения безопасности системы с учетом возможности искажения данных посредством несанкционированного доступа, сбоя системного или прикладного ПО.
            2.3. Обработка ошибок. Эта категория требований объясняет, как программа должна реагировать на возникающие ошибки. Например, что должна делать программа, если она получает сообщение из другой программы в неразрешенном формате? Это не касается ошибок, генерируемых самой программой.
            2.4. Интерфейсные требования. Интерфейсные требования описывают формат, в котором программа общается с окружением.
            2.5. Ограничения. Ограничения на проектирование или реализацию описывают границы или условия того, как приложение должно быть задумано и разработано. Например, накладываются ограничения на инструменты и языки программирования ввиду сложившихся традиций организации, опыта программистов, совместимости и проч.
            3. Обратные требования – это функционал, который система не обеспечивает.

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

            1. Процесс начинается с перечисления классов, упомянутых в вариантах использования – это т.н. классы анализа.
            2. Полученный набор классов обычно неполон и следует попытаться найти остальные классы предметной области.
            3. Для каждого из полученных классов выписывается вся необходимая функциональность программы, за которую отвечает данный класс. Например, «у каждого клиента будет имя» (атрибут класса Клиент) и «программа должна иметь возможность вычислять капитал каждого клиента» (метод класса Клиент). События, которые должны обрабатывать объекты класса, также должны быть определены. В это же время должны быть разработаны и планы тестирования для каждого D-требования.
            4. Связи между классами определяются в два этапа:
            4.1. Начальный набор связей определяется на основе анализа диаграмм сотрудничества (collaboration) или диаграмм последовательности. Если два объекта взаимодействуют (обмениваются сообщениями), между ними на диаграмме должна существовать связь (путь взаимодействия), которая преобразуется в двунаправленную ассоциацию между соответствующими классами. Если сообщения между некоторой парой объектов передаются только в одном направлении, то для соответствующей ассоциации вводится направление навигации.
            4.2. Анализируются и уточняются ассоциации между классами-сущностями. Задаются мощности ассоциаций, могут использоваться множественные ассоциации, агрегации, обобщения и ассоциации-классы.
            5. D-требования проверяются и сравниваются с С-требованиями.
            6. D-требования проверяются заказчиком и, затем, публикуются.

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

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

            1. Класс анализа является четкой абстракцией, моделирующей один конкретный элемент предметной области. Он должен имеет от 3-х до 5-ти операций. Все свойства класса служат реализации его назначения. Однако для реализации своего назначения класс должен иметь минимальное количество связей с другими классами.
            2. В классах анализа содержаться только ключевые атрибуты и операции, определенные на очень высоком уровне абстракции. Как правило, каждая операция уровня анализа затем разбивается на несколько операций уровня проекта.
            3. Необходимо избегать глубоких деревьев наследования (3 и более уровней), поскольку частой ошибкой при построении иерархии наследования является использование функциональной декомпозиции, где каждый уровень абстракции имеет только одну операцию. Наследование использует только там, где есть явная иерархи наследования, вытекающая непосредственно из предметной области.
            4. При выявлении классов посредством анализа текста С-требования, существительные указывают на классы или атрибуты, а глаголы служат признаком операций. Однако синонимы и омонимы могут стать причиной появления ложных классов.
            5. При выявлении классов совместно с пользователями часто используют т.н. CRC(Class-Responsibilities-Collaborators)-анализ с помощью стикеров и мозговой штурм.

            Без возможности четкого контроля каждого требования от проекта до программного кода, реализующего это требование, было бы сложно убедиться в том, что программа разработана в соответствии с установленными требованиями. Когда требования меняются (чего следует ожидать), это становится еще сложнее. Возможность отображать каждое требование на соответствующие части проекта и программы называется прослеживанием.
            Один из способов, помогающих обеспечить прослеживание, заключается в отображении каждого функционального D-требования на конкретную функцию целевого языка. На рисунке демонстрируется обеспечение принципа прослеживания для некоторого требования №NNN «Поиск учебно-методических материалов (УММ)»:

            1. С-требования, сформулированные заказчиком при проведении анкетирования (или интервью), отображаются на диаграмме вариантов использования;
            2. на этапе проработки D-требований, каждое С-требование представляется комплектом из трех диаграмм: деятельности, классов и последовательностей;
            3. при проектировании архитектуры системы для удовлетворения требования №NNN в некотором классе слоя предметной области предусматривается соответствующий метод(ы) (например, «findByAuthor» и «findByTitle)»;
            4. на стадии детального проектирования прорабатывается алгоритм метода, отвечающего за выполнение требования №NNN, а также создается ER-диаграмма БД и конструируется SQL-запрос(ы), выполнение которого обеспечит удовлетворение данного требования;
            5. на стадии реализации для выполнения требования №NNN разрабатываются листинги соответствующих методов и, наконец, на стадии тестирования выполнение требования №NNN проверяется с использованием составленного плана тестирования.

            Рисунок – Пояснение принципа прослеживания
            Пояснение принципа прослеживания требований

            На протяжении всего процесса проектирования необходимо прилагать усилия по планированию будущего тестирования. Существует несколько преимуществ в написании тестов одновременно с требованиями.
            Во-первых, это позволяет прояснить требование.
            Во-вторых, это переносит некоторую часть работы из фазы тестирования проекта в фазу разработки требований. Пусть, например, SRS включает в свой состав D-требование №NNN следующего содержания: «NNN. ФИО каждого студента информационной системы «Деканат» будет представлять собой строку символов от 1 до 256». C целью планирования процедуры тестирования необходимо составить проект плана тестирования, примерная форма которого может быть представлена в виде таблицы .

            Таблица «Тестовые данные для проверки D-требования №nnn»

            № п/п Входные тестовые данные Ожидаемый результат
            1 Иванов Иван Иванович Иванов Иван Иванович
            2 length()<10 Сообщение с вопросом о корректности вводимых данных
            3 length()>256 Сообщение с вопросом о корректности вводимых данных
            4 … …

            При формировании требований к АСОИУ необходимо обеспечить достижение ряда показателей, среди которых наиболее значимыми являются: прослеживание, полнота, согласованность и т.д. Набор D-требований согласован, если между требованиями нет противоречий. По мере увеличения числа D-требований согласованность может стать труднодостижимой, но объектно-ориентированная организация требований помогает избежать несогласованности благодаря классификации D-требований по классам и с помощью разложения их на простейшие составляющие.
            С целью проверки указанных характеристик составляют таблицу, форма которой приведена на рисунке:

            Рисунок «Шаблон таблицы для проверки D-требований»
            Шаблон таблицы для проверки D-требований

            Во втором столбце таблицы приводится идентификатор D-требования. В столбце 3 приводится идентификатор С-требования, в состав которого входит данное D-требование. В столбце 4 приводятся идентификаторы D-требований, выполнение которых необходимо и достаточно для реализации данного D-требования. В столбце 5 делают отметку, если данное D-требование не противоречит никакому другому D-требованию из перечисленных в таблице. В столбце 6 делают отметку, если данное D-требование может быть реализовано с учетом ограничений, накладываемых другими С- или D-требованиями, средой разработки, аппаратной платформой и т.д.

            В столбце 7 делают отметку, если данное D-требование не может быть истолковано двояко. В столбце 8 делают отметку, если данное D-требование сформулировано предельно просто. В случае отсутствия отметки необходимо привести дополнительные разъяснения по содержанию такого требования. В столбце 9 делают отметку, если в данном требовании указаны допустимые отклонения от необходимого результата. В столбце 10 делают отметку, если формулировка данного D-требования не претерпит существенных изменений при возникновении в будущем необходимости наращивания функциональных возможностей системы. В столбце 11 делают отметку, если для данного требования составлен план тестирования. В столбце 12 делают отметку по окончании реализации данного D-требования в виде программного кода.

            Порядок разработки каждого D-требования показан выше на рисунке и включает следующие шаги:

            1. Предварительный анализ требования:
              1. Классификация требования как функциональное или нефункциональное (рекомендуется использовать подсказки IEEE SRS для большинства нефункциональных требований);
              2. выбор метода организации функциональных требований.
            2. Обеспечение прослеживания требования. Убедиться в возможности прослеживания при проектировании и реализации.
            3. Обеспечение тестируемости требования. Спланировать конкретный тест, устанавливающий выполнение требования.
            4. Проверка недвусмысленности требования.
            5. Назначение требованию приоритет. Например, высокий («важно»), средний («желательно») или низкий («не обязательно»).
            6. Проверка полноты требования. Для каждого требования следует убедиться в присутствии всех остальных необходимых или сопутствующих требований.
            7. Добавление состояния ошибки:
              1. сформулировать, что требуется выполнить при возникновении нештатных ситуаций;
              2. в критичных местах добавить состояния ошибок программирования.
            8. Проверка согласованности. Необходимо убедиться, что ни одно требование не противоречит каким-либо аспектам другого требования.

            Как только все D-требования собраны, необходимо обновить SPMP и передать D-требования под управление конфигурациями.
            Для формализации и детальной фиксации требований рекомендуется использовать спецификацию требований к программному обеспечению (Software Requirements Specification — SRS) в соответствии со стандартом IEEE 830-1993.

            Наименование департамента

            [НАИМЕНОВАНИЕ ПРИЛОЖЕНИЯ ИЛИ СИСТЕМЫ]

            Документ с бизнес-требованиями

            Документ с бизнес-требованиями

            Руководство по использованию шаблона требований

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

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

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

            Определение бизнес-требований является обязательным этапом во всех проектах.
            Template Completion

            Note:  Text within <  > brackets need to be replaced with project-specific information.

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

            ·   не всегда очевидны;

            ·   могут поступать из многочисленных и разнообразных источников;

            ·   нуждаются в управлении кросс-функциональными группами людей;

            ·   могут вызывать сложности при формулировании в ходе написании документации;

            ·   могут формулироваться на разных уровнях детализации.

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

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

            2.     Заполните документ, используя вспомогательную информацию в <скобках>.

            3.     Для небольших проектов можно объединить все разделы требований в одну таблицу, добавив столбец «Тип требования».

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

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

            6.     После того, как были внесены изменения в документ, и вы готовы его завершить, убедитесь, что Вы обновили оглавление документа.

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

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

            9.     Если вносятся изменения в документ, то необходимо обновить раздел с историей обновлений документа.

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

            Информация по документу и согласование документа

            История версий  
            № версии Дата создания Кем пересмотрена версия Причина для изменений
            1.0 9/17/09 Иванов Петр Рассмотрение проектным офисом
                   
                   
                   
                     

            Этот документ был утвержден в качестве официального документа с бизнес-требованиями для проекта «<имя проекта>», и точно отражает текущее понимание бизнес-требований. После утверждения этого документа, изменения требований будет регулироваться через процесс управления изменениями, включая анализ последствий (impact analysis), проходя стадии рассмотрения и согласования.

            Согласование документа  
            Имя утверждающего Проектная роль Подпись/Электронная подпись Дата
                   
                   
                   
                   
                     

            Оглавление документа

            1. Назначение документа. 1
            2. Ресурсы для создания документа. 1
            3. Словарь терминов.. 1
            4. Обзор проекта. 1

            4.1 Обзор проекта и предпосылки. 1

            4.2 Зависимости проекта. 1

            4.3 Заинтересованные стороны.. 1

            1. Основные допущения и ограничения. 2

            5.1 Основные допущения и ограничения. 2

            1. Сценарии использования/Варианты использования (Use Cases) 2

            6.1 Диаграмма вариантов использования. 2

            6.2 Изложение фактов по варианту использования. 3

            1. Бизнес-требования. 5
            2. Приложения. 7

            8.1 Приложение A – Потоки бизнес-процессов. 7

            8.1.1 Диаграммы «Как Есть» (As Is) 8

            8.2 Приложение B – Каталог бизнес-правил. 10

            8.3 Приложение C- Модели. 10

            8.4 Матрица трассировки/отслеживания требований (Traceability Matrix) 10

            8.5 Инструкция описания вариантов использования. 10

            1. Назначение документа

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

            • Создание дизайнов Решения;
            • Разработка плана тестирования, скриптов тестирования и сценариев тестирования;
            • Определение критериев завершенности проекта;
            • Оценка успешности проекта.
            1. Ресурсы для создания документа
            Имя Бизнес-подразделение Роль
            <Идентифицируйте все заинтересованные стороны и ресурсы, которые будут вовлечены в процесс сбора требований>    
                 
                 
                 
                 
            1. Словарь терминов
            Термин / Сокращение Определение
            <Определите термины и сокращения, которые используются в данном документе >  
               
               
               
               
            1. Обзор проекта

            4.1 Обзор проекта и предпосылки

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

            4.2 Зависимости проекта

            <Перечислите любые связанные проекты, которые затрагивают целиком или частично Ваш проект, или которые имеют зависимости от этого проекта.>

            4.3 Заинтересованные стороны

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

              Заинтересованные стороны
            1.  
            2.  
            3.  
            1. Основные допущения и ограничения

            5.1 Основные допущения (предположения) и ограничения

            # Допущения (предположения)
              Перечислите любые допущения, на которых основаны требования
               
               
               
               
               
            # Ограничения
              Перечислите любые ограничения, на которых основаны требования
               
               
               
               
               
            1. Сценарии использования/Варианты использования (Use Cases)

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

            6.1 Диаграмма вариантов использования

            6.2 Изложение фактов по варианту использования

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

            ID Варианта использования:  
            НаименованиеВарианта использования:  
            Кем создан:   Кем в последний раз изменен:  
            Дата создания:   Дата последнего изменения:  
            Акторы:  
            Описание:  
            Предварительные условия:  
            Постусловие:  
            Нормальный ход событий:  
            Альтернативный ход событий:  
            Исключения:  
            Содержит:  
            Приоритет:  
            Частота использования:  
            Бизнес-правила  
            Специальные требования:  
            Предпосылки (предположения):  
            Примечания и вопросы:  
            Графическое представление варианта использования

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

            ID Варианта использования: 1
            НаименованиеВарианта использования: Просмотр интерактивной карты кампуса
            Кем создан: Иванов Петр Кем в последний раз изменен:  
            Дата создания: 19/04/2015 Дата последнего изменения:  
            Акторы: Пользователь
            Описание: Этот вариант использования описывает основной способ использования интерактивной карты кампуса. Пользователь через браузер получает доступ по соответствующему URL и взаимодействует с представленной функциональностью.
            Предварительные условия: Веб-браузер открыт и получен доступ к интерактивной карте кампуса через URL.
            Постусловие: Пользователь переходит с интерактивной карты кампуса на веб-сайт.
            Нормальный ход событий: 1.     Открывается браузер;

            2.     Переход по URL карты кампуса;

            3.     Взаимодействие с картой кампуса при помощи доступной функциональности.
            Альтернативный ход событий: Отсутствует
            Исключения: Отсутствуют
            Содержит:  
            Приоритет: Высший
            Частота использования: Одно использование на одно посещение.
            Бизнес-правила TBD
            Специальные требования: ·         Доступ 24/7

            · Время отклика сопоставимо с общими картографическими решениями (например, карты Google)
            Предпосылки (предположения):  
            Примечания и вопросы:  
            Графическое представление варианта использования  
            1. Бизнес-требования

            Следующие разделы документа представляют различные бизнес-требования данного проекта.

            Тип требования ID – Префикс  

            ID – Номер

            Функция – Характеристика — Требование

            Ссылка на вариант использования

            		 ?? ?? ?? ??

            Комментарии
              Требования бизнес-пользователей
              f 01-001              
              f 01-002              
              f 01-003              
              f 01-004              
              f 01-005              
              f 01-006              
              f 01-007              
              f 01-008              
              Требования к отчетности
              f 02-001              
              f 02-002              
              f 02-003              
              f 02-004              
              f 02-005              
              f 02-006              
              f 02-007              
              f 02-008              
              Требования к правам доступа пользователей и безопасности
              f 03-001              
              f 03-002              
              f 03-003              
              f 03-004              
              F 03-005              
              f 03-006              
              f 03-007              
              f 03-008              
              Требования к уровню сервиса и к производительности
              f 04-001              
              f 04-002              
              f 04-003              
              f 04-004              
              f 04-005              
              f 04-006              
              f 04-007              
              f 04-008              
              Требования к масштабируемости
              f 05-001              
              f 05-002              
              f 05-003              
              f 05-004              
              f 05-005              
              f 05-006              
              f 05-007              
              f 05-008              
              Требования к поддержке и техническому обслуживанию
              f 06-001              
              f 06-002              
              f 06-003              
              f 06-004              
              f 06-005              
              f 06-006              
              f 06-007              
              f 06-008              
            1. Приложения

            8.1 Приложение A – Потоки бизнес-процессов

            <Опишите текущий существующий процесс документооборота используя диаграмму потоков (Visio Flowcharts) и дайте подробное описание>

            8.1.1 Диаграммы «Как Есть» (As Is)

            <Вставьте сюда диаграмму «Как Есть» (если это применимо к проекту)>

            8.2.2 Диаграммы «Как Будет» (To Be)

            < Вставьте сюда диаграмму «Как Будет» (если это применимо к проекту)>

            8.2 Приложение B – Каталог бизнес-правил

            <Инструкции: используйте следующий шаблон для каждого бизнес-правила>

            Наименование бизнес-правила <Имя должно дать вам хорошее представление о теме бизнес-правила>
            Идентификатор <Определите уникальный идентификатор.> Например: BR1
            Описание <Опишите детали бизнес-правила.>

            Например: «Весь труд рабочих отслеживается, составляется отчет и выставляется счет в 30 минутных интервалах»
            Пример <(Необязательное поле) Пример использования бизнес-правила>
            Источник <Источник правила. Например, заинтересованная сторона>
            Связанные бизнес-правила <Список связанных правил, для обеспечения процесса трассировки>

            8.3 Приложение C- Модели

            <Вставьте сюда модели>

            8.4 Матрица трассировки/отслеживания требований (Traceability Matrix)

            <Вставьте сюда матрицу трассировки требований>

            8.5 Инструкция описания вариантов использования

            <Инструкции по заполнению описаний по сценариям использования содержатся в этом разделе. По завершению документа с бизнес-требованиями удалите эти инструкции>.

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

            · Просмотреть информацию по номеру заказа.

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

            · Заказать компакт-диск с обновленной версией ПО.
            Кем создан Содержит имя человека, который изначально задокументировал этот Вариант использования
            Дата создания Введите дату, когда был задокументирован изначально Вариант использования
            Дата последнего изменения Введите дату последнего обновления Варианта использования
            Кем в последний раз изменен Содержит имя человека, который внес последние изменения.
            Актор Введите лицо или другие субъекты, которые являются внешними по отношению к системе ПО, и которые взаимодействуют с системой в соответствии с вариантом использования в рамках выполнения задач. Различные акторы часто соответствуют различным классам пользователей или ролям, идентифицируя их с группой пользователей заказчика, которые будут использовать продукт. Имя акторов, которые будут выполнять этот Вариант использования.
            Описание Дайте краткое описание причины и результатов этого Варианта использования, или приведите высокоуровневое описание последовательности действий и результата выполнения Варианта использования.
            Предварительные условия Перечислите мероприятия, которые должны состояться, или любые условия, которые должны выполниться до того, как вариант использования будет запущен. Количество предварительных условий. Примеры:

            · Идентификатор пользователя должен пройти проверку подлинности.

            · Компьютер пользователя имеет достаточное количество свободной памяти для запуска задачи.
            Постусловие Опишите состояние системы по завершении исполнения варианта использования. Количество постусловий. Примеры:

            · Документ содержит только допустимые теги в SGML.

            · Цена товара в базе данных была обновлена с новым значением.
            Нормальный ход событий Предоставьте подробное описание действий пользователя и реакции системы, которые будут проходить во время выполнения варианта использования в нормальных, ожидаемых условиях. Это последовательность действий внутри диалогового окна, в ходе которой будет достигнута цель, которая указана в названии варианта использования и в его описании. Это описание может быть написано как ответ на гипотетический вопрос: «Как мне выполнить задачу, которая указана в имени Варианта использования?». Лучше всего это делать в виде нумерованного списка действий, которые выполняет актор, чередуя их с реакциями системы на производимые действия.
            Альтернативный ход событий Задокументируйте другие, разумные сценарии использования, которые могут иметь место в пределах данного варианта использования. Обозначьте альтернативный ход событий и опишите какие-либо различия в последовательности шагов, которые могут потребоваться. Укажите номер каждого альтернативного хода, используя ID варианта использования в качестве префикса, а затем добавьте к номеру префикс «AC», чтобы обозначить «альтернативный ход событий». Например: X.Y.AC.1
            Исключения Опишите любые предполагаемые условия возникновения ошибок, которые могут возникнуть во время выполнения варианта использования, а также определите, как система должна отреагировать на эти условия. Также опишите, каким образом система должна реагиовать, если вариант использования завершится по какой-то непредвиденной причине. Номер каждого исключения формируется при помощи ID Варианта использования и специального префикса «EX». Пример: X.Y.EX.1
            Содержит Перечислите любые другие варианты использования, которые вызываются этим вариантом использования. Общие функциональные возможности, которые появляются в нескольких отдельных вариантах использования могут быть включены в отдельный вариант использования.
            Приоритет Укажите относительный приоритет реализации функциональности, которая необходима для того, чтобы этот вариант использования был выполнен. Используемая схема приоритетов должна быть такой же как та, которая используется в спецификации требований к программному обеспечению.
            Частота использования Оцените частоту использования данного Use Case за единицу времени.
            Бизнес-правила Перечислите любые бизнес-правила, которые влияют на этот вариант использования.
            Специальные требования Идентифицируйте любые дополнительные требования, такие как нефункциональные требования, для варианта использования, которые необходимо будет рассмотреть в ходе проектирования и реализации решения. Они могут включать в себя требования к производительности или атрибуты качества.
            Предпосылки (предположения) Перечислите какие-либо допущения, которые были сделаны при анализе, что привело к принятию данного варианта использования в описании продукта и написанию подробной информации по варианту использования.
            Примечания и вопросы Перечислите любые дополнительные комментарии по данному варианту использования или любые нерешенные вопросы, или TBD лист (то, что будет определено позднее). Определите, кто будет заниматься каждым отдельным вопросом или проблемой и к какому сроку все пункты должны быть разрешены.
            Источник

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

            Определение

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

            Путаница в терминологии возникает по трем основным причинам:

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

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

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

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

            Акценты процесса

            требования разработка и примеры оформления

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

            Обзор

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

            Состав заявок

            требования примеры оформления

            Требования бизнес-процесса часто включают в себя:

            1. Контекст, область и фон, в том числе и причины изменений.
            2. Ключевые заинтересованные стороны, у которых есть требования.
            3. Факторы успеха для будущего или целевого состояния.
            4. Ограничения, налагаемые бизнесом или другими системами.
            5. Модели и анализ процессов, часто использующие блок-схемы для представления всего «как есть».
            6. Логическая модель данных и ссылки на словарь.
            7. Глоссарии деловых терминов и местный жаргон.
            8. Диаграммы потоков данных для иллюстрации того, как они проходят через информационные системы (в отличие от блок-схем, изображающих алгоритмический поток бизнес-операций).

            Роли

            разработка и примеры оформления

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

            Полнота

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

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

            Прообраз

            примеры оформления

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

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

            Разработка

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

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

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

            Примеры оформления

            Бизнес требования примеры оформления

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

            Трудности

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

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

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

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

            Источник

            Понравилась статья? Поделить с друзьями:
          1. Бизнес фильмы которые стоит посмотреть зарубежные
          2. Бизнес центр амбер плаза ул краснопролетарская 36
          3. Бизнес центр дмитровский бутырская 76 как доехать
          4. Бизнес центр костромской области официальный сайт
          5. Бизнес центр невская ратуша санкт петербург адрес