Документ описывает методы, техники и приемы, используемые в инженерии требований, включая storyboarding и requirements workshops. Он акцентирует внимание на важности эффективной коммуникации между заказчиками и разработчиками для извлечения и уточнения требований к продукту. Включены также недостатки и преимущества различных подходов, таких как матрица RACI и анализ силового поля.

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

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

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

4. Извлечение требованийИнтервьюированиеФокус-группыАнкетированиеStoryboardingRequirements WorkshopОпросникАнализ существующей документацииDomain AnalysisIntrospectionCard SortingEthnographyObservationViewpointsBrainstormingJADGroup Work

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

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

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

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

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

10. Элементы Requirements WorkshopПодготовкаПроведениеПостобработкаУточнить потребности ЗЛ и цель проведения RW.Определить необходимый и достаточный состав ЗЛ для проведения RW.Разработать план проведения RW.Определить способы документирования результатов.Назначить дату и время встречи и оповестить всех участников.Логистика.Разослать участникам материалы для ознакомления.Провести предварительные встречи с ЗЛ для разъяснения целей и задач данного RW.Выявлять и документировать выявленные требования.

11. Достичь консенсуса по конфликтующим точкам зрения.

12. Поддерживать фокусностьRW, не отдаляясь от поставленных целей и задач.

13. Facilitator должен управлять ходом RW, делая нужные вступления, отслеживая регламент и поддерживая дисциплину.

14. Facilitator не должен вмешиваться в процесс принятия решения, но должен способствовать появлению идей, и задавать тон обсуждения.

15. Facilitator должен контролировать, что все ЗЛ высказали свою т.з.

16. Facilitator должен задавать «правильные» вопросы, анализируя ход обсуждения.

17. Задача Scriber-а, фиксировать результаты обсуждения в принятом формате

18. Пройтись по всем открытым пунктам задач отмеченных на RW.

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

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

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

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

23. Матрица RACIRACI – это инструмент, помогающий определить:Какие задачи/функции должны быть выполнены.

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

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