Holistic View

A Skill Set for Business Analysts.

Holistic view of requirements

There are many aspects to requirements engineering; these aspects, shown in the quadrants of the accompanying requirements grid, may be considered to collectively cover the realm of business, process, rules and data analysis, from strategy to implementation. Frequently these aspects are considered separately and may be associated with specialist roles such as business rules analyst or business process analyst, an architect or a project manager. But business analysts must be able to take a holistic view of the situation and every analyst should have an appreciation of the entire set.

The business analyst must be sensitive to the nature of the project at hand, to its characteristics and to the environment in which it is operating. Working with other stakeholders such as the project manager they should dynamically determine how to combine the aspects shown in the accompanying grid and to assign the optimal weight to each element in order to achieve a balanced approach.

Requirements Activities

The Activities quadrant in the requirements grid shows the activities typically associated with requirements engineering. But effective requirements engineering and business analysis should not be carried out in isolation.

Requirements Context

Requirements need to be seen in a particular context. The context will help to ensure relevance and completeness and will affect how we capture and record requirements, in particular the level of detail and formality that is appropriate.

Requirements Enablers

In conducting the requirements activities it is usually necessary to use one or more of the Enablers shown in the above chart. Separation of the individual enablers helps to manage complexity and supports the development of flexible and maintainable systems. Sometimes one aspect is touted as being somehow more important than the others; we will sometimes hear this from specialists in a particular enabler. Whilst not denying the value of specialists, every business analyst should have at least an appreciation of the entire set. They are all important.

Requirements Interfaces

To achieve success with requirements it is necessary that the business analyst works with other groups – these groups are shown in the Interfaces quadrant of the requirements grid.

Benefits of the Integrated Approach to Business Analysis

The integrated approach, properly applied by professional analysts, will be a significant contributor to the rapid creation of high quality, relevant and useful requirements; these will be the basis for the development of systems that are needed by the business now and are readily adaptable to meet changing business needs. We believe that the approach maximises the chances of being right first time.

Stakeholder Analysis

What is it?
Stakeholder analysis is a technique, typically done at the outset of any sort of change initiative that seeks to identify stakeholders and their attitudes, positive or negative, towards the change, the programme or project and the people involved bring about the change. It is very much concerned with risk management and is key to stakeholder management.
It is also a key technique for business analysts.

Why bother?
Whenever I have been involved in any sort of change initiative, failure to do a stakeholder analysis, lack of rigour in the analysis, has always resulted in problems somewhere down the line. Stakeholder management has been extremely curtailed and usually there was at least one nasty surprise.
Thinking about your own current (or past) projects, do you know who the real source of power is? Do you know all the key stakeholders? Do you know who is affected indirectly as well as directly? Who influences their opinions? And critically, who influences their opinion of you? If you are an external consultant, or you are working in an unfamiliar part of your organisation, do you understand the local (social) networks? It is said that knowledge is power. Lack of knowledge is certainly a weakness.

Getting starting
A simple device to start is create a ‘map’ with horizontal and vertical axes. The former represents increasing power and the latter represents increasing interest (in the change).
Identify as many stakeholders as possible, and put their names on the map in a position corresponding their interest and power. Dividing the map with one vertical and one horizontal line to create four quadrants can facilitate the placing of names. Note that stakeholders may be individuals or groups such as Human Resources.
Pre-pend each name with a ‘++’, ‘+’, ‘- -‘, ‘-‘ or an ‘N’ to denote degrees of support, neutrality or opposition. By the way, it is probably best not to leave this document lying around.

Analysis
Highlight risks and issues to your change project as highlighted by the map.
Attempt a preliminary analysis one why particular individuals or groups are supporters or opponents.
Create links between the names highlighting formal and informal connections. Informal connections may be social or may identify who shapes who’s opinion.

Using the analysis
Create strategies and tactics for stakeholder engagement.
Create strategies and tactics for turning opponents into supporters.
Determine how to capitalise on support and manage opposition.
Determine how to get to people or groups that you do not know, (e.g. sources of power), through people that you do know.

What can prevent a stakeholder analysis?
Lack of support from appropriate people within the organisation.
Deliberate prevention of an analysis by one or more of your managers.
Pressure to just get started with the project.

The Business Context

In the following highly simplified view of the requirements process I feature three organisational elements:

1. The business, from which we elicit requirements.
2. The engine room, where we schedule and resource – and re-schedule, continuously.
3. The test area, where we verify the requirements.

The engine room can be full of activity and stress. We are assured, if not reassured, by the engine room that everything is under control, everything is being done properly. We are told that they don’t have enough staff, but, thanks to their (heroic) efforts, everything is just fine.

The metrics from the test area seem to tell a different story. There are literally hundreds of requirements related incidents representing waste, scrap and re-work. So what’s gone wrong?

To answer this question it can be worth examining the business end. Are projects are being kicked off with an adequate appreciation of the business context? Is the business problem well understood? What about the business goals? The business priorities? The list of questions could obviously go on and could be lifted from any text book on requirements engineering.

So, nothing revolutionary here, but the reality is that this is so often where things start to go badly – from the outset. If we understand the business problem that supposedly gave rise to project then we have some chance of coming up with a solution that will be satisfactory to the business. We will also have a chance of identifying readymade solutions in the market place or even of realising that someone else is already working on that same problem. If we understand the business priorities we have some chance of resolving issues of resource shortage. Again, the list goes on.

Whether our approach is Agile, Waterfall or something else, I suggest that we need to understand the business context. I think that this will always be true. Whether our requirements project is starting from a study of the business or whether we are simply being given a set of product requirements it is always useful to have some understanding of the business context, the problems, objectives and goals, scope, stakeholders, priorities and issues. And if we not given it, I suggest we make efforts to discover it for ourselves.

See also stages 2 and 3 of Capiro’s 8 Steps to Requirements Success for a view on the same topic.

UML Domain Models and Requirements

In typical commercial data base centric systems, the domain model can be a valuable start point for requirements analysis, as long as the business analyst is experienced in their use. Unfortunately the creation of any form of data model is too often thought of as a job for technicians, probably data base designers. I feel that this can lead straight to the consideration of database efficencies before we have really understood the business view of the data and the business rules. Iwas therefore pleased to see this article, although not written by a business analyst, on the OMG web site – Articulate Class Models.

I believe the quality of analysis could be considerably improved if more BAs improved their class / entity modelling skills to the point where creation of a domain model became as natural as creating use cases.