Наименование департамента
[НАИМЕНОВАНИЕ ПРИЛОЖЕНИЯ ИЛИ СИСТЕМЫ]
Документ с бизнес-требованиями |
Документ с бизнес-требованиями
Руководство по использованию шаблона требований
Для того, чтобы правильно создать документ с описанием бизнес-требований, пожалуйста, придерживайтесь следующих принципов данного руководства. После завершения написания документа, удалите данный раздел.
Назначение | Требование — это задокументированное условие или возможность продукта, сервиса или системы, которые должны соответствовать задачам проекта. Управление требованиями представляет собой семантический подход к выявлению, организации и документированию требований продукта, сервиса или системы. Документ с описанием бизнес-требований служит базовой линией проекта, которая поясняет, в бизнес-терминах, что необходимо сделать на этапе проектирования в проекте.
Так как требования являются динамичными, то документ с бизнес-требованиями является постепенно изменяющимся документом, целью которого является записывать то, что известно на данный момент, а затем используя эти записи строить документ дальше по ходу развития проекта. Именно из этого документа появляется более конкретная проектная документация, которая формируется на основе потребностей проекта и других взаимодополняющих методологий. |
Владение документом | Бизнес-анализ и руководители проекта работают с бизнес-спонсором и любыми другими необходимыми бизнес или техническими лидерами на проекте в рамках формирования документа с бизнес-требованиями. |
Когда документ формируется | Формирование документ с описанием бизнес-требований запускается во время начальной стадии выполнения проекта, который предшествует стадии проектирования в жизненном цикле управления проектами.
Определение бизнес-требований является обязательным этапом во всех проектах. |
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), проходя стадии рассмотрения и согласования.
Согласование документа | ||||
Имя утверждающего | Проектная роль | Подпись/Электронная подпись | Дата | |
Оглавление документа
4.1 Обзор проекта и предпосылки. 1
4.3 Заинтересованные стороны.. 1
5.1 Основные допущения и ограничения. 2
6.1 Диаграмма вариантов использования. 2
6.2 Изложение фактов по варианту использования. 3
8.1 Приложение A – Потоки бизнес-процессов. 7
8.1.1 Диаграммы «Как Есть» (As Is) 8
8.2 Приложение B – Каталог бизнес-правил. 10
8.4 Матрица трассировки/отслеживания требований (Traceability Matrix) 10
8.5 Инструкция описания вариантов использования. 10
Этот документ определяет высокоуровневые требования <введите имя бизнес-линии, внутренней организации, заинтересованной стороны> этого проекта. Документ будет использоваться в качестве основы для следующих видов деятельности:
- Создание дизайнов Решения;
- Разработка плана тестирования, скриптов тестирования и сценариев тестирования;
- Определение критериев завершенности проекта;
- Оценка успешности проекта.
Имя | Бизнес-подразделение | Роль |
<Идентифицируйте все заинтересованные стороны и ресурсы, которые будут вовлечены в процесс сбора требований> | ||
Термин / Сокращение | Определение |
<Определите термины и сокращения, которые используются в данном документе > | |
4.1 Обзор проекта и предпосылки
<Информация для данного раздела может быть взята из Устава проекта. Данный пункт содержит краткое описание того, что из себя представляет проект. Данный пункт включает в себя описание текущей ситуации, существующих проблем и целей. Этот раздел служит основой для начала процесса выявления требований. Каждое требование должно подводить проект к описанию основной концепции>
4.2 Зависимости проекта
<Перечислите любые связанные проекты, которые затрагивают целиком или частично Ваш проект, или которые имеют зависимости от этого проекта.>
4.3 Заинтересованные стороны
Ниже перечислены внутренние и внешние заинтересованные стороны, чьи требования представлены в этом документе:
Заинтересованные стороны | |
1. | |
2. | |
3. |
5.1 Основные допущения (предположения) и ограничения
# | Допущения (предположения) |
Перечислите любые допущения, на которых основаны требования | |
# | Ограничения |
Перечислите любые ограничения, на которых основаны требования | |
<Основная цель сценариев использования (вариантов использования) заключается в том, чтобы зафиксировать требуемое поведение системы с точки зрения конечного пользователя для достижения одной или нескольких желаемых целей. Вариант использования содержит описание потока событий, который описывает взаимодействие между акторами и системой. Вариант использования также может быть представлен визуально в UML для того, чтобы показать взаимосвязи с другими вариантами использования и акторами>.
6.1 Диаграмма вариантов использования
6.2 Изложение фактов по варианту использования
<Каждый вариант использования должен быть задокументирован с помощью этого шаблона. Смотрите инструкцию для описания вариантов использования>
ID Варианта использования: | |||
НаименованиеВарианта использования: | |||
Кем создан: | Кем в последний раз изменен: | ||
Дата создания: | Дата последнего изменения: |
Акторы: | |
Описание: | |
Предварительные условия: | |
Постусловие: | |
Нормальный ход событий: | |
Альтернативный ход событий: | |
Исключения: | |
Содержит: | |
Приоритет: | |
Частота использования: | |
Бизнес-правила | |
Специальные требования: | |
Предпосылки (предположения): | |
Примечания и вопросы: | |
Графическое представление варианта использования |
Пример заполненного варианта использования:
ID Варианта использования: | 1 | ||
НаименованиеВарианта использования: | Просмотр интерактивной карты кампуса | ||
Кем создан: | Иванов Петр | Кем в последний раз изменен: | |
Дата создания: | 19/04/2015 | Дата последнего изменения: |
Акторы: | Пользователь |
Описание: | Этот вариант использования описывает основной способ использования интерактивной карты кампуса. Пользователь через браузер получает доступ по соответствующему URL и взаимодействует с представленной функциональностью. |
Предварительные условия: | Веб-браузер открыт и получен доступ к интерактивной карте кампуса через URL. |
Постусловие: | Пользователь переходит с интерактивной карты кампуса на веб-сайт. |
Нормальный ход событий: | 1. Открывается браузер;
2. Переход по URL карты кампуса; 3. Взаимодействие с картой кампуса при помощи доступной функциональности. |
Альтернативный ход событий: | Отсутствует |
Исключения: | Отсутствуют |
Содержит: | |
Приоритет: | Высший |
Частота использования: | Одно использование на одно посещение. |
Бизнес-правила | TBD |
Специальные требования: | · Доступ 24/7
· Время отклика сопоставимо с общими картографическими решениями (например, карты Google) |
Предпосылки (предположения): | |
Примечания и вопросы: | |
Графическое представление варианта использования |
Следующие разделы документа представляют различные бизнес-требования данного проекта.
Тип требования | 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 |
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 Comments