BA Skill Assessment B

Chandra Sekhar

Q1. What are does & don’ts for a BA?

Ans. Do’s & Dont’s as Business Analyst.

• Never say NO to client

• Never imagine anything in terms of GUI
• There is NO word called as “By Default”
• Consult an SME for clarifications in Requirements
• Go to client with a plain mind with no assumptions.
• Listen carefully and completely until client is done and then ask your queries.
• Do not interrupt the client when giving you the problem.
• Maximum try to extract the leads to the solution from the client itself.
• Never try to give solutions straight away to the client with your previous experience and
assumptions.
• Try to concentrate on important and truly required requirements.
• Don’t be washed away by add on functionalities or imagine solutions on screen basis.

Q2. Write about a Business Process Model?

Ans. A business process is a collection of activities designed to produce a specific output for a
particular customer or a market. It emphasis on how the work is done within an organisation,
in contrast to a product’s on what. A process is thus a specific ordering of work activities
across time and place, with a beginning , an end, and clearly defined inputs and outputs a
structure for action.
 Has a GOALS
 Has specific INPUTS
 Use RESOURCES
 Perform ACTIVITIES in some order
 Has specific OUTPUT
 Creates END VALUE to Customers

Q3. List out Challenging Areas for a BA?

Ans. Challenges for a Business Analyst

 Obtaining sign-off on requirement

• Change Management- with respect to cost and timelines

• Coordination between developers & testers

• Conducting meetings
 • Driving client for UAT completion

• People Management (coordinating with different people and different teams).

Q4.What are different categories of tools that can be used in a project, you are aware of?

Ans.

 MS Visio (UML Diagrams)

 Axure RP Pro ( Prototype)
 Balsamiq ( Wireframe tool)
 Tableau ( Data Visualization)
 Power BI ( Data Visalization)
 MS Power Point (Presentation)

Q5. Explain “actor generalization” and “use case generalization “with example?

Ans. In the context of use case modeling the actor generalization refers to the relationship which
can exist between two actors and which shows that one actor (descendant) inherits the role
and properties of another actor (ancestor).  The generalization relationship also implies
that the descendant actor can use all the use cases that have been defined for its ancestor.

Example:

When it comes to air travel, both a "Business Traveler" and a "Tourist" are "Passengers".   The
fact that they are passengers allow them to have common behavior such as "Buy Ticket" but
the fact that they are separate actors implies they can also have differences.  The "Business
Traveler" might be able to "Redeem Business Miles" while the "Tourist" cannot.

Use-case Generalization

In the context of use case modeling the use case generalization refers to the relationship

which can exist between two use cases and which shows that one use case (child) inherits
the structure, behavior,  and relationships of another actor (parent).  The child use case is
also referred to the more specialized use case while the parent is also referred to as
the more abstract use case of the relationship.
 Example:

If you are creating a payment system which allows students of a training provider to pay for
courses both on-line and by phone, there will many things in common between the two
scenarios: specifying personal info, specifying payment info, etc.  However, there would also
be differences between the two.  So, the best way to accomplish this is to create one use
case (the parent) which contains the common behavior and then create two specialized child
use cases which inherit from the parent and which contain the differences specific to
registering on-line vs. by phone.

Q6. When do you use "Include" and "extend" in use case diagrams and give an example?

Ans. The «include» relationship allows us to include the steps from one Use Case into another. This
is valuable when the included steps occur as a recognisable sequence in many different
contexts.

Example:Check Available Balance is a use case. This can be initiated by the Customer to check his /
her Balance.

➢ Also when Withdraw Cash , Transfer Funds use cases are initiated, then Check Available
Balance use case will be initiated and performed inherently.

➢ This is include relationship that exists between Withdraw Cash and Check available Balance.
And also between Transfer Funds and Check Available Balance use case.

The «extend» relationship allows us to modify the behaviour of the base Use Case.

Example:

➢ If you consider Print Receipt use case , this is an optional use case, where the customer can
opt to take a print out or not to take a print out.

➢ This use case is an extension of the Financial Transaction use case.

