You are a tool minded business analyst, if the first question that comes to your
mind on hearing the words: “Use Cases, UML or User Acceptance Testing” is: “what tool
should I use to create my Use Case / UML / User Acceptance requirements document
Tool minded business analysts are more interested in learning the intricacies, features
or behavior of the software tools used in their requirements elicitation, analysis or documentation tasks than in correctly analyzing, validating or defining business requirements.
Hazel, a business analyst posted some excellent advice on what it means to be a business analyst and I wanted to shared her advice with you in this post
Hazel’s advice covers specializing as an IT Business Analyst vs. Non IT Business Analyst (Capital markets, Broadcasting, Mortgage, Marketing, etc.). It includes tips on how to develop professional presentation skills and it also goes to the heart of the matter in describing “what or who is a business analyst”!
Read Hazel’s advice below. It is succinct, relevant and powerful … here is the rest of it:
A use case is a description of how a system’s behavior in response to a request from a stakeholder known as an actor. The actor could be a person or an external system that interacts with the system being described.
The actor initiates an action with the system with the purpose of accomplishing a goal. The system responds to the actor’s action in a way that fulfills the interests of all of its stakeholders. A use case summarizes a complete series of related scenarios that may unfold.