I am writing this post to discuss some tips and tools which a Business Analyst can use during the course of a project life. From my experience, I find these tools very useful for comprehensive and correct coverage of a business requirement. Which tool or methodology to use for effective business analysis depends on many factors like:
- Type and size of project
- Organization and business for which the project will be done
- Software methodology like agile, waterfall or hybrid
The roles and responsibilities of a business analyst has expanded in all the project phases; staring from requirement engineering till the system starts doing business, a BA is the single thread to bind all the stakeholders.
Requirements Investigation
- Brainstorming sessions
- Focus groups: All participants perform the same role
- Cross-functional groups: All business functions involved in an end-to-end process One-on-one interviews
- Research of existing artifacts
- Prototyping
- Wiki (A tool that can be used to allow stakeholders and team members to collaboratively contribute to the requirements)
- Surveys and understanding of business domain
Business Process Diagram
A diagram that models the work flow of a business process. It is very useful to understand the get the domain understanding of the business and at the same time get the agreement from business users on the proposed solution.
Business Use Case
A business use case is an interaction with a business that provides value to an actor (an entity outside the business). Business use-case analysis involves a number of components: Business use cases to model business services and processes; business use- case diagrams to indicate the participants in each process; business use-case descriptions to describe the interaction between actors and the business area; and business use-case realizations, representing the internal business process used to implement the functionality. Business use-case descriptions (specifications) are usually documented as a text narrative; the text should be augmented with an activity diagram if the flows connect in complex ways. Business use-case realizations are usually expressed as activity diagrams, with one partition for each participant. Business use-case diagrams should be used in early meetings with stakeholders and in documentation to communicate high-level business issues: the business processes impacted by the project and the participants involved with each process. A BA should use business use-case descriptions to describe business functionality and business use-case realizations to describe the internal work flow for each impacted process.
Requirements Attribute Table
It is a table used to document properties of requirements, such as authorship, priority, and so on. It provides information such as priority and stability for making decisions concerning requirements, such as when to schedule implementation. It is a central place to look up data about a requirement, such as its author, current version number, etc.
Requirements Traceability Matrix
A table used to trace each requirement backwards to the business processes and objectives it supports and forwards to the subsequent artifacts, events, and changed configuration items that result from it like use cases, functional specifications and test scenarios. A BA should map requirements to other artifacts and configuration items so that the upstream and downstream impact can be determined.
System Use Case and Diagrams
A way that the software will be used by an actor. (An actor is an external entity that uses the IT system under discussion.). It also defines a user task: The task must be complete from the user's point of view and yield a result of value to the user. (The term user, in this context, refers to any entity that uses the system and may be human or an external IT system; it is equivalent to the term actor.)
A use case may be of any size but typically represents a unit of work accomplished in one IT session by a single initiating (primary) actor. It consists of sequences of interactions between an initiating (primary) actor and an IT system, covering normal and alternative pathways for carrying out the task. It may also contain interactions that the IT system initiates with other (secondary) actors. A related term, scenario, refers to a specific sequence of actions that illustrates behaviors. A scenario may be used to illustrate one way the actor-system interaction may play out over the course of a system use case.
Managing Risk
At the beginning of the project, and periodically as the project progresses, the BA should support the PM in analyzing risk. A BA should characterize and evaluate each risk's impact, likelihood, level, type, and risk-management strategy. Each risk should have an associated plan for managing it. Your plan should consider the following strategies:
- Avoid: Prevent the risk from happening. Possible avoidance plans include changing the scope and re- planning the project.
- Transfer: Transfer the responsibility for dealing with the risk to another entity.
- Accept: Accept the risk and highlight it immediately to the apposite stakeholders.
- Mitigate: Take action to reduce the impact. Mitigation plans may be proactive or retroactive--such a contingency plan ("Plan B").
Three vital tools of a Business Analyst: Eyes, Ears and Thinking
No process or tool in the world can help in absence of a thinking head. A BA should have the strong tendency to read, understand and think intensely. Today a BA is expected to understand the real business problem and then provide all possible solutions. A BA should think and find out all the hidden and covered business problems and should focus on re usability of existing requirements and solutions.
There are three broad sets of skills and knowledge needed for business analysis:
- Technical skills of the profession
- Business knowledge
- and a range of personal and interpersonal skills.
A BA should have the capability of listening to multiple voices, viewpoints and perspectives, analyzing multiple situations, reflecting on all those voices, synthesizing them and pulling it all together into a proposed way (or ways) forward that meets both strategic needs and the needs of those on the ground.
There are times in project when the misunderstanding emerges out between:
- Development and QA team during system testing
- Development/ QA and UAT team during User Acceptance Testing
- Business Users and Project Managers during the actual imolementation
The above conflicts are the true testing waters for a BA, and using some vital tools and check points is a proven way (based on my own experience) to close down all the understanding, scope and delivery gaps. I think that is the reason a BA is called a bridge or conduit.
Thanks
Himanshu Sanguri