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. 

How to identify the 'Use Cases' in a complex domain

The Standish Group reported that forty percent of the software projects fail due to poor requirements management; incorrect definition of requirements from the start of the project and poor requirements management throughout the software development lifecycle. One way to help ensure the success of a project is to implement an effective requirements management process. Requirements management offers numerous benefits such as improved predictability of a project's schedules and deliverables, reduced project costs and delays, improved software quality, better team communication, greater compliance with standards and regulations.

The objective of this approach is to identify and capture the business requirements in the form of 'Use Cases' in a domain or system that is like a ‘black box’ to the analyst. The first five steps listed below shall be overlooked if you have a great understanding of the domain or system, in a sense you will intuitively do those steps in your mind. For example, if you already knew the sales processes and want to build a system to process sales leads, you could quickly identify the scope and the use cases by thinking of the processes  or tasks that users would need to accomplish in the system. You could quickly come up with: Enter Lead, Edit Lead, Route Lead, Cancel Lead, Work Lead, Print Lead, Sell Lead etc., so you can jump into the 6th step directly; whereas this approach is a generic one, it will be helpful in a domain or system that's like a 'black box' for the analyst.

• Follow the steps to capture the business requirements as Use Cases: 

1. Identify all the stakeholders of the proposed system.
2. Identify the roles and responsibilities of each stakeholder. 
3. Identify the primary flow in the system, and divide the primary flow into multiple stages.
4. Identify all the major activities of the identified stakeholders, their major inputs and corresponding major outcomes, for each stage.
5. Identify the interrelationships of the major inputs and the major outcomes w.r.t the identified stakeholders in each stage.
6. Identify the major transactions in each stage through the proposed system, which is a subset of major inputs and major outcomes.
7. For each identified transaction in each stage, identify the primary actor and their goals, along with the secondary actors.
8. All the identified goals in each stage will form the cloud level use case (each goal will be a separate use case).
9. Start writing the use cases for each stage, and limit the basic flow to a maximum of 7 steps.
10. Hence split each cloud level use cases into user or sea level use cases for each stage.
11. Draw the UML diagrams based on the interrelationships of the sea level use cases for each stage.
12. Identify the missing use cases from the logical disconnect (if any) of the sea level use cases through UML diagrams, in each stage.
13. Identify the missing use cases (if any) w.r.t the roles and the responsibilities of each stake holder within in the proposed system.
14. Write the use cases for the newly identified use cases, go to step 9 (continue the loop till it's sufficient to cover all transactions through the proposed system).