План управления требованиями проекта

Аббревиатура	Расшифровка	Описание
RTM	Requirements Traceability Matrix	Матрица отслеживания требований
WBS	Work Breakdown Structure	Иерархическая структура работ
REQ	Requirement	Требование (используется в ID требований)
TC	Test Case	Тестовый сценарий
ЗИТ	Запрос на изменение требования	Формальный запрос на изменение требования проекта
RACI	Responsible, Accountable, Consulted, Informed	Матрица ответственности
BSL	Built-in Script Language	Встроенный язык 1С
БА	Бизнес-аналитик	Роль в проекте
РП	Руководитель проекта	Роль в проекте (Нечаева Н.А.)
ВР	Ведущий разработчик	Роль в проекте
СА	Системный администратор	Роль в проекте
ИП	Индивидуальный предприниматель	Организационно-правовая форма
ООО	Общество с ограниченной ответственностью	Организационно-правовая форма
ТЗ	Техническое задание	Документ с детальными требованиями
ID	Identifier	Идентификатор, уникальный номер

Термин	Определение
Система лояльности	Механизм автоматического предоставления скидок клиентам на основе накопленной суммы выкупа
Сумма выкупа	Общая сумма всех покупок клиента в магазине “1Стиль”
Уровень клиента	Классификация клиента (Базовый, Премиальный, ВИП) на основе суммы выкупа
Базовый план	Утвержденная версия плана проекта (по содержанию, расписанию, стоимости)
Валидация требований	Процесс проверки требований на корректность и соответствие критериям качества
Приоритизация	Процесс определения важности и очередности реализации требований
Критерий приемки	Условия, при выполнении которых требование считается реализованным
Комитет по изменениям	Группа специалистов, принимающая решения об одобрении изменений требований

Категория	Описание	Приоритет	Ответственный	Примеры в проекте
Бизнес-требования	Цели и потребности магазина “1Стиль”	Критический	ИП Сорокин Г.В.	Увеличение доли постоянных клиентов на 30%, рост среднего чека на 15%
Функциональные	Функции системы	Высокий	Бизнес-аналитик	Расчет суммы выкупа, автоматическое применение скидок, формирование отчетов
Нефункциональные	Качественные характеристики	Высокий	Ведущий разработчик	Время обработки документа ≤ 2 сек, надежность, удобство интерфейса
Технические	Технические ограничения	Высокий	Системный администратор	Платформа 1С:Предприятие 8.3, без изменения типовых механизмов
Требования к интерфейсу	Удобство использования	Средний	Бизнес-аналитик	Интуитивный интерфейс для менеджеров, быстрый доступ к справочникам

Метод	Применение в проекте	Участники	Результат	Период
Интервью с заказчиком	Сбор бизнес-требований к системе лояльности	ИП Сорокин Г.В., Бизнес-аналитик	Требования к уровням клиентов, размерам скидок	26-27 августа
Анализ текущих процессов	Изучение работы магазина “как есть”	Бизнес-аналитик, менеджеры по продажам	Процессы продаж, учета товаров	28 августа
Интервью с пользователями	Сбор требований к удобству системы	Менеджеры, бухгалтер, БА	Требования к интерфейсу, отчетам	29-30 августа
Анализ аналогов	Изучение систем лояльности конкурентов	Бизнес-аналитик	Лучшие практики, идеи	31 августа
Мозговой штурм	Генерация идей по функционалу	Команда проекта	Дополнительные функции	01 сентября
Прототипирование	Визуализация интерфейсов 1С	Ведущий разработчик	Макеты форм документов и справочников	02-05 сентября

Источник	Тип требований	Контактное лицо
Заказчик (ИП Сорокин Г.В.)	Бизнес-требования, критерии успеха	Спонсор проекта
Менеджеры по продажам	Функциональные требования к продажам	Будущие пользователи системы
Сотрудники склада	Требования к учету товаров	Пользователи модуля поставок
Бухгалтер	Требования к отчетности	Пользователь отчетов
Нормативные документы	Требования к учету, налогообложению	-
Документация 1С	Технические ограничения платформы	Техподдержка 1С

---

4. Документирование требований

4.1 Структура документа требований

Техническое задание на автоматизированную систему для магазина “1Стиль” включает:

1. Введение и область применения
   • Цель автоматизации магазина одежды
   • Границы проекта
