BABOK_Guide_v3_member_copy

The Information Technology Perspective
Perspectives
requirements. For some change initiatives, the definition of non-functional
requirements could define all business goals for the change effort.
Business analysts often rely on other change agents to produce technical designs
for software solutions. A systems architect, programmer, database manager, or
other technical expert is often needed to determine how to use technology to
satisfy a set of requirements. IT business analysts define process steps, business
rules, screen flows, and report layouts. Defining requirements to include detailed
functionality of a system, the business, and system processes is a crucial part of
solution design and does not separate analysis and design.
As part of requirements analysis, an IT business analyst may partner with another
business analyst with a different focus, such as an enterprise business analyst or
business architect, to ensure that the IT requirements align to business or
organizational strategy.
Complimentary IIBA® Member Copy. Not for Distribution or Resale.
Requirements analysis and design definition frequently involves documenting
requirements using words and pictures. In some cases, requirements may be
represented in other ways such as a proof of concept, working software
prototypes, or simulations. In all cases, the business analyst works to produce
documentation with sufficient and appropriate details for:
• the business to verify and validate the requirements,
• the developers to design from, and
• the testers to measure the solution against before it is implemented into a
production environment.
BABOK ® Guide Techniques
• Business Rules Analysis (p. 240)
• Data Dictionary (p. 247)
• Data Flow Diagrams (p. 250)
• Data Modelling (p. 256)
• Decision Analysis (p. 261)
• Decision Modelling (p. 265)
• Document Analysis (p. 269)
•Estimation(p.271)
• Functional Decomposition (p. 283)
•Glossary(p.286)
• Interface Analysis (p. 287)
• Non-Functional Requirements
Analysis (p. 302)
• Organizational Modelling (p. 308)
• Process Modelling (p. 318)
• Prototyping (p. 323)
• Reviews (p. 326)
• Roles and Permissions Matrix
(p. 333)
• Scope Modelling (p. 338)
• Sequence Diagrams (p. 341)
• State Modelling (p. 348)
• Use Cases and Scenarios (p. 356)
• User Stories (p. 359)
.6 Solution Evaluation
Solution evaluation focuses on solution components and the value they provide.
Within an IT context, this includes a focus on the interactions between multiple
406