Monday, April 22, 2013

Certifications for a Business Analyst


Question: What are the different certificates a BA can pursue?

Response: 
Certifications not only put a stamp of knowledge about the skills but also enhance the possibility of selection. There are many certifications that a business analyst can pursue.  It becomes easier to earn the certification when you are working in that particular area. It’s easier to pass the certification exam when you are able to relate the theory and practical. There is no end to the number of certifications you could pursue. Every organization and area has its own certifications. Some of the popular certifications a BA can pursue are:
  • Certified Business Analysis Professional (CBAP) from International Institute of Business Analysis (IIBA);
  • Project Management Professional (PMP) certification  from Project Management Institute (PMI);
  • OMG Certified UML Professional (OCUP) from Object Management Group (OMG);
  • Six Sigma level (Green Belt, Black Belt, Master Black Belt, etc.);
  • ITIL certifications from IT Service Management (ITSM);
  • Certifications from IBM on Rational Product suite;  and
  • Certified Software Quality Analyst (CSQA) from QAI Global Institute (QGI).

You can also pursue domain related certifications for ex:
  • FLMI – LOMA if you are working in the Life and Health insurance;
  • Courses from America’s Health Insurance Plans (AHIP) if you are working in the Healthcare; and
  • Property and Liability Insurance Principles Exam (INS 21, 22, 23) if you are working in the P&C insurance.

Sunday, April 14, 2013

Requirement Artifacts by Business Analysts

QuestionWhat artifacts you would produce to satisfy developers and business stakeholder’s need?

Response: 
The way I approach is that I do a brief assessment of technical and business needs of the project. I also look for any environmental factors such as already existing templates, tools used, and so on.

My main aim is to decide a format/template in which I can put the requirements so that both the parties agree; we can stabilize the requirements and move forward in the acceptance and development process. The target is to generate accurate and concise artifacts.

I also try to understand the assumptions and constraints while eliciting the requirements.

If it is a functional requirement (like System Requirements Specifications (SRS), Business Requirement/Specification Document (BRD or BSD)) then I usually produce a flow diagram and use case document with screen shots. The document also contains UML diagrams, data dictionary assumptions, business rules, related reports, error handling, testing strategy, etc. If we have an existing system, then I would also include configuration changes, and data changes.

If it is a process requirement I would dissect each part of the process into various steps. For each step I would talk about the input and output data. What processing or decision will occur at each step? We can put a context diagram and then explode it into data flow diagram showing each level. We can also use Business process modeling.

If it is an interface requirement (like Interface Control Document (ICD)) I will mention technical details on frequency, format, fields, field length, mapping with existing data dictionary, Service Level Agreement (SLA),  along with the steps involved in how the interface will work. We will attach XSD or XML sample if possible.
This document could also include the non-functional requirements then I include performance, security standards, data migration and conversion needs, availability required, and interface needs (batch or messages).

Sunday, April 7, 2013

Requirement elicitation approach


Question: How do you start the requirement elicitation and analysis work? Or what would be your approach for collecting requirements?

Response
The elicitation and analysis begins the moment the Request for Proposal (RFP) or any other client requirement document is received or understanding from prior discussions.

We study the document and research the topic and make a requirement elicitation plan which includes:
  •   What techniques to use to collect requirements? For ex. focus groups, interviews,     Joint Application Development (JAD) sessions, shadowing, questionnaire, etc.
  •   How to record the information you collect?
  •   Time frame/schedule for information collection?
  •   Initial design/architecture on base system.

In parallel we dissect the requirement and try to develop a Work Break Down structure in which we define the smallest unit of deliverable we need to produce. For ex. Let’s consider a sport’s club system in that has epics and user stores. For instance, member accessing my account can be an epic, whereas member login, or reset password can be user stories.
In this process we collect questions we need answers for clarifications.

