The Role of a Business AnalystPosted 14 November 2007 - 1:00am by dugarsSanjay DugarA "Business Analyst" (BA) is a role that can mean different things to different people.In some companies, the BA plays a technical role with very little businessknowledge; while in other companies, the BA has a full understanding of thebusiness with very little knowledge of the IT systems and architecture.In todays times - the BA has come to become a person of great value to anorganization, and who is a generalist capable of functioning competently in diverseroles. Typically, these people have a broad educational background and a diverseskill set with a wide range of work experience in different jobs and industries. Inessence, they are able to visualize the "big picture" - that is - understand thebusiness from different perspectives, as well as the technology side of what can beeffectively used to improve the business.The Business Analyst Skills in a broad perspective comprises of the person being aBusiness Planner, Systems Analyst, Project Manager, Subject Area Expert,Organization Analyst, Financial Analyst, Technology Architect, Data Analyst,Application Analyst, Application Designer, and Process Analyst.As we drill down deeper into the specific roles of a BA and understand the essentialskills required for each of the roles, it would give a clear picture.The major roles of a BA, as defined by certification experts are:-
1.Define and Scope Business AreasThe BA must be sure that the project scope is clear and complete before the start ofdetailed requirements gathering. The BA may be given the scope pre-defined by theproject sponsor or may be responsible for defining and documenting the scope aspart of the requirements gathering task.Defining and documenting the project scope requires the BA to understand why theproject has been initiated, and the objectives of the project. An important contributionof the BA to the project is the analyzing of the business problem without "jumping" toa solution.In addition, a complete project scope will name and define all the stakeholders thatwill be involved with the project, including people, systems, internal departments,and external organizations.Other important components of the project scope documentation include the projectviewpoint, project assumptions, and business risks. These components give the BAthe information necessary to prioritize and focus the requirements gathering.
Finally the project scope should include a high-level description of the businessprocesses. It may also include a list of items that specifically will not be included inthe scope. This gives the entire project team a complete understanding of the workthat the BA will be doing during the detailed requirements gathering phase.One additional task required of the BA, is the creation of an organized system formaintaining project information. A glossary should be started along with a filingsystem for maintaining all of the information that will be gathered during the project.Essential Skills Required: 1. Facilitation skills to bring multiple groups together to scope project and get consensus 2. Ability to document the project scope using business terminology 3. Project scope documentation techniques2. Elicit RequirementsThe most important task of a BA is to gather the detailed requirements that clearlyand completely define the project. We use the word gather because the BA must besure to ask the right questions of the right people to gather accurate requirements.Further, we use the word elicit, since the BA must be able to get people to say allthat they have to and not leave anything as assumptions.It is critical that the BA initially gathers Business Requirements and completelyunderstand the business needs before defining a software solution.The BA must assess the type of project, the people involved, and the volume ofinformation required; and then determine how and where to find the requirements.BAs have a variety of techniques available to them including interviews, facilitatedinformation gathering sessions, surveys, questionnaires, observation, and existingdocumentation from which to choose. In addition, the BA will often have manypeople with whom to talk and several existing automated systems about which tolearn.Gathering complete, detailed requirements is an iterative process that involves theBA asking questions, pondering answers, asking follow-up questions, and bringing
divergent opinions to consensus. It also involves prioritizing the requirements toassure that the most critical issues are addressed by the project solution.Essential Skills Required: 1. Asking the right questions 2. Active listening 3. Interviewing techniques 4. Facilitation techniques 5. Documentation 6. Ability to categorize requirements3. Analyze and Document RequirementsRequirements are analyzed and documented using an iterative approach. As each ofthe requirements is documented, additional questions will arise requiring the analystto probe deeper. There are many different approaches to documenting requirements.The BA is responsible for following their organizations standard documentationformat or for creating their own. When developing a documentation format, the BAmust consider the best format for communicating with the information technologyteam and the best format for communicating with the business area experts. Bothgroups must be able to read and review the document and clearly understand therequirements. Some requirements are more appropriately documented in textualdescriptions, others in diagrams or graphical displays. The BA must also determinethe appropriate level of detail for the documentation.Ideally, the entire organization uses a consistent documentation format andapproach. This makes the review process easier for people working on multipleprojects. It also allows the organization to constantly improve the format as qualityenhancements are discovered. The BA is often the person leading the developmentand maintaining the standard documentation format.Typically there are many requirements. To organize them and make them easy toreview, they are divided into categories or groupings. It may be good to categorizerequirements into Business, Functional, and Technical.Essential Skills Required: 1. Analysis Skills 2. Understand the system development methodology
3. Utilize modelling techniques 4. Categorization skills 5. Prototype user interfaces 6. Develop a textual template for requirements4. Communicate RequirementsThe BA should be the best communicator on the project team. The role is to act as aliaison between the business area experts and the technical team. This role requiresthe BA to "speak" both languages. The BA must also work very closely with theProject Manager to ensure that the project plan is adhered to and scope creeps /changes are approved and documented.As the requirements documentation is being created, the BA will conduct informaland formal requirements reviews. These review sessions increase the quality of thedocument by finding missing or unclear requirements. It is important that theinformation is presented to the business and technical audiences in a manner that ismost appropriate for their understanding. Summaries of the requirements or variousgraphical representations may be appropriate as part of the reviews. Understandingyour audience is critical to the successful communication of the requirements.Essential Skills Required: 1. Run effective meetings 2. Active listening skills 3. Precision questioning techniques 4. Conduct formal and informal presentations 5. Write clear emails, memos, and status reports 6. Conduct a comprehensive requirements review 7. Change management 8. Write review summaries5. Identify SolutionThe BA should work closely with the Business Area Experts to make arecommendation for a solution and work with the technical team to design it. Thisrecommendation may include software changes to existing systems, new software,procedural or workflow changes, or some combination of the above. If softwareautomation is part of the solution, the BA should assist with the screen design, reportdesign, and all user interface issues by providing detailed functional requirements.
If a software package is going to be purchased, the BA works with the Business AreaExperts, IT personnel, and the potential vendors to discuss the requirements andverify that the package selected will meet the needs. The BA may also beresponsible for writing the Request for Proposal (RFP). Detailed business andfunctional requirements should be completed to accurately reflect the needs for thesoftware and a thorough review should be conducted.Essential Skills Required: 1. High level understanding of the software design 2. Ability to evaluate vendor software packages 3. Ability to estimate solution costs and benefits and build a business case for implementation6.Verify Solution meets the RequirementsThe BA should remain involved in the project even after the technical team takesover. The BA reviews the technical designs proposed by the design team forusability issues and to assure that the requirements are being satisfied. Once thesolution is developed into software, the BA is uniquely qualified to assess thesoftware and determine how well it meets the original project objectives.The BA should work closely with the Quality Assurance team and to assist with theentire testing process. Testing is based on requirements, so the BAs intimateknowledge of the requirements allows accurate design of test cases. If there is noQuality Assurance team available, the BA can still assist with User Acceptancetesting, the time when the Business Area Experts are asked to approve the softwarefor implementation. As the software is tested, the BA ensures that it is clearlydocumented and reports defects and variances from requirements.Essential Skills Required: 1. Basic understanding of system design concepts 2. Knowledge of software usability principles 3. Understanding of testing principles 4. Ability to write and review test cases
Seriously... The reality is that there isnt such as thing as a standard requirements documenttemplate to help guide the business analyst in the creation of this document.The format of a Requirements Document vary depending on the type and size of project, typeof organization, maturity of the business analysis team, use of specialized requirementsmanagement tools, type of methodology and development process(agile vs. RUP vs.structured analysis), etc.Having said that, here are some common types of information found in many requirementsdocuments: Background/History Scope and Objectives Regulatory Requirements Business Level Requirements o Strategic o Tactical (Interoperability) o Operational (Process related mostly) Stakeholder and User Analysis User Requirements (the abilities that the users need) Functional Requirements Non-functional Level User Requirements Assumptions/Constraints Risks and Dependencies Solution Options Business Glossary (the nouns and noun-verb phrases of the business) Reference to Business Rules Reference to Business Case/Vision Use Case ModelsOne more observation: requirements documents are also known by a variety of names which,at times, mean the same thing and, other times, refer to totally different documents: Requirements Document Business Requirements Document (BRD) Software Requirements Document Software Requirements Specification (SRS)