2. Бизнес-требования
   • Увеличение лояльности клиентов
   • Рост выручки и среднего чека
   • Автоматизация учета товаров
   • Автоматизация системы скидок
3. Функциональные требования
   • Справочники (Контрагенты, Номенклатура, Организации)
   • Документы (Реализация товара, Поставка товара)
   • Регистры (Остатки номенклатуры, Сумма выкупа клиента, Цены номенклатуры)
   • Отчеты (Остатки номенклатуры, Сумма выкупа)
   • Система лояльности (уровни клиентов, автоматическое применение скидок)
4. Нефункциональные требования
   • Производительность (время обработки документа ≤ 2 сек)
   • Надежность (отсутствие потери данных)
   • Удобство использования (интуитивный интерфейс)
   • Безопасность (права доступа по ролям)
5. Технические ограничения
   • Платформа: 1С:Предприятие 8.3 (не ниже версии 8.3.15)
   • Без изменения типовых механизмов 1С
   • Язык программирования: 1С:Встроенный язык (BSL)
6. Требования к интерфейсу
   • Удобство работы для менеджеров по продажам
   • Быстрый доступ к справочникам и документам
   • Понятные формы документов
7. Требования к отчетности
   • Отчет “Остатки номенклатуры”
   • Отчет “Сумма выкупа клиента”
8. Критерии приемки
   • Функциональное тестирование всех модулей
   • Нагрузочное тестирование
   • Пользовательское тестирование

4.2 Формат описания требования

Шаблон требования для проекта “1Стиль”:

• ID: Уникальный идентификатор (REQ-1ST-XXX, где 1ST - код проекта)
• Название: Краткое название требования
• Описание: Детальное описание функции/характеристики
• Категория: Бизнес / Функциональное / Нефункциональное / Техническое / Интерфейс
• Приоритет: Критический / Высокий / Средний / Низкий
• Источник: Кто предоставил требование (заказчик, менеджер, бухгалтер и т.д.)
• Критерий приемки: Как проверить выполнение требования
• Зависимости: Связанные требования (ID других требований)
• Статус: Новое / Утверждено / В разработке / Реализовано / Протестировано / Принято
• WBS: Элемент иерархической структуры работ
• Тестовый сценарий: ID тестового сценария (TC-XXX)

4.3 Примеры документирования требований проекта

Пример 1: Функциональное требование

• ID: REQ-1ST-001
• Название: Автоматический расчет суммы выкупа клиента
• Описание: Система должна автоматически накапливать сумму всех покупок клиента в регистре накопления “Сумма выкупа клиента” при проведении документа “Реализация товара”
• Категория: Функциональное
• Приоритет: Критический
• Источник: ИП Сорокин Г.В.
• Критерий приемки: При проведении документа реализации сумма документа добавляется к общей сумме выкупа клиента в регистре
• Зависимости: REQ-1ST-002 (Определение уровня клиента)
• Статус: Утверждено
• WBS: 4.4 (Создание документов)
• Тестовый сценарий: TC-001

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

• ID: REQ-1ST-010
• Название: Увеличение доли постоянных клиентов
• Описание: Система лояльности должна способствовать увеличению доли постоянных клиентов на 30% в течение 12 месяцев после внедрения
• Категория: Бизнес-требование
• Приоритет: Критический
• Источник: ИП Сорокин Г.В.
• Критерий приемки: Через 12 месяцев после внедрения доля постоянных клиентов увеличилась на 30% (измеряется по данным системы)
• Зависимости: REQ-1ST-001, REQ-1ST-002, REQ-1ST-003
• Статус: Утверждено
• WBS: 1.0 (Весь проект)
• Тестовый сценарий: -

---

5. Матрица отслеживания требований (RTM - Requirements Traceability Matrix)

5.1 Назначение матрицы отслеживания

Матрица отслеживания требований обеспечивает:

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

5.2 Полная матрица отслеживания требований проекта “1Стиль”

5.3 Статистика требований

По статусу (на момент утверждения плана - 25 августа 2025):

• Утверждено: 20 требований (100%)
• К реализации: 20 требований
• Плановая дата начала реализации: 06 сентября 2025

По приоритету:

• Критический: 13 требований (65%)
• Высокий: 7 требований (35%)

По категориям:

• Функциональные: 14 требований (70%)
• Нефункциональные: 3 требования (15%)
• Технические: 2 требования (10%)
• Бизнес-требования: 3 требования (15%)