Initial requirement artifacts are developed which are used during JAD sessions with Subject Matter Experts (SMEs) and clients. We try to nail down the requirements as much as we can.

We document the requirements in Business Requirement Documents (BRDs) and Functional Specs which include use cases, flow/activity diagram, data requirement, configuration needs, business rules, assumptions, exclusions. The document templates vary with company.

Documents goes for internal approval, walk through sessions are organized consisting of internal stakeholders. Once changes are incorporated, and internally accepted, it’s forwarded to client for acceptance and sign off.

Saturday, March 30, 2013

Types of requirements


Question: What are the different types of requirements? In other words, how would you categorize the different types of requirements?

Response:
Broadly speaking the two types of requirements are:
  •          Functional – A functional requirement try to seek answers to what a system needs to do to satisfy the objectives / needs; and
  •          Non-Functional – A non-functional requirement try to gather information on how a system needs to do activities to fulfill the functional objectives for ex. security, performance, availability, configuration needs, etc.
Requirements can also be categorized from an architecture point of view such as:
  •           Business: How a business work. A very high level view. For example: product and service, financial structure, business processes, etc.
  •      Application: Services and functionalities from a end user perspective. Automated and non-automated services.
  •           Operations – what the organization needs to run the processes and operations like data management, replication services, security levels, etc.
  •          Technology – S/W and infrastructure requirements such as environment, database, security, network and so on.

Sunday, March 24, 2013

Difference between requirements, wants and needs?


Question: What are requirements? What is the difference between requirements, needs, and wants?

Response: 

Requirement: A requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an objective.
In other words, requirements indicate the characteristic of the process that are essential for meeting the goals of the business.

Needs: Needs are the capabilities a stakeholder deem necessary to achieve objectives, and approved by the sponsors.
Requirements are subset of needs.

Wants: Wants are important but not essential to achieving the business goals or resolving the business challenges. Wants are based on the actual day to day experiences of the people. However, they represent an ideal stake of how people would like things to be in the business. During SDLC some wants may become requirements and vice verse.

For example: Let’s consider a company trying to venture in the insurance market.
The new company needs new business, underwriting, and policy administration, but has budget for only new business system.

In this scenario, apart from the new business system the company has to have underwriting, and policy administration system to run its operations, but so far because of constraints sponsors were able to establish only the new business process and solution. Therefore, new business, underwriting, and policy administration are the needs of the new insurance company but the new business system is the current requirement.

In case the sponsors thinks that a capability for the customer to do changes to the policy online will be better instead of calling the company, but they are constrained. In this scenario online system is a want and capability of calling the company is a need, and a requirement for the IT department.

Saturday, March 16, 2013

Tell us about your Business Analysis background


Question: Can you tell us about your Business Analysis background?

Response: As a business analyst I actively participate in all phases of software development life cycle (SDLC) and project management life cycle (PMLC). However, my role and responsibilities varies depending upon the project requirements.

In the planning phase, I work with Project Manager/leads in creating the work break down structure (WBS) from the client requirement documents or request for proposal (RFP). I assist in creating schedule, resource planning and artifact template creation activities.

In the requirement phase, I organize JAD sessions, workshops or employ other requirement elicitation techniques to get detail client requirements, manage and document requirements. Usually we create business requirement documents (BRDs) and functional specifications. BRDs contain use cases and detail information about the scope.

Functional specifications contain various models, process flow diagrams, data needs, screen layouts, reports required, and configuration needs (if any). It really depends upon how much detail information the project needs. The template varies between organizations. In some projects I have also created data dictionary, data migration and conversion, and report analysis. We also have to follow the internal and external requirement approval processes.

In the development or coding phase, I guide the development team in better understanding of requirements or defect, clarify their doubts.

During testing phase, I work with the testing team to create test cases and automation scripts. Since BA has the first hand information about the requirements his role becomes even important. As a product owner at times I participate in functional testing. I make sure that there is traceability right from client requirement document, BRDs, functional specification up to test cases.

