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.