Бизнес требования пример: Пример написания функциональных требований к Enterprise-системе / Habr – Шаблон документа с бизнес-требованиями.doc | Бизнес-Анализ в России

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

Скачать Шаблон документа с бизнес-требованиями.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

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

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

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

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

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

7. Бизнес-требования. 5
8. Приложения. 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. Назначение документа

 

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

 

• Создание дизайнов Решения;
• Разработка плана тестирования, скриптов тестирования и сценариев тестирования;
• Определение критериев завершенности проекта;
• Оценка успешности проекта.

2. Ресурсы для создания документа

 

Имя	Бизнес-подразделение	Роль
<Идентифицируйте все заинтересованные стороны и ресурсы, которые будут вовлечены в процесс сбора требований>

 

3. Словарь терминов

 

Термин / Сокращение	Определение
<Определите термины и сокращения, которые используются в данном документе >

 

4. Обзор проекта

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

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

 

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

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

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

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

 

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

 

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

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

 

#	Допущения (предположения)
	Перечислите любые допущения, на которых основаны требования
#	Ограничения
	Перечислите любые ограничения, на которых основаны требования

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

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

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

 

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

 

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

 

ID Варианта использования:
НаименованиеВарианта использования:
Кем создан:		Кем в последний раз изменен:
Дата создания:		Дата последнего изменения:

 

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

 

 

 

 

 

 

 

 

 

 

 

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

 

ID Варианта использования:	1
НаименованиеВарианта использования:	Просмотр интерактивной карты кампуса
Кем создан:	Иванов Петр	Кем в последний раз изменен:
Дата создания:	19/04/2015	Дата последнего изменения:

 

Акторы:	Пользователь
Описание:	Этот вариант использования описывает основной способ использования интерактивной карты кампуса. Пользователь через браузер получает доступ по соответствующему URL и взаимодействует с представленной функциональностью.
Предварительные условия:	Веб-браузер открыт и получен доступ к интерактивной карте кампуса через URL.
Постусловие:	Пользователь переходит с интерактивной карты кампуса на веб-сайт.
Нормальный ход событий:	1.     Открывается браузер; 2.     Переход по URL карты кампуса; 3.     Взаимодействие с картой кампуса при помощи доступной функциональности.
Альтернативный ход событий:	Отсутствует
Исключения:	Отсутствуют
Содержит:
Приоритет:	Высший
Частота использования:	Одно использование на одно посещение.
Бизнес-правила	TBD
Специальные требования:	·         Доступ 24/7 · Время отклика сопоставимо с общими картографическими решениями (например, карты Google)
Предпосылки (предположения):
Примечания и вопросы:
Графическое представление варианта использования

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

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

 

Тип требования	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. Приложения

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

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

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

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

Определение

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

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

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

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

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

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

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

Обзор

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

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

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

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

Роли

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

Полнота

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

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

Прообраз

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

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

Разработка

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

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

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

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

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

Трудности

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

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

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

Бизнес vs Функциональные требования

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

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

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

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

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

Пример функционального требования:

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

Обычно мы включаем

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

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

Название сценария: Создание рекламного места
Роль: Администратор

Пример функционального требования:

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

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

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

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

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

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

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

Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5– количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1= Охват.

Основные принципы

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

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

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

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

Вот такой прототип экрана редактирования рекламной кампании был включен в ТЗ на систему баннерной рекламы.

Читайте также:

Рекомендуемые страницы:

Поиск по сайту

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

Первая часть статьи «Разработка технического задания «Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?» вызвала немалый интерес. Кроме своей рассылки, я ее опубликовал и на известном сайте разработчиков Инфостарт, где она вызвала еще больший интерес, что не может не радовать. Как и обещал, пишу продолжение.

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

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

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

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

Как обычно происходит в жизни:

