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:

If you are practicing activities that fall within the BABOK, then what you do is very simple and only takes three words! You "HELP COMPANIES CHANGE."

And this is what we exactly do, by bridging the gap between business and technology!