5.4 Цель матрицы отслеживания

• Обеспечить прослеживаемость от требования до реализации и тестирования
• Контролировать выполнение всех требований проекта
• Связывать требования с элементами WBS и тестовыми сценариями
• Управлять изменениями требований и их влиянием на проект
• Предоставлять отчетность заказчику о статусе требований

---

6. Приоритизация требований

6.1 Метод MoSCoW для проекта “1Стиль”

Для приоритизации требований проекта используется метод MoSCoW с учетом специфики магазина одежды:

6.2 Критерии приоритизации требований

Для проекта магазина “1Стиль” используются следующие критерии:

1. Бизнес-ценность (вес 40%)

• Влияние на увеличение выручки
• Повышение лояльности клиентов
• Экономия времени персонала
• Конкурентное преимущество

2. Срочность (вес 25%)

• Критичность для открытия магазина
• Зависимость других требований
• Требования заказчика

3. Стоимость и сложность реализации (вес 20%)

• Трудозатраты на разработку (человеко-дни)
• Необходимость привлечения дополнительных специалистов
• Техническая сложность на платформе 1С

4. Риски (вес 15%)

• Технические риски реализации
• Риски изменения требований
• Риски для проекта при неудаче

6.3 Матрица приоритизации (Value vs Effort)

6.4 Процесс приоритизации

1. Сбор требований от всех заинтересованных сторон (26-31 августа)
2. Первичная оценка бизнес-аналитиком по критериям (01 сентября)
3. Техническая оценка сложности ведущим разработчиком (02 сентября)
4. Совместная сессия приоритизации с заказчиком (02 сентября)
5. Финальное утверждение приоритетов заказчиком (05 сентября)
6. Документирование в матрице отслеживания требований

---

7. Управление изменениями требований

7.1 Процедура изменения требования

Этапы процесса управления изменениями:

Шаг 1: Инициация запроса на изменение

• Любая заинтересованная сторона может инициировать запрос
• Заполнение формы “Запрос на изменение требования” (ЗИТ)
• Указание обоснования изменения
• Ответственный: Инициатор изменения

Шаг 2: Первичный анализ (1 рабочий день)

• Проверка корректности заполнения запроса
• Первичная оценка влияния
• Категоризация изменения (незначительное/среднее/критическое)
• Ответственный: Бизнес-аналитик

Шаг 3: Детальный анализ влияния (2-3 рабочих дня)

Анализ влияния изменения на:

• Другие требования: зависимости, конфликты
• WBS и расписание: изменение сроков, добавление/удаление работ
• Стоимость проекта: дополнительные затраты
• Качество: влияние на нефункциональные требования
• Риски: новые риски или изменение существующих
• Документацию: необходимые обновления
• Ответственный: Бизнес-аналитик + Ведущий разработчик

Шаг 4: Рассмотрение комитетом по управлению изменениями

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

Состав комитета:

• Председатель: ИП Сорокин Г.В. (заказчик)
• Секретарь: Руководитель проекта (Нечаева Н.А.)
• Члены: Ведущий разработчик, Бизнес-аналитик

Шаг 5: Принятие решения

Возможные решения:

• Одобрить - реализовать изменение
• Одобрить с условиями - реализовать с ограничениями
• Отложить - рассмотреть в будущих версиях
• Отклонить - не реализовывать

Шаг 6: Обновление документации (1 рабочий день)

При одобрении изменения:

• Обновление матрицы отслеживания требований
• Актуализация технического задания
• Обновление базовых планов (содержание, расписание, стоимость)
• Корректировка тестовых сценариев
• Ответственный: Бизнес-аналитик

Шаг 7: Коммуникация изменений

• Уведомление всех заинтересованных сторон
• Рассылка актуализированной документации
• Фиксация в журнале изменений
• Ответственный: Руководитель проекта

7.2 Пороги одобрения изменений

7.3 Контроль изменений требований

Метрики управления изменениями:

7.4 Журнал изменений требований

Все изменения требований документируются в журнале с указанием:

7.5 Предотвращение изменений требований

Для минимизации изменений требований в проекте предусмотрены:

1. Тщательный сбор требований на этапе планирования (26 августа - 05 сентября)
2. Прототипирование ключевых интерфейсов (02-05 сентября)
3. Валидация требований с заказчиком перед утверждением ТЗ (05 сентября)
4. Регулярные демонстрации результатов заказчику (еженедельно)
5. Вовлечение пользователей в тестирование (октябрь-ноябрь)