Как это происходит в большинстве проектов
Шаги	Как это происходит
Решение принято, проекту быть!	Понятное дело, что есть повод для радости, особенно, если проект большой, ничего плохого в этом нет! Главное, не радоваться слишком долго, оттягивая начало фактических работ, с этой минуты время будет идти по-другому.
Провели совещание с руководителями, собрали некоторую информацию об их видении результата.	Обычно этот процесс ограничивается несколькими встречами с руководством, затем с руководителями подразделений. Зафиксировав некие «позывы» со стороны Заказчика, они фиксируются в виде общих формулировок. Иногда к этому добавляют имеющуюся документацию (кто-то когда-то пытался уже поводить обследование, документы по существующим регламентам, формы используемых отчетов) Как ни удивительно, но после этого большинство внедренцев систем автоматизации радостно восклицает: «да в нашей системе все это есть! Ну немного поднастроить и все будет работать». На вопрос, надо ли обсуждать, как все должно работать (или как выполняется конкретный процесс) с конечными пользователями, ответ обычно отрицательный. Высказывается мнение, что руководитель все знает за своих подчиненных. А зря… За этим скрывается множество ловушек и препятствий, и сдача работ может превратиться в марафон по полосе с препятствиями. Как известно, марафон принято бегать по ровной дороге, а бег с препятствиями возможен только на коротких дистанциях (можно и не добежать).
Документирование результатов работы	После этого начинается документирование результатов в зависимости от целей работ: Если требуется разработать Техническое задание, консультант начинает рассовывать полученную информацию по заготовленному шаблону документа, чтобы и выглядело красиво, и основные требования были зафиксированы (те, что озвучены от руководства, а то ведь могут не утвердить). Понимая, что на практике такое Техническое задание особо не используется и приходится все выяснять «по ходу дела», главной целью Технического задания он ставит минимальное время согласования и утверждения. И, если получится, информация для примерной оценки стоимости будущих работ (кстати, тоже немаловажно). Если требуется описать бизнес-процессы. Как ни странно, но часто все предшествующие действия выглядят аналогично, как и в случае с разработкой Технического задания. Разница лишь в оформлении документации. Тут возможны варианты: консультанты описывают процесс произвольными словами или используют какие-либо правила описания бизнес-процессов (нотации). В первом случае такой документ получается удивительным образом похож на Техническое задание. Бывает даже такое, что если заменить титульный лист, никакой разницы не увидишь.В последнем случае часто делают акцент не на соответствии действительности, а на «правильности описания», т.е. формальное следование правилам описания.К сожалению, оба варианта являются не самой лучшей практикой, т.к. являются скорее формальностью, а пользы приносят не много.

Почему сложилась такая практика, как описано выше? Признаться, я не знаю. У кого ни спроси, никто не знает. При этом ситуация меняется не очень быстро, хотя на эту тему постоянно дискутируют, обмениваются опытом, пишут книги… Мне кажется, что одна из причин – низкое качество соответствующего образования. Может еще сказывается и тот факт, что много специалистов приходит вообще их другого бизнеса, и постигают все на практике, т.е. их опыт формируется в той среде, куда они попали. Об отношении ВУЗов и отсутствия их стремления быть ближе к реальности, тоже факт известный, но меня иногда удивляет их позиция. Например, у меня был случай, когда дипломница, талантливый специалист, хотела писать дипломную работу на платформе 1С (хорошую отраслевую разработку), но на кафедре ей сказали, что независимо от темы, на оценку «отлично» рассчитывать будет нельзя, т.к. 1С несерьезная система. Тут дело не в серьезности и объективности такого мнения, а в том, что примитивное задание на классическом языке программирования тут же считалось достойным оценки «отлично».

Давайте попробуем придать рассмотренному выше процессу более системный подход. Как он может тогда выглядеть?

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

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

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