Q7. What standards do you follow to create FRD document and write down its subsections?

Ans. The Functional Requirements Document (FRD) is a formal statement of an application’s

functional requirements. It serves the same purpose as a contract. Here, the developers agree to
provide the capabilities specified. The client agrees to find the product satisfactory if it provides the
capabilities specified in the FRD.
Functional requirements capture the intended behaviour of the system. This behaviour may be
expressed as services, tasks or functions the system is required to perform. The document should
be tailored to fit a particular project’s need. They define things such as system calculations, data
manipulation and processing, user interface and interaction with the application.
The Functional Requirements Document (FRD) has the following characteristics −
 It demonstrates that the application provides value in terms of the business objectives and
business processes in the next few years.
 It contains a complete set of requirements for the application. It leaves no room for anyone
to assume anything which is not stated in the FRD.
 It is solution independent. The ERD is a statement of what the application is to do— not of
how it works. The FRD does not commit the developers to a design. For that reason, any
reference to the use of a specific technology is entirely inappropriate in an FRD.
The functional requirement should include the following −
 Descriptions of data to be entered into the system
 Descriptions of operations performed by each screen
 Descriptions of work-flows performed by the system
 Descriptions of system reports or other outputs
 Who can enter the data into the system?
 How the system meets applicable regulatory requirements?
The functional specification is designed to be read by a general audience. Readers should
understand the system, but no technical knowledge should be required to understand this
document.
Q.8 Sequence Diagram

Employee Login Login CC Emp EC Emp Login BC

Verify Login Data [ ]

Login [ ]

Login Success [ ]

Validation [ ]
Q.9 Requirement Questionnaire
Ans. 1. What are your goals in developing this Point of sale system?
2. Who are the key stakeholders and users? Do their goals differ? If so, how?
3. How do the system goals map to business goals?
4. What is the most important business goal of the system?
5. Will the system change the way you are doing things now?
6. Will the system help you be more efficient? How?
7. What are the system deliverables?
8. What will the new system accomplish that is not currently accomplished manually or with other
systems?
9. What will the new system do?
10. What business requirements will this system address?
11. What functionality do you need from the system?
12. What are the current problems facing without the system today?
13. What problems should this system solve?
14. Do you have functional limitations that you'd like to change?
15. Who will be using the system?
16. What are the titles and roles of the people who will use the system?
17. How much historical information is required?
18. Do you have performance problems that need to change?
19.Do you have functional limitations that you'd like to change?
20. Which reports do you currently use? What data on the report is important? How do you use the
information?
Q 10. What is the role of BA in Change Request?
Ans.

When a BA is working on any Project he has to be ready to expect for a change. The client may raise
a Change Request at any stage of the project, it may be at the very initial stage or it may be at the
final stage.

When a client request for a change, firstly BA has to understand the reason for the change and how
the change will impact the project.

Secondly, the BA has to understand the effort required to implement the change. It is very important
to analyze the impact on the project. As BA has to evaluate the resources that will be incurred for
the change i.e., time, staff, money.

BA has to get an Approval or rejection of the change before he can actually implement the Change
Request. He has to get the approval from the change manage or the project manager to move
further.
If the change request is complex then the Developing team will increase the scope of the project
drastically, which may also have an increase in resources, time and money. BA has to validate the
impact of the change with the Stakeholders and all the Team members.

BA has to go through the change request in 3 different stages. Which are,

1.Feasibility Stage
If the change is worth the investment. To accept or reject the change.

2.Impact Analysis
What are all the changes going to be made to the Project.

3.Effort Estimation
To implement the change in the project.
Q11. Use-case Diagram

Library Management System

Branch Wise Title

«extends» «extends»

Search Book

Library Database
Add

CD/DVD items
Edit

Librarian
Request home
delivery
Delete
VIP Member

Order Book
Reserve Book

«uses»
Feedback

Return Book
«uses»

Comment

Regular User Pay Fine

Apply for VIP

Membership
Activity Diagram:

Search book

[If not found]

[If found]

Reserve Book

Check Membership

Regular Member

VIP Member

[If available] [If not available]

Request Home delivery Order Book