---

8. Валидация требований

8.1 Критерии валидации требований

Каждое требование проекта “1Стиль” должно соответствовать критериям качества (используется аббревиатура SMART+):

S - Specific (Конкретное)

• Требование четко определяет, что нужно сделать
• Нет двусмысленных формулировок
• Пример: ✓ “Система должна рассчитывать сумму выкупа клиента автоматически” vs ✗ “Система должна работать с клиентами”

M - Measurable (Измеримое)

• Есть критерий приемки
• Можно проверить выполнение
• Пример: ✓ “Время обработки документа ≤ 2 секунд” vs ✗ “Система должна работать быстро”

A - Achievable (Достижимое)

• Технически возможно реализовать на платформе 1С:Предприятие 8.3
• Есть необходимые компетенции в команде
• Укладывается в сроки и бюджет проекта

R - Relevant (Актуальное)

• Решает реальную проблему магазина “1Стиль”
• Связано с целями проекта (лояльность, автоматизация)
• Имеет бизнес-ценность

T - Testable (Проверяемое)

• Можно разработать тестовый сценарий
• Результат проверяем
• Критерии приемки однозначны

+ Дополнительные критерии:

• Полное: Вся необходимая информация для реализации
• Последовательное: Нет противоречий с другими требованиями
• Приоритизированное: Определен приоритет (Must/Should/Could/Won’t)
• Понятное: Понятно всем заинтересованным сторонам

8.2 Процесс валидации требований

Трехуровневая валидация:

Уровень 1: Внутренняя валидация (команда проекта)

• Участники: Бизнес-аналитик, Ведущий разработчик
• Срок: 03 сентября 2025
• Проверяется:
  • Соответствие критериям SMART+
  • Техническая реализуемость на платформе 1С
  • Полнота описания требования
  • Отсутствие противоречий между требованиями
  • Наличие зависимостей
• Результат: Список требований, готовых к внешней валидации

Уровень 2: Внешняя валидация (заказчик и пользователи)

• Участники: ИП Сорокин Г.В., менеджеры по продажам, бухгалтер
• Срок: 04-05 сентября 2025
• Проверяется:
  • Соответствие бизнес-потребностям магазина
  • Понятность требований для пользователей
  • Приоритеты требований
  • Критерии приемки
• Метод: Совместные сессии, демонстрация прототипов
• Результат: Утвержденный список требований

Уровень 3: Техническая валидация

• Участники: Ведущий разработчик, Системный администратор
• Срок: 05 сентября 2025
• Проверяется:
  • Реализуемость на платформе 1С:Предприятие 8.3
  • Соответствие архитектуре решения
  • Отсутствие конфликтов с типовыми механизмами 1С
  • Оценка трудозатрат
  • Технические риски
• Результат: Подтверждение технической реализуемости

8.3 Чек-лист валидации требования

Перед утверждением каждое требование проверяется по чек-листу:

• ID присвоен в формате REQ-1ST-XXX
• Название краткое и понятное
• Описание детальное и однозначное
• Категория определена (Бизнес/Функциональное/Нефункциональное/Техническое)
• Приоритет назначен (Критический/Высокий/Средний/Низкий)
• Источник указан (заказчик/менеджер/бухгалтер и т.д.)
• Критерий приемки сформулирован четко
• Зависимости выявлены и задокументированы
• WBS привязка к элементу работ
• Тестовый сценарий запланирован
• Реализуемость подтверждена технически
• Утверждение получено от заказчика

8.4 Обработка невалидных требований

Если требование не прошло валидацию:

1. Доработка - уточнение формулировки, добавление деталей
2. Разделение - если требование слишком крупное, разбить на несколько
3. Объединение - если требования дублируются, объединить
4. Отклонение - если требование не актуально или нереализуемо

---

9. Роли и ответственность в управлении требованиями

9.1 Матрица ответственности (RACI)

Условные обозначения:

• R - Responsible (Ответственный исполнитель) - выполняет работу
• A - Accountable (Подотчетный) - несет ответственность за результат, принимает решения
• C - Consulted (Консультируемый) - дает экспертное мнение
• I - Informed (Информируемый) - получает информацию о результатах

9.2 Детальное описание ролей