Как это может происходить при более грамотной организации работ
Шаги	Как это происходит
Решение принято, проекту быть!	Тут ничего не меняется относительно первого варианта, эмоции никто не отменял
Провели совещание с руководителями, собрали некоторую информацию об их видении результата.	Этот шаг тоже остается, и он имеет большое значение. Но основное назначение первой встречи (или нескольких встреч) с руководителями и собственниками это знакомство. Знакомство в первую очередь с людьми и компанией. Сформулированные цели и пожелания на таких общих встречах могут быть самими различными, в том числе фантастическими. Все они будут, конечно же, выслушаны, но не факт, что будут реализованы. При более глубоком погружении в бизнес компании будут как появляться другие цели, так и отвергаться предыдущие. Я это к тому, что из предварительных встреч нельзя сформулировать четкие цели, все это потребует тщательной проработки.На таких встречах необходимо конспектировать все посылы от собственников и первых лиц, чтобы потом можно было к ним вернуться и обсудить, когда будет собрано достаточное количество информации. Даже простое на первый взгляд требование может оказаться нереализуемым либо очень трудоемким.
Формирование рабочей группы от Заказчика и Исполнителя, распределение ролей	Необходимо определиться, кто будет работать над проектом как со стороны Заказчика, так и со стороны Исполнителя. Несмотря на кажущуюся простоту данного этапа, он имеет очень большую роль. Если не зафиксировать четко, кто за что отвечает, в ходе реализации работ Вы рискуете столкнуться с неразберихой. Если со своей стороны Вы можете всегда конкретизировать роли в своей команде, то у Заказчика с этим могут возникнуть проблемы. На что следует обратить внимание: в состав рабочей группы Заказчика обязательно должны войти те люди, которые будут в дальнейшем хоть как-то влиять на принятие результата. Если допустить ситуацию, что при сдаче работ подключатся сотрудники Заказчика, которые не принимали участие в работах по формированию целей и выявлению требований, то проблемы гарантированы. Возможна даже такая абсурдная ситуация, что все, оказывается, сделано не так, как требовалось.В моей практике я сталкивался с такой ситуацией не раз.Поэтому, Вы себя можете обезопасить, если оговорите и зафиксируете документально, что никто, кроме рабочей группы Заказчика не может принимать участие в приемке-сдаче работ. А лучше всего, прописать такое в договорных условиях (В договоре или Уставе проекта). Помню, был такой случай: в одном крупном проекте учредитель решил подключиться к процессу (уж не знаю почему, скучно видать стало) и посетил одну из рабочих встреч, где обсуждался вопрос формирования счетов клиентам. Он с удивлением для себя узнал, что счет клиенту выставляет менеджер по продажам. В его представлении счет должен выставлять бухгалтер, и никак иначе. Но на самом деле бухгалтер вообще не представлял, о чем идет речь, а менеджер не мог себе представить, как так работать, если за каждым счетом бегать к бухгалтеру. В результате потеряли кучу времени, но ничего не поменялось, счет по-прежнему выставлял менеджер. А учредитель остался при своем мнении, но больше в процесс не вмешивался. На этом же этапе целесообразно разработать Устав проекта, в котором зафиксировать роли участников, порядок коммуникаций, регламент и состав отчетности, а также все остальное, что следует прописать в Уставе. Разработка Устава проекта это тема опять же отдельная.
Обучение проектной команды методикам и инструментам работы, согласование правил работы, видов и состава документации	Во-первых, необходимо разъяснить проектной команде все, что прописано в Уставе, как это будет применяться на практике. Во-вторых, проектную команду Заказчика необходимо обучить тем методам работы, которые Вы собираетесь использовать на всех последующих этапах. Имеет смысл обсудить форматы документов, которые будут использоваться, рассмотреть образцы. Если будут применяться какие-либо правила описания моделей или бизнес-процессов, то надо обсудить и эти правила, чтобы они были понятны.
Анкетирование	Этап анкетирования позволяет сравнительно быстрым способом получить достаточно достоверный срез информации о компании. Качество такой информации будет определяться тремя факторами: В первую очередь тем, как Вы обучили проектную группу Заказчика. Они должны четко понимать, как происходит процесс анкетирования и уметь донести информацию до всех участников Сама форма анкет. Анкеты должны быть понятными. Желательно, чтобы была инструкция по заполнению анкет. Еще лучше, если будет пример заполнения. Состав участников. Необходимо правильно выбрать состав участников. Если ограничиться только руководителями, собрать достоверную информацию не получится. Я рекомендую включать в состав анкетирования всех, кто будет в будущем являться пользователем конечных результатов. Например, если речь идет о внедрении автоматизированной системы, то стоит включить всех, кто будет являться пользователем. Бывают случаи, когда из 10 сотрудников одной должности найдется один, который выполняет какую-нибудь особенную функцию, о которой никто из оставшихся 9-ти больше не знает (например, готовит особый отчет для руководства). Если речь идет о дальнейшем перераспределении обязанностей или разработке должностных инструкций, следует поступить аналогично. Обращаю внимание, что методика анкетирования для последующей внедрения автоматизированной системы или описания бизнес-процессов в правильном случае различается. Конечно, структура анкет может быть и одинаковая, но это не самый лучший вариант. Когда мы описываем бизнес-процессы, то анкеты обычно носят более общий характер, т.к. неизвестно точно, с чем придется столкнуться. Если же речь идет о внедрении конкретной автоматизированной системы, то лучше иметь анкеты, учитывающие особенности этой системы. При таком подходе можно сразу выявить все узкие места системы, которые не подходят для данного предприятия. Как правило, методики внедрения готовых систем предусматривают наличие таких анкет. Такие анкеты могут разрабатываться либо по отдельным областям учета (например, учет заказов, продажи, ценообразование), либо для конкретных должностей (финансового директора, например). Состав вопросов примерно одинаковый.
Опросы	Опросом называется проведение устного собеседование со специалистами с целью выяснить особенности отдельных процессов. Необходимо организовать опрос так, чтобы он не выглядел как просто «встретились-поговорили», а более организовано. Для этого необходимо подготовить так называемый план опроса. В него можно включить те части анкеты, которые у Вас вызывают вопросы, противоречат сведениям других анкет или информация представлена поверхностно. Целесообразно добавить вопросы и просто из личного опыта.Ответы надо конспектировать в обязательном порядке. Идеально, если Вы договоритесь о ведении аудиозаписи. На этом же этапе следует проследить за полнотой предоставленной информации о документообороте (как форм первичных документов, так и различных отчетов)
Выделение ключевых бизнес- процессов или областей автоматизации	После анкетирования и опроса можно обосновано считать, что информации достаточно, чтобы делать выводы о выделении ключевых бизнес-процессов. На самом деле, уже можно выделить не только ключевые бизнес-процессы, но и практически все (если состав участников был выбран правильно). Вопрос выделения бизнес-процессов это тема совсем отдельная и не простая. Научиться тут сложно и вырабатывается в основном опытом. Из выделенных бизнес-процессов следует составить перечень (классификатор). Затем можно будет принимать решения, какие из них следует исследовать более глубоко, какие нет, а также выделять приоритеты.
Формулирование ключевых требований к системе, целей, критериев успешности проекта, процессов для детального изучения	К этому этапу должна быть собрана вся первичная информация о деятельности компании, составлен перечень бизнес-процессов. Теперь в самое время вернуться к целям, конкретизировать их, при необходимости обсудить с первыми лицами компании. При формулировке целей следует учесть конкретные показатели, при достижении которых будем считать проект успешным. Если речь идет о внедрении автоматизированной системы, то отдельным перечнем можно выделить требования к системе от ключевых пользователей. Я это делаю в виде отдельной таблицы, где все требования сгруппированы по подсистемам, для каждого требования указывается автор требования, формулировка и приоритет. Данную информацию можно будет использовать для составления плана развертывания системы (последовательности внедрения отдельных подсистем), а также для предложений по дальнейшему развитию системы (если отдельные подсистемы в текущем проекте внедрять не планируется). Если необходимо описать бизнес-процессы, принимаются решения о тех процессах, которые необходимо исследовать более детально.

 

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

