1. ПРАКТИКА
УПРАВЛЕНИЯ
ТРЕБОВАНИЯМИ
Интенсив-тренинг

2. Цели тренинга
 Знакомство с полным процессом
управления требованиями при
разработке ПО
 Формирование практических навыков
по управлению требованиями
 Определение направлений для
самостоятельного углубленного
изучения
Тренинг «Практика управления требованиями»
2

3. Для кого полезен?
 Начинающим аналитикам для
эффективного освоения и закрепления
необходимых компетенций
 Опытным аналитикам для
систематизации знаний и знакомства с
особенностями работы с различными
видами требований в различных типах
проектов
Тренинг «Практика управления требованиями»
3

4. Структура
1. Роль аналитика и процесс управления
требованиями
2. Техника сбора требований
3. Анализ и систематизация требований
4. Определение концепции
продукта/решения
5. Прототипы и UI спецификации
6. Разработка спецификации требований
7. Организация сдачи проекта
8. Управление изменениями
Тренинг «Практика управления требованиями»
4

5. Часть 1. Роль аналитика и процесс
управления требованиями

6. Что такое требования?
Это
 Условия или
возможности, необходимые
пользователю для решения
проблем и достижения целей;
Тренинг «Практика управления требованиями»
6
 Условия или возможности, которыми
должна обладать система или системные
компоненты.

7. Роль аналитика в проекте
Концепция
Проектиро
вание
Разработка Внедрение
Аналитик
Тренинг «Практика управления требованиями»
7

8. Задачи аналитика
1. Выявление требований
 Сбор, документирование, учет
2. Анализ требований
 Систематизация и приоритезация
3. Участие в проектировании решений
 Прототипирование, моделирование, специ
фицирование
4. Управление изменениями
5. Сдача проекта
Тренинг «Практика управления требованиями»
8

9. Компетенции аналитика
 Коммуникативность
 Аналитические
навыки
 Методики и
инструменты
Анализ
Коммуникация
Систематизация
Методики
Тренинг «Практика управления требованиями»
9

10. Процесс управления требованиями
Этап 1. Определение целей проекта
Этап 2. Сбор и анализ требований
Разработка концепции
Этап 3. Разработка спецификации
Договоренность о сдаче проекта
Этап 5. Управление изменениями
Этап 6. Сдача проекта и внедрение
Тренинг «Практика управления требованиями»
10

11. Пирамида требований
Как?
Что?
Зачем?
Потребности
Функционирование
Реализация
Концепция
Спецификация
ПО
Тренинг «Практика управления требованиями»
11

12. Трассировка требований
Заказчик
Пользователи
Исполнители
Сколько % времени тратиться на
непроизводственные активности
Нужна функция генерации сводного отчета о
затраченном времени с группировкой по проектам
Активность Кол-во часов % от всего времени
Проекты 2000 80%
Непроектное время 500 20%
Тренинг «Практика управления требованиями»
12

13. Важно!
Искусство аналитика – в умении
выбирать правильный ракурс в
передаче информации и в понимании
уровня достаточности требований.
Тренинг «Практика управления требованиями»
13

14. Часть 2. Техника сбора требований

15. Сбор требований
 Определить ключевых лиц проекта и
ЛПР (=лицо, принимающее решение)
 Определить источники требований
 Выявить требования
Тренинг «Практика управления требованиями»
15

16. Источники требований
 Заинтересованные лица
(клиент, пользователь, разработчик)
 Внешние организации (представители
смежных систем, гос. органы)
 Программное обеспечение (уже
используемое в компании, аналогичные на
рынке, конкурирующие)
 А еще регламенты, стандарты
индустрии, исследования рынка, личный
опыт… Тренинг «Практика управления требованиями»
16

17. Методы выявление требований
 Интервью
 Анкетирование
 Форум
 Изучение документов и бизнес-процессов
 Изучение аналогичного ПО
 Мозговой штурм
 Слежение
 Прототипы
 И т.п.
Тренинг «Практика управления требованиями»
17

18. Интервью. Ошибки и советы
Ошибки
 Бессистемное
интервью
 Скатывание до
малозначительных
деталей
 Озвучивание
решений вместо
выявления проблем
Что поможет
 Подготовленный
опросник:
• Цель проекта
• Кто пользователи
• Какие потребности
• Есть ли регламенты
 Придерживаемся целей
интервью
 Вопрос «А зачем?»
 Диктофон, блокнот и
ручка
Тренинг «Практика управления требованиями»
18

19. Важно!
 Источников требований МНОГО, важно
учесть ВСЕ
 Обязательно определяем потребность, из
которой проистекает требование
 Выявляем требования в несколько
итераций до тех пор, пока не будет
достигнут нужный уровень точности и
понимания текущего этапа
Тренинг «Практика управления требованиями»
19

