Business Analyst - Credibility

Business Analyst: Build your Credibility

A Business Analyst acts as a face of Customer to the Development team, most of the time. A Business Analyst should be credible enough and the team should have absolute faith in him. Development team should be able to ask any question regarding the system and they should believe in the answers that BAs provide. If they start having doubts on the answers BAs provide they may get tempted to develop something that is not needed by the business or spend extra time in clarifying the doubt from various sources.

The development team should trust a BA; this was the first lesson that I got from a senior BA. When I asked him how to do it, he told me that you have to figure that out for yourself there is no proven formula. Some of the things that I tried and how they helped me in building a good rapport with the development team.

• Interact with the developers regularly and keep asking them if they have any doubts. The idea is not to overdo it as they may get a feeling that you are trying to judge their work. Keep it simple and just make sure that they know you are there if they need any clarifications in the requirements.
• Make sure you run the development team through the requirements before they start with the implementation. Do it on module-to-module basis, plan with the Project Managers and Team Leads. Make sure you keep these sessions as informal as possible and try to make them understand the business pain points rather than teaching them (as they may switch off).
• Encourage the team to approach you for any clarification in the requirements. When they approach you make sure you clarify their issues or get the issues raised to correct person, if you are not the right one.
• It is a good idea to explain the business side to the developers and also let them know about the domain, as you have that knowledge. Have these talks at non-work timings like lunch, coffee or while traveling. Make sure you don’t come out as a person who is bragging about his knowledge but as a person who is genuinely helping. Keep it honest; if you are not comfortable don’t try it.

I tried these things and they helped me immensely in building a good relation with the development team. Do let me know what works with you and how you achieved it?

Business Documentation - Part II

Implementation (transition) requirements

are capabilities or behaviors required only to enable transition from the current state of the enterprise to the desired future state, but that will thereafter no longer be required.

Report specifications

define the purpose of a report, its justification, attributes and columns, owners and runtime parameters.

The Traceability Matrix

Is a cross matrix for recording the requirements through each stage of the requirements gathering process. High level concepts will be matched to scope items which will map to individual requirements which will map to corresponding functions. This matrix should also take into account any changes in scope during the life of the project. At the end of a project, this matrix should show each function built into a system, its source and the reason that any stated requirements may not have been delivered

Business Documentation - Part I

What is Business Analyst ?

An internal consultancy role that has responsibility for investigating business systems, identifying options for improving business systems and bridging the needs of the business with the use of IT

Business requirements (project initiation document):

What the needed achievements will be, and the quality measures. They are usually expressed in terms of broad outcomes the business requires, rather than specific functions the system may perform. Specific design elements are usually outside the scope of this document, although design standards may be referenced.

Functional Requirements:

Describe what the system, process, or product/service must do in order to fulfill the business requirements. Note that the business requirements often can be broken up into sub-business requirements and many functional requirements. These are often referred to as System Requirements although some functionality could be manual and not system based, e.g., create notes or work instructions.

User (stake holder) Requirements:

are a very important part of the deliverables, the needs of the stakeholders must be correctly interpreted. This deliverable can also reflect how the product will be designed and developed, and define how test cases must be formulated. However, stakeholders may not always be users of a system.

Quality of Service (non-functional) Requirements:

are requirements that do not perform a specific function for the business requirement but are needed to support the functionality. For example: performance, scalability, quality of service (QoS), security and usability. These are often included within the System Requirements, where applicable.