The big picture

earth-viewThis site is intended to serve business analysts and this article will provide you with the helicopter view (i.e. very high level view) of business analysis, covering all the key areas very rapidly. You can then choose which areas you want to explore further.

If you want to know which articles already exist, just look at the posts on the right and the tags – that should give you a good idea of which areas have already been covered.

Alternatively, just drop me a line at with the content you were looking for and I’ll see what I can do.

What is business analysis?

If you’re brand new to this and are thinking of taking up a career, I’d highly recommend you read this article – What is business analysis?. This is where I present a simple analogy of the analyst as interpreter between the business and IT as a means of explaining the BA’s role. Have a look and see if it helps you out.

In the beginning (why?)

A good place to start is where a business analyst is first called upon. The business always has to justify any expenditure in changing the business by understanding the cost and demonstrating the value or benefit that the desired change supplies – this is supplied by the Business Case.

An early decision is made at this point whether to proceed – if the cost outweighs the benefit, clearly there is no point in proceeding. Of course, at this stage, the costs aren’t really that well understood so a more detailed investigation is required. This comes in the form of a Feasibility Study which allows the business to invest a relatively modest sum to provide more reliable costs. There are many other aspects to the feasibility study regarding, for example, the impact on the organisation of the proposed change and how it would be introduced.

The Study will make a recommendation on whether to proceed and, if so, how to proceed with the proposed change. The appropriate parties within the business (typically at executive level) will decide whether to proceed based on this information.

The middle (let’s do it)

Once the project has been authorised to proceed then some nuts and bolts work is required. There will be some planning to decide how to proceed with the project. The project manager would have been appointed by this time and he will have overall responsibility for delivering the project. He will look to the business analyst (or lead business analyst) to provide the plan and approach on how to gather the requirements, document them and have them agreed with the stakeholders.

The initial task for the business analyst is to create a requirements plan which will determine the team required, the stakeholders , other involved parties and the approach to be taken.  The business analyst’s responsibility though the remainder of the project is often referred to as requirements engineering.

In creating the plan, it is necessary to understand the parties involved in the business who have an interest in the project whether directly or indirectly. They may have an interest because:

  • their day job will be impacted – maybe it will make them more productive
  • they are responsible for managing cost and the ultimate success of the project – usually the business or executive sponsor
  • they are managing the organisation risk with regard to regulatory compliance
  • they will have to support the business change once the project has completed
This is referred to as stakeholder analysis and is key as the failure to identify and involve all the stakeholders will put the project at risk.
The requirements gathering will involve a number of techniques to analyse and understand the scope of the project and to identify all the requirements:
  • Analyse existing documents
    This could be, for example,  existing training materials, business processes or legal documents
  • Interviewing users
    This can be successful but requires a sensitive approach that is open and puts the user at ease
  • Receiving user training
    This is an interesting variation on the above which tends to put the user at their ease
  • Observing users
  • Prototyping
    People always respond better to something that looks like  a real system – they wil be more engaged than with documents.
  • Workshop (see Workshops – an Introduction)
    This is a common technique which is necessary when there are a number of different views and there may need to be negotiation and compromise
  • Questionnaire
    Can be valuable in very specific circumstances

The business analyst must document the requirements and this can take several forms depending on the type of requirements:

Business operating model or business domain model

This represents a pure business view and is used to understand both the current state of the organisation and the how it will look after the project has been completed

  • To Be and As is process models
  • Organisational context
  • Requirements catalogue
    This shows the high level requirements of the business driven from the project objectives. It is not a simple exercise to ensure quality requirements (see Requirements engineering and quality)

Functional requirements

These are the specific requirements that relate to the behaviour of the proposed system:

  • Use case model (see Use Cases – an Introduction)
    Well etablished approach using a mixture of diagrams and narrative descriptions
  • Storyboard (see Requirements Gathering alongside use cases for more on this)
    Less formal approach using pictures, based on the idea from the film world
  • Prototype
    More engaging approach which delivers ‘mockup’ of system. Can vary from very approximate static diagrams through to fully interactive with representative data.
  • State diagram
    Very specific approach that adds value when an entity has a complex lifecycle e.g. Customer, Order

It will also be necessary to detail non-functional requirements which describe the characteristics or qualities of the resulting system (see Non-functional requirements).

If you would like to read more about use case modelling and how it fits in with business processes and context diagrams, see Use Cases – what comes before?

Data requirements

These show the entities and attributes of importance to the business. These can be overlooked and treated as ‘technical documents’ but they provide an important statement of the business and their requirements from a different viewpoint.

  • Business object model
    Shows business entities, their attributes and relationships
  • Data dictionary
    Shows more detail about attributes


There are several methods for gathering requirements and, subsequently, documenting them but this should not be viewed as a linear process. In reality, the business analyst will pick and choose from the techniques and repeat the cycle of eliciting, documenting and reviewing requirements several times.

The focus must be on one particular area at a time as stakeholders will expect different levels of involvement depending on their degree of interest or the relevance of a specific area to them. Requirements management and planning should take account of this so that the level of stakeholder involvement can be communicated at the outset


The gathering and documenting exercise will reach a point where agreement needs to be reached between all parties concerned. Typically, this will involve the creation of one or more documents which will be distributed for review before a final sign off workshop where the business analyst will facilitate a discussion between the stakeholders to resolve any outstanding concerns or disputes before agreeing the final set of requirements.

Depending on the project approach, this may happen several times, for each iteration where the project delivers an agreed system within each iteration which evolves towards the complete system (aka the Agile approach).

The heavy lifting

Once the requirements have been established, that’s when the project really ramps up as designers, builders, testers and 3rd parties are engaged to design, build and test what has been specified. Of course, this would have been started in parallel to requirements gathering but it can’t really take off until the requirements have been formally agreed.

This takes a lot of manpower and is where significant costs are incurred. The business analyst’s role during this phase is to be available to explain and clarify the requirements, ensure the requirements are traced through to design and build, support the testing or QA effort and assist in managing change.

The end (did we do it?)

As the testing or QA phase starts to ramp up, it is determined whether the project delivered on the original requirements. The original requirements are traced through to test scripts and conditions which are used as part of the verification. There may be several testing initiatives with names such as system testing, business acceptance testing or user acceptance testing. They will have different objectives but they should, altogether, be proving the requirements have been delivered.

Benefits realisation

Beyond the successful delivery of the project, there will be efforts to ensure that the benefits that were originally identified are delivered and the cost savings achieved.

Useful links

Most of this was my based on my experience but I used the Business Analysis Body of Knowledge (available here in draft or official version if you become a member) to provide some of the structure.

About Alex Papworth

15 Responses to “The big picture”

Read below or add a comment...

  1. Ananda says:

    Thanks Alex,I want to pursue my career as a Business Analyst,Following your articles on BA ,I got an idea of this profession.

  2. onlineprofessionaleducation says:

    Great article Alex.

    Reading through the comments reminded me of this article I came across about "requirements management", it may be helpful in further explaining requirements.

  3. Hey Alex, very impressive and comprehensive description of the BA role. Most of the BA’s / role definitions I’ve seen match this model. One thing that I didn’t see is an emphasis on collaboration between the BA and the sponsor – as Jon points out in his comments.

    There is a lot of value in having the BA collaborate on the vision / business case. There is also a significant value to having the BA involved in the design of the approach (the next level below the business case, but above writing specifications). Since “requirements vs. design” is such a hot topic, I’ll use an example to clarify what I mean:

    Business Case / Vision: Penetrate the online storage subscription market…
    Design of Approach: Create a product for smart-phones, targeted at early adopters…
    Writing Specs: The client application must run on the Palm Pre…

    My quickly-cobbled example might be put inside the vision, but the idea is sound – that there is a level of detail that is too much for a business case or vision document, but that still lives above “requirements gathering” as I’ve usually seen it described for BA roles.

    This level of involvement changes the BA role from a “cost center” to a “profit center” in that the BA is not just mechanically decomposing and documenting a solution, but rather, contributing to the quality and likelihood of success of the solution that is to be built, by affecting change to “build the right stuff” decisions as well as “build it right” decisions.

    When I was working with Dell, this was labeled as a “business architect” role rather than a “business analyst” role. I hadn’t seen that title elsewhere.

    • Alex P says:

      Thanks Scott.

      I agree with your comments. The BA’s role used to be much more mechanical but is evolving to, as you say, becoming a ‘profit center’ rather than cost. My experience is that my description is still more typical but that your description is becoming more common. From a business perspective it’s very compelling and for a BA looking to improve their prospects it is obvious that he/she should be looking to develop skills in this direction.

      I wrote a related article very recently about how the business analysis role has evolved which you may find interesting. I’d be interested if this matches your experience or how your experience differs.

      By the way, I’ve just added your blog to my blogroll – long overdue!

  4. Jon Crosby says:

    I find producing a Vision document, focussing on high level Needs and Features, is very useful at the start of a project to get agreement from major stakeholders on what is really needed. This can be done alongside or before a Business Case. I tend to lead on writing the Vision, whereas the business sponsor leads on writing the business case, although both are a joint effort. If the project is approved, it can be used to trace to use cases and NFRs (using ReqPro if you like). This then acts as a check that all detailed requirements link to a real Need or Feature and helps to avoid scope creep, or ensures that new Needs and Features are revealed and agreed at a high level and subject to Change Control.

  5. alexpapworth says:

    Hi Robert
    In answer to your first question regarding persuading client to support the early joining of the BA to a project, along with the PM:

    it’s desirable that they both join the project at a similar time and as early in the process described above.
    As for most things, clients need to understand the benefits of bringing in the BA early. Perhaps it would be possible to quote problems that would have been avoided from past projects?
    Clearly the best opportunity for achieving this is with understanding of the client organisation and their processes and relevant politics.

    Second question : How do reqts relate to the business case?

    My view is that the business case will describe a change in the business that will deliver certain benefits. The business change will be defined and, ultimately, many of the requirements will be justified by delivering one or more aspects of the business change. In some ways, the business change can be seen as a set of high level requirements.

    Third question : Is the PM in charge of ongoing stakeholder management?

    I’m not familiar with the BCS book so I’m answering somewhat blind.
    I wouldn’t be so prescriptive. I think the sensible BA is always aware of stakeholders, which ones are relevant to a BA and their particular interest. However, the project manager should take a similar view from their perspective. I would suggest that stakeholder management would be discussed and agreed between the PM and BA in light of the BA’s experience. The experienced BA may well take more ownership of the stakeholder management but not with regard to cost, timescales and the executive sponsor given the high profile of that stakeholder.

  6. In the BCS book (p83) it says ‘much of the groundwork for stakeholder management begins before the before the Business Analysis project proper begins’ and ‘the main responsibility for Stakeholder Management rests, of course, with the PM’. This suggests that the BA does the Stakeholder Analysis as a task but then hands it over to the PM to manage. Is this how you see it?

  7. How do Requirements relate to the Business Case?

  8. Alex,
    Frequently BAs are brought in AFTER a Project Manager is in place. How can clients be educated to bring in a BA at an earlier stage?


  1. […] a problem domain (as a precursor to determining requirements) see The big picture to understand the overall […]

  2. […] a problem domain (as a precursor to determining requirements) see The big picture to understand the overall context) […]

  3. […] If you want to see the how a project fits into the larger context of a business, you should read The big picture […]

Leave A Comment...