20. Часть 3. Анализ и систематизация

21. Анализ требований
 Объединение
 Исключение дубликатов
 Систематизация и группировка
 Разрешение конфликтующих требований
 Исключение ненужных требований
 Добавление недостающих требований
 Трансформация требований
 Определение приоритетов
Тренинг «Практика управления требованиями»
21

22. Как разрешить противоречия?
 Кто будет пользоваться функционалом?
 Кто заказчик (ЛПР)?
 Поддержка нескольких альтернативных
вариантов реализации
Тренинг «Практика управления требованиями»
22

23. Как найти ненужные требования?
 Есть ли трассировка вверх до функций и
потребностей?
 Кто будет пользоваться данной
функцией?
 Какова бизнес-польза?
Тренинг «Практика управления требованиями»
23

24. Как найти недостающие требования?
 Каким образом пользователи и другие
объекты будут появляться в системе?
 В каких условиях будет
функционировать система?
Тренинг «Практика управления требованиями»
24

25. Трансформация требований
 Пример
Категория Группа Требование Источник
Функционирование Заполнение
отчетов
Отчеты должны
быть заполнены до
12.00 след. дня
Регламент
Функционирование Уведомления Отправка
уведомления о
незаполненном
отчете в 11.00
Аналитик
Функционирование Заполнение
отчетов
Блокирование
незаполненных
отчетов
Аналитик
Тренинг «Практика управления требованиями»
25

26. Важно!
 Когда требований становится много,
группируем их и систематизируем
 В случае противоречий ищем
компромиссные решения или решаем
через ЛПР
Тренинг «Практика управления требованиями»
26

27. Часть 4. Определение концепции
продукта/решения

28. Концепция (Vision)
 Vision –документ, описывающий систему в
общих чертах, фиксирующий потребности
пользователей, основные функции и другие
общие требования к проекту.
 Используется для:
• Осмысления предстоящей разработки и
достижения договоренности между
заинтересованными лицами
• В маркетинговых целях
Тренинг «Практика управления требованиями»
28

29. Важно!
 Быстро (от 1 до 2-4 недель)
 Кратко (до 20-30 страниц)
 На уровне «Потребность/Функционирование»
 Только основные функции (сгруппированные в
модули по 7+/- 2)
Тренинг «Практика управления требованиями»
29

30. Часть 5. Прототипирование и UI
спецификации

31. UI прототип
 UI прототип – это модель (эскиз)
пользовательского интерфейса.
 Используется для:
• Визуализация предполагаемого
решения
• Уточнения невысказанных
требований
Тренинг «Практика управления требованиями»
31

32. Инструменты
 Ручка и бумага
 Маркерная доска
 MS Office
 Balsamiq Mockups (www. balsamiq.com)
 Axure (www. axure.com)
Тренинг «Практика управления требованиями»
32

33. Часть 6. Спецификация требований

34. Подходы к разработке спецификаций
Agile
 Акцент на
небольшие
итерации
 Много общения
 Минимум
документов и
формализации
RUP
 Основательное
продумывание
решений и
требований
 Подробные
спецификации
Тренинг «Практика управления требованиями»
34

35. Артефакты аналитика в Agile
 Product Backlog – единое хранилище
всех требований
 User Story – описание требования
Тренинг «Практика управления требованиями»
35

36. Фундаментальный подход
(RUP)
 Создание спецификаций (Software
Requirements Specification)
 Описание функций в формате Use Cases
 Описание модели данных
 Описание модели состояний
Тренинг «Практика управления требованиями»
36

37. Часть 7. Организация сдачи проекта

38. Важно!
 Не так важно, как сделаешь проект.
Гораздо важнее то, как его сдашь!
Тренинг «Практика управления требованиями»
38

39. Часть 8. Управление изменениями

40. Изменение требований
 Источники изменений
• Внешние = Среда
функционирования или Клиент
• Внутренние = Исполнители или сам
Аналитик
Тренинг «Практика управления требованиями»
40

41. Реакция на изменения
 Зафиксировать новое требование
 Проанализировать новое требование и его
влияние
 Проинформировать заинтересованных лиц
 Принять решение (зависит от модели
разработки, временного фактора, сложности и
критичности изменения, влияния на проект в
целом)
• Не делать вообще
• Сделать позже
• Сделать сейчасТренинг «Практика управления требованиями»
41

42. Литература
 Business Analysis Body of Knowledge
 Dean Leffingwell – “Managing software
requirements: a unified approach”
 Karl Wiegers – “Software requirements”
 Henrik Kniberg - “Scrum for scratches”
 Alistair Cockburn – “Writing effective use
cases”
42

43. Спасибо за внимание!
43