Trinh Hieu Trung

There is no industry standard definition of the term “business analysis” and it can mean different things to different organisations. To some, a business analyst is a person who documents and analyses software requirements, to others the analyst is one who helps the business define and document their business strategy. It could be said that business analysis spans a range of activities that starts with the former and ends with the latter.

Historically in software development, one of the problems has been a lack of understanding of the underlying business among software developers and the discipline of business analysis is supposed to resolve that problem. Despite the existence of this discipline, however, there continue to be problems.

The key things to note about business analysis are that its purpose is to provide an understanding of the nature and objectives of a business, and that it focuses on the business needs and business solutions to those needs rather than technological solutions.

The range of activities that fall within the discipline of business analysis can include the following:

• Strategy analysis
• Business system modelling
• Business process modelling
• Information analysis
• Stakeholder analysis
• High level requirements analysis (HLRA)
• Low level requirements analysis (LLRA)

I will provide an overview of each of these activities in future posts, so if you return later, you will see the activities listed above will have become hyperlinks. Note that very rarely would an analyst be experienced across the whole range and most analysts I have met have experience in only two or three areas. Indeed, many who list analysis as one of their capabilities are not even aware of this range of activities.

It is important to remember that being an analyst involves more than just showing up at customer workshops and taking notes. There are techniques involved that are specific to each of the activities listed above. Moreover, analysis is a mindset and while I think it is a good thing for developers to have some analysis skills, it is important to approach analysis tasks with an analysis mindset. In simple terms, this means constantly thinking “What is the real business need here?” rather than “What solutions can I put in place?” I will discuss this mindset in future posts.

You will notice that I have highlighted Strategy Analysis, Business System Modelling and Business Process Modelling and I would like to explain why.

These first three activities result in what can be called the Business Architecture, which is essentially what is supposed to fill the gap in understanding that I mentioned in the second paragraph above .

Without the business architecture, the information architecture cannot be completed, although information analysis can begin. In simple terms, Information Analysis deals with how an organisation manages its information, so this activity could start in parallel with development of the business architecture but also must be informed by the final business architecture in order to produce the information architecture. Both of these architectures should be stable before defining the technology architecture. However, since Information Analysis includes low-level Data Analysis, this activity would carry on during LLRA.

Without the business architecture and information architecture being finalised, high level system requirements (HLRs) should not be addressed, since there would be no context for them. Without the HLRs, there is no scope for any kind of system development. Indeed, I see the high level requirements as defining the scope. The HLRs should be used to identify and select the appropriate technology (and development personnel) with which to build the solution. Therefore, I would draw a line between production of the Business Architecture and Information Architecture on the one hand and the high-level requirements analysis on the other.

Similarly, I would draw a line between high-level requirements analysis and low-level requirements analysis for two reasons. Firstly, HLRA must be complete in order to choose the technology and development team, whereas LLRA starts after the “solution approach” has been decided. Therefore, (and secondly), since HLRA must be complete before LLRA can begin, HLRA cannot be rolled into any iterative plan, whereas LLRA can (and, in my opinion, should) be approached iteratively.

Stakeholder analysis forms part of stakeholder management and thus comes under the remit of the Project Manager. However, I would expect to see considerable input from a business analyst around the same time the business architecture is being produced. Stakeholder analysis should be complete by the time the project scope has been defined. Everyone needs to be aware of who the stakeholders are and how they can influence the project.

Sequence of analysis activities (does not imply any time-scale)

Here are some examples of how it all can go wrong:

• No business architecture nor information architecture have been produced, with the result that there is no context for any subsequent work and the resulting system is not really what the business needed.
• No scope has been defined prior to starting the development life-cycle and the result is confusion and expanding costs.
• No stakeholder analysis has been done and so people don’t know who they are trying to help and why, or indeed, who might be trying to obstruct the project and why.
• Production of the business architecture is built into the iterations of the system development life-cycle, with the result that the business architecture is not complete until two thirds of the system has already been built and considerable chunks of it having to be rebuilt to match the final business architecture.

I hope this article has given you some idea of what business analysis is about, although it is a weighty and continually evolving subject and one which I continue to study and explore.

Source: www.chellar.com