Type cast Business Analyst

It is sad that the business analyst has been typecast as solely a definer of requirements and to run interference with the business community. I tend to buy into the business analysts name - someone who analyzes the business to solve business problems.

There are two approaches depending on the business analyst's stance. A deductive or tactical business analyst responds to stated problems from the business. From that perspective, the business analyst would not be involved until someone identifies a problem - the difference between the current situation and what that someone perceives the current situation should be. Then the business analyst steps in to solve the problem and might in the course of defining the solution document some requirements for change.

In the second approach, the business analyst reviews the business process and identifies improvements or problems that could be solved to improve the process without being told there is a business problem to solve. For example, in the situation of a mechanic using a web site to help diagnose a problem with a vehicle (actual situation), the business analyst might suggest reorganizing the web site so that it reflects the natural way the mechanic uses the information instead of the logical flow of data that would be normally defined by a systems analyst or data base designer. The business analyst  observes the way the mechanic uses the website and suggest improvements not in the mechanic's process but in the way the computer system on the web site supports that process. Once the inductive business analyst's suggestion for improvement is adopted, the deductive business analyst (same guy, different hat) steps in to define the solution in a set of requirements that are implemented to improve the process.

Both business analysis approaches are valid and necessary to add value to the organization.