Business Analysis Concepts

• Study notes for business analysis concepts, techniques, and best practices are detailed below

Root Cause Analysis of Software Flaws

• The main objective is to determine why the flaw happened in the first place
• Look at process, people, and technology to prevent future issues
• A fishbone diagram (Ishikawa) is a good tool for this, as it helps visually organize possible causes

Weighted-Ranking Matrix

• Calculate the option's final score by multiplying each criterion's weight by its rating
• Add these results for all criteria to get the final score
• The highest score means the solution aligns best with what stakeholders want

Solution Scope Definition

• A business analyst defines the solution scope: what the new system will and won't include
• Solution design is technical; business requirements are high-level needs; a business case shows the project's value

Impact Analysis of Requirement Changes

• A business analyst needs to trace requirements
• They need to measure how changes impact the project's timeline
• This step is important before making changes

Brainstorming Technique

• Brainstorming gathers lots of ideas from people without judging them at first
• It encourages creativity and explores different views

Proactive Stakeholder Engagement

• A business analyst should identify all users as stakeholders
• This ensures their needs are considered early on

Requirements Status Communication

• A business analyst should use a traceability matrix to update on requirements
• This matrix shows how requirements connect to project parts (business needs, design, tests)

Observation Technique

• Observation means watching processes in action
• This gives direct insights into the process that other methods might miss

Initial Response to Defects

• A business analyst should compare defects to user acceptance test results
• This helps find problems with testing or understanding requirements

Operational Feasibility Assessment

• A business analyst checks if a solution fits the organization's structure and resources
• This looks at things like organization, user skills, and available resources

As-Is Process Analysis

• Identify limitations of a current application
• New features are explored with end users for the next version, this information is used to determine project scope

Observation for Business Process Understanding

• Observing processes gives first-hand insight

Tracking Rejected or Deferred Requirements

• Use a system requirements verification matrix or traceability matrix
• Rejected requirements should be tracked in the system requirements verification matrix

Power/Interest Grid

• The power/interest grid helps identify and sort stakeholders by influence and interest
• Excellent tool for initial stakeholder identification

Business Use Cases for Requirement Alignment

• Use cases show how the product meets user goals
• This helps ensure requirements align with business goals

Managing Scope Creep

• Define a requirements baseline, and use a change control process

Pareto analysis

• Used for prioritizing complaints by system users

Clarifying Business Needs

• Ask "What is the business need?"
• This helps prioritize requirements

Ensuring Requirements Coverage

• A traceability matrix ensures all requirements are addressed

Tracking Requirements

• Record requirements in a matrix
• Review, get approval from stakeholders, and regularly update it

Product Acceptance

• Inspection is used to gain product acceptance, where the customer is able to examine the delivered product against acceptance criteria

Locating Requirement Source

• Find the original source of a requirement in the traceability matrix

Communicating Which Requirements Will Be Implemented

• The traceability matrix is the most valuable tool
• It shows requirements linked to deliverables

Identifying Missing Project Stakeholders

• The business case includes a list of stakeholders
• The purchasing department should be in the list of stakeholders, as well

Reporting Implementation Progress

• Report the number of requirements tested and approved to showcase new feature enhancements

Managing Requirement Versions

• Use a traceability matrix to keep track of requirement versions as they evolve

Analyzing Vendor Products

• Surveys will provide a good basis for analyzing vendor products, they capture customer needs

Building Test Scripts

• Use cases are perfect for building end-to-end business process tests

Managing Requirements Revisions

• A change management plan defines the process for managing requirements revisions

Eliciting Requirements for Projects Involving a Low Number of Stakeholders

• Interviews a great elicitation technique if there are a low number of stakeholders

Mitigating Concerns About Meeting Business Requirements

• Create traceability matrices to trace design to technical requirements with included verification methods

Managing Scope Creep

• Establish a change control process

Identifying Unclear Requirements

• System requirements must be displayed in the correct place, like a verification matrix
• Requirements in the technical specification must not be unclear or ambiguous

Writing Clear Requirements

• Be specific

Understanding Stakeholder Decisions

• Ask about reasons for choosing actions
• You can get all of the underlying reasons why stakeholders make these decisions by asking this

Eliciting Clear Requirements in Workshops

• Use Prototyping, to clear vague or conflicting stakeholder decisions

Defining Requirement Rationale

• Capture the reasons and assumptions

Requirements Validation

• Validate that the system aligns with requirements by the client

Components of a Requirements Management Plan

• Requirements work plan
• Prioritization process
• Traceability matrix template

Measurable and actionable requirements

• Use case diagram

Tracking Requirements Documentation

• Use version control system

Interviewing method

• When eliciting requirements, interviewing is good for gathering detailed information

Documenting Requirements

• User stories are clear, concise, and testable, which bridges users and developers

Determining Requirement Scope

• Review the traceability matrix, it links the requirements to business needs, and that will determine the scope

Ensuring Product Design Meets Requirements

• Use a traceability matrix to ensure design aligns with requirements

Managing Changes to Project Documentation

• A configuration management system manages changes to project documentation

Primary Purpose of Requirements Traceability Matrix

• Ensure that all requirements have been met

Documenting Acceptance Criteria

• Must be clear and measurable, and align with requirements

Requirements Specification

• Details the customer's needs with a functional model, data model, and a glossary of terms

Gaining Objective Insight

• Observation provides unbiased, direct insight into tasks

Identifying Requirements

• Have a team peer review, it will aid in identifying ambiguous or unverifiable requirements

Managing Project Scope

• MoSCoW is great for prioritization and scope management

Valuable Requirements Document for a Database Administrator

• The entity relationship diagram is most valuable for a database administrator

Documenting New Processes

• Create guidance for stakeholders on how to request changes

Addressing Varying Viewpoints in Requirements Workshops

• Make sure the objective is clearly defined before facilitating
• This is a key step in facilitating requirement gathering sessions

Identifying out-of-scope requirements

• These are typically not linked to business needs

Elicitation Technique

• Interviews are a great elicitation technique to implement if the subject matter experts (SME's) are very knowledgeable

Securing Stakeholder Agreement

• A formal or informal review of requirements is the next crucial step to take

Elicitation Technique

• A survey or questionnaire are often used to elicit information from a large number of users, over a short period of time