Доклад, сделанный на конференции ReqLabs 2009, г. Москва. В докладе рассматривается подход к классификации методов и техник используемых в инженерии требований и описание ряда техник.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

32. Сформулировать типичные задачи и определить какие методы, техники и приемы помогают в их решении.

33. Оценить применимость тех или иных методов для конкретного случая.

34. Понимать какие техники в рамках каких методов могут быть скомбинированы для решения поставленных задач.База знаний

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

36. Список источников 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

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