Scribd
Upload
57 views7 pages

BA Best Practices

The document outlines the key steps and considerations for business analysis on a project. It includes: 1) Defining business needs by understanding current problems and opportunities for improvement. 2) Identifying stakeholders and planning analysis activities. 3) Performing analysis including identifying business needs, performing gap analysis, defining scope, eliciting requirements, prioritizing requirements, and refining requirements. 4) Addressing operational requirements around security, audit trails, data currency, reliability, recoverability, availability, and performance.

Uploaded by

sanju5626
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
57 views7 pages

BA Best Practices

The document outlines the key steps and considerations for business analysis on a project. It includes: 1) Defining business needs by understanding current problems and opportunities for improvement. 2) Identifying stakeholders and planning analysis activities. 3) Performing analysis including identifying business needs, performing gap analysis, defining scope, eliciting requirements, prioritizing requirements, and refining requirements. 4) Addressing operational requirements around security, audit trails, data currency, reliability, recoverability, availability, and performance.

Uploaded by

sanju5626
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

Define Business Needs

BA should assist in identifying and defining business needs for the business area concerned by
understanding the current problems and exploring any opportunities for continuous service
improvements. Defining business needs helps to explain why a change to the current system is required.

Business analysis approach

Typically there are two main approaches: plan-driven versus change-driven.

Identify Stakeholders

Identify business User, stakeholders, SME and sponsors (RACI)

Plan Business Analysis Activities

Plan the business analysis deliverables


Identify communication vehicle and frequencies with stakeholders
Effort estimation & resources required

Perform Analysis

1. BUSINESS NEED
a. Why change to current system required
b. Problem/limitation with current system and exploring new opportunities
c. Define desired outcome, major functions and features & processes to be improved or
redesigned.
2. GAP ANALYSIS
a. In order to understand the gap between the current as-is state and future to-be state
b. Technique such as SWOT analysis can be used to perform gap analysis
3. SCOPE
a. Define business processes to be involved or redesigned
b. Business related dependencies e.g. regulatory, operational
c. External system dependency both upstream and downstream
d. Any business related assumptions and constraints business rules
4. ELICITATION
a. Various techniques can be used to say few brainstorming, Analysis, Interviews,
Workshop, Prototyping, Survey/Questionnaires etc.
b. Understanding existing system with available resources
c. All provided information should be properly recorded and documented and summary
should be floated
d. BA should agree with stakeholders on
i. scope of work
ii. elicitation work schedule
iii. mechanism for verifying and sign off elicited results
5. PRIORITISE REQUIREMENT
a. Business Value
b. Stakeholder Agreement
c. Impact on users
i. effecting their current processes
ii. require additional staff, training etc
d. Impact on other systems
i. may not be capable
ii. not willing to do the change
e. Regulatory and Compliance
f. Dependency
i. other requirement that needs to early implemented due to higher dependency
g. Urgency or time sensitivity
h. Business or technical risk
i. Implementation difficulty
MoSCoW technique can be used for quick prioritization

6. REFINE & ORGANIZE REQUIREMENT


