O BABOK v2 define, em sua área de conhecimento Análise de Re...

A alternativa correta é a D - cenário e casos de uso. Abordando a tarefa Organizar Requisitos, parte da área de conhecimento Análise de Requisitos do BABOK v2, é essencial reconhecer que a utilização de cenários e casos de uso constitui uma técnica recomendada para estruturar e detalhar requisitos. Este método permite:

• Visualizar o sistema a partir da perspectiva do usuário.
• Descrever interações específicas entre o usuário e o sistema.
• Delimitar e clarificar os requisitos funcionais por meio de exemplos concretos de uso do sistema.

Essas narrativas funcionam como uma ponte entre as necessidades dos stakeholders e a concepção técnica do sistema, facilitando, assim, o entendimento e a validação dos requisitos. Outras técnicas listadas, como análise de riscos, benchmarking, brainstorming, e dicionário de dados, têm suas importâncias distintas dentro da Engenharia de Requisitos, mas não se enquadram diretamente na tarefa de Organizar Requisitos conforme determinado pelo BABOK v2.

Particularmente, considero questões que adentram nos BoK até o nível de técnicas/ferramentas, inputs ou outputs de nível difícil. São muitos BoK. Assim, acabamos por confundir. De todo modo, vai aí trecho extratído do BABOK 2 (lembrando que a versão atual é o BABOK 3, lançada em abril de 2015).

Requirements Analysis (Chapter 6) describes how business analysts prioritize and progressively elaborate stakeholder and solution requirements in order to enable the project team to implement a solution that will meet the needs of the sponsoring organization and stakeholders. It involves analyzing stakeholder needs to define solutions that meet those needs, assessing the current state of the business to identify and recommend improvements, and the verification and validation of the resulting requirements.

Organize Requirements6.2

Purpose6.2.1

The purpose of organizing requirements is to create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives.

Description6.2.2

There are two key objectives when organizing requirements.

Understand which models are appropriate for the business domain and solution ▶▶scope.

Identify model interrelationships and dependencies. Requirements alone are not ▶▶complex; it is the relationships and interdependencies among requirements that adds the element of complexity. Therefore, the organized requirements must also clearly depict the inherent relationships between requirements.

Techniques6.2.5

Business Rules Analysis (9.4): Business rules may be separated from other requirements for implementation and management in a business rules engine or similar.

Data Flow Diagrams (9.6): Shows how information flows through a system. Each function that modifies the data should be decomposed into lower levels until the system is sufficiently described.

Data Modeling (9.7): Describes the concepts and relationships relevant to the solution or business domain.

Functional Decomposition (9.12): Breaks down an organizational unit, product scope, or similar into its component parts. Each part can have its own set of requirements.

Organization Modeling (9.19): Describes the various organizational units, stakeholders, and their relationships. Requirements can be structured around the needs of each stakeholder or group.

Process Modeling (9.21): Requirements may be organized around relevant processes.

Processes themselves can embed subprocesses, and describe a hierarchy from the top level, end-to-end processes to the lowest-level individual activities.

Scenarios and Use Cases (9.26): Describe the requirements that support the individual goals of each actor, or the response to the triggering event.

Scope Modeling (9.27): Requirements may be organized based on the solution components they are related to.

User Stories (9.33): Describe the stakeholder objectives that the solution will support.

Valeu Maurício!

A ideia é organizar requisitos dentro de um documento. Uma das formas é agrupar de acordo com os cenários e casos de uso. GAB D

LETRA D

Matei sabendo o significado de algumas das técnicas, mas para contribuir:

• A. Análise de riscos: Embora a análise de riscos seja importante em projetos, ela não é especificamente uma técnica recomendada para a tarefa de organizar requisitos.
• B. Benchmarking: Benchmarking é uma técnica que envolve comparar práticas e desempenho com outras organizações, mas não está diretamente relacionada à organização de requisitos.
• C. Brainstorming: O brainstorming é uma técnica criativa para gerar ideias, mas não é específica para a organização de requisitos.
• D. Cenário e casos de uso: Essa técnica envolve a criação de cenários e casos de uso para descrever como o sistema será usado. É útil para entender os requisitos e organizar informações.
• E. Dicionário de dados: O dicionário de dados é uma ferramenta para documentar os termos e definições usados nos requisitos, mas não é uma técnica de organização em si.

Fonte: Copilot