Последнее время у меня часто спрашивают шаблон документа Концепция.
Поэтому я решил опубликовать шаблон, который я периодически использую в своей работе уже довольно давно.
Шаблон доступен по следующей ссылке http://www.msmirnov.ru/public/pm_doc_templates.zip
А теперь сам шаблон (без разбивки по страницам и без фирменного стиля, которым он должен обладать):
1.2. Характеристика продукта
Цели создания продукта. Его характеристика.
2. Позиционирование.
2.1. Описание проблемы.
Описание проблемы (или проблем), которые должен решить продукт.
Описание формируется по следующему правилу
Проблема состоит в том, что <в чем состоит проблема?>. Проблема затрагивает <кого затрагивает проблема?>. Это приводит к тому, что <к чему это приводит?>. Удачным решением была бы <описание предлагаемого решения>.
3. Описание пользователей.
Краткая сводная информация по типам пользователей.
3.1. Типы пользователей
3.1.1. Тип пользователя.
Краткая характеристика. Основные потребности. Уровень технической грамотности.
3.2. Среда пользователей
3.2.1. В каком режиме и как часто будет происходить работа тех или иных пользователей? Какие типичные операции будут выполняться наиболее часто?
3.2.2. На какие платформы стоит ориентироваться при разработке продукта?
3.3. Основные потребности пользователей.
3.3.1. Тип пользователя.
3.3.1.1. Список основных потребностей.
4. Краткое описание продукта
4.1. Общий вид продукта
Диаграмма структуры организации продукта в разбивке на подсистемы или компоненты.
Описание подсистем и компонентов.
4.2. Краткий обзор возможностей
4.3. Предположения и зависимости
4.3.1. Перечень предположений и зависимостей.
5. Функции продукта
5.1. Обязательные функции для версии 1.0
Список функций для текущей версии с указанием некоторых параметров:
Статус – Принята/Предложена
Приоритет – Полезная/Важный/Критический
Риск - Низкий/Средний/Высокий
Стабильность - Низкая/Средняя/Выскоая
6. Основные прецеденты
Перечень основных прецедентов.
6.1. Название прецедента
Описание прецедента.
7. Другие требования к продукту.
Описание нефункциональных требований.
7.1. Применяемые стандарты.
7.1.1. Перечень применяемых стандартов.
7.2. Системные требования.
7.2.1. Перечень системных требований.
7.3. Инсталляция.
Требования к инсталляции и настройке.
7.4. Требования к производительности.
7.4.1. Перечень требований к производительности.
8. Требования к документации
8.1. Документация для пользователей
8.1.1. Руководство пользователя
Перечень материалов для конечных пользователей.
8.1.2. Руководство по инсталляции и конфигурации
Перечень материалов по настройке.
9. Глоссарий
9.1. Определения данного документа
9.1.1. Атрибуты функций
9.1.1.1. Статус - отслеживает ход процесса определения базового уровня проекта и последующей разработки. Пример, функция может иметь статус предлагаемая, утвержденная, включенная
9.1.1.2. Приоритет - Определение относительных приоритетов или полезности для конечного пользователя открывает путь к диалогу между заинтересованными лицами и членами команды разработчиков. Этот атрибут используется при управлении масштабом и определении очередности. Пример, определение функции как критической, важной, полезной
9.1.1.3. Риск - Вероятность того, что данная функция вызовет нежелательные последствия, такие как увеличение расходов, отставание от графика или даже закрытие проекта. Пример, высокий, средний и низкий уровень риска
9.1.1.4. Стабильность - Вероятность того, что будет меняться данная функция или ее понимание командой. Используется для того, чтобы помочь при определении приоритетов разработки и выявлении тех элементов, для которых следующим действием должно стать дополнительное исследование
9.1.1.5. Целевая версия - Указание версии продукта, в которой впервые появится реализация данной функции. Комбинирование этого атрибута с полем статуса даст команде возможность предлагать, записывать и обсуждать различные функции, не принимая их к разработке.
9.1.1.6. Назначение - Во многих проектах функции будут предназначаться "функциональным командам", ответственным за дальнейшую их доработку, написание программных требований, а также, возможно, их реализацию
9.1.1.7. Обоснование - Используется для отслеживания источника запрашиваемой функции. Например, ссылка может указывать па страницу или номер строки спецификации продукта или временной маркер на видеозаписи важного интервью с клиентом.
Поэтому я решил опубликовать шаблон, который я периодически использую в своей работе уже довольно давно.
Шаблон доступен по следующей ссылке http://www.msmirnov.ru/public/pm_doc_templates.zip
А теперь сам шаблон (без разбивки по страницам и без фирменного стиля, которым он должен обладать):
Документ-концепция
<Название проекта>
1. Введение
1.1. Цель документа-концепции.
Этот документ описывает текущее состояние концепции <название проекта>.
Цели создания продукта. Его характеристика.
2. Позиционирование.
2.1. Описание проблемы.
Описание проблемы (или проблем), которые должен решить продукт.
Описание формируется по следующему правилу
Проблема состоит в том, что <в чем состоит проблема?>. Проблема затрагивает <кого затрагивает проблема?>. Это приводит к тому, что <к чему это приводит?>. Удачным решением была бы <описание предлагаемого решения>.
3. Описание пользователей.
Краткая сводная информация по типам пользователей.
3.1. Типы пользователей
3.1.1. Тип пользователя.
Краткая характеристика. Основные потребности. Уровень технической грамотности.
3.2. Среда пользователей
3.2.1. В каком режиме и как часто будет происходить работа тех или иных пользователей? Какие типичные операции будут выполняться наиболее часто?
3.2.2. На какие платформы стоит ориентироваться при разработке продукта?
3.3. Основные потребности пользователей.
3.3.1. Тип пользователя.
3.3.1.1. Список основных потребностей.
4. Краткое описание продукта
4.1. Общий вид продукта
Диаграмма структуры организации продукта в разбивке на подсистемы или компоненты.
Описание подсистем и компонентов.
- Подсистема или компонент.
Описание решаемых задач.
4.2. Краткий обзор возможностей
Предоставляемая возможность
|
Функция
|
Предлагаемая возможность
|
Перечень функций
|
4.3. Предположения и зависимости
4.3.1. Перечень предположений и зависимостей.
5. Функции продукта
5.1. Обязательные функции для версии 1.0
Список функций для текущей версии с указанием некоторых параметров:
Статус – Принята/Предложена
Приоритет – Полезная/Важный/Критический
Риск - Низкий/Средний/Высокий
Стабильность - Низкая/Средняя/Выскоая
Функция
|
Статус
|
Приоритет
|
Трудозатраты
|
Риск
|
Стабильность
|
6. Основные прецеденты
Перечень основных прецедентов.
6.1. Название прецедента
Описание прецедента.
7. Другие требования к продукту.
Описание нефункциональных требований.
7.1. Применяемые стандарты.
7.1.1. Перечень применяемых стандартов.
7.2. Системные требования.
7.2.1. Перечень системных требований.
7.3. Инсталляция.
Требования к инсталляции и настройке.
7.4. Требования к производительности.
7.4.1. Перечень требований к производительности.
8. Требования к документации
8.1. Документация для пользователей
8.1.1. Руководство пользователя
Перечень материалов для конечных пользователей.
8.1.2. Руководство по инсталляции и конфигурации
Перечень материалов по настройке.
9. Глоссарий
9.1. Определения данного документа
9.1.1. Атрибуты функций
9.1.1.1. Статус - отслеживает ход процесса определения базового уровня проекта и последующей разработки. Пример, функция может иметь статус предлагаемая, утвержденная, включенная
9.1.1.2. Приоритет - Определение относительных приоритетов или полезности для конечного пользователя открывает путь к диалогу между заинтересованными лицами и членами команды разработчиков. Этот атрибут используется при управлении масштабом и определении очередности. Пример, определение функции как критической, важной, полезной
9.1.1.3. Риск - Вероятность того, что данная функция вызовет нежелательные последствия, такие как увеличение расходов, отставание от графика или даже закрытие проекта. Пример, высокий, средний и низкий уровень риска
9.1.1.4. Стабильность - Вероятность того, что будет меняться данная функция или ее понимание командой. Используется для того, чтобы помочь при определении приоритетов разработки и выявлении тех элементов, для которых следующим действием должно стать дополнительное исследование
9.1.1.5. Целевая версия - Указание версии продукта, в которой впервые появится реализация данной функции. Комбинирование этого атрибута с полем статуса даст команде возможность предлагать, записывать и обсуждать различные функции, не принимая их к разработке.
9.1.1.6. Назначение - Во многих проектах функции будут предназначаться "функциональным командам", ответственным за дальнейшую их доработку, написание программных требований, а также, возможно, их реализацию
9.1.1.7. Обоснование - Используется для отслеживания источника запрашиваемой функции. Например, ссылка может указывать па страницу или номер строки спецификации продукта или временной маркер на видеозаписи важного интервью с клиентом.
Комментариев нет:
Отправить комментарий