Important to create a complete, clear, accurate and consistent representation of all
requirements
a. Functional 4C`S
i. clear
ii. complete
iii. consistent
iv. correct
b. Non Functional
v. audit
vi. security
vii. service level requirement
viii. performance
c. Provide inputs to IT team for assessing the proposed system option and they are able to
meet the business needs
d. Complexity due to interdependency among the requirement should be handled properly
b. Future process to be defined to help visualize the requirement using diagrams ex
i. Use cases
ii. data modeling
iii. flow/activity/sequence diagram
iv. prototypes
7. VERIFY REQUIREMENT
a. It should be clear, concise, complete, consistent, correct, feasible, traceable back to
business need
b. All variation i.e. exception and branching logics are covered
c. Give example to strengthen business case as appropriate
d. Requirement could not deliver direct or indirect business values should be removed
e. Requirement could deliver value to stakeholder but not aligned with business case
should be separately covered and marked out of scope
8. SYSTEM IMPLEMENTATION
a. Resolve issue/conflicts
b. Close communication & Ensure everybody is speaking the same language
c. Support to UAT
d. Support to pre-prod during roll-out
9. Other Responsibilities
i. Keep an eye on progress
ii. work schedule
iii. planned activities
iv. target deliverables
v. change management
1. Scope creeping i.e. uncontrolled changes should be avoided
10. Challenges
a. Insufficient Users Commitment
b. User Reluctant to share information and contribute constructive ideas
c. · Manage Stakeholders availability for requirements
· Frequently changing requirements
· Freeze requirements
· Coordination with developers and testers
· Change management
· Drive UAT phase – on time completion of UAT
Background

Purpose

Assumptions and Constraints

Interfaces to External Systems

4 FUNCTIONAL REQUIREMENTS
The functional requirements describe the core functionality of the application. This section
includes the data and functional process requirements.

Context
User requirement

4.3 Data Requirements


Describe the data requirements by producing a logical data model, which consists of entity
relationship diagrams, entity definitions, and attribute definitions. This is called the
application data model. The data requirements describe the business data needed by the
application system. Data requirements do not describe the physical database.

4.4 Functional Process Requirements


Process requirements describe what the application must do. Process requirements relate
the entities and attributes from the data requirements to the users’ needs.

Process requirements may be expressed using data flow diagrams, text, or any technique
that provides the following information about the processes performed by the application:

Context
Detailed view of the processes
Data (attributes) input to and output from processes
Logic used inside the processes to manipulate data
Accesses to stored data
Processes decomposed into finer levels of detail

5 OPERATIONAL REQUIREMENTS
Operational requirements describe the non-business characteristics of an application.

5.3 Security
The security Section describes the need to control access to the data. This includes
controlling who may view and alter application data.

State the consequences of the following breaches of security in the subject application:
5.4 Audit Trail
List the activities that will be recorded in the application’s audit trail. For each activity,
list the data to be recorded.

5.5 Data Currency


Data currency is a measure of how recent data are. This section answers the question,
“When the application responds to a request for data how current must those data be?”
Answer that question for each type of data request.

5.6 Reliability
Reliability is the probability that the system will be able to process work correctly and
completely without being aborted.

State the following in this section:

What damage can result from this system’s failure?


o Complete or partial loss of the ability to perform a mission-critical function
o Loss of revenue

5.7 Recoverability
Recoverability is the ability to restore function and data in the event of a failure. Answer
the following questions in this section:

In the event the application is unavailable to users (down) because of a system failure,
how soon after the failure is detected must function be restored?
In the event the database is corrupted, to what level of currency must it be restored? For
example “The database must be capable of being restored to its condition on no more
than one hour before the corruption occurred.”
If the process site (hardware, data, and onsite backup) is destroyed how soon must the
application be able to be restored?

5.8 System Availability


System availability is the time when the application must be available for use. Required
system availability is used in determining when maintenance may be performed.

5.9 Performance
Describe the requirements for the following:

Response time for queries and updates


Throughput
Expected volume of data
Expected volume of user activity (for example, number of transactions per hour, day, or
month)
11. Biography: The candidate’s career background and motivations.
12. Expertise: An assessment of the candidate’s functional knowledge and skills.
13. Competencies: Questions designed to test behaviours and management
practices, based on the Fidelity Success Profile:

Exceeds Customer Expectations

Connect Intentionally

Innovate Courageously

Decide Insightfully

Execute Relentlessly

Lead and Develop Talent

Build an Effective Workforce

Buil d an Effec ti ve Wor kforc e

 Why is it important to always act in the best interest of clients?


 How have you utilised internal networks to get the best results?
 What is your experience of experimenting with new ideas in the workplace and what
level of success have you had?
 How have you used or supported the use of technology to drive innovation and service?
 What does being a winning organisation mean to you?

You might also like