Шаги	Что и как делать
Выделяем бизнес-процесс	Из общего перечня бизнес-процессов, полученного на предыдущих этапах, выделяем один (по приоритету) для детальной проработки. С остальными затем поступаем аналогично.
Детальное изучение бизнес- процесса	Выделенный бизнес-процесс подвергаем детальному изучению: анализируем полученные первичные документы, отчеты и их структуру, используемые в процессе программы, различные файлы (например, Excel), разговариваем с конечными исполнителями. Собираем различные идеи о том, как можно улучшить процесс. Очень полезно, если удастся понаблюдать за процессом именно в тех условиях, в которых он выполняется (не многие любят, когда за ними наблюдают, но что делать)
Графическое и/или текстовое описание бизнес-процесса (первичное)	Полученную подробную информацию начинаем описывать.Прежде чем описывать процесс, надо определиться, потребует ли он графического описания. Если процесс простой и понятный, функций в нем мало, и, графическое представление не улучшит его понимание или восприятие, то не надо тратить на это время. В этом случае достаточно описать его в текстовом виде в табличной форме. Если же процесс сложный, с различными логическими условиями, то лучше привести его графическую схему. Диаграммы всегда воспринимаются легче. Если Вы решили описать процесс в графическом виде, это вовсе не означает, что не надо приводить его текстовое описание. Т.е. текстовое описание процесса должно быть в любом случае, причем выполненное по одинаковой схеме. Удобно это делать в виде таблицы, в которой указать: исполнителей каждого шага, какую информацию они получают на входе, описание каждого шага, какую информацию формируют на выходе. Ниже мы посмотрим на примере, как это может выглядеть.
Согласование с исполнителями и владельцем бизнес-процесса	Лучший способ понять, насколько удачно вы выбрали стиль изложения информации, это показать результат пользователям (исполнителям) процесса.На самое главное в такой демонстрации это понимание того, насколько правильно Вы поняли, как процесс выполняется.Если обучение проектной команды прошло успешно, то можно ожидать от исполнителей вполне адекватной обратной связи. А если им станет интересно, то продвигаться все начнет гораздо быстрее.Выявленные уточнения и несоответствия необходимо отразить в описании (актуализировать), при необходимости операцию повторить.
Выделение показателей бизнес-процесса	После того, как выработано правильное понимание, как выполняется бизнес-процесс, надо подумать над показателями, которыми можно измерить качество или скорость выполнения процесса. Это не просто, но необходимо. Показатель должен быть измеряемым, т.е. выражен в числовом выражении и должен существовать простой способ эту величину получить. Если измеряемый показатель выделить невозможно, есть риск того, что бизнес-процесс выделен неудачно. Кроме того, не будет возможности понять (измерить ведь нельзя), приведут ли изменения процесса к его улучшению или нет.
Окончательное документирование бизнес-процесса	После того, как мы убедились в правильном понимании, как процесс выполняется (или должен выполняться), можно включать его в документацию.
Дальнейшие действия (или их отсутствие), в зависимости от целей проекта	Дальше возможны варианты: рассматриваемые процессы будут анализироваться и оптимизироваться, разрабатываться должностные инструкции, приниматься решения о необходимости автоматизации отдельных процессов и т.д.Это может быть и отдельный проект: описание бизнес-процессов.

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

 

