11.3.5 Impact on Knowledge Areas
This section explains how specific business analysis practices within information technology are mapped to business analysis tasks and practices as defined by the BABOK® Guide. It also describes how each knowledge area is applied or modified within the IT discipline.
Each knowledge area lists techniques relevant to an IT perspective. Techniques used in the discipline of information technology do not deviate, to any great extent, from the BABOK® Guide techniques. BABOK® Guide techniques are found in the Techniques chapter of the BABOK® Guide. This is not intended to be an exhaustive list of techniques but rather to highlight the types of techniques used by business analysts while performing the tasks within the knowledge area.
.1 Business Analysis Planning and Monitoring
A business analysis approach is a fundamental communication tool which can be used to identify resources required for business analysis work and ensure adequate time for the analysis effort. A well-defined business analysis plan integrates into the overall project plan and provides business analysts with the opportunity to define and schedule the business analysis activities for the project.
Many organizations have some standards and processes in place, which may identify certain analysis tasks and deliverables. If these are not in place, the business analyst identifies these tasks and deliverables based on the needs of the specific initiative.
It is important that the context of the analysis work is understood. This includes understanding the inter-operation of software systems, business processes, and the data that is passed from one system to the next. Changes to any single system or process may have a ripple effect that brings additional systems, processes, or
stakeholder groups into the scope of the initiative.
The IT business analyst may be embedded within a software team. This approach allows the business analyst to become quite knowledgeable about specific software or processes supported by the software. Stakeholder attitudes and needs may change or shift in regards to each particular change. Roles, collaboration, and communication plans are planned for every change effort.
COTS solutions can involve major systems integration efforts, customizations, and many unexpected tasks due to the introduction of external software. When planning for unknown impacts and unknown customization needs, business analysts engage both internal stakeholders who understand the needs of the
change, and external stakeholders who have expertise with the COTS solution being implemented.
BABOK® Guide Techniques
- Backlog Management (p. 220)
- Document Analysis (p. 269)
- Estimation (p. 271)
- Functional Decomposition (p. 283)
- Item Tracking (p. 294)
- Metrics and Key Performance
Indicators (KPIs) (p. 297) - Organizational Modelling (p. 308)
- Roles and Permissions Matrix (p. 333)
- Scope Modelling (p. 338)
- Stakeholder List, Map, or Personas (p. 344)
.2 Elicitation and Collaboration
Information technology changes frequently affect many stakeholders with distinct relationships to the solution or change. When a change involves an IT application or system, the technical staff may have expertise, perspectives, or experience that can identify additional impacts to systems or processes as requirements and solutions are defined. For this reason, it is beneficial to have at least one elicitation session with IT technical personnel, such as development or technical design staff, and business SMEs in the same room at the same time. This type of elicitation approach provides a platform for collaboration between technical and business teams, where the IT business analyst serves as a facilitator and liaison for the process.
Business analysts practicing in an IT environment may utilize any of the techniques identified in the Elicitation and Collaboration knowledge area.
Additionally, the following methods can be of great benefit in the information technology discipline:
- Investigation: using organizational process assets, market research, competitive analysis, functional specifications, and observation,
- Simulations: using statistical modelling and mock-ups, and
- Experimentation: using proofs of concept, prototypes, alpha- and betareleases, and A/B testing.
Information technology changes can be seen as a distraction or cost by business stakeholders if the change is not perceived as mission critical or if the stakeholder is experiencing negative value from the change. This can make engagement for elicitation challenging. Elicitation across organizational boundaries may be impeded, causing collaboration breakdowns and rework. IT business analysts can decrease the risk of rework by engaging information technology and business resources in collaboration activities.
BABOK® Guide Techniques
- Brainstorming (p. 227)
- Collaborative Games (p. 243)
- Document Analysis (p. 269)
- Focus Groups (p. 279)
- Interface Analysis (p. 287)
- Interviews (p. 290)
- Observation (p. 305)
- Process Modelling (p. 318)
- Prototyping (p. 323)
- Scope Modelling (p. 338)
- Sequence Diagrams (p. 341)
- Stakeholder List, Map, or Personas (p. 344)
- State Modelling (p. 348)
- Survey or Questionnaire (p. 350)
- Use Cases and Scenarios (p. 356)
- Workshops (p. 363)
.3 Requirements Life Cycle Management
IT initiatives frequently experience major discoveries while creating the change. It is through exploration that the business analysts discover the implications of the new functionality provided by the solution. This sense of discovery in IT environments has led to the adaptation of short cycle times (agile and continuous improvement), rigorous change control (Capability Maturity Model Integration (CMMI) and predictive), and externalized information technology (Software as a Service (SaaS) and cloud services).
Business analysts working in IT pay particular attention to alignment, approval, change control, traceability, and requirements life cycle management tools. It is the role of the business analyst to work with stakeholders to develop a consistent method for reviewing evolving requirements to ensure alignment with the business objectives for the initiative.
In many cases, changes to approved requirements are driven by changes to higher-level requirements such as business objectives. Business analysts collaborate with stakeholders to ensure these requirements are stable before proceeding to solution or technical requirements. When changes to requirements are presented, the business analyst analyzes the impact and plans how to manage proposed changes.
As the complexity of an information technology environment grows, it becomes increasingly important to track each change to each requirement or between requirements and other information. Traceability that includes dependencies and relationships among requirements makes it easier for stakeholders to understand what is changing about the IT system and predict impacts of additional changes.
As technical systems are changed over time, it is helpful when each version of each requirement is stored in some way and accounted for. Traceability makes it possible to find the source and owner of each requested function and feature, as well as why, when, and how it changed over time. This history is important for ensuring that the requirements are complete and that the approval of requirements is a sensible decision. When the change–work and the IT system are audited, regulators and other interested parties can understand what happened, when, and why. This can be especially important for audit purposes, when an application manages data or processes systematically without human intervention for each transaction or instance of the process occurring. This tracing also helps the organization understand why some functionality is not delivered or implemented in the IT system, and why it was dropped from the scope of this implementation.
BABOK® Guide Techniques
- Acceptance and Evaluation Criteria (p. 217)
- Decision Analysis (p. 261)
- Item Tracking (p. 294)
- Metrics and Key Performance Indicators (KPIs) (p. 297)
- Prioritization (p. 311)
