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

1. Одиннадцатая независимая научно-практическая
конференция «Разработка ПО 2015»
22 - 24 октября, Москва
Анна Абрамова
Управление требованиями –
это не только требования

2. Абрамова Анна
7 лет опыт работы в качестве системного и бизнес-аналитика
Предметные области: платёжные системы, телекоммуникации, медицина
Лидер сообщества аналитиков СПб с 2013 года
6 лет опыт работы в качестве преподавателя/тренера
Опыт в проектах: сложная предметная область, тиражируемый продукт, распределённая команда
Со стороны разработки

3. Управляемость
Куда мы
идём?
Сколько нам
осталось идти?
Где мы?

4. Управление требованиями и управление проектом
Деньги
Время Результат
Требования
Управление
требованиями

5. Системные требования - иерархический чеклист
Требование 1 Требование 1.1
Требование 1.2
…
…
… …
…
Требование 1.3
Требование 2 Требование 2.1
Требование 2.2
Требование 2.3
…… …
… …
……
… …
…
… …

6. Информация проекта ≠ требования
Бизнес-
потребности
Системные
требования
Модель
предметной
области
Входящие
запросы
Прототипы
интерфейсов
Описание
системы

7. Различие видов информации проекта
Бизнес-
потребности
Модель
предметной
области
Системные
требования
Входящие
запросы
Прототипы
интерфейсов
Роль
ответственного
Бизнес-
аналитик
Бизнес-
аналитик
Системный
аналитик
Бизнес-
аналитик
Проекти-
ровщик
интерфейсов
Структура
текст
Текст+
модель
дерево
Текст/
Задачи
Картинки/
Спецформат
Частота
изменения
низкая низкая средняя + высокая
Критичность
изменения
высокая высокая средняя - низкая
Согласование с
Заказчиком
+ + +/- + +/-

8. Задачи
Доопределить проект
Обосновать текущее решение
Отслеживать объем работ
Оценивать критичность запросов для разработки
Обеспечивать управляемость на длительном промежутке времени

9. Задача 1. Доопределить проект
Вхождение в
новый проект
Выход из
медового
месяца со
старым

10. Нужны требования – нужен аналитик

11. Требования – функция от потребностей бизнеса
S𝑦𝑠𝑡𝑒𝑚 = 𝑅𝑄 𝐵𝑢𝑠𝑖𝑛𝑒𝑠𝑠
Бизнес-
потребности
Система
Требования

12. Понять, где находимся

13. Бизнес-потребности
Заинтересованные лица
Бизнес-контекст
Проблемы/цели/задачи
Среда эксплуатации
Подпись заказчика

14. Кто будет делать?

15. А теперь системные требования

16. Миф: разработчик – не писатель
Разработчик
Время
Шаблон
+ Автодокументирование

17. Доопределение проекта
Бизнес-
потребности
Состояние
системы
Развиваем!
Системные
требования

18. Задача 3. Обосновать текущее решение
ЗапросыЗаказчик
Руководитель
Аналитик
Разработчик
Тестировщик

19. Сохранять запросы с указанием источника
Запросы
Документы
ЗадачиПочта

20. Фильтровать запросы на изменения

21. Решение: фиксировать и фильтровать запросы на изменения
Запросы
Системные
требования
Отказ
Новый
проект

22. Задача 4. Оценивать критичность запросов
Тип
информации
Бизнес-
потребности
Изменение
предметной
области
Реализация

23. Противодействие ролей
Прототип
интерфейса
Требование
Ответственный Проектировщик
интерфейсов
Аналитик
Частота
изменений
Часто, вместе с
реализацией
Редко

24. Процесс формирования структурной информации
Разбивать запрос на
атомарные
Проверять каждый
на соответствие
блоку информации
Оценивать
критичность
Формировать
системные
требования

25. Задача 4. Обеспечить управляемость на длительном
промежутке времени
Jira/TFS/RedMine
Бизнес-
потребности
Системные
требования
Модель
предметной
области
Входящие
запросы
Прототипы
интерфейсов

26. Требования в системе управления разработкой
Требование 1 Требование 1.1
Требование 1.2
…
…
… …
…
Требование 1.3
Требование 2 Требование 2.1
Требование 2.2
Требование 2.3
…… …
… …
……
… …
…
… …

27. Бизнес-потребности и предметная область в системе
Система Бизнес-
потребности
Предметная
область
Доступ
заказчика - + +
Атомарная
структура + - -

28. Варианты хранение информации
Бизнес-потребности Текст с подписью Документ
Модель предметной
области
Текст, модели Документ, Модель, Wiki
Системные
требования
Система управления +
плагин визуализации
запросов
Wiki
Входящие запросы Система управления С трассировкой на
требования
Прототипы
интерфейсов
SVN
Описание системы Автогенерация Текст

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

30. Управление
проектом
Требования
Система
Прототипы
Запросы
на изменения
Бизнес-
потребности
Предметная
область

31. Готова ответить на вопросы
 E-mail: abramova.web@gmail.com
 Skype: abramova_anna
 LinkedIn: https://ru.linkedin.com/in/annasergeevna
 Сообщество аналитиков Санкт-Петербурга
 E-mail: spbanalysts@gmail.com
 FB: https://www.facebook.com/groups/1376717479249794/
 VK: https://vk.com/spb_analytics