Interview -2

This was an Interview with a company which wanted the development following waterfall method in the world where everything is moving or moved to Agile methodology..This was quit interesting to me As I started working in a waterfall methodology and I still like working in the same fashion as I find there is more consistency in this methodology.

The questions asked were :

1.How have you worked on Waterfall model projects ?

Answer:

The main characteristics of the Waterfall model is a sequential progression through the different stages of a project from initiation to the delivery phase. The waterfall model does have its limitations and because of this there have been many spin off models created over the years.

The Waterfall model consists of the following phases:

1.Initiation/Requirement gathering 2.Requirement Analysis 3.Design 4.Development or coding 5.Testing 6.Implementation and maintenance

The waterfall model used with the SDLC progresses through the six phases. You can picture this process as a waterfall with one phase flowing into the next.

1.Initiation or requirement gathering Phase
The purpose of the initiation phase is to conduct an initial high-level investigation of the business need and come up with a recommendation for the solution. Once approved by the management team, stakeholders, client or project sponsor, it will proceed to the next phase.

2.Requirement Analysis Phase
The purpose of the requirements analysis phase is to conduct a detailed analysis of the current business needs and identify what options are available to achieve those business needs. During the Analysis Phase, the Business Analyst will create the Business Requirements Document (BRD).

3.Design Phase
The purpose of the design phase is to identify and document a solution that will be constructed including technical and procedural specifications. A design document will be created that should include but not limited to technical, environmental, data, program, procedural, testing specifications.

4.Development or Coding Phase
The development phase is where a resource will take the design document created during the design phase and translate it into a functional program or system.

5.Testing Phase
The purpose of the testing phase is to test the system and related procedures that it meets the requirements specified by the stakeholders and documented in the BRD, design plan, and testing plan.

6.Implementation Phase
The purpose of the implementation phase is to release a fully tested and operational product to an end user or customer. The product should meet all the requirements that were documented in the BRD and pass the testing phase before it can be released to a production environment.

Question: 2

How do you write a use case?

Answer:

Use cases capture what the software does not how the software does.


Use cases contain the following elements:
Name – A clear verb/noun or actor/verb/noun descriptor that communicates the scope of the use case.
Brief Description – A brief paragraph of text describing the scope of the use case.
Actors – A list of the types of users who can engage in the activities described in the use case. Actor names should not correspond to job titles.
Preconditions – Anything the solution can assume to be true when the use case begins.
Basic Flow – The set of steps the actors take to accomplish the goal of the use case. A clear description of what the system does in response to each user action.
Alternate Flows – Capture the less common user/system interactions, such as being on a new computer and answering a security question.
Exception Flows – The things that can happen that prevent the user from achieving their goal, such as providing an incorrect username and password.
Post Conditions – Anything that must be true when the use case is complete.

Question :3

What is the responsibilities work of a Business Analyst?

Answer.Business Analysts are responsible for discovering,synthesizing and analyzing information from variety of sources in a given enterprise.including tools ,processes,documentation, and stakeholders.

the BA is responsible for eliciting the actual needs of a stakeholder-Which frequently includes investigating and clarifying their expressed desires- In order to determine the underlying issues and causes.

Business Analysts plays a role in aligning the designed and delivered solutions with the needs of stakeholders.The activities thata BA perfor include

1.Understanding the enterprise problem and goals

2.Analyzing needs and solutions

3.Devising strategies

4.Driving change

5.Facilitating stakeholder collaboration

Question 4:

What is a requirement traceability matrix(RTM) ?

Answer :4

Requirement Traceability Matrix (RTM) is document in form of a table (mostly a spreadsheet) which shows if each requirement has a respective Test case / cases to make sure if the requirement is covered for testing.

It is used to ensure that ALL the requirements and Change Requests are or will be tested.

Advantages of Requirement traceability matrix.

1. Gives Overview of ALL the requirements.
2. Shows how requirements are linked to Test Cases.
3. Makes sure 100% coverage of requirements.
4. Easy to prepare.
5. No special tool is required.                                                                                                                                                                                                                                                               
   Question 4:Role of BA in UAT                                                                                                          Answer :4                                                                                                                                           1.When testing comes into picture; test cases are prepared which are performed during UAT by the business users. Test cases help in getting a real time understanding of the functioning of the system developed. A business analyst helps in achieving this.                                                          2.UAT checks the effectiveness and efficiency of the system. When a BA is involved in UAT, he can help clear the doubts and questions of the users during testing sessions, as he is the one with end-to-end functional knowledge of the system.                                                                                3.UAT also helps in zeroing down if any new feature or functionality needs to be incorporated in the software. The rationale behind the necessity of the new feature is evaluated by the business analyst and Change Advisory Board together, along with other business stakeholders                    4.If any errors are discovered during UAT, which impose risk on the working of the system and have a high impact on the functioning of other modules, they are rectified or undergo change management (depending on the severity of the error). A business analyst helps in determining the severity of the errors.                                                                                                                  5.UAT helps the users in checking if the system is running smoothly as per the specifications and expectations. This helps in avoiding any drastic changes to the system once it has gone live. The presence of a BA helps in ensuring the precision of the software.
6. Steps to prepare a RTM

1. Get all available requirement documents. For e.g. Business Requirement Document(BRD), Functional Requirement Document(FSD), Technical Requirement Document(TSD)
2. First list down All the requirements from BRD one by one with requirement ID#
3. Now go to FSD, and list all respective functional requirements for each Business Requirements
4. Open Test Scenario or Test Case document and link available TC IDs to respective Functional Requirements

Lets take an example:

Project:Opening Online Flight booking Application

Business Requirement Document(BRD)

This document is provided by Client with high level business Requirements. Suppose for Flight Booking Application it shows below 2 requirements

BR_1 Flight Booking Module :

