Business Analyst Study Notes: Frameworks, Tools And Techniques

Since business analysis is an established discipline, there are a range of frameworks, tools and techniques that are available to BAs. It is rarely necessary to reinvent the wheel, and there are many useful resources on which BAs can draw for inspiration. Frameworks provide useful patterns for a practitioner to use, but the way that a framework is applied will vary depending on the context. An urgent need to respond to a sudden security concern may, for example, be handled differently from a larger, longer-term organisational change.

Some frameworks and models are:
- Business Analysis Process Model (BCS);
- Requirements Engineering Framework (BCS);
- BABOK® Knowledge Areas (IIBA®).

Remember: There is no single ‘paint-by-numbers’ approach that will be effective in every single conceivable situation. 
Re-engineering a procurement process in a small and efficient business would, for example, be a very different analysis engagement from a project aiming to implement an electronic patient record system in a hospital.
The tools and techniques that are used (and the analysis artefacts that are produced)will be guided by the context in which the analysis is undertaken. BAs have a broad set of tools and techniques at their disposal, and part of the analyst’s job is to choose the best tool for the situation (and to be prepared to change approach if a particular tool or technique does not work in a given situation). Contextual and external factors – such as available budget, time pressure, risk and culture – can affect the suitability of particular tools or can mean that they have to be used in a particular way.
However, using a set of unrelated tools in isolation is unlikely to lead to the most effective outcome. Not only do analysts need to think holistically about the business situation which they are investigating but they also need to think holistically about how the overall set of analysis tasks will be completed. A number of complementary frameworks have emerged which can be of great assistance. Two of particular relevance are BCS’s Business Analysis Process Model and Requirements Engineering Framework and another is the collection of Knowledge Areas from within IIBA®’s BABOK® Guide.

Business Analysis Process Model
BCS’s Business Analysis Process Model is designed to provide high-level, flexible guidance on how a business analysis engagement is typically conducted. The stages of the process model are relevant whatever the initiative: for very small initiatives or those where there is a clearly provable problem and solution, a lightweight approach might be taken. Other initiatives where the landscape is less clear may require significantly more analysis work up front. The model supports either approach and leaves the practitioner and the project team to select the right tools for any given situation.

A BA may join this model at any stage or may progress through certain stages in parallel or iteratively. In some cases, one single ‘stage’ might be the assignment (e.g. an initial report to investigate the situation). Whatever the assignment, the business context must be kept front of mind at all times – this will help the practitioner to select relevant tools and guide relevant activities.

Stages of the Business Analysis Process Model
Stage Brief Description - Involves: 

Business context 
- gaining and maintaining an understanding of the external and internal business environments;
- maintaining an awareness of existing organisational strengths and weaknesses;
- maintaining a good understanding of the organisational strategy and of how potential projects and programmes align with it.

Investigate situation 
Involves: - conducting an initial investigation of the problematic situation;
- conducting an initial scope of the analysis work;
- documenting the business situation.

Consider perspectives 
Involves: - identifying, categorising and planning to engage with stakeholders – potentially including stakeholders both inside and outside the organisation;
- assessing the various worldviews and perspectives held by stakeholders;
- creating models based on stakeholder perspectives (conceptual models such as business activity models);
- seeking ‘accommodation’ or, where possible, consensus between competing perspectives.

Analyse needs 
Involves: - conducting a gap analysis to compare the desired state and current state;
- conducting further, more detailed examination of the current situation and processes.

Evaluate options 
Involves: - generating a list of potential improvement opportunities;
- assessing the feasibility of each option;
- creating justification and an artefact that supports decision making – typically a business case.

Define requirements 
Involves: - eliciting, analysing and validating requirements;
- creating requirements documentation, including relevant models;
- using the Requirements Engineering Framework.

Requirements Engineering Framework
The Requirements Engineering Framework provides an overall pattern that can be used by analysts when operating within the define requirements stage. It is a flexible framework which outlines the core business analysis activities without mandating the specific tools or techniques that a BA should use. That is to say, it very much says what ought to be done but does not specify how it should be done – nor does it specify how much of each activity should be undertaken. This is an important distinction, as the context of the situation will drive how tools and techniques are used. If we are procuring a solution, we may need a high-level list of requirements to be present in their entirety up front, and this may need to be packaged as an RFP. This would lead to a very different application of the framework compared with, say, changes to an existing website that are undertaken in an adaptive way. In the former we are likely to work fairly sequentially: eliciting and analysing, then formalising the documentation, prior to validating. In the latter we are likely to work in iterative cycles, perhaps validating prototypes for a particular area, seeing how this looks once it has been developed, then considering other areas of functionality.

Stages of the Requirements Engineering Framework
Stage - Brief Description

Requirements elicitation 
- Aims to draw out the requirements from the business situation. This typically involves using a range of different elicitation techniques, some which involve stakeholders (such as interviews, workshops and observation)and some of which initially do not (such as document analysis).
- Particular care must be paid to tacit knowledge – that is, knowledge that has become second nature and that stakeholders may not think to mention when asked.
- The output from an elicitation activity is the elicitation results. These are often raw in form and will need significant tidying up and analysis before they are considered to be potential requirements.

Requirements analysis 
- This stage ensures that the requirements are well organised, prioritised and well written.
- It acts as a quality filter, weeding out duplicates, imprecise and untestable requirements, and any other problematic requirements.
- It ensures consistency between different requirement artefacts, including checking for consistency across any relevant requirements models.
- Often analysis of requirements leads to further elicitation activity, as questions arise and need to be investigated further.

Requirements validation 
- This stage involves the review of requirements by interested stakeholders.
- It includes achieving approval from the sponsor, requirement owners and any other appropriately nominated stakeholders.

Requirements documentation 
- This is an ongoing activity. A requirements document typically starts rough, with potential requirements being added as they are elicited.
- As analysis takes place, the requirements document becomes more structured.
- The ‘document’ may take any number of formats: requirements can be stored in word-processed documents or specific requirements management or computer-aided software engineering tools.

Requirements management 
- This includes ensuring that requirements documentation is stored in some form of central repository where only those with a genuine business need can access them.
- It is also about implementing version control and change control and ensuring that there is a ‘single source of the truth’.
- It involves baselining requirements after sign-off, where appropriate, responding to change, and keeping the requirements maintained and up to date.
- The specific requirements management practices will vary depending on context, including whether an adaptive or predictive approach is being utilised.

IIBA® Knowledge Areas
IIBA®’s Business Analysis Body of Knowledge was developed independently of the BCS framework, but as you would expect with a profession that is maturing, the two are similar in intent and can be seen as being complementary rather than divergent. BABOK® outlines six Knowledge Areas, plus a range of underlying competencies and perspectives. Knowledge Areas are described as representing ‘areas of specific business analysis expertise that encompass several tasks’. Each underlying task is typically conducted at least once, although often multiple times, in any single business analysis engagement. The IIBA® framework is flexible – it may be that on one project each task is conducted very formally with detailed documentation created. On a smaller and less risky project, tasks may be less formal, with lighter-weight documentation.

The Six BABOK® Knowledge Areas
Knowledge Area - Brief Description

Business Analysis Planning and Monitoring 
- This Knowledge Area involves planning the overall business analysis approach and how to engage and work with stakeholders.
- It also involves assessing how the BA work will be governed and where BA documents and artefacts will be stored.
- Additionally, it covers the ongoing monitoring of BA activities, including identifying any ways of improving the quality of the analysis and the performance of the analyst team.

Elicitation and Collaboration 
- This Knowledge Area involves the preparation and carrying out of elicitation activities, and the confirmation of elicitation results.
- It includes elicitation early in the business change lifecycle (where a problem or opportunity is being investigated)as well as more detailed elicitation that takes place later on.
- It also includes ongoing communication and collaboration with stakeholders.

Requirements Life Cycle Management 
- This Knowledge Area includes the tracing and general maintenance of requirements.
- It involves prioritising requirements.
- It also includes seeking (and achieving)approval of requirements, and assessing requirement changes.

Strategy Analysis 
- Often this Knowledge Area is related to work carried out up front to understand underlying problems and opportunities.
- It includes analysing the current state, defining the desired future state and assessing any risks that may emerge.
- It includes defining a ‘change strategy’, which will likely involve evaluating several options and recommending an approach in a business case or equivalent document.

Requirements Analysis and Design Definition 
- This Knowledge Area includes the specification, modelling and documentation of requirements.
- It also involves the verification (quality checking)and validation (ensuring alignment with objectives that are valued by the business)of relevant artefacts.
- It includes definition of a ‘requirements architecture’ – that is, defining how different requirement artefacts connect together conceptually. For example, this might define how different models relate to each other, how they connect to any textual requirements artefacts and so forth.
- It covers the definition and recommendation of design options. It should be noted that BABOK® acknowledges that analysis often blurs into design – for example, detailed specification of a process might involve defining the physical steps which will be undertaken by those who are involved in the execution of the process. This implies a strong element of both definition and design. However, it should be noted that BAs do not normally undertake IT technical design work. The extent to which BAs are involved with design will depend on the context, the type of problem or opportunity, and the options being pursued.

Solution Evaluation 
- This Knowledge Area considers the tasks undertaken by BAs in relation to solutions that have been constructed (built).
- It includes measuring and analysing solution performance – either of a solution that has been deployed or of a proof of concept.
- It covers assessment of any (internal)enterprise limitations that are inhibiting the performance of the solution.
- It encompasses making any recommendations to improve the performance of the solution and realise additional benefits.
 

Read Next: Business Analyst Study Notes: Commonly Used Tools And Techniques