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

ПРАКТИКА УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ

Интенсив-тренинг

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

2

Цели тренинга Знакомство с полным процессом

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

Формирование практических навыков по управлению требованиями

Определение направлений для самостоятельного углубленного изучения

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

3

Для кого полезен? Начинающим аналитикам для

эффективного освоения и закрепления необходимых компетенций

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

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

4

Структура1. Роль аналитика и процесс управления

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

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

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

6

Что такое требования?

Это Условия или возможности,

необходимые пользователю для решения проблем и достижения целей;

Условия или возможности, которыми должна обладать система или системные компоненты.

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

7

Роль аналитика в проекте

Концепция Проектирование Разработка Внедрение

Аналитик

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

8

Задачи аналитика1. Выявление требований

Сбор, документирование, учет2. Анализ требований

Систематизация и приоритезация3. Участие в проектировании решений

Прототипирование, моделирование, специфицирование

4. Управление изменениями5. Сдача проекта

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

9

Компетенции аналитика Коммуникативность Аналитические

навыки Методики и

инструментыАнализ

Коммуникация

Систематизация

Методики

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

10

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

Этап 1. Определение целей проекта

Этап 2. Сбор и анализ требований Разработка концепции

Этап 3. Разработка спецификации Договоренность о сдаче проекта

Этап 5. Управление изменениями

Этап 6. Сдача проекта и внедрение

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

11

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

Как?

Что?

Зачем?Потребности

Функционирование

Реализация

Концепция

Спецификация

ПО

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

12

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

Заказчик

Пользователи

Исполнители

Сколько % времени тратиться на непроизводственные активности

Нужна функция генерации сводного отчета о затраченном времени с группировкой по проектам

Активность Кол-во часов % от всего времени

Проекты 2000 80%

Непроектное время 500 20%

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

13

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

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

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

15

Сбор требований Определить ключевых лиц проекта и

ЛПР (=лицо, принимающее решение) Определить источники требований Выявить требования

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

16

Источники требований Заинтересованные лица (клиент,

пользователь, разработчик) Внешние организации (представители

смежных систем, гос. органы) Программное обеспечение (уже

используемое в компании, аналогичные на рынке, конкурирующие)

А еще регламенты, стандарты индустрии, исследования рынка, личный опыт…

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

17

Методы выявление требований

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

18

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

Интервью. Ошибки и советы

Ошибки Бессистемное

интервью Скатывание до

малозначительных деталей

Озвучивание решений вместо выявления проблем

Что поможет Подготовленный

опросник:• Цель проекта• Кто пользователи• Какие потребности• Есть ли регламенты

Придерживаемся целей интервью

Вопрос «А зачем?» Диктофон, блокнот и ручка

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

19

Важно! Источников требований МНОГО, важно

учесть ВСЕ Обязательно определяем потребность, из

которой проистекает требование Выявляем требования в несколько

итераций до тех пор, пока не будет достигнут нужный уровень точности и понимания текущего этапа

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

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

21

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

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

22

Как разрешить противоречия?

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

вариантов реализации

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

23

Как найти ненужные требования?

Есть ли трассировка вверх до функций и потребностей?

Кто будет пользоваться данной функцией?

Какова бизнес-польза?

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

24

Как найти недостающие требования?

Каким образом пользователи и другие объекты будут появляться в системе?

В каких условиях будет функционировать система?

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

25

Трансформация требований Пример

Категория Группа Требование Источник

Функционирование Заполнение отчетов

Отчеты должны быть заполнены до 12.00 след. дня

Регламент

Функционирование Уведомления Отправка уведомления о незаполненном отчете в 11.00

Аналитик

Функционирование Заполнение отчетов

Блокирование незаполненных отчетов

Аналитик

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

26

Важно! Когда требований становится много,

группируем их и систематизируем В случае противоречий ищем

компромиссные решения или решаем через ЛПР

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

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

28

Концепция (Vision) Vision –документ, описывающий систему в

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

Используется для:• Осмысления предстоящей разработки и

достижения договоренности между заинтересованными лицами

• В маркетинговых целях

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

29

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

модули по 7+/- 2)

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

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

31

UI прототип UI прототип – это модель (эскиз)

пользовательского интерфейса. Используется для:• Визуализация предполагаемого

решения• Уточнения невысказанных

требований

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

32

Инструменты Ручка и бумага Маркерная доска MS Office Balsamiq Mockups (www. balsamiq.com) Axure (www. axure.com)

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

34

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

Подходы к разработке спецификаций

Agile Акцент на

небольшие итерации

Много общения Минимум

документов и формализации

RUP Основательное

продумывание решений и требований

Подробные спецификации

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

35

Артефакты аналитика в Agile

Product Backlog – единое хранилище всех требований

User Story – описание требования

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

36

Фундаментальный подход (RUP) Создание спецификаций (Software

Requirements Specification) Описание функций в формате Use Cases Описание модели данных Описание модели состояний

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

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

38

Важно! Не так важно, как сделаешь проект.

Гораздо важнее то, как его сдашь!

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

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

40

Изменение требований Источники изменений• Внешние = Среда

функционирования или Клиент• Внутренние = Исполнители или сам

Аналитик

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

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”

43

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