The making of an effective BA

The BA(business analyst) role existed in the initial years to fulfill the gap between the business managers and the software developers. Since then the software development has advanced to new levels by borrowing the best practices from the other industries such as manufacturing and construction (the principles of lean management and objects/components oriented approaches) to make software development effort highly predictable, flexible, cost effective, high quality and easy to maintain applications & systems. 

BA shall be a business technologist (BT) for achieving the above objectives; the business requirements have to be broken down into 'objects' and the further these 'objects' have to be categorized into 'classes' ('Boundary', 'Entity' and 'control', refer http://en.wikipedia.org/wiki/Class_diagram) and map their inter-relationship through class/collaboration diagrams. When the BA does this work, the business requirement communication gap with the architect/design teams can be eliminated to a greater extent, since the BA has the best knowledge of the business requirement. From here the architect/design team can take off.

The Use Case and UML based approach to requirements gathering is more convenient to identify the 'objects' from the business requirements. Tools such as Rational Requisite Pro helps to organize, store, retrieve and manage requirements; tools such as Rational Rose helps to organize objects and group them into packages/components, draw the class/collaboration diagrams (from the identified objects & classes) as well as generate code automatically. Integration of these tools will facilitate the direct mapping of requirements to class diagrams, so that the changes in requirements can be managed easily.

So it's no longer business requirements gathering it's "Business Requirements Engineering" to create  a highly predictable, flexible, cost effective and easy to maintain applications & systems. That's why we hear the 'Open UP', 'Agile' & 'Scrum' practices often (refer http://www.eclipse.org/epf/general/OpenUP.pdf, http://www.jimhighsmith.com/articles/IEEEArticle1Final.pdf and http://www.cs.colostate.edu/~france/publications/AgileSE-draft.pdf), so that the changes in business requirements can be accommodated to the last extent possible and remain cost effective and in time! 

Hence the BA’s role straddles from business analysis to process improvement by incorporating the industry best practices and striving to create the next practices, identifying the opportunities for automation in the improved/redesigned business processes, converting the automation opportunities to business requirements, then decoding the business requirements to ‘objects’ by performing the object oriented analysis to give primary inputs to architecture/design team, guiding the development  and quality assurance teams to be on track and negotiate change, enabling the user acceptance tests and hand-holding the client to embrace the change in adopting to new systems and business processes, thus delivering exceptional business value.