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

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

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

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

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)

http://www.balsamiq.com/



http://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

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

Documents

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