BA FINALS

Unified Modeling Language

• Is a visual language used to model, understand, and communicate software systems

• It helps people see how a system is designed before or while it is being built

Structure Diagrams

• Shows the static parts of the system

• e.g: class diagrams, component diagrams, deployment diagrams, object diagrams, package diagrams

Behavior diagrams

• Shows how the system acts, changes, or interact over time

• e.g: Use case diagram, activity diagram, state machine diagram, sequence diagram, communication diagram, interaction overview diagram, timing diagram

Use case diagram

• It is a UML diagram that shows what users can do with a system

• This helps teams to understand the system from the user’s point of view

Actor

• Someone or something that interacts with the system

use case

• Is a function or action that the actor wants to perform using the system

system boundary

• shows what is inside the system being designed

• It is usually drawn as a rectangle

Association

• It is the line that connects an actor to a use case

Activity diagrams

• Helps us show how a process flows from start to finish

• They are useful for modeling workflows, use case behavior business processes, and system logic

start node

• It is the beginning of the activity, represented by a black circle

Actions

• Indicates the activities that make up a modeled process

• These symbols, which include short descriptions within the shape, are the main building blocks of an activity diagram

• These are commonly shown using rounded rectangles

connector symbol

• shows the direction of movement between activities

• Are the connectors that show how one step moves to the next

Decision symbol

• Used when the process branches based on a condition

• Represents a decision and always has atleast two paths branching out with the condition text to allow users to view options

Guard conditions

• Are labels that explain why a path is taken

• Placed near decision arrows, often inside square brackets

Merge node

• brings alternative decision paths together

fork node

• splits one flow into parallel activities

• used when activities happen concurrently or in parallel

join node

• Combines parallel flows after they are completed

activity final node

• shows that the whole activity is completed

swimlanes

• Group activities by actor, role, department, or system

Component diagram

• Shows the major parts of a software system and how they related to one another

• Its purpose is to show relationships between different components in a system

• Breaks down a system into high level functionality, where each component has a clear responsibility

components

• Are modular parts of the system that encapsulates functionality and support modularity and reusability

Provided interface

• shows what a component offers to other component

• Represents the services delivered by the component

Required interface

• Shows what a component need from another component

• These are interfaces where a component needs information to perform its function

port

• is an interaction point on the boundary of a component

• these are small squares on a component boundary used to show interaction points

dependency

• means one component relies on the other

assembly connector

• connects a required interface to a provided interface

Package

• can group related components similar on how folders group files

node

• represents a physical or virtual execution environment, such as server, device, or cloud environment

Business Analysis

• It is a discipline that focuses on understanding business problems and needs, identifying stakeholders and requirements, and supporting the definition of effective solutions that deliver value.

• It helps distinguish the actual problem from the symptoms or assumptions

• It also reduces the likelihood of failure by identifying the risks, gaps, and misunderstandings early

• It is a practice focused on problems and solutions

Business Analyst

Any person who performs business analysis activities, regardless offcial job title

Stakeholder

• Any individual or group that has an interest in, influence on, or is affected by a project or initiative

Requirement

• A documented need or condition that a solution must meet.

Solution

• A way of satisfying a business need, which may include systems, processes, or changes in behavior

Business requirement

• High-level needs describing why a change is required

Stakeholder requirements

• Needs of specific stakeholders or group

Non-functional requirement

• Quality attributes such as performance or security

MoSCow Method

• Prioritization Framework categorizing requirements as Must, Should, Could, Wont

Requirement Maintenance

• Keeping requirements updated for future use.

Predictive approach

• A plan driven approach where requirements are defined early

• Detailed Planning Upfront

• Stable Requirements

• Formal Documentation

Adaptive Approach

• An iterative approach where requirements evolve over time.

• Flexible requirements

• Continuous Feedback

Stakeholder Identification

• It is the process of recognizing all the individuals or group impacted by a change

• It is important because it ensures that all affected parties are considered

Influence

• It is the ability to affect decisions or outcomes

Stakeholder mapping

• Classifying stakeholders based on influence and impact

Engagement Strategy

• Planned actions to involve stakeholders appropriately.

Problem analysis

• Its main goal is to identify the real issue behind symptoms

Problem Focus

• Concentrating on underlying issues rather than surface symptoms

Solutioneering

• Prematurely proposing solutions without understanding the problem

5 whys

• A technique that repeatedly asks why to reach root cause

Problem statement

• A clear definition of the issue to be addressed

Fishbone diagram

