Hi Kumar,

In general, you are correct: the approach that a business analyst takes is fairly consistent from project to project: understand the business needs (the why), discover the things that need to get done in order to fulfill the need (the what), and design the solution (the how).

The approach that you mentioned involves documenting what as functional requirements (use cases), and documenting the how by showing both the static (class diagram) and dynamic (sequence, state chart, activity diagrams) of the system.

At the high level, I see a couple of things missing:

• The Why: this is the business case aka business need aka business problem aka vision - you need to understand why this project is important and needed before you get to the requirements.
• Non-functional requirements which are the requirements which generally are not captured using use cases (performance requirements, usability requirements, availability requirements, scalability requirements, etc.)

Once you fill the gaps, this process will work for most projects. There are project that will require additional tools in your arsenal.

For example: 

• if you are working on a data migration project then data analysis and mapping artifacts become important,
• if your system needs to support strict processes flows and specific workflows then you might need to be able to create process flow diagrams,
• if your project is a data warehouse/reporting then having a solid Entity-Relationship diagram would be very useful,
• etc.

- Adrian