BUSINESS ANALYST SKILL ASSESSMENT

CODE A

Q1. What is the % of BA in Team Size and Project Duration?

BA Proportion in projects

 The total project time should be allotted to BA is 2 months’ time for 1 year project.
 12% to 16% of team size should be BA’s. (2 BAs in 12, 13 members team whereas 4
BAs in 24,25 members team
Project Sizes

 Small Projects Up to 500 Man-Hours

 Medium Projects: Up to 500-1000 Man-Hours
 large Projects: Up to Above 1000 Man-Hours

Q2. What is the role of BA in a product development IT Company?

The role of BA in a product development IT Company is,
SDLC Methodologies
Waterfall Model
Stages – Waterfall Model
Practical – V Model
RUP – Rational Unified Process
Spiral Model
Agile Manifesto
Scrum

Q3. Explain Agile & Scrum Process?

AGILE
Four main Values

➢ Individuals and interactions over processes and tools

➢ Working software over comprehensive documentation

➢ Customer collaboration over contract negotiation

➢ Responding to change over following a plan

Twelve Principles of Agile Software
1. Satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with
a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done. Agile Manifesto Twelve Principles of Agile
Software
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11.The best architectures, requirements, and designs emerge from self-organizing teams.
12.At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behaviour accordingly.

SCRUM
It can be implemented either beginning of the project or when you sense that project is
falling behind schedule. This model exercises full admin power.

✓ Product/ Sprint Burndown

✓ Product Backlog

✓ Sprint Backlog

✓ DOR- Definition of Ready

✓ DOD- Definition of Done

✓ Task

✓ WIP – Work in Progress

✓ Sprint Meetings
1. Sprint Planning Meeting
2. Daily Scrum Meeting
3. Sprint Review Meeting
4. Sprint Retrospective Meeting
SCRUM TEAM
Project resources are grouped as scrum teams which comprises of BA’S, developers and
testers. Each team will size average be 7-8.
SCRUM MASTER
He will monitor the performance of team within the sprint. Team will raise all their issues to
scrum master and he will run to look for the answers.

Q4. List all diagrams of UML and draw samples?

UML - (Unified Modelling Language)
• UML diagram is known as language of diagrams.
• The base of UML diagram is object-oriented approach (OOA)
• UML has 9 diagrams: – 5 Static – 4 Dynamic
Use Case Diagram
• A Use case is a high-level diagram.
• The main purpose of the diagram is to identify the requirement.
• A use case diagram is an actor specific.
• A use case diagrams are designed to explain how an external user are interacting with the
system.
Use cases are Verbs and are unique
Actors are Nouns
Essential Use Cases
– makes sense and completeness to the end user
Supporting Use Cases
– makes sense and supports Essential Use case
Use Case Diagram – Example - Basic
An ATM Application should have the following features:
➢Customer should be able to withdraw Cash using the Card issued by the bank.

➢After the Card is inserted into the Slot, 4-digit PIN Should be entered.

➢If the PIN is Correct, then ATM will allow to do a Transaction.

➢Three times incorrect PIN tried, The ATM will retain the Card.

➢Customer should be able to deposit cash in the ATM

➢Customer should be able to transfer funds within his Accounts

➢Operator will refill the cash in the money Trays.

➢All Transactions will be communicated by the ATM to the Bank and acquires no objection
from Bank to perform that Transaction.
Use cases are Verbs and are unique
Actors are Nouns
Essential Use Cases–
makes sense and completeness to the end user
Supporting Use Cases –
makes sense and supports Essential Use case
Use Case Diagram – Generalization

➢ A VIP Customer has an extra privilege to order Check book through the ATM.

➢ Customer is Generalized Actor and VIP Customer is a Specialized Actor.

➢ Financial Transactions is Generalized Use case for Withdraw Cash, Cash Deposit, and
Transfer funds use cases.
Use Case Diagram – Include / Extend Include

➢ 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 including relationship that exists between Withdraw Cash and Check available
Balance. And also, between Transfer Funds and Check Available Balance use case. Extend

➢ 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.

Use Case Diagram System Clock Automation
When the Money tray in ATM reaches a minimum level of cash, It will automatically send an
alert to the Bank. This can be explained as, periodically the System clock will be checking for
available cash levels and if found less than the minimum level, then an alert is sent to Bank.

Q5. Explain Abstraction, encapsulation, polymorphism, Inheritance?

Implementing OOA
Abstraction
Considering what is required, ignoring what is not required.
Encapsulation
Information & Complexity hiding technique.
Inheritance
Child class inheriting the properties of Parent class.
Polymorphism
Single instruction, multiple operations.

Q6. what steps you follow to draw a use case diagram from a Case study?
Use Case Diagram – Example – Basic

Use cases are Verbs and are unique

Actors are Nouns

Essential Use Cases–

makes sense and completeness to the end user

Supporting Use Cases –

makes sense and supports Essential Use case

Use Case Diagram – Generalization

➢ A VIP Customer has an extra privilege to order Check book through the ATM.

➢ Customer is Generalized Actor and VIP Customer is a Specialized Actor.

➢ Financial Transactions is Generalized Use case for Withdraw Cash, Cash Deposit, and
Transfer funds use cases.
Use Case Diagram – Include / Extend Include

➢ 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 including relationship that exists between Withdraw Cash and Check available
Balance. And also, between Transfer Funds and Check Available Balance use case. Extend

➢ 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.

Use Case Diagram System Clock Automation
When the Money tray in ATM reaches a minimum level of cash, It will automatically send an
alert to the Bank. This can be explained as, periodically the System clock will be checking for
available cash levels and if found less than the minimum level, then an alert is sent to Bank.
Use Case Diagram from a Case Study
1. Information which we do NOT model in Use Case diagrams are
➢Names of the systems (laptops, Desktops, Workstations),
➢ Architectures (2 Tier, 3 Tier, n Tier, Client Server),
➢ Databases Names (DB2, SQL Server, My SQL)
➢ Networks (LAN, WAN, Internet),
➢ Brand Names (HP, Lenova, Wipro, Sony),
➢ Technology Names ( Java, .Net, Mainframes)
2. Differentiate information against Actions
3. Write all sequence of Actions
4. Try to find out which actor is performing the above action
5. Try to identify Essential Use cases and Supporting Use Cases
6. Try to identify some modules with respect to functionality or usage.
7. Try to draw the relationships appropriately between the identified Actors and Use
cases

Q7. Why MVC Architecture is used? What are MVC Rules in identifying
classes? What guidelines will you follow to place the classes on a three
tier Architecture? What are persistence and Transient classes?

MVC Architecture
Entity Class Data base classes, Persistent class (Back-end designers)
Boundary Class (or) FORM Class
Controller Class Transient Class (Given to Front end designers)

MVC ARCHITECTURE
MODEL: The model class knows about all the data that need to be displayed. It is model
who is aware about all the operation that can be applied to transform that class. It only
represents the data of an application. The model represents enterprise data and the
business rule that governs access to and updates of data.

VIEW: The view represents the presentation of the application. The view class refers to
the model. It uses the query methods of the model to obtain the contents and renders
it. The view is not dependent on the application logic.

CONTROLLER:
Whenever the user sends a request for something then it always go through the
controller. The controller is responsible for intercepting the request from view and
passes it to the model for the appropriate action. After the action has been taken at the
data, the controller is responsible for directing the appropriate view to the user.

Model – View – Controller (MVC)

MVC Architecture Rules
1. Combination of One Actor and a use case results in one Boundary class
2. Combination of Two Actors and a use case results in two Boundary classes
3. Combination of Three Actors and a use case results in Three Boundary classes and so
on. Note: only one primary actor is to be considered with a use case.
4. Use case will result in a controller class
5. Each Actor will result in one entity class

MVC Classes in 3 Tier -Guidelines

Guidelines to place identified MVC Classes in a 3 Tier Architecture
➢Place all Entity Classes in DB Layer
➢Place Primary Actor associated Boundary Class in Application Layer
➢Place Controller Class in Application Layer
➢If governing Body influence or Reusability is there with any of remaining Boundary
Classes, place them in Business Logic Layer else place them in Application Layer.

Q 8. What is a Requirement? How many types of requirements are there?

Explain them with examples

Requirement
A requirement in the context of Business Analysis is simply a statement provided by a
stakeholder about what they believe they need in order to solve a particular business
problem or respond to a specific business need.  Once this requirement has been raised
by the stakeholder it is the business analyst’s role to further define, analyse, validate
and prioritize the requirement statement as it is now included within the business
analysis context of requirements management.
 In real life, the stakeholder will typically state their business problem or need and then
provide a whole range of individual requirements throughout the requirements
management process managed by the business analyst.

An important point about Requirements Analysis

Before we start defining the different types of requirements it is important to point out that
during the Requirements Analysis phase of the project the Business Analyst starts with a
broad and general description of the what is required to be done (often a business need or
problem description) and then start working with the key stakeholders within and
surrounding the project to define the Scope (what is included and excluded in the project’s
deliverables), Business Requirements (high-level requirement statements), Stakeholder
Requirements (which becomes more specific describing ‘what’ is required) and finally
delving into specifics of how to implement (with Solution Requirements and finally
transition requirements). It is therefore a journey working from a concept level right down
towards a detailed and specific requirements level.

Solution Requirements

 Solution Requirement Example 1: “I want my bedroom to be painted pink so that

everyone will know it is my room” – Stakeholder who raised this requirement is the
little girl.
 Solution Requirement Example 2: “I want my bedroom floor space to be at least 30
square meters so that I can practice my skateboard tricks in the bedroom” –
Stakeholder who raised this requirement is the teenage boy in the family.
 Solution Requirement Example 3: “Every bedroom must have an air-conditioning
unit implemented so that the family can stay cool during the summer” – Stakeholder
who raised this requirement is the father in consultation with the architect.

There are two sub-types of Solution Requirements:

 Functional Requirements: This type of solution requirement describes how the

solution must behave. In the example of the house, it describes how the house must
look (colours, size of bedroom) and perform (have an air-conditioning unit in each
bedroom). In a system related scenario example, the different functions that you
want a system to perform is typically described as functional requirements (in an
Agile Project context, it is referred to as a ‘user story’). An easy way to remember
this type of solution requirement is to think about what do you want to the system
to be able to do. Another example in the context of the house would be that a
functional requirement exists to have internal doors, which can be opened and
closed but not locked. This is something that you want the house to be able to do, a
function you want the house to be able to perform.
  Non-functional Requirements: The non-functional requirement type of solution
requirement describes the characteristics that you want the system to have. In the
context of the house example, solution requirement 4 is describing a characteristic
that is required of the house walls. It is not a function of the house but rather a
characteristic of the walls. In the scenario of a system an example that compares to
this house analogy would be a non-functional requirement describing the need to
have a backup-system installed to be used in the event of a disaster to prevent
unnecessary data loss. The non-functional type of solution requirement therefore
describes the attributes a system or process should possess and not a function that
the system must perform.

Requirement Types

There are a number of different types of requirements that system engineers will have to
develop on an acquisition program through it life-cycle. These requirements range from very
high-level concept-focused to very specific for a part. The main types of requirements are:

 Functional Requirements
 Performance Requirements
 System Technical Requirements
 Specifications

Functional Requirements

A functional requirement is simply a task (sometimes called action or activity) that must be
accomplished to provide an operational capability (or satisfy an operational requirement).
Some functional requirements that are associated with operations and support can be
discerned from the needed operational capability (see Operational Requirements). Others
often result only from diligent systems engineering. Experience in systems engineering has
identified eight generic functions that most systems must complete over their life cycle:
development, manufacturing, verification, deployment, training, operations, support, and
disposal. These are known as the eight primary system functions. Each must usually be
considered to identify all the functional requirements for a system.

Performance Requirements

A performance requirement is a statement of the extent to which a function must be

executed, generally measured in terms such as quantity, accuracy, coverage, timeliness, or
readiness. The performance requirements for the operational function and sometimes a few
others often correlate well with the statement of the needed operational capability as
developed by the Joint Capabilities Integration and Development System (JCIDS) Process.
The statement of other performance requirements usually requires thorough systems
engineering.
System Technical Requirements

Result in both allocated and derived requirements.

 Allocated Requirements: flow directly from the system requirements down to

the elements of the system.
 Derived Requirements: dependent on the design solution (and so are
sometimes called design requirements). They include internal interface
constraints between the elements of the system.
Specifications

A specification is a detailed, exact statement of particulars, especially a statement

prescribing materials, dimensions, and quality of work for something to be built, installed, or
manufactured. The overall purpose of a specification is to provide a basis for obtaining a
product or service that will satisfy a particular need at an economical cost and to invite the
maximum reasonable competition. By definition, a specification sets limits and thereby
eliminates, or potentially eliminates, items that are outside the boundaries drawn. A good
specification should do four things:

1. Identify minimum requirements

2. List reproducible test methods to be used in testing for compliance with
specifications
3. Allow for a competitive bid
4. Provide for an equitable award at the lowest possible cost.

Q 9. Write use case specification for withdraw cash use case in an ATM?

ATM Withdraw Cash – Use Case

Use Case Description: Allows any bank customer to obtain cash from their bank
account. This use case begins when an ATM customer chooses a type of account from which
the cash is to be withdrawn (e.g., checking) from a list of possible accounts, and to choose a
dollar amount from a list of possible amounts. The system sends the transaction to the
financial system for verification. If the financial system approves the transaction, the
machine dispenses the appropriate amount of cash and issues a receipt. The dispensing of
cash is also recorded in the ATM’s log.

Use Case Name:

 Withdraw Cash

Actors:

 Any Bank Customer (Has an existing account)

 Banking System (Any bank’s ATM and its infrastructure)

Triggers:

 The user wants to withdraw money from one of his/her account.

Preconditions:

 The ATM is operational.

 The bank customer has a card to insert into the ATM.

Post conditions:

 The bank customer has received their cash (and optionally a receipt).

 The bank has debited the customer’s bank account and recorded details of the
transaction.

Normal Flow:

1. The customer enters their card into the ATM.

2. The ATM verifies that the card is a valid bankcard.
3. The ATM requests a PIN code.
4. The customer enters their PIN code.
5. The ATM validates the bankcard against the PIN code.
6. The ATM presents service options including “Withdraw”.
7. The customer chooses “Withdraw”.
8. The ATM verifies sufficient funds in the customer’s bank account.
9. The ATM presents options for amounts.
10. The customer selects an amount or enters an amount.

 The ATM verifies that the customer is below withdrawing limits.

1. The ATM verifies that it has enough cash in its hopper.

2. The ATM debits the customer’s bank account.

3. The ATM returns the customer’s bankcard.

4. The customer takes their bankcard.

5. The ATM issues the customer’s cash.

6. The customer takes the cash.

7. Use case ends.

Alternate Flows:

The user has an invalid card. This can be caused because of the condition of the card i.e.,
card is either broken, bent or magnetic stripe/computer chip is damaged or the encoded
data is erased, blocked or not authorized account, inactivated card and/or wrongly inserted
card i.e., card is upside down.

1. The ATM will display error message.

2. The ATM will eject the card.

3. The user will take the card.

4. The use case returns to step 1 and continues.

Q 10. Draw a Use case Diagram and Activity Diagram

The hospital has several specialized departments like Cardiology,

Gynaecologic, Orthopaedics, Paediatrics, ENT etc. OPD is another
independent department. A doctor is only associated with one
specialized department at a time though he/she can be a member of
the OPD (Outside Patients Department) department. Each doctor has a
visiting time and day in a week. At reception the patient details are
entered and the fees are also taken and the patient is tracked on the
basis of the Id generated. In routine a patient can visit the doctors
either directly selecting a doctor or by getting admitted to the hospital
and then a doctor visits the patients. A doctor can prescribe tests for
the patient to perform. The patient visits the lab to get done the tests
prescribed by his/her doctor. The reports are given to the patient. The
payments pertaining to the tests are done at the reception. Referring
the reports, the doctor prescribes the patient medicines or further
tests or is asked to get admitted. A patient is admitted into a ward of a
specialized department (if available) as per the doctor’s prescription.
The number of wards is limited and if there is no vacant ward the
admission of the patient is rescheduled. As per the prescription of the
doctor the patient is operated on a specified date and time as decided
by the doctor who is doing the operation. After the completion of the
treatment a patient may get discharged on an advice of a doctor and
upon the complete payment of all due charges at the reception. On
payment of full dues, the reception generates a discharge ticket for the
patient
USE CASE DIAGRAM
ACTIVITY DIAGRAM
Q 11. What are the roles and responsibilities of Business Analyst in given
phases?
Phases Tasks of BA and contributions Resources associated and
artifacts
Pre Projects Enterprise analysis-SWOT Analysis, GAP Business case
analysis, market research, feasibility SOW (statement of work)
study, root cause, decision analyst, PO (purchase order)
strategy analysis, enterprise
architectural frameworks, project scope,
and business case writing.
Requirements Before Project Kick off PM
Planning Sr. BA
Requirements 1. Stakeholders identify and BRD (business requirement
gathering document document)
2. Client gives BRD or BA prepares BA
BRD by interacting with client-
brainstorming. PM
3. Prototyping can be used by BA
to make the client to give more
specific requirements.
4. Sort the gathered requirements.
Requirements 1. Draws UML diagrams (use case Functional requirements
Analysis and activity diagrams) specification
2. Prepares functional SSD (supplementary support
requirements from business documents)
requirements. SRS (software requirements
3. All architects come up with specifications)
technical requirements.
4. SRS will have functional BA
requirements and technical PM
requirements. Solution-architect
DB-architect
NW-architect
Design 1. From use case diagram test BA
manager or BA will prepare test PM
cases. Solution-architect
2. Communications with client on DB-architect
the design and solution NW-architect
documents. GUI-designer
3. BA will initiate the preparation Test manager
of end user manuals
4. Updates RTM
5. From use case diagram solution-
architect recommends
architecture of the IT solutions.
Coding / 1. BA organizes JAD sessions LDD-CDD
Development 2. BA clarifies queries of technical Application
team during coding.
3. Developers refer diagrams and
transient of BA and code their
unit Development team
4. Update end user manuals BA
5. Update RTM PM
Testing 1. BA prepares test cases from use Test concerning documents
cases or assists test manager to applications with less errors
do so.
2. BA performs high level testing. Testing team
3. BA prepares clients for UAT BA
4. Test data is requested by BA PM
from client client
5. Updates end user manuals
Deployment and 1. Forwards RTM to client or
Implementation the PM which should be
attached to the projects
Closure documents.
2. Coordinates to complete and
share end user manuals.
3. Plans and organizes training
sessions for end users.