Oct 17, 2009 / Labels: Business Analysis, Malcolm Gladwell, Outliers
Why I Like Being a Business Analyst?
Those three things--autonomy, complexity, and a connection between effort and reward--are, most people agree, the three qualities that work has to have if it is to be satisfying.
Isn't this true? No matter how well you are paid you can never continue and be
satisfied with a job which is monotonous, non challenging under an autocratic(let’s say non-democratic) management. This I like best about Business Analysis and being a Business Analyst.
Sep 27, 2009 / Labels: Business Analysis, COTS, Requirement Gathering
Business Analysis in COTS Environment- Part 2

- The marketplace, not one system’s needs, drives COTS component development and evolution.
- COTS components and the marketplace undergo frequent, almost continuous change.
- Frequency and context of COTS component releases are determined at the discretion of the vendor.
- COTS components are built based on unique architectural assumptions and are not constructed using a universal or consistent architectural paradigm.
- There is at best limited visibility into COTS component internals and behavior.
- COTS component assumptions about end-user processes may not match those of a specific organization.
- "Vendor” is not a new name for subcontractor. Different relationships are required to have insight and to influence component changes.
- COTS components often have unsuspected dependencies on other COTS components.
- BA in a familiar COTS environment i.e. when you know the product.
- BA in unfamiliar COTS environement i.e. when you have no idea about the product's capabilities.
Sep 19, 2009 / Labels: Business Analysis, COTS, Requirement Gathering
Business Analysis in COTS Environment- Part 1
Jun 30, 2009 / Labels: Downloads, Use Case Template, Use Cases
Use Case Template
It's not too difficult to create a use case template as there are plenty available on the web and best practices to create an use case are well documented. Still I struggle to create one when it is needed. Utilizing the break between sprints in my current assignment, I have created a template which is consolidation of learning from various projects. The template is available in the downloads section or it can be downloaded by clicking here. Hope it would be useful.
Jun 10, 2009 / Labels: Implicit Requirements, Requirement Gathering
Gathering Implicit Requirements

May 31, 2009 / Labels: Business Analysis, Concise requirements
Concise Requirements and More
I have been following a very interesting discussion of LinkedIn on whether restricting Requirements to 140 Characters is a Good Idea? See this Link; you might have to join the IIBA group to follow this discussion. The discussion was started by Adam Feldman and what seems to be inspired by Twitter rapidly got attention of many Business Analyst professionals. It is interesting to see how the opinions changed (mine changed at least). If we don't see requirements in terms of models for capturing them like Use Cases and User Stories we can actually put together very good and concise requirement in less than 140 characters. From my experience I have learned that we often tend to get verbose while documenting requirement which often leaves a lot of room for manipulations and interpretations. The Idea should be to keep them as simple and as concise as possible… why? Well because like any other thing in this world the best requirements are on which are simple and easy to understand and a good Business Analyst should always try to make requirements simplest not simpler(Isn't this what Einstein said!!).So if the use case is getting to lengthy with many alternated paths and extension, try to break it into simple ones. If the user story is taking more than few lines to write it has should be broken down into multiple stories. I came across a very interesting article by Jeff Martin on defining the Business Analyst role, in his article he points out how to handle "So, What do you?" situations. It has happened many times when people ask me "So, What do you do?" and still being proud and confident about my profile I never had a perfect answer. Quoting Martin this is how the response should be: And this is what we exactly do, by bridging the gap between business and technology!
Apr 26, 2009 / Labels: Business Analysis
Business Analysis: It is more than Requirment Gathering
- Understanding of the how technology behaves will help in connecting closely with architects, designer and developers.
- You will be able to participate better in design and architecture brainstorming and interfacing with quality folks.
- This will be help in understanding the system as it is developed and you will be confident while providing demos, walkthroughs and during UAT.
- While the high level business requirements will broadly remain unchanged but when the requirements are broken into functionalities they are impacted by limitation of the technology, understanding how technology serves requirements and what additional it can provide helps the Business Analyst during negotiation on what can be done with business stake holders.
Mar 25, 2009 / Labels: Use Cases, User Stories
Use Cases and User Stories- When to use what?
I currently working in a very complex SCRUM project, a huge business problem is divided among multiple teams and with Scrum masters and Business Analyst involved at various levels. In such complex environment Practicing Agile is tough but one that comes really handy is writing both use cases and User stories.
- [Description of Use Case] ->From User Story
- [Actors] - >form User Story
- [Pre Condition] - >Not Covered in User Story
- [Post Condition]-> Not Covered in User Story
- [Basic and Alternate Flow] -> Not Covered in User Story
- [Assumptions] ->Not Covered in User Story
- [Exception]->Not Covered in User Story
- [Implementation Notes]-> try writing this section where the discussion from Architect and dependencies from other teams /system can be noted down
Jan 22, 2009 / Labels: Agile, Business Analysis, Scrum
Business Analysis 'Scrumed'
While the debate continuous about the role Business Analyst plays in an agile environment -it is interesting to note the Paradigm shift that it brings in the mindset of the team members and the way their role changes.
Dec 6, 2008 / Labels: Business Analysis, requirements
Has Requirement gathering actually evolved?
Technologies have evolved, Softwares have become smarter, the development time is now minimal for IT applications. But the Software Development Life cycle has still not Shortened. The amount of time consumed in requirements has increased over the period from 24% to 45%.
Oct 15, 2008 / Labels: Business Analysis, Use Cases
What to do after Business Use Cases are written?
You have documented understood the Business Process and Documented the Business Use Cases. How to transition from here to System Use Cases?
The BA Mantra:-
Imagine the System
Simple and Obvious, but take my words this will sail you through :)
Sep 20, 2008 / Labels: Business Analysis, Storyboards
Business Analysis: Creating Storyboards and Prototypes
John: "Ranjan, do you know how to play chess?"
Ranjan: "Yes, a bit"
John: " You must plan your future moves.See things ahead. And that's the way systems should we made, today its E2(End-to-end) tomorrow it can be E3,E4 .. You must plan for E7. You have your limitations but keep one thing in mind: Make your systems Horizontally consistent. Symmetrical and modular. What I am trying to verbalize is that call each section as a 'thing' and that 'thing' should have similar properties. Later replace 'thing' by real names: Issues, meetings, Lists, product etc... follow this in UI also."
John is an architect and has extensive exp. of more than 150 systems for wall street companies. We are working together on my current assignments for one of the largest pharma companies. Here I have tried to capture my learning while prototyping the application in this presentation:


