Career Forums

Raj,

For starters, you have found the right community.  It's a shame you didn't find us 3 years ago.  You have a great educational background for a role as a BA.  I too come from a Mechanical Engineering background.  Engineers typically make good problem solvers.  The MIS, Systems, and Marketing eduction all help too.

Communication is paramount to the role of a BA.  From your post, you seem to have that.

May I ask why YOU believe that your current manager took a disliking towards you.  Look inside yourself and try to find a really honest answer.  It may help this community better answer your questions.

You are in a BA role now, so I would suggest acquiring the skills in your current position that you will need to get your next BA role .  If I had to list the top skills required of a BA (in the systems space since that seems to fit your background) it would be:

• Communication Skills (Written and Oral) - conveying complex ideas in a well structured email or document is something most people struggle with.
  
• Requirements Elicitation and Writing - Writing clear, unambiguous requirements takes real work.  Everybody thinks their requirements are clear until someone else reads them.  ALL requirements should be able to be traced back to high level business goals, though this almost never seems to happen. 
  
• Process Flow Documentation - This is important for both current and target state environments.  UML Activity diagrams work and are probably the most known and accepted standard.  You should learn it if you don't know it, but I prefer the sophistication of BPMN.  Also a highly respected standard
  
• Business Entity Diagrams/Entity Relationship Diagrams - Here i'm referring to logical information design NOT physical data design.  UML Class diagrams can be used to create these logical models. Understanding the static structure of a system is so important for understanding a solution and catching problems early.
  

A close second to these might be:

• UML Sequence Diagrams - Specifically for cases where lots of systems or services talk to each other.
  
• Context Diagram/Data Flow Diagrams (from Structure Systems Analysis and Design - search Ed Yourdon)
  

Find ways to start using just one of these skills or techniques in your current job. Don't try to master them all at once.  Document (literally write down) your lessons learned after using it.  Come back an ask questions :-)

Raj,

Tools (Software) can be helpful, but to really learn these things I recommend Visio, books or training, and on-the-job application of the skills.

UML Activity Diagrams, Class Diagrams, and Sequence Diagrams I recommend starting with an overview book like: UML Distilled by Martin Fowler

Another well written book after you have some of the basic down is UML 2 Toolkit

When it comes to BPMN there aren't too many good resources out there yet, but I picked up the following book and really like it so far. It starts simple and builds on itself with good examples. BPMN 2.0 by Thomas Allweyer

Requirements Elicitation and Writing is a little trickier.  There are tons of  books out there that will tell you the basic tips of what to do and what not to do.  Traceability is very important.  However, requirements should be based on the Business Entity Model you develop so that everybody is speaking the same vocabulary.  These are also called Fact Models.  Do some research online to start and understand this concept a bit. Then we can have all sorts of fun discussions on good requirements.