In the roll out phase I work with the project manager and deployment manager in preparing the roll out checklist, pilot and training activities.

When the project goes to maintenance, I study the change requests, analyze the impact and gap, and submit my analysis to change control board (CCB) for a decision.

To summarize as a BA I am heavily involved in all phases of a project. Compared to other roles a BA has the maximum and wide variety of tasks.

Sunday, March 3, 2013

Introduce your self

In this blog we are going to discuss the most important initial question in almost all interviews:
“Introduce yourself”. This question is important because most of the time it drives the remaining discussion, particularly when the interviewer has no preselected list of questions. He/she will ask questions from the points mentioned during your introduction. Therefore, you must have complete command over the terms mentioned during your presentation. Qualities an interviewer is going to judge in your presentation would be:

  • How much prepared you are?
  • How you are presenting and the way you have structured/organized your presentation?
  • Your communication skills and your confidence. 

You can use the following tips to organize your presentation:
  • Limit your speech to not more than 3.5 to 4.0 minutes. You can practice this using a (cellphone) timer. Make sure you speak clearly and in plain English.
  • Make sure the speech content is in line with your resume.
  • Begin with a thank you note to demonstrate that you really value the opportunity.
  • Present your educational qualification, credentials, and certification you have.
  • Present your work experience in chronological ascending order i.e. start when you started working in this field, your first job. Few tips you would want to include are:
o   Name of the organization, role and time period in years or months;
o   What were your activities in that role;
o   What methodology and special tools (if any) you used;
o   If you have numbers of projects to present then select a few which are relevant to the position; and
o   Be brief in your initial projects and elaborate on your recent projects.
  • At the end summarize your presentation to reemphasize that you are competent candidate for this position.
The interviewer can put this question in different ways such as:
  • Can you tell us about your IT experience/background?
  • Can you tell us about your Business Analysis background?
  • How do you think you are best suited to this position?
-          What were your roles in past few projects? What were your day to day activities as a BA?
The responses for all these are same only difference being that the organization and structure of your response. I am going to provide some sample introductions which you can use to construct your own response:

Sample:  

Sample question:

Q: Could you please tell us something about your IT experience/background?

Sample Response:
First of all I would like to thank you / the team for selecting my profile, and taking the time and effort in discussing this opportunity with me. 

As far as my educational qualification is concerned I have a <degree last completed> degree .  I have <certification name> certifications. I am active participant to <community name> community.
Talking about my IT background, I have <number of years> years of IT experience including <number of years> years of strong business analyst experience.

I started my IT career in <year> with <company1 name> in their <project name> project as a business analyst. As a business analyst my work was to elicit requirements from the customer/business, analyze and document the requirements.

Between <year1> and <year2>I worked for clients such as <company 1>, <company2>, and <company3> as a business analyst. The roles were technical. At <company1> the project used UML diagrams in their requirement elicitation, analysis and design process. I developed business requirement documents, functional specification, and worked with development and testing teams.

In <year3> <company2 name> I lead a team of 4 BAs. <project name> project we build end to end system. The project used agile methodology where we had 1 month sprints ending with a release. We used UML diagrams extensively and generated blue print codes. 

Since 2011 I am with <company3 name> as a business analyst. Our main client is <client name>. We are using business process modeling to analyze the processes. We are eliciting and managing, analyzing, and documenting requirements. We are also supporting development and testing teams. We are using Requisite Pro, Visio in our processes.

To summarize, I have <years> of business analysis experience with through understanding of BA’s role in SDLC. Having development, management and analysis background make me a perfect fit for all kinds of analysis work required in a project.

Lastly, I would like to say that I am a proactive hard working person with strong interpersonal skills. I enjoy challenges and look to creative solutions to problems. I often got the best performance ratings in the companies I worked for.


Next I will post a sample for:
Can you tell us about your Business Analysis background”?