ИП Сорокин Г.В. (Заказчик, Спонсор проекта)

• Предоставление бизнес-требований и целей проекта
• Утверждение всех требований и их изменений
• Финальное решение по приоритетам требований
• Участие в валидации требований
• Одобрение критических изменений требований
• Приемка результатов реализации требований

Руководитель проекта (Нечаева Н.А.)

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

Бизнес-аналитик

• Сбор требований от всех заинтересованных сторон
• Детальное документирование требований
• Создание и ведение матрицы отслеживания требований
• Анализ требований на полноту и непротиворечивость
• Прототипирование решений
• Валидация требований с пользователями
• Анализ влияния изменений требований
• Подготовка отчетов по требованиям

Ведущий разработчик

• Техническая валидация требований
• Оценка реализуемости на платформе 1С
• Оценка трудозатрат на реализацию
• Выявление технических рисков
• Участие в анализе влияния изменений
• Консультации по техническим вопросам

Тестировщик

• Разработка критериев приемки требований
• Создание тестовых сценариев
• Участие в валидации требований
• Проверка реализации требований
• Отчеты о соответствии реализации требованиям

Системный администратор

• Предоставление технических ограничений (инфраструктура)
• Оценка требований к производительности
• Консультации по вопросам развертывания
• Валидация нефункциональных требований

Менеджеры по продажам

• Предоставление требований к модулю продаж
• Описание бизнес-процессов продаж
• Участие в валидации интерфейсов
• Пользовательское тестирование

Бухгалтер

• Предоставление требований к отчетности
• Проверка соответствия нормативным требованиям
• Валидация отчетов
• Пользовательское тестирование отчетов

9.3 Коммуникации по требованиям

Регулярные встречи:

• Еженедельные статус-встречи (понедельник, 10:00) - обсуждение статуса требований, изменений
• Сессии валидации (по необходимости) - совместная проверка требований с пользователями
• Заседания комитета по изменениям (по запросу, не реже 1 раза в 2 недели)

Отчетность:

• Еженедельный статус требований для руководителя проекта
• Ежемесячный отчет для заказчика о выполнении требований
• Журнал изменений требований (обновляется по факту изменений)

---

10. Инструменты управления требованиями

10.1 Инструменты для проекта “1Стиль”

10.2 Структура хранения требований

Расположение документов:

/docs/
  /План_управления_требованиями/
    - План_управления_требованиями.md
    - План_управления_требованиями.pdf
  /Техническое_задание/
    - ТЗ.md
    - Требования_детальные.xlsx
    - Матрица_отслеживания_требований.xlsx
  /Прототипы/
    - Прототипы_интерфейсов.png
  /Изменения_требований/
    - Журнал_изменений_требований.xlsx
    - Запросы_на_изменения/

10.3 Версионирование требований

• Версия 1.0 - Начальная версия ТЗ (05 сентября 2025)
• Версия 1.x - Незначительные изменения (уточнения)
• Версия 2.0 - Значительные изменения (добавление/удаление требований)

Контроль версий:

• Все изменения фиксируются в Git
• История изменений доступна всем участникам проекта
• Каждая версия утверждается заказчиком

10.4 Шаблоны документов

Для проекта используются следующие шаблоны:

1. Шаблон описания требования (см. раздел 4.2)
2. Форма “Запрос на изменение требования”
3. Матрица отслеживания требований (см. раздел 5.2)
4. Чек-лист валидации требования (см. раздел 8.3)

---

11. Заключение

11.1 Критерии успеха управления требованиями

Управление требованиями в проекте считается успешным, если:

• ✓ Все требования собраны, задокументированы и утверждены заказчиком (до 05 сентября 2025)
• ✓ Матрица отслеживания требований актуальна и доступна всем участникам
• ✓ Количество изменений требований не превышает 10% от общего числа
• ✓ Все требования будут реализованы и протестированы согласно критериям приемки
• ✓ Заказчик удовлетворен реализацией требований (оценка ≥ 4/5)

11.2 Ключевые даты

• 26-31 августа 2025 - Сбор требований
• 01-05 сентября 2025 - Валидация и утверждение требований
• 05 сентября 2025 - Финальное утверждение ТЗ заказчиком
• Еженедельно (сентябрь-декабрь) - Контроль выполнения требований
• 31 декабря 2025 - Плановая дата приемки всех требований заказчиком