From Wikipedia, the free encyclopedia - View original article
|This article needs additional citations for verification. (August 2010)|
Business analysis is a research discipline of identifying business needs and determining solutions to business problems. Solutions often include a software-systems development component, but may also consist of process improvement, organizational change or strategic planning and policy development. The person who carries out this task is called a business analyst or BA.
Business analysts do not work solely on developing software systems. Those who attempt to do so, run the risk of developing an incomplete solution.
Business analysis as a discipline has a heavy overlap with requirements analysis sometimes also called requirements engineering, but focuses on identifying the changes to an organization that are required for it to achieve strategic goals. These changes include changes to strategies, structures, policies, processes, and information systems.
Examples of business analysis includes:
Focuses on understanding the needs of the business as a whole, its strategic direction, and identifying initiatives that will allow a business to meet those strategic goals. It also includes:
Involves planning the requirements development process, determining which requirements are the highest priority for implementation, and managing change.
Describes techniques for collecting requirements from stakeholders in a project. Techniques for requirements elicitation include:
Describes how to develop and specify requirements in enough detail to allow them to be successfully implemented by a project team.
The major forms of analysis are:
Requirements documentation can take several forms:
Describes techniques for ensuring that stakeholders have a shared understanding of the requirements and how they will be implemented.
Describes how the business analyst can perform correctness of a proposed solution, how to support the implementation of a solution, and how to assess possible shortcomings in the implementation.
There are a number of generic business techniques that a business analyst will use when facilitating business change.
Some of these techniques include:
This is used to perform an external environmental analysis by examining the many different external factors affecting an organization.
The six attributes of PESTLE:
This is used to perform an in-depth analysis of early stage businesses/ventures on seven important categories:
This is used to perform an internal environmental analysis by defining the attributes of MOST to ensure that the project you are working on is aligned to each of the four attributes.
The four attributes of MOST
This is used to help focus activities into areas of strength and where the greatest opportunities lie. This is used to identify the dangers that take the form of weaknesses and both internal and external threats.
The four attributes of SWOT analysis:
This is used to prompt thinking about what the business is trying to achieve. Business perspectives help the business analyst to consider the impact of any proposed solution on the people involved.
There are six elements of CATWOE:
This is often used in a brainstorming session to generate and analyse ideas and options. It is useful to encourage specific types of thinking and can be a convenient and symbolic way to request someone to “switch gears". It involves restricting the group to only thinking in specific ways - giving ideas & analysis in the “mood” of the time. Also known as the Six Thinking Hats.
Not all colors / moods have to be used
Five Whys is used to get to the root of what is really happening in a single instance. For each answer given a further 'why' is asked.
This is used to prioritize requirements by allocating an appropriate priority, gauging it against the validity of the requirement itself and its priority against other requirements.
This technique is used when analyzing the expectations of multiple parties having different views of a system in which they all have an interest in common, but have different priorities and different responsibilities.
The SCRS approach in business analysis claims that the analysis should flow from the high-level business strategy to the solution, through the current state and the requirements. SCRS stands for:
As the scope of business analysis is very wide, there has been a tendency for business analysts to specialize in one of the three sets of activities which constitute the scope of business analysis, the primary role for business analysts is to identify business needs and provide solutions to business problems these are done as being a part of following set of activities.
In any case, the term "analyst" is lately considered somewhat misleading, insofar as analysts (i.e. problem investigators) also do design work (solution definers).
The role of Business Analysis can exist in a variety of structures within an organizational framework. Because Business Analysts typically act as a liaison between the business and technology functions of a company, the role can be often successful either aligned to a line of business, within IT or sometimes both.
A business process improvement (BPI) typically involves six steps:
1. Selection of process teams and leader
Process teams, comprising 2-4 employees from various departments that are involved in the particular process, are set up. Each team selects a process team leader, typically the person who is responsible for running the respective process.
2. Process analysis training
The selected process team members are trained in process analysis and documentation techniques.
3. Process analysis interview
The members of the process teams conduct several interviews with people working along the processes. During the interview, they gather information about process structure, as well as process performance data.
4. Process documentation
The interview results are used to draw a first process map. Previously existing process descriptions are reviewed and integrated, wherever possible. Possible process improvements, discussed during the interview, are integrated into the process maps.
5. Review cycle
The draft documentation is then reviewed by the employees working in the process. Additional review cycles may be necessary in order to achieve a common view (mental image) of the process with all concerned employees. This stage is an iterative process.
6. Problem analysis
A thorough analysis of process problems can then be conducted, based on the process map, and information gathered about the process. At this time of the project, process goal information from the strategy audit is available as well, and is used to derive measures for process improvement.
Includes the following steps:
Ultimately, business analysis wants to achieve the following outcomes:
One way to assess these goals is to measure the return on investment (ROI) for all projects. According to Forrester Research, more than $100 billion is spent annually in the U.S. on custom and internally developed software projects. For all of these software development projects, keeping accurate data is important and business leaders are constantly asking for the return or ROI on a proposed project or at the conclusion of an active project. However, asking for the ROI without sufficient data of where value is created or destroyed may result with inaccurate projections.
Project delays are costly in two different dimensions:
N.B. On a lot of projects (particularly larger ones) the project manager is the one tasked with ensuring that a project is completed on time. The BA's job is more to ensure that if a project is not completed on time then at least the highest priority requirements are met.
Business analysts want to make sure that they define the requirements in a way that meets the business needs, for example, in IT applications the requirements need to meet end-users' needs. Essentially, they want to define the right application. This means that they must document the right requirements through listening carefully to ‘customer’ feedback, and by delivering a complete set of clear requirements to the technical architects and coders who will write the program. If a business analyst has limited tools or skills to help him elicit the right requirements, then the chances are fairly high that he will end up documenting requirements that will not be used or that will need to be re-written – resulting in rework as discussed below. The time wasted to document unnecessary requirements not only impacts the business analyst, it also impacts the rest of the development cycle. Coders need to generate application code to perform these unnecessary requirements and testers need to make sure that the wanted features actually work as documented and coded. Experts estimate that 10% to 40% of the features in new software applications are unnecessary or go unused. Being able to reduce the amount of these extra features by even one-third can result in significant savings. An approach of minimalism or "Keep it Simple" and minimum technology supports a reduced cost number for the end result and on going maintenance of the implemented solution.
Efficiency can be achieved in two ways: by reducing rework and by shortening project length.
Rework is a common industry headache and it has become so common at many organizations that it is often built into project budgets and time lines. It generally refers to extra work needed in a project to fix errors due to incomplete or missing requirements and can impact the entire software development process from definition to coding and testing. The need for rework can be reduced by ensuring that the requirements gathering and definition processes are thorough and by ensuring that the business and technical members of a project are involved in these processes from an early stage.
Shortening project length presents two potential benefits. For every month that a project can be shortened, project resource costs can be diverted to other projects. This can lead to savings on the current project and lead to earlier start times of future projects (thus increasing revenue potential).