Основные техники выявления требований.

Оглавление

1. Подготовка к процессу выявления потребностей
2. Техники выявления потребностей
3. Pros and cons of elecitation techniques
4. Действия после сбора требований
5. Методы анализа требований
6. Артефакты, которые следует подготовить

• Первое – определить цели выявления требований: кто является заказчиком этого процесса, кто будет работать с теми требованиями, которые мы соберем, зачем это делается.
• Следующий шаг – проанализировать и определить, какие существуют источники требований: откуда мы можем черпать информацию для того, чтобы эти требования определить.
• Исходя из полученных целей и источников требований, которые нам доступны, мы выбираем шаги и техники, которые мы будем применять для того, чтобы эти требования извлечь и зафиксировать.

Процесс подготовки бизнес-аналитика к выявлению требований включает несколько ключевых этапов. Этот процесс помогает аналитику эффективно собирать, анализировать и документировать требования, которые будут отражать потребности бизнеса и заинтересованных сторон. Вот основные этапы:

1. Понимание Бизнес-Контекста и Целей Проекта:
• Изучение информации о компании, ее миссии, целях и стратегиях.
• Понимание целей и ожиданий проекта, для которого выявляются требования.
2. Анализ Заинтересованных Сторон:
• Определение всех стейкхолдеров проекта, их ролей и влияния на проект.
• Планирование коммуникаций и взаимодействий с разными группами стейкхолдеров.
3. Подготовка и Планирование Сбора Требований:
• Выбор подходящих методов и техник сбора требований в зависимости от проекта и стейкхолдеров (например, интервью, опросы, фокус-группы).
• Разработка плана сбора требований, включая графики, инструменты и ресурсы.
4. Разработка Инструментов и Материалов для Сбора Требований:
• Подготовка вопросников, чек-листов, шаблонов для записи и анализа информации.
• Создание прототипов или макетов, если это необходимо для сбора обратной связи.
5. Обучение и Развитие Навыков:
• Изучение лучших практик и методологий в области бизнес-анализа.
• Повышение навыков коммуникации, аналитических навыков и навыков решения проблем.
6. Проработка Процесса Анализа и Документирования Требований:
• Определение формата и структуры документов требований.
• Освоение инструментов для документирования и управления требованиями (например, JIRA, Confluence).
7. Подготовка к Обратной Связи и Итерациям:
• Планирование процессов обратной связи с заинтересованными сторонами.
• Готовность к корректировке требований и подходов на основе полученной обратной связи.

1. Интервью: Подходит для получения детальной информации от ключевых стейкхолдеров. Эффективно, когда требуется глубокое понимание индивидуальных потребностей и предпочтений.
2. Опросы и анкетирование: Хороший выбор для сбора информации от большой группы людей. Особенно полезны, когда требуется собрать статистически значимые данные или мнения широкой аудитории.
3. Фокус-группы: Подходят для генерации идей и обсуждения требований в группе. Используются для получения разнообразных мнений и стимулирования дискуссии между заинтересованными сторонами.
4. Наблюдение (полевые исследования): Идеально подходит для понимания реальных рабочих процессов и проблем пользователей. Особенно полезно в ситуациях, когда пользователи не могут точно сформулировать свои потребности.
5. Анализ документации: Подходит для проектов, где уже существует обширная документация. Это может быть анализ бизнес-планов, технических спецификаций, руководств пользователя и других документов.
6. Мозговой штурм: Эффективен для генерации новых идей и решений. Подходит для проектов, требующих инновационного подхода и креативного мышления.
7. Прототипирование: Используется для получения обратной связи по конкретным аспектам продукта или системы. Особенно полезно в разработке программного обеспечения и дизайне продуктов.
8. Анализ сценариев использования и пользовательских историй: Подходит для выявления и документирования конкретных способов использования системы. Особенно важно для проектов, ориентированных на пользовательский опыт.

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

Интервью