• A visual tool to categorize possible causes of a problem

Critical success factors

• Key areas that must succeed for objectives to be met.

Key performance Indicators

• Measurable values used to track performance

Balanced scorecard

• Framework linking objective to performance measures

Business Case

• A document outlining the rationale, benefits, costs, and risks, of a proposed change

Requirements Elicitation

• Process of gathering information about needs and expectations

Interview

• structured conversation to gather detailed information

Workshop

• Collaborative session to explore and agree on requirements.

Observations

• Watching users perform tasks to understand real behavior

Prototyping

• Using early models to clarify needs and ideas

Requirements catalogue

• a structured list of documented requirements

User story

• A short statement describing a user need and expected value.

acceptance criteria

• Conditions that must be met for a requirement to be accepted.

Clear Requirement

• This ensure that a requirement is easy to understand and unambiguous

Testable Requirement

• This ensures that a requirement can be verified objectively

Traceability

• This means linking requirements to objectives and solutions

Change Control

• It is managing modifications in a structured way

Value

• It is the benefit delivered to the stakeholders and the organization

Software Development LIfe Cycle

• is a structured process used to develop software systems from planning to maintenance

• It provides a systematic approach to building reliable and efficient software

Planning Phase

• Is the initial stage of the Software Development Life Cycle where the project idea is evaluated and the overall direction of the system is defined.

• During this phase, the organization determines whether the project is feasible, valuable, and achievable.

Technical Feasibility

• Determines whether the required technology and expertise exist to build the system

Economic Feasibility

• Evaluates whether the benefits of the system justify its cost.

Operational Feasibility

• Assesses whether the organization can successfully implement and use the system.

Schedule Feasibility

• Determines whether the system can be completed within the required timeframe.

Requirements Analysis Phase

• focuses on identifying, gathering, analyzing, and documenting the needs of stakeholders for the proposed system.

• This phase determines what the system must do

Solution requirements

• Details of what a solution must do

Transition Requirements

• Temporary capabilities needed to move from the current system to the new system

System Design Phase

• translates requirements into a detailed technical blueprint that developers will use to build the system.

• this phase defines how the system will work.

High level design

• Defines overall system architecture including Modules, Components, System interactions

Low level design

• Provides detailed design of individual components such as Algorithms, Data structures, Interface specifications

Development Phase

• Developers begin coding the system based on the design specifications.

• This phase transforms requirements into working software

Testing Phase

• evaluates the software system to verify that it meets the specified requirements and performs correctly.

• this phase identifies defects, errors, and performance issues before the system is deployed.

• It helps improve software quality

Unit testing

• Tests individual components.

Integration testing

• Tests interaction between modules.

System Testing

• Tests the complete system.

User Acceptance Testing

• Confirms that the system meets business requirements

• ensures that the system satisfies business needs.

• Stakeholders validate whether the solution works as expected

Deployment Phase

• is the process of releasing the completed software system to the production environment where it becomes available to users.

• This stage transitions the system from development to real world operation.

Maintenance Phase

• is the final stage of the Software Development Life Cycle where the software system is monitored, updated, and improved after it has been deployed to users.

Waterfall model

• follows a sequential process.

• Each phase must be completed before the next phase begins.

Agile methodology

• Iterative development

• Continuous feedback

• Rapid delivery of value

Stakeholder Analysis

• helps identify Influence, Interest, Authority, Expectations, Communication needs.

RACI Matrix

• defines stakeholder responsibilities.

• Responsible, Accountable, Consulted, Informed

Manage Closely

• It is done when a stakeholder has high power and high interest

Keep satisfied

• It is done when the stakeholder has high power but low interest

Keep informed

• It is done when the stakeholder has low power but high interest

Monitor

• It is done when a stakeholder has low power and low interest

Stakeholder Onion Diagram

• defines stakeholder responsibilities.

• Layers represent proximity to the system

• Center → solution

• Inner layer → delivery team

• Middle layer → affected departments

• Outer layer → external stakeholders

BA governance

• defines how decisions are made.

• Key elements: Decision authority, Requirement prioritization, Change control, Approval process

BA Information Management

• Defines how BA information is managed.

• Includes: Requirements, Models and diagrams, Meeting notes, Documentation, Traceability

Stakeholder Register

• lists all project stakeholders and key details about them.

Requirements Traceability Matrix

• tracks relationships between requirements and other project artifacts.

• It connects: Business requirements, Functional requirements, Design components, Test cases, Implementation