Шаги	Что и как делать
Выделяем бизнес-требование/область автоматизации	Выделение в качестве требований целой области автоматизации (например, «Складские запасы») на практике используется, однако, это не самый эффективный способ детализации требований. Область автоматизации представляет собой группу требований, и рассматривать их лучше каждое в отдельности. Например, «Учет поступления материала на склад»
Детальное изучение бизнес-требования	Под детальным изучением бизнес-требования понимается то, как это хочет видеть и будет использовать конечный пользователь (разумеется, в соответствии с целями проекта). В технологиях разработки программного обеспечения это часто называют «вариант использования». Таким образом, детальное изучение бизнес-требования сводится к проработке вариантов использования. Пример такого варианта приведен в приложении 2 к статье. В простейших случаях варианты использования вовсе не обязательно рисовать в виде графических схем, можно ограничиться и текстовой формулировкой. Например, требование «При вводе номенклатуры цена должна рассчитаться как цена закупки +20%» рисовать не имеет смысла. В виде диаграммы имеет смысл представлять требования, объединенные до области автоматизации, как показано в примере в приложении 2.
Моделирование требований в информационной системе	Вот оно! Как Вы наверное помните, я уже обращал внимание на этот важнейший элемент в методике разработки Технических заданий. «Построй модель – получишь результат!» А что надо моделировать? Моделировать надо варианты использования, полученные на предыдущем этапе. Что должно быть на выходе моделирования? Должна получиться демонстрационная программа, в которую внесены пользовательские данные, причем желательно привычные его (пользователя) слуху, с учетом отраслевой специфики, актуальных проблем. И не просто так внесены, а должно быть понятно, откуда эти данные взялись, как рассчитались. В этом месте у читателя должны возникнуть вопросы: А что, если планируется разработка новой системы и моделировать попросту не в чем? Что, если для демонстрации не хватает функциональности, и систему надо дорабатывать? Конечно, Вы должны столкнуться с такой ситуацией, и это нормально. Что делать? Если система совсем новая (как говорится «с нуля»), то моделировать придется по большей части на бумаге, тут Вам диаграммы вариантов использования очень помогут. Частично имеет смысл набросать некоторые экранные формы, которые предполагается разработать (прямо в той среде, в которой будет вестись разработка), т.к. рисовать их в каком–нибудь редакторе будет дольше и эта работа скучная. Если внедряется готовая система, и в ней не хватает функциональности, то ничего страшного нет, данные вносятся руками, а пользователю так и рассказывается, что после необходимых доработок должно рассчитаться так-то и так (и он это видит). Целесообразно сопроводить такую модель текстовым описанием, пусть даже кратким, чтобы пользователь мог самостоятельно попробовать поработать с моделью в свободное время. В этом же описании можно формулировать требования к доработкам.
Демонстрация информационной модели рабочей группе	Полученную модель показываем Заказчику и рассказываем, как все должно работать.Демонстрацию модели лучше проводить по подсистемам, т.е. по группам требований. В случае, если выяснится, что у клиента предлагаемая схема работать не будет, надо подумать о других вариантах использования, внести изменения в модель и показать еще раз. Только если есть уверенность, что планируемая модель у данного клиента «будет жить», можно считать модель удачной.
Разработка тестов	Зачем нужны тесты? То, как мы смогли реализовать требования, нужно будет проверять. Соответственно, на все ключевые участки, сложные алгоритмы и пр. тесты желательно сделать. В том числе эти тесты могут быть использованы при сдаче работ. Вовсе необязательно делать тесты на каждую функцию системы, везде должен быть здравый смысл. Если речь идет о готовой системе, то делать тест на «ввод нового элемента в справочник клиентов» будет выглядеть глупо и бесполезной тратой сил и времени. А вот если это совсем новая система, такое вполне возможно. Зачем делать тесты, если еще нет системы?Во-первых, разработчику будет понятнее, чего от него хотят добиться. Во-вторых, мы облегчаем жизнь тестировщику (кто-то ведь будет тестировать результат разработки). Вообще, тестирование это отдельная дисциплина, весьма не простая с множеством методик. На практике, как правило, все равно используются самые простые методы тестирования.
Документирование требований в виде Технического задания	Собранная информация на предыдущих этапах будет являться как раз тем, что и должно войти в основу документа «Техническое задание» в раздел с требованиями.Так что остается все это грамотно оформить.
Дальнейшие действия (или их отсутствие), в зависимости от целей проекта	Дольше может начаться процесс разработки, поиск партнеров для проекта, тендер и т.д., все зависит от ситуации.

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

