Документирование образа и границ проекта

Сведения об образе и границах проекта могут быть оформлены в виде отдельного документа [4], владельцами которого являются лица, финансирующие проект. Этот документ должен содержать следующую информацию.

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

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

2. Положение об образе проекта.

Положение об образе проекта должно содержать описание:

· целевой аудитории пользователей, их потребности или возможности;

· имени, категории и ключевого преимущества – основы для использования;

· отличий от конкурентов или текущего бизнес-процесса, описание основного отличия и преимущества продукта.

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

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

3. Масштабы и ограничения проекта.

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

4. Бизнес-контекст.

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

5. Приоритеты проекта.

Перечисляются приоритеты факторов, которыми может оперировать менеджер проекта для достижения успеха. Например, каждый проект имеет пять измеряемых параметров [4, 10]: объем (функции), качество, график, затраты и кадры. Каждый из параметров может относиться к одной из категорий: ограничение (лимитирующий фактор, в рамках которого должен оперировать менеджер), ключевой фактор (важный фактор успеха, ограниченно гибкий при изменениях) и степень свободы (фактор, который можно в некоторой степени изменять). Тогда расстановка приоритетов – это соотнесение параметров и категорий параметров.

6. Операционная среда.

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

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

Вопросы для самоконтроля

1. Каковы основные цели анализа предметной области?

2. Как используется методика «будет – не будет» при определении области действия проекта?

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

4. Для каких программных систем должен проводиться анализ осуществимости?

5. Что определяют бизнес-требования и бизнес-правила?

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

7. Что определяет образ продукта и границы проекта?

8. Перечислите основные разделы документа, описывающего образ продукта и границы проекта?

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

3.1. Определение способа сбора и анализа требований

3.1.1. Источники возникновения требований

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

· требования, определяемые предметной областью;

· требования, определяемые пользователями системы.

Под требованиями, определяемыми предметной областью здесь понимаются ограничения, накладываемые на программную систему законами природы и, которые поэтому нельзя изменить. Источниками остальных требований являются люди. Чем меньше объективных ограничений имеет проблема, тем большее количество ее ограничений должно быть получено от людей. Для большинства распространенных («офисных») приложений этот источник поставляет более 80% требований.