Шаблон документа с бизнес-требованиями.doc

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

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

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

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

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

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

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

 

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

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

 

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

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 лист (то, что будет определено позднее). Определите, кто будет заниматься каждым отдельным вопросом или проблемой и к какому сроку все пункты должны быть разрешены.

 

4.7 3 Голоса
Рейтинг статьи
4
0
Оставьте, пожалуйста, свой комментарий!x