It should allow user to book one or more tickets, one way or round way for future dates

BR_2 Payment Module:

User should able to make payment for booked tickets via Credit / Debit Card or through Reward Points


Functional Specification Document (FSD)

This document is prepared by Technical team which further elaborate business requirements into functional requirements that can be implemented in a software.

Suppose above 2 business requirements in BRD have more detailed functional requirements:

BR_1 Reservation Module :
FR_1 : One Way Ticket booking
It should allow user to book one way ticket
FR_2 Round Way Ticket
It should allows user to book round way ticket
FR_3 Multicity Ticket booking
It should allows user to book one way or round way ticket for multiple cities

BR_2 Payment Module:
FR_4: By Credit Card
It should allows user to make payment by Credit Cards
FR_5 By Debit Card
It should allows user to make payment by Debit Cards
FR_6 By Reward Points
It should allows user to make payment by Reward Points

And you have written some test cases or test scenarios for each functional requirement.

So if we prepare simple Requirements Treaceability Matrix (RTM) for above example it would like as below:

You can also add Execution Status and Defects columns in RTM to view overall status of all requirements along with Test Cases.

BA Interview questions and answers-1

Hello there!

I worked as a Java developer for around 8 years and as soon as (after 2 years of start)I looked into the business,the process and the functionalities I started getting a flare for the business and its processes ,analysing and writing the use cases.Even then it took more than 2 years to move to a full fledged business analyst role but the flare for it was always alive somewhere inside me reason being while working as a developer I kept getting involved in the elicitation and requirement analysis ,client interaction,writing use cases,getting involved in drawing UML diagrams,writing functional specifications and BRD documents and all the activities which kept alive ..The BA inside me.

Now once I have moved to the field this idea of writing about my interviews and experiences crossed my mind and here I am..So the motto behind starting this blog is to keep you informed with any good idea,Interview questions I come for Business analyst and business analysis field.

My first interview was with a small product company...remember when its a small company they have lots of expectation from you so they will try to ask you everything possible.

1.How do you prioritize your requirement? Or what is the basis of prioritising your requirement?

Ans :
Typical factors that influence prioritization:

1.Benefit

II.Penalty

III.Cost

IV.Risk

V.Dependencies

VI.Time Sensitivity

VII.Stability

VIII.Regulatory or Policy compliance

2.What is an Epic?

It just means “big user story.” Epics generally take more than one or two sprints to develop and test. They are usually broad in scope, short on details, and will commonly need to be split into multiple, smaller stories before the team can work on them.

3.What is Service level agreement?

Ans :Agreement between the service provider and the customer:

A service level agreement (SLA) is a contract between a service provider (either internal or external) and the end user that defines the level of service expected from the service provider. SLAs are output-based in that their purpose is specifically to define what the customer will receive. SLAs do not define how the service itself is provided or delivered. The SLA an Internet Service Provider (ISP) will provide its customers is a basic example of an SLA from an external service provider. The metrics that define levels of service for an ISP should aim to guarantee:

I.A description of the service being provided – maintenance of areas such as network connectivity, domain name servers, dynamic host configuration protocol servers 

II.Reliability – when the service is available (percentage uptime) and the limits outages can be expected to stay within

III.Responsiveness – the punctuality of services to be performed in response to requests and scheduled service dates

Procedure for reporting problems - who can be contacted, how problems will be reported, procedure for escalation, and what other steps are taken to resolve the problem efficiently

IV.Monitoring and reporting service level – who will monitor performance, what data will be collected and how often as well as how much access the customer is given to performance statistics

V.Consequences for not meeting service obligations – may include credit or reimbursement to customers, or enabling the customer to terminate the relationship.  

VI.Escape clauses or constraints – circumstances under which the level of service promised does not apply. An example could be an exemption from meeting uptime requirements in circumstance that floods, fires or other hazardous situations damage the ISP’s equipment.

Though the exact metrics for each SLA vary depending on the service provider, the areas covered are uniform: volume and quality of work (including precision and accuracy), speed, responsiveness, and efficiency. In covering these areas, the document aims to establish a mutual understanding of services, areas prioritized, responsibilities, guarantees, and warranties provided by the service provider. 

The level of service definitions should be specific and measureable in each area. This allows the quality of service to be benchmarked and, if stipulated by the agreement, rewarded or penalized accordingly. An SLA will commonly use technical definitions that quantify the level of service such as mean time between failures (MTBF) or mean time to recovery, response, or resolution (MTTR), which specifies a “target” (average) or “minimum” value for service level performance.

SLAs are also very popular among internal departments in larger organizations. For example, the use of a SLA by an IT helpdesk with other departments (the customer) allows their performance to be defined and benchmarked. The use of SLAs is also common in outsourcing, cloud computing, and other areas where the responsibility of an organization is transferred out to another supplier. 

4.What is pareto principle?

Ans : The Pareto principle is a principle, named after economist Vilfredo Pareto, that specifies an unequal relationship between inputs and outputs. The principle states that 20% of the invested input is responsible for 80% of the results obtained. Put another way, 80% of consequences stem from 20% of the causes; this is also referred to as the "Pareto rule" or the "80/20 rule."!--break--This principle serves as a general reminder that the relationship between inputs and outputs is not balanced. For instance, the efforts of 20% of a corporation's staff could drive 80% of the firm's profits. In terms of personal time management, 80% of your work-related output could come from only 20% of your time at work. In Pareto's case, he used the rule to explain how 80% of the wealth is controlled by 20% of the country's population.

5.What estimation techniques you follow in your organization?

Ans : 

1.Delphi :Expert judgment and history ,Estimation is shared with expert and corrections are done based on the feedback,Average of 3 estimations are taken

2.Pert(Optimistic +pessimistic+4 most likely value)/6