Приложение 1. Описанный бизнес-процесс в нотации EPC.

Приложение 2. Вариант использования подсистемы « Заказы»

Бизнес-требования к информационной системе — это… Что такое Бизнес-требования к информационной системе?



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

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

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

Общие положения

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

Характеристика объекта автоматизации

• Детальное описание
• Терминология предметной области

Продукты и услуги

• Перечень продуктов и услуг, планируемых к реализации в проекте
• Параметры продуктов и услуг (каналы продаж, тарифы и т.д.)
• Бизнес-логика

Базовые сущности

Выходные печатные формы

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

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

Изменения в отчетности

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

Требования к разграничению доступа и данным

Требования к каналам продаж

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

Требования к порядку внедрения

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

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

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

См. также

Архитектура предприятия

Бизнес-архитектура

Wikimedia Foundation.
2010.

• Бизнес-парк
• Бизнес-школа

Смотреть что такое «Бизнес-требования к информационной системе» в других словарях:

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

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

• Моделирование бизнес-процессов — Бизнес моделирование деятельность по выявлению и описанию существующих бизнес процессов (анализ бизнес процессов), а также проектированию новых (проектирование бизнес процессов). Бизнес моделированием также называют дисциплину и отдельный… …   Википедия

• ГОСТ Р 53114-2008: Защита информации. Обеспечение информационной безопасности в организации. Основные термины и определения — Терминология ГОСТ Р 53114 2008: Защита информации. Обеспечение информационной безопасности в организации. Основные термины и определения оригинал документа: 3.1.19 автоматизированная система в защищенном исполнении ; АС в защищенном исполнении:… …   Словарь-справочник терминов нормативно-технической документации

