Business Analysis

home

Articles

Blog

Books

Tools

Links

FAQ Page

Business Analysis

What
For a definition I have amended Philippe Krutchen's one of Business Modelling.

Business Analysis defines the processes, roles and responsibilities of an organization in a model of the business.

This model is then used to identify business needs that need satisfying.

Business Analysis Modelling is a core technical discipline in the RUP

Why?
Business analysis provides the foundation on which solid functional and non-functional requirements are be built. Once the processes have been analyze and proven, designers and software architects can have confidece in the work they produce.

A potential risk with business analysis is that does not agree with the findings. In a worse case scenario, refuses to accept or pay for the finished product.

Who?
A Business Analyst. However in many organisations, there is no distinction between analysts. In an ideal world, the business analyst has a thorough understanding of the business environment in which the Software Under Test (SUT) will operate. The analyst or analysis team should continue to be involved througout the cycle, as guiding lights. This mirrors the idea that the business requirements do not become shelfware, in the drive to develop.

The RUP splits the businees modelling role even further. A Business Process Analyst and a Business designer.

In my experience, business analysts are best as a permanent employee. I can see the value of a contractor, particularly if she is an expert in her field. This might be case for such areas as Basel II and Sarbanes-oxley. However, permanent employees, have the edge in the greater chance of them staying with the project.

Where?
Usually within the organisation. Some development methodologies, such as agile development will engage the customer as a stakeholder. Thus business analysis might be partially done within the client.

When?
Depends on the development approach taken. In a traditional waterfall approach, the business analysis is completely finished before drawing up requirements has begun. Firm foundations can be laid for a successful development, if the the analysis is accurate. However this is a big "if" on which to spend thousands of man days.

An iterative approach however would seek to continually seek to confirm that the software under test (SUT) meets the business requirements of the user. An example of iterative development is the Rational Unified Process.

Essentially the difference between the Waterfall and RUP approaches is risk. In the waterfall, the organisation does not know until the customer takes delivery of the product, if it meets their business requirements. A worst case scenario is that the customer refuses to take delivery.

The RUP takes the opposite approach. Attack the biggest risks first and keep attacking them. Business analysis is more about mitigating risk than design.

Thus the object of the first phase, inception, is to mitigate business risk. A coarse grained analysis is conducted. This broadly defines what the organisation is to build. It also sets out the broad requirements the SUT is to meet. At the end of inception all stakeholders are aware of the business risk and how it is going to be mitigated.

As the project moves through the phases of elaboration, construction and transition, the business analysis is of a finer granularity. Thus in construction, individual components may be analysed in a business sense. Finally in the transition phase when the customer implements the SUT, everyone can be sure that it meets the business needs of the client.

In contrast, with the Waterfall framework, business acceptance testing, might be the first time the client has seen the SUT. Up until this point there is a very high risk of failure.

How?
In a standards free zone, business analysis can be done in many different ways. Under the waterfall, an analyst or a team of them produce the business requirements. A hefty folder, this will contain a great amount of detail. As the development cycle progress, the "business model" will slowly gather dust as the customer changes her mind, developers create workarounds etc. Templates and other infrastructure may be required.

Again I take an idea from Krutchen. That of Ceremony. The idea springs from the amount of status given to writing things down and storing them. Business modelling like everything else in the RUP, contextual. In the early phases and iterations, the business processing takes centre stage, especially inception. Inception is where we seek to mitigate business risk. The ceremony involved should be appropriate to the task in hand. Thus in inception, the business modelling is coarse grained.

RUP makes extensive use of Unified Modelling Language, to create Use Cases. The process however does list numerous artifacts thank be used again.