Базовый инструментарий аналитика. Методы и техники используемые в инженерии требований.

Базовый инструментарий аналитика. Техники и приемы используемые в инженерии требований
Юрий Булуй, HP
Lead Solution Consultant

Методы, техники и приемы, используемые в инженерии требований

Подход к классификации
Определиться с терминологией, что есть методы, техники и приемы, …
Соотнесение и иерархия
Распределение по областям RE

Извлечение требований
Интервьюирование
Фокус-группы
Анкетирование
Storyboarding
Requirements Workshop
Опросник
Анализ существующей документации
Domain Analysis
Introspection
Card Sorting
Ethnography
Observation
Viewpoints
Brainstorming
JAD
Group Work

Storyboarding
Storyboard – концептуальное описание функциональности системы в рамках отдельного сценария, включающее описание взаимодействие пользователя с системой.
Показывает, как сценарий будет выполняться в системе, представляя шаги сценария в виде картинок, диаграмм, слайдов или «скриншотами».
Элементы Storyboard – текст и иллюстрации.
Позволяет «обрамить» UC деталями GUI, традиционно не включаемыми в них.
Storyboard
GUI
Storyboard
Business Logic
Use Cases
Data
Scenario (Сценарий)это история, написанная на доступном для пользователя языке и объясняющая как будет использоваться система с т.з. пользователя. В идеале, такой сценарий описывает один Use Case.

Типы Storyboarding
Пассивный
Рассказ пользователю, включающий эскизы, иллюстрации, screenshots и/или образцы входных/выходных форм приложения
Простое пояснение что и когда происходит при движении по сценарию.
Активный
Постараться, чтобы пользователь «увидел фильм, который еще не сделан»
Интерактивный
Постараться добиться эффекта, как если бы пользователь уже пользовался данной системой.
Требует интенсивного вовлечения пользователей.
Сложность реализации

Storyboarding. Преимущества и недостатки
Преимущества
Позволяет уточнить логику использования системы.
Позволяет получить отзывы на ранних этапах.
Позволяет утвердить концепцию UI на ранних этапах при невысоких затратах.
Недостатки
Может не охватывать весь UI, т.к. Сценарии и UC могут быть не полностью отражать всю функциональность системы
UI достаточно изменчивый артефакт, высока вероятность что элементы и концепция UI будут изменены

Requirements Workshop
Requirements Workshop – это четко структурированная встреча, на которой тщательно отобранная группа ЗЛ и специалистов предметной области работают совместно для создания/уточнения и достижения согласия о требованиях к конечному продукту.
Основным преимуществом Requirements Workshop является возможность собрать вместе ЗЛ (включая пользователей) и разработчиков для улучшения качества конечного продукта еще до его создания.
Является одним из наиболее мощных инструментов для извлечения требований.
Может объединять множество известных техник и приемов.
Роли Facilitator и Scriber – одни из ключевых.

Типы Requirements Workshop
Любой из типов RW требует наличия подготовленного Facilitator.

Элементы Requirements Workshop
Подготовка
Проведение
Постобработка
Уточнить потребности ЗЛ и цель проведения RW.
Определить необходимый и достаточный состав ЗЛ для проведения RW.
Разработать план проведения RW.
Определить способы документирования результатов.
Назначить дату и время встречи и оповестить всех участников.
Логистика.
Разослать участникам материалы для ознакомления.
Провести предварительные встречи с ЗЛ для разъяснения целей и задач данного RW.
Выявлять и документировать выявленные требования.
Достичь консенсуса по конфликтующим точкам зрения.
Поддерживать фокусностьRW, не отдаляясь от поставленных целей и задач.
Facilitator должен управлять ходом RW, делая нужные вступления, отслеживая регламент и поддерживая дисциплину.
Facilitator не должен вмешиваться в процесс принятия решения, но должен способствовать появлению идей, и задавать тон обсуждения.
Facilitator должен контролировать, что все ЗЛ высказали свою т.з.
Facilitator должен задавать «правильные» вопросы, анализируя ход обсуждения.
Задача Scriber-а, фиксировать результаты обсуждения в принятом формате
Пройтись по всем открытым пунктам задач отмеченных на RW.
Оформить материалы и разослать участникам.

Requirements Workshops. Преимущества и недостатки
Преимущества
Эффективная коммуникация м/у заказчиком и разработчиком.
Возможность получения потребностей и требований «из первых рук»за достаточно короткое время.
Возможность разрешить конфликты требований, исходящих от разных ЗЛ.
Возможность получения согласованного представления о требованиях у всех ЗЛ.
Как правило требует меньше времени, чем проведение интервью со всеми ЗЛ по отдельности.
Возможность получить быструю реакцию ЗЛ на предложения и предположения
Недостатки
Facilitator должен быть опытным и владеющим предметом обсуждения. Успех RW во многом зависит от Facilitator.
Не всегда возможно собрать вместе нужных ЗЛ.
Политические и этические аспекты – не все ЗЛ готовы высказывать свою т.з. на проблему в присутствии других ЗЛ.
Накладные расходы на подготовку и организацию.