• ГОСТ Р ИСО/ТО 13569-2007: Финансовые услуги. Рекомендации по информационной безопасности — Терминология ГОСТ Р ИСО/ТО 13569 2007: Финансовые услуги. Рекомендации по информационной безопасности: 3.4 активы (asset): Все, что имеет ценность для организации [2]. Определения термина из разных документов: активы 3.58 анализ риска (risk… …   Словарь-справочник терминов нормативно-технической документации

• ГОСТ Р ИСО ТО 13569-2007: Финансовые услуги. Рекомендации по информационной безопасности — Терминология ГОСТ Р ИСО ТО 13569 2007: Финансовые услуги. Рекомендации по информационной безопасности: 3.4 активы (asset): Все, что имеет ценность для организации [2]. Определения термина из разных документов: активы 3.58 анализ риска (risk… …   Словарь-справочник терминов нормативно-технической документации

• Средний бизнес — (Medium business) Определение среднего бизнеса, нюансы среднего бизнеса Информация об определении среднего бизнеса, нюансы среднего бизнеса Содержание Содержание О “Что делать” и “с чего начать” вот в чем вопрос! О пользе… …   Энциклопедия инвестора

• Оптовая торговля — Оптовая торговля  торговля партиями товара. Чаще всего, товар, покупаемый у оптового продавца, предназначен для последующей перепродажи. Но также нередко покупателями выступают крупные потребители товара. Оптовая торговля является… …   Википедия

• Моделирование бизнеса — Бизнес моделирование деятельность по выявлению и описанию существующих бизнес процессов (анализ бизнес процессов), а также проектированию новых (проектирование бизнес процессов). Бизнес моделированием также называют дисциплину и отдельный… …   Википедия

• система — 4.48 система (system): Комбинация взаимодействующих элементов, организованных для достижения одной или нескольких поставленных целей. Примечание 1 Система может рассматриваться как продукт или предоставляемые им услуги. Примечание 2 На практике… …   Словарь-справочник терминов нормативно-технической документации

Нефункциональные требования к программному обеспечению. Часть 1 / Habr

Введение

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

В этой статье я расскажу о следующем:

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

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

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

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

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

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

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

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

• Внешние интерфейсы — описание аспектов взаимодействия с другими системами и операционной средой. К ним относятся требования к API продукта или системы, а также требования к API других систем, с которыми осуществляется интеграция.

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

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

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

• Юридические требования — требования к лицензированию, патентной чистоте, etc.

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

Нефункциональные требования: как их определять

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

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

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

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

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

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

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

1. Система получает оповещение о событии, инициирующем рассылку уведомлений.

2. Система осуществляет рассылку оповещений по адресам из списка рассылки X, используя шаблон Y. Для рассылки сообщений используется сервис Z.

3. В случае невозможности завершения рассылки, система предпринимает повторные попытку рассылки.

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

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

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

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

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

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

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

• Полнота (отдельного требования и системы требований) — требование должно содержать всю необходимую информацию для его реализации. В него включается вся информация об описываемом параметре, известная на момент описания. Система требований также не должна содержать невыявленных и не определенных требований. Причины неполноты описания следует явно объявлять.
• Однозначность — требование должно быть внутренне непротиворечиво и все работающие с ним должны понимать его одинаково. Требования следует выражать просто, кратко и точно, используя известные термины. Обычно базовые знания читателей спецификации требований к ПО различаются. Поэтому в ее состав нужно включить раздел с определением понятий прикладной области, используемых при определении требований. Пример, неоднозначного требования. «Период обновления экрана должен быть не менее 20 сек.»
• Корректность отдельного требования и согласованность (непротиворечивость) системы требований — требование не должно содержать в себе неверной, неточной информации, а отдельные требования в системе требований не должны противоречить друг другу.
• Необходимость — требование должно отражать возможность или характеристику ПО, действительно необходимую пользователям, или вытекающую из других требований.
• Осуществимость — включаемое в спецификацию требование должно быть выполнимым при заданных ограничениях операционной среды. Осуществимость требований проверяется в процессе анализа осуществимости разработчиком. В частности, для нефункциональных требований проверяется возможность достижения указанных численных значений при существующих ограничениях.
• Проверяемость — проверяемость требования означает, что существует конечный и разумный по стоимости процесс ручной или машинной проверки того, что ПО удовлетворяет этому требованию. Каждое требование (особенно нефункциональное) должно содержать достаточно информации для однозначной проверки его реализации. Иначе, факт реализации будет основываться на мнении, а не на анализе, что приведет к проблемам при сдаче готового ПО. Для атрибутов качества (как мы помним, отдельной разновидности нефункциональных требований) критерием проверямости можно считать наличие численных значений характеристик качества продукта или системы

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

Атрибуты качества

Этот раздел будет посвящен характеристикам качества продукта или системы.

Характеристики качества и модель качества ПО

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

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

Среди них можно выделить следующие:

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

• 1061-1998 IEEE Standard for Software Quality Metrics Methodology
• ISO 8402:1994 Quality management and quality assurance

Характеристики качества с точки зрения влияния на архитектуру системы

Все атрибуты качества с точки зрения архитектуры системы можно разделить на две большие группы: первая группа (runtime) – это атрибуты, относящиеся ко времени работы приложения или системы; вторая группа (design time) определяет ключевые аспекты проектирования приложения или системы. Многие из этих атрибутов взаимозависимы.

Рассмотрим более подробно каждую из этих групп.

Группа runtime

К этой группе относятся следующие атрибуты качества:

• Доступность — атрибут качества, определяющий время непрерывной работы приложения или системы. Чтобы определить этот параметр, обычно указывают максимально допустимое время простоя системы.
• Надежность — требование, описывающее поведение приложения или системы в нештатных ситуациях (примеры: автоматический перезапуск, восстановление работы, сохранение данных, дублирование важных данных, резервирование логики)
• Требования к времени хранения данных (например, использование БД в качестве постоянного хранилища данных, продолжительность хранения данных)
• Масштабируемость — требования к горизонтальному и/или вертикальному масштабированию приложения или системы. Говоря о вертикальной масштабируемости, мы определяем требования к вертикальной архитектуре системы или приложения. К требованиям вертикальной масштабируемости могут относиться, например, возможность переноса приложений на более мощные SMP-системы, поддержка большого объема памяти и файлов. Говоря о горизонтальной масштабируемости, мы определяем требования к горизонтальной архитектуре системы или приложения. К требованиям горизонтальной масштабируемости могут относиться, например, возможность использования технологий кластеризации. Следует особо заметить, что вертикальное масштабирование обычно направлено на повышение производительности системы. Горизонтальное масштабирование, помимо производительности, позволяет повысить отказоустойчивость системы. Более подробно о вертикальном и горизонтальном масштабировании можно прочитать, например, здесь.
• Требования к удобству использования системы/приложения (с точки зрения пользователя) и требования к удобству и простоте поддержки (Usability)
• Требования к безопасности, как правило, включают в себя три большие категории: требования, связанные с разграничением доступа, требования, связанные с работой с приватными данным, и требования, направленные на снижение рисков от внешних атак.
• Требования к конфигурируемости приложения, взаимодействия и расположения компонентов можно условно разделить на четыре уровня:
  
  1. конфигурируемость на основе предопределенного набора параметров (predefined configurability), когда необходимый уровень модификации достигается путем изменения значений параметров из предопределенного набора;
  
  2. конфигурируемость на основе предопределенного набора базовых объектов (framework constrained configurability), когда необходимый уровень модификации достигается путем перекомпоновки предопределенного набора процессов, сущностей и служебных процедур;
  
  3. конфигурируемость путем реализации новых базовых объектов (basis reimplementation), когда обеспечивается расширение набора процессов и сущностей;
  
  4. конфигурируемость путем новой реализации системы (system reimplementation), когда система должна устанавливаться и настраиваться с нуля.
• Требования к производительности решения, определяемые в терминах количества одновременно работающих пользователей, обслуживаемых транзакций, времени реакции, продолжительности вычислений, а также скорости и пропускной способности каналов связи
• Ограничения, накладываемые на объем доступной памяти, процессорного времени, дискового пространства, пропускную способность сети, при которых приложение должно эффективно выполнять возложенные на него задачи

Группа design time

К этой группе относятся следующие атрибуты качества:

• Требования к повторному использованию реализации или компонентов приложения или системы (Reusability). О том, как это выражается в конкретной реализации, будет рассказываться далее. Пока ограничимся лишь тем, что чаще всего эти требования будут возникать там, где общие компоненты используются несколькими модулями разрабатываемой вами системы.
• Требования к расширяемости (Extensibility) приложения или системы в связи с появлением новых функциональных требований, тесно связанное с таким архитектурным атрибутом качества, как переносимость кода. Как правило, на начальном этапе сбора требований можно ограничиться указанием тех функциональных областей, которые в дальнейшем должны удовлетворять требованию расширяемости.
• Требования к переносимости (Portability) приложения или системы на другие платформы.
• Требования к взаимодействию между компонентами решения, между внешними компонентами, использование стандартных протоколов и технологий взаимодействия (Interoperability). Например, к таким требованиям можно отнести возможность использования нескольких стандартных протоколов для обмена данными между одной из подсистем разрабатываемой системы и внешней системой-поставщиком данных (на примере ArcGIS)
• Требования к поддержке системы или приложения (Supportability). Среди этих параметров могут быть названы такие как, напрмер, дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа ошибок и проблем в работе
• Требования к модульности приложения или системы (Modularity). Обычно такие требования указывают, каким образом система должна быть разделена на модули, или перечисляют список обязательных модулей, которые должны входить в состав системы.
• Требования к возможности тестирования (Testability) приложения или системы определяют объем требований к автоматическому и ручному тестированию, наличие необходимого инструментария
• Требования к возможности и простоте локализации (Localizability) приложения или системы определяют возможности и специфические архитектурные требования, накладываемые процессом локализации. Эти требования содержат также перечень языков, на которые предполагается выполнять локализацию приложения или системы

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

Часть 1. Требования

Рубрика: Качество
требований,Статья

Данная
статья является второй в серии статей,
которые я публикую в рамках темы
“Управление качеством требований”.
Введение к серии было представлено на
данном сайте в теме “Управление
качеством требований. Начало.”
от 12 декабря 2009 года.

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

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

На сегодняшний день существует множество
определений термина требование к
программному обеспечению (software
requirement). Наиболее подходящим, на мой
взгляд, является определение, приведенное
в [2]:

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

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

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

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

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

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

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

«Бизнес требования» (business requirements)
описывают высокоуровневые цели
организации или заказчиков системы.
Как правило, их высказывают те, кто
финансируют проект, покупатели системы,
менеджеры пользователей, отдел маркетинга.
«Бизнес требования» относятся к
наивысшему уровню абстракции требований
и обычно характеризуют цели организации,
ее миссию и решения проблем бизнеса.

Для проектов, разрабатываемых в
соответствии с ГОСТ, «бизнес требования»
описывают цели и назначение разрабатываемой
системы, и могут размещаться в
соответствующем разделе технического
задания.

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

Ключевые возможности

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

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