• Особенности: Один-на-один диалог с заинтересованными сторонами.
• Преимущества: Глубокое понимание индивидуальных потребностей; возможность задать уточняющие вопросы; получение детализированной информации.
• Недостатки: Трудоемкость; зависимость от навыков интервьюера; возможные субъективные предубеждения интервьюируемого.

Опросы и анкетирование

• Особенности: Стандартизированные вопросы, распространяемые среди большой аудитории.
• Преимущества: Сбор большого объема данных; анонимность может способствовать честности ответов; статистический анализ данных.
• Недостатки: Ограниченные возможности для углубленного понимания; отсутствие обратной связи; низкая отзывчивость.

Фокус-группы

• Особенности: Групповые обсуждения под руководством модератора.
• Преимущества: Генерация идей и обсуждение; динамичное взаимодействие участников; широкий спектр мнений.
• Недостатки: Возможность доминирования более активных участников; групповое мышление; сложность организации.

Наблюдение

• Особенности: Непосредственное наблюдение за пользователями в их рабочей среде.
• Преимущества: Реальное понимание процессов и проблем; наблюдение за неочевидными аспектами поведения.
• Недостатки: Затраты времени и ресурсов; невозможность наблюдать за всеми аспектами; возможное изменение поведения людей под наблюдением.

Анализ документации

• Особенности: Изучение существующих документов, отчетов, руководств.
• Преимущества: Использование уже имеющейся информации; понимание текущего состояния и истории проекта.
• Недостатки: Могут быть устаревшие или неполные данные; отсутствие контекста или объяснения причин.

Мозговой штурм

• Особенности: Групповая техника для генерации идей.
• Преимущества: Способствует креативности и инновациям; быстрое получение большого количества идей.
• Недостатки: Не всегда сфокусирован на конкретных решениях; может быть неструктурированным.

Прототипирование

• Особенности: Создание ранних версий продукта для демонстрации функционала и сбора обратной связи.
• Преимущества: Наглядное представление продукта; раннее выявление ошибок и недочетов; активное вовлечение пользователей.
• Недостатки: Дополнительные затраты и время на разработку; возможное прикрепление к идеям первого прототипа.

Анализ сценариев использования и пользовательских историй

• Особенности: Описание конкретных ситуаций использования продукта или системы.
• Преимущества: Конкретика в описании требований; легкость понимания и визуализации процесса.
• Недостатки: Может упустить неочевидные требования; требует хорошего понимания пользовательских потребностей.

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

После того, как бизнес-аналитик выявил требования, он должен выполнить ряд действий и подготовить соответствующие артефакты для дальнейшего использования в проекте. Вот основные шаги и артефакты:

Действия после выявления требований

1. Анализ и Оценка Требований:
• Проверка требований на полноту, непротиворечивость, реализуемость и соответствие целям проекта / Checking the requirements for completeness, consistency, feasibility, and alignment with the project goals.
2. Приоритизация Требований:
• Работа с заинтересованными сторонами для определения приоритетов требований в зависимости от стратегической важности, рисков, стоимости и времени реализации / Working with stakeholders to prioritize requirements based on strategic importance, risks, cost, and implementation time.
3. Документирование Требований:
• Формализация собранных требований в структурированный документ или систему управления требованиями / Formalizing the gathered requirements into a structured document or a requirements management system.
4. Получение Одобрения на Требования:
• Презентация и обсуждение документированных требований с заинтересованными сторонами для получения их утверждения
  / Presenting and discussing the documented requirements with stakeholders to obtain their approval.
5. Планирование Реализации:
• Разработка плана реализации требований совместно с командой проекта.
6. Коммуникация и Координация:
• Постоянное информирование всех заинтересованных сторон о статусе требований и изменениях в проекте.

In business analysis, several methods of requirement analysis are employed to evaluate, prioritize, and document the needs and requirements of stakeholders for a proposed product or system. Here are some of the key methods of requirement analysis:

1. Decomposition: Breaking down complex requirements into smaller, manageable parts. This helps in understanding each requirement more clearly and simplifies the development process.
2. Modeling: Using various types of diagrams and models (e.g., data flow diagrams, use case diagrams, class diagrams) to visualize, analyze, and discuss requirements with stakeholders.
3. Compliance Check: Comparing requirements against business goals, regulatory requirements, and other high-level documents to ensure they are relevant and acceptable.
4. Dependency Analysis: Identifying relationships between requirements to uncover potential conflicts and dependencies that may impact prioritization and implementation.
5. Prioritization: Determining the priority of each requirement based on its significance to the business, implementation cost, and other factors. Prioritization methods include MoSCoW or pairwise comparison.
6. Gap Analysis: Identifying the differences between the current and desired states of systems or processes to pinpoint necessary changes or improvements.
7. Prototyping: Creating initial versions of the product or system to demonstrate and test ideas and requirements with real users. This helps to identify misunderstandings and refine requirements.
8. Requirements Review Sessions: Meetings with stakeholders to discuss, verify, and approve requirements. This helps to ensure the accuracy and completeness of requirements.
9. Use of User Stories: In Agile projects, user stories help to focus on user value by defining features and requirements from the end-users' perspective.
10. Impact Analysis: Assessing the potential impacts of changes in requirements on the project and stakeholders. This helps to understand the consequences of changes and manage them effectively.

1. Документ Спецификации Требований (SRS - Software Requirements Specification):
• Подробное описание функциональных и нефункциональных требований продукта или системы.
2. Матрица Трассируемости Требований:
• Таблица или документ, отслеживающий связь между требованиями и другими элементами проекта (например, тестовыми случаями, источниками требований, задачами разработки).
3. Диаграммы и Модели:
• Диаграммы потоков данных, ER-диаграммы, диаграммы использования и другие визуальные представления, помогающие понять и проанализировать требования.
4. Пользовательские Истории или Сценарии Использования:
• Описание функционала с точки зрения пользователя для понимания контекста и целей использования системы.
5. План Управления Требованиями:
• Документ, описывающий процесс управления требованиями в проекте, включая методы сбора, анализа, документирования и отслеживания / A document that describes the requirements management process in the project, including techniques for collection, analysis, documentation, and tracking.
6. Прототипы или Макеты:
• Ранние версии продукта или его интерфейса, используемые для демонстрации и проверки концепций с пользователями.

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

Here are the stages of the requirement life cycle:

- Stated - The requirement is initially expressed by stakeholders. Used to capture the initial intent or need as communicated by the stakeholders.

- Elicited - Done to ensure the requirement reflects a deeper understanding of the stakeholders' needs.

- Confirmed - Done to ensure all parties have a common understanding of the stakeholders' needs.

- Analyzed - Performed to identify gaps, refine the requirement, assess feasibility, and determine the best way to represent the stakeholders' needs.

- Specified - Done to provide a detailed and precise definition of the requirement for development and testing.

- Verified - Performed to ensure the requirement is clear, feasible, and ready for implementation.

- Validated - Performed to confirm that the requirement meets the actual needs of the users and stakeholders.

- Traced - Done to maintain alignment between requirements and other project artifacts, ensuring all are covered and addressed.

- Prioritized - Done to determine the order of implementation and focus on high-value requirements first.

- Approved - Used to finalize the requirement as part of the project scope and to serve as a baseline to assess potential changes.

- Implemented - Completed to realize the requirement through coding, configuration, or system setup during development.

- Tested - Performed to validate the requirement's implementation against the specification.

- Deployed - Completed to ensure the requirement is available for use in the live or production environment.

- Maintained - Performed to keep the requirement relevant and functional over time.

- Retired - Done to remove obsolete requirements from the system.

P.S. Check out our Requirement Elicitation Questions MASTER LIST and CHECKLIST here: https://lnkd.in/g8YNsNgW

http://requirements.ru/lections_22