Definition: Business Analyst

I thought I’d do some simple posts that just outline what I mean by certain terminologies. Some terminologies can get a little vague as we start to cross methodologies. The first on my list is

Business Analyst


A person who analyses the operations of a department in order to develop a solution to its problems.

I really like this definition. I’m sure there are those who will hit me over the head with definitions from the BCS or the IIBA, however I think its pretty good. I like it because firstly, its simple. Simple to understand amd simple to explain. I also like it because it doesn’t mention technology.

There are obviously variations on the BA role:

  • Systems Analysts
  • Process Analysts
  • etc..

While I have been known to undertake elements of these in my work, I’m proud to say I’m a Business Analyst.

Engaging A Business Analyst: For Web Projects

Recently I was asked to help define some guidelines to help my team engage a Business Analyst. Initially I was quite surprised, but then I realised what a great opportunity it was to highlight some of the many areas of a project a Business Analyst can engage with and what benefits they can bring.

Before I go into, what to many will seem obvious, it’s probably important for me to give overview of the team that I work with, its size and its culture. I’ve recently joined a team who is making the slow but sure steps from being just another web development agency to being a software house. Although they still make websites, there is a real shift towards bespoke web applications and information systems. It’s a really exciting opportunity, yet slightly daunting as many of the team have never worked with a full-time BA.

Capturing or eliciting requirements can be done by anyone, and when the projects aren’t complicated there is little that can go wrong. It’s only as the scale of the projects increase, the budgets grow and with it the clients expectation, that it becomes clear that things have to get a little more formal.

The following is a very rough guide to how a BA could be engaged throughout the life cycle of a traditional software project. While I’d like to formalise it, I’ve come to realise that every project is different and every project will require different tools.


At the Project Initiation process it’s the responsibility of the Business Analyst to cover the high level scope and objectives of the project and establish communication channels.

  • Help to write PID docs
  • Help to determine technologies used

Understanding the business processes for a section of an organisation or for the whole of the organisation.

  • On site visits
  • Investigations & Interviews

Clear Understanding and communication of Requirements is a very important aspect of a Business Analyst role as it ensures that there is minimum gap between the expectations of the end users and the final deliverable from the technical team.

  • Writing spec documents
  • Meetings & Interviews

During Development

Regular interactions by the Business Analyst with the developers and the technical leads is essential as the knowledge transfer of the user expectations should be ongoing.

  • Continual interaction and collaboration

Functional Testing during the testing phase to ensure that features and functions behave as per the users original requirements.

  • Writing test plans
  • Write automated test suites


After the implementation of the software system, the business analyst also may need to handle the change management process if there are any new requirements or changes proposed.

  • Training sessions
  • User Documentation

This is not an exhaustitive list of possible activities that could be undertaken throughout the life of a project, nor should it be seen as limiting. It’s merely a guide to developers and project managers who have not had the opportunity to work directly with BA’s on projects before, to help understand how you should engage your BA.


Its been a while in the making but it’s finally here! If you’re reading this then you’ve stumbled across my blog.

This is my personal blog about Business Analysis. It’s my intention to write about things that I find useful in my day to day job as BA, tools, books and methods. I’ll probably also aim to comment on some of the things I experience along the way.

Please have a look about and let me know what you think.