Анализ требований
Анализ интерфейсов
Моделирование оргструктуры
Root Cause Analysis
RACI matrix
Визуальное моделирование процессов
Mind Map
Потоки данных
Модели данных
Функциональная декомпозиция
Прототипирование
Problem Tracking
SWOT Analysis
Force Field Analysis
Scope Modeling
Контекстная диаграмма

Force Field Analysis
Kurt Levin – американский социальный психолог, автор концепции Force Field Analysis.
Force Field Diagram (Диаграмма силового поля) – модель, построенная на идее, что силы как способствуют, так и сдерживают изменения.
Система находится в динамическом «равновесии» при балансе сил.
Для проведения изменений, необходимо чтобы сумма «движущих сил» (driving forces), была больше суммы «сдерживающих сил» (restraining forces)

Звучит знакомо?
Четверо коллег должны сделать важную работу, пусть их имена будут
Каждый(Everybody)
Кто-то(Somebody)
Кто-нибудь(Anybody)
Никто(Nobody)
Важную работу, попросили сделать Каждого, но Каждый уверен, что ее сделает Кто-то. Кто-нибудь должен же её сделать, но её делает Никто! Кто-то очень сердит, т.к. работа не сделана – ведь это же была работа Каждого!
Получается, что Каждый думал, что Кто-нибудь сделал работу, но Никто и представить себе не мог, что Кто-то не сделал ее!
Закончилось все тем, что Каждый винил Кого-то, что Никто не сделал то, что Кто-нибудь должен был сделать!
Вывод из истории: Необходимо определять кто за что отвечает!

Матрица RACI
RACI – это инструмент, помогающий определить:
Какие задачи/функции должны быть выполнены.
Кто должен их сделать.
Responsible
Роль, или должность непосредственно работающая над задачей
Степень ответственности определяется тем, кто принимает решения
Может быть распределена по ролям/должностям/персонам
Accountable
Роль или должность, ответственная за работу в целом. Тот с кого будут спрашивать за результат целиком.
У него есть право вето
Он может определять кто будет выполнять работу
Consult
Тот, у кого необходимо проконсультироваться до начала работы
Могут непосредственно не участвовать в выполнении работ, но влияют на успешное выполнение работы
Двусторонние коммуникации
Inform
Тот, кто должен быть оповещен о решении или результатах работы. Вклад их в успех не важен, но они должны знать о результатах.
Односторонняя коммуникация

Анализ RACI
Пример RACI matrix:
Горизонтальный
Вертикальный

Вариации на тему RACI
RASCI (RASIC) – расширенная версия RACI, которая разбивает «R» на:
Responsible. Собственно тот, кто отвечает за непосредственное выполнение конкретной задачи.
Support.Ресурсы, которые может использовать «R». В отличие от «С», кто «дает вход» в решение задачи, «S» помогает в непосредственном выполнении.
RACI-VS (VARISC) – расширение RACI с двумя дополнительными ролями:
Verifier. Тот, кто проверяет, что результаты соответствуют критериям приемки.
Signatory. Тот, кто подтверждает решение «V». Должен работать в тесном сотрудничестве с «A».

Scope Modeling.Контекстная диаграмма
Пример из реального документа …

Документирование требований
Словарь данных и глоссарий
Scenarios and Use Cases
UML (в документации требований)
Check Lists

Словарь данных
Словарь данных, определяет ключевые для предметной области структуры данных и их элементы.
Может содержать отдельные элементы данных или композитные структуры данных
Может быть представлен в табличном виде.

Check Lists
Пример реального документа

Выбор подходящих методов, техник и приемов
Какие методы, техники и приемы должны быть использованы в конкретном случае?
Какие из этих методов взаимозаменяемы, а какие являются альтернативами?
Рекомендации:
Понимать и уметь использовать все (в идеале) методы, техники и приемы.
Сформулировать типичные задачи и определить какие методы, техники и приемы помогают в их решении.
Оценить применимость тех или иных методов для конкретного случая.
Понимать какие техники в рамках каких методов могут быть скомбинированы для решения поставленных задач.
База знаний

Вместо заключения …

Список источников
A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0
«Form Feeds Function. The role of storyboards in requirements elicitation». Jochen Krebs. The Rational Edge, 15 Dec 2005.
Software Requirements, Second Edition by Karl E. Wiegers.
Discovering Real Business Requirements for Software Project Success. Robin F. Goldsmith, Artech House, 2004.
Discovering Requirements: How to Specify Products and Services Ian Alexander and LjerkaBeus-Dukic. John Wiley & Sons, 2009

Вопросы
Юрий Булуй
E-mail:
yury.buluy@hp.com
bouloui@mail.ru
Блог:
http://yurybuluy.blogspot.com/

http://yurybuluy.blogspot.com	204
http://www.yurybuluy.blogspot.com	31
http://www.slideshare.net	9
http://xss.yandex.net	5

Базовый инструментарий аналитика. Методы и техники используемые в инженерии требований.

by byur on Nov 22, 2009

Accessibility

Tags

Upload Details

Usage Rights

4 Embeds 249

Statistics

Базовый инструментарий аналитика. Методы и техники используемые в инженерии требований. — Presentation Transcript