Issue Book

Return Book

Check Due Date

[Quota Exeeded] [Not Exceeded]

Calculate Fine Give Feedback

Collect Fine
Q 12. What are the roles and responsibilities of Business Analyst in given phases?

Stages Activities Artifacts & Resources

Pre project Enterprise Analysis – SWOT Business Case SOW (Statement
Analysis, GAP Analysis, Market of Work) PO (Purchase Order)
Research, Feasibility Study, Sr. BA, Business Architects Pre
Root Cause Analysis, Decision sales Consultants
Analysis, Strategy Analysis,
Enterprise Architectural
Frameworks, Project Scope and
Business case writing, Risk
analysis
Planning & Estimations & 1. Understand Assumptions and PM
Assessment Constraints along with Business Sr. BA
Project Kick Off Rules and Business Goals
2. Plan Packages for Big
Projects
3. Understands the project plan
from PM
4. BA conducts stakeholders
Analysis
5. Plan BA approach strategy
(Req. gathering techniques,
communication, Req. mgmt,
Documents to follow, Tools to
use, Change Request Handling
methodology )for this Project
Requirements Gathering 1. Stakeholders identify and BRD (Business Requirements
document Document)
2. Client gives BRD or BA
prepares BRD by interacting
with Client – Brainstorming ,
Document Analysis, Reverse
engineering, Interviews,
workshops, Focus Groups,
Observation, Questionnaires .
3. Prototyping can be used by
BA to make the Client to give
more specific requirements
4. Sort the gathered
Requirements (avoiding
duplicate Reqs , grouping into
similar functionality or into
modules)
5. Prioritize requirements –
MoSCoW
6. Validate RequirementsFURPS
Requirement s Analysis 1. Draws UML Diagrams Functional Requirements
( Usecase and Activity Specification
Diagrams) 2. Prepares SSD(Supplementary Support
Functional Document) SRS (Software
Requirements from Business Requirements Specification)
Requirements RTM (Requirements
3. All Architects comes up with Traceability Matrix
Technical Requirements (SSD)
4. SRS will have Functional
Requirements and Technical
Requirements
5. Takes Signoff on SRS from
Client. SRS is the first legal
binding Doc between the
Business and the technical
Team
6. BA prepared RTM from SRS
before Design phase starts. (BA
is the owner of RTM).
7. BA traces how requirements
are dealt in each phase of
development life cycle from
Design till UAT
Design 1. From Usecase Diagram , Test Solution Document Design
Manager or BA will prepare Document – HDD – ADD
Test Cases
2. Communicates with Client on
the design and Solution
documents (updates Status to
Client and make them
understand how the solution
would look like to prepare
them to drive UAT)
3. BA will initiate the
preparation of End user
manuals
4. updates RTM
5. From Use case Diagram
Solution-Architect recommends
Architecture of the IT solution
6. DB Architect uses Persistence
Classes (Entity Classes) and
comes up with ER Diagrams or
DB Schema.
7. GUI Designer will look into
Transient Classes ( Boundary
Classes) and designs all possible
Screens for the IT Solution
Coding 1.BA organizes JAD Sessions LDD – CDD Application
 2. BA clarifies queries of
Technical Team during Coding
3. Developers refer Diagrams
and Transient (Controller
Classes) of BA and code their
unit
4. Update End user manuals
5. Update RTM
6. Conducts regular Status
meetings with technical team
and the Client and tuning Client
for participation in UAT
Testing 1.BA- Prepares Test Cases from Test Concerning Documents
Use Cases or assists Test Application with less errors
Manager to do so
2. BA performs high level
testing
3. BA prepares Client for UAT
4. Test Data is requested by BA
from Client
5. Updates End User Manuals
6. Updates RTM
7. Take signoff from Client on
Client Project Acceptance form
Deployment and 1.Forwards RTM to Client or the
Implementation PM which should be attached
to the Project Closure
Document
2. Coordinates to complete and
share End User Manuals
3. Plans and Organizes Training
Sessions for End Users
4. Prepares Lessons learned
from this project (to take
precautions for coming
projects)