В отличие от Устава проекта Концепция (Vision) проекта в большей степени нужна для проектной команды, а не для тех лиц, чьи интересы команда обслуживает.
Этот документ должен содержать как общую информацию о проекте, так и ссылки на всевозможные требования и описания продукта. Каждый член команды проекта сможет самостоятельно найти в Концепции максимум необходимой информации.
Концепция содержит описание «проектного подхода». Она отвечает на вопросы:
- Какие правила общения с заказчиком установлены в проекте?
- Как условились с командой проводить совещания?
- Где посмотреть, кто, за что отвечает на проекте?
- Как поступать при необходимости внести изменения в первоначальные требования или добавить новое?
Сама по себе концепция может быть немногословна, но она должна содержать ссылки на все необходимые внешние документы.
Структура документа Концепция, как правило, включает следующие разделы:
1. Введение
1.1. Цель
Определяется цель этого документа
1.2. Область применения
Определяется область применения системы
1.3. Определения, акронимы и сокращения
Приводится глоссарий (словарь).
2. Основные положения
2.1. Возможности системы
Описываются возможности системы
2.2. Формулировка проблемы
2.3. Формула продукта
3. Описание заинтересованных лиц и пользователей
В этом разделе приводится описание типов пользователей.
3.1. Потенциальные потребители
Приводится краткая характеристика.
3.2. Заинтересованные лица
В разделе приводится описание заинтересованных лиц в следующей форме:
3.3. Пользователи
В разделе приводится описание пользователей системы в следующей форме:
3.4. Пользовательская среда
Приводится краткое описание пользовательской среды.
3.5. Основные потребности заинтересованных лиц/пользователей
Приводится перечень потребностей в форме:
4. Обзор продукта
Этот раздел концепции содержит общее описание возможностей системы, ее внешних интерфейсов, а также конфигурации.
4.1. Перспективы продукта
Указываются возможные перспективы развития программного продукта
4.2. Возможности продукта
Приводятся основные возможности системы в терминах ее
свойств и достоинств с точки зрения потребителей.
4.3. Проектные ограничения
Отражаются все проектные ограничения (по времени разработки, стоимости и качеству).
4.4. Стоимость проекта
Выполняется ориентировочная оценка проекта.
4.5. Лицензирование и установка
Приводятся требования к лицензированию и установке
5. Функциональные возможности продукта
В данном разделе определяются и приводятся высокоуровневые
функциональные возможности (свойства) системы, которые необходимы сточки зрения пользователей (варианты использования).
5.1. Вход в систему
Устанавливается правила входа в систему.
5.2. …….
И так далее, все, что связано с функциональными возможностями.
6. Требования к качеству
В этом разделе определяются требования к производительности, надежности, удобству использования и другим характеристикам
качества системы.
Готовность:
Удобство использования:
Сопровождаемость:
7. Приоритеты
Данный раздел определяет относительную важность предлагаемых функциональных возможностей системы.
8. Прочие требования к продукту
8.1. Используемые стандарты
Требования к стандартам интерфейса, …
8.2. Системные требования
8.3. Требования к производительности
8.4. Требования к окружающей среде
9. Требования к документации
9.1. Руководство пользователя
Руководство пользователя должно описывать использование системы с точки зрения пользователей и включать:
- минимальные системные требования;
- установку ПК-клиента;
- вход в систему;
- выход из системы;
- все функциональные возможности системы;
- информацию о поддержке пользователей.
9.2. Диалоговая помощь
Указывается, какие средства диалоговой помощи будут предусмотрены в системе.
9.3. Руководство по установке, конфигурированию
9.4. Маркировка и упаковка
Можно использовать различные шаблоны концепции, важно только, чтобы в документе отражались все необходимые сведения. Наиболее распространенная форма Концепции приведена в приложении.
В следующей статье приводятся рекомендации к разработке отдельных разделов Концепции проекта.