5 key techniques and skills to master as a business analyst

The business analyst role is multi-faceted and it is rare to find two BAs with the same set of experiences, skills and knowledge. It is common for BAs to have experience of a broad range of industries and projects as well as knowledge of both waterfall and agile methodologies. Equally, there are BAs who have chosen to specialise in just one industry or discipline.

As such, it is difficult to describe a ‘typical’ BA, but no matter which camp they fall into, there are several key skills and techniques which are integral to the role and are essential additions to any BA’s toolkit.

#1 Stakeholder engagement

The business analyst is often one of the first points of contact for stakeholders when a business change or systems development project arises. Whilst stakeholders in some organisations may discuss the business requirement, opportunity or problem with a business partner, in others the BA will undertake initial engagement activities.

Stakeholder engagement encompasses stakeholder identification, analysis and management. In its simplest form it is how a BA works with their stakeholders (loosely termed as any users, customers, sponsors and other individuals or groups impacted by a change).

There are some excellent models and techniques for identifying, analysing and managing stakeholders. A basic stakeholder matrix is extremely useful for mapping stakeholders by their power (influence) and interest and can assist in deciding the strategy for working with different individuals and groups impacted by a project.

Tools such as this can be extremely valuable and it is useful to learn how to use them. An aspiring BA could do much worse than procuring a copy of Cadle, Paul & Turner’s Business Analysis Techniques and reading the section on ‘Working with Stakeholders’.

The most powerful thing to remember when dealing with stakeholders is that they are human. They are people with wants, needs, aspirations and concerns. As such, great stakeholder engagement is as much, if not more, about communication, negotiation, relationship building and empathy as it is about knowing specific techniques and tools.

#2 Requirements elicitation

Requirements gathering is often the activity most non-BAs associate with the role of the business analyst. Essentially, it is the process of discovering the functional and non-functional requirements (the wants and needs) of stakeholders for a system. Whilst these will usually be the requirements of an IT-related solution, the term ‘system’ is holistic; it is often necessary to also consider and capture process, organisational and ‘people’ requirements.

There are several excellent elicitation techniques, all of which have their strengths and limitations. Often, the best approach is to use a combination of two or more techniques to balance out these pros and cons, providing a more thorough and rounded view of the requirements. As an aspiring BA, it is well worth gaining some hands-on experience of the following:

• Observation
• Workshops
• Interviews
• Document analysis
• Brainstorming
• Surveys and questionnaires
• Prototyping

#3 Requirements prioritisation

A thorough requirements gathering exercise can generate hundreds of requirements, some of which will be vital to the success of the project, whilst others may be more aspirational. Time and budgetary constraints will usually dictate that a choice needs to be made on which of these requirements will make the final cut and go forward into development.

For you

Be part of something bigger, join BCS, The Chartered Institute for IT.

This can be quite a daunting part of the BA role, as it often means challenging stakeholders to truly consider their priorities and to frame their requirements with their end goal in mind. Where there are conflicting priorities between different stakeholders, the BA can often find themselves mediating discussions and managing conflict.

A much-used approach is MOSCOW prioritisation, where stakeholders are asked to categorise requirements as follows:

Must Have - requirements which must be delivered when the project goes live. The project cannot go live and the solution will not work without all of these.

Should Have - requirements that are needed, but can be rolled out later. They’re important, but the solution will work without them for the interim.

Could Have - requirements that are useful, but not essential. They may be rolled out if there’s time or pushed to a later release.

Would Like - it is valuable that these requirements have been captured, but they won’t be included in this development.

#4 Requirements documentation

Once a BA has gathered the requirements, the information must be documented in a format that can be used by developers and testers. Requirements documentation may be used to create a functional specification, technical specification, a product backlog, or may be used directly for development. As such, one of the challenges for the BA is capturing the requirements in language which is both understandable to the business (which needs to sign them off) and useful to a solutions architect and the development team.

The approach to documentation will often vary depending on the organisation. Some will require a requirements catalogue, combined with a detailed requirements document; whereas others will use user stories for agile development. Detailed data requirements may be documented using entity-relationship diagrams or class diagrams, whilst business-level requirements may call for process mapping. Software used for requirements documentation may range from Microsoft Excel, Visio and Word, through to more sophisticated requirements management tools such as JIRA or HP Quality Centre.

With this variety in mind, here are some key tools and techniques to investigate further:

• Requirements catalogues
• Use cases (UML)
• User stories
• Process modelling (including BPMN, UML, flowcharts and data flow diagrams)
• Data modelling (class diagrams (UML), entity-relationship diagrams)
• It is also a very good idea to get familiar with MS Visio

#5 Communication

Returning to #1, communication is essential to building strong stakeholder relationships. Throughout a project, stakeholders need timely communications, using the channels they prefer, containing a message that is relevant to them. As communication is a two-way street, it is also essential that stakeholders feel they have a voice and that their BA is approachable, open to discourse and is empathetic to their situation.

In technical projects, a business analyst is often described as a translator between the stakeholders (who have the requirements) and the technical IT teams (who will be designing and building the solution). It is the responsibility of the BA to understand the requirements of the business and communicate them to technical teams, whilst also understanding the technical abilities and constraints and feeding them back to the business in a way that makes sense in the business context.

The BA also needs to operate at a strategic level: understanding the strategic context of a project, the cultural impacts it may have and the longer-term organisational goals that it relates to. As such, a BA may also find themselves needing to be a sales person, a visionary, or a trainer - all roles that  require strong communication and presentation skills.

But lest we forget the importance of communication and engagement within the project team. Whilst we often focus on stakeholder communication, it’s important for BAs to ensure they keep open, clear and honest communications with the project manager or scrum master and other members of the project team.

Lack of communication is often cited as one of the main reasons for project failure and as such at a good communication in all areas is key to success.

Rachel Drinkwater: Senior Business Analyst, Digital Transformation Specialist, Copywriter, Blogger