Techniques for Gathering Requirements

Posted by Mike Ramm on January 29, 2008

I found recently an article called 10 techniques for gathering requirements. While Tom Mochal is a very competent expert and I admire his opinion a lot, some of the techniques he describes look too trivial - one-on-one interview, group interview, facilitated session - they are pretty much obvious.

More interesting to me were some techniques which I find very efficient but seemingly more rarely used. So I decided to take a closer look on them and to analyze them in more details.

Following people around (Observation). It happens very often a customer to come to us with their vision about how the new product should look like and what it should do without being able to explain what exactly is the business process running in their company or how it is going to change with the deployment of the new software solution. One of the most effective approaches to study the customer’s business process and the habits and the technical skills of the future end users is just to stay there and observe their daily activities. Observation gives us the ability to see some flaws in their work, some too complex or unnecessary activities that could be eliminated or to get some ideas to improve the process and thus to increase the customer’s profit from implementing the new software solution. It is much better if our business analysts have the ability to the actual work the users do to get a hands-on feel for the real situation.
Unfortunately, we are often pressed by tight deadlines especially in the analysis phase (which is a big mistake!) and we rarely use this technique for gathering information.
Sometimes, the customer doesn’t allow us to meet their employees using security arguments. In those cases we should strongly emphasize that this is a risk for the right understanding of the requirements and for the successful release of the project.

The role of the Business Analyst - poll results

Posted by Mike Ramm on September 11, 2007

I wrote a post in Bulgarian about the role of the business analyst in a software development team and I put a poll to survey how the people in the software development business in Bulgaria evaluate it. Now the poll is closed and I am giving you the results.

Question: How do you evaluate the role of the business analyst in your team?
Total votes: 27 (little but I still have few readers).

Answers:

Very important role. The BA investigates the customer’s needs and represent them before the team - 14 votes (52%)
All roles are equal. The BA is responsible for the functional (requirements) specification, which the developers implement - 6 votes (22%)
We don’t need such a person. The developers do the client’s business analysis themselves - 4 votes (15%)
What is a “business analyst”? - 3 votes (11%)
He just hangs around here and looks silly. He cannot write a simple JavaScript - 0 votes (0%)

How to interpret the results? Obviously, the first thing that has to be noted is the small number of the votes. For me, the main reason is the fact that still very few people visit my blog and most of them weren’t impressed by the poll. I think I will open it again in the future when there will be more visitors to my blog.

Anyway, the good news is that despite the few voters, the results show that the position of the business analyst exists in the software teams nowadays and it is appreciated positively. No matter if considered as very important (answer #1) or considered equal to all the others (answer #2), the business analyst takes his/her well-deserved place in the software team (totally 20 votes for both answers, which gives around 74%)

Answer #5 is rude and represents the vulgar and arrogant attitude of some developers to the surrounding world that doesn’t write code. I am glad that nobody voted for it. It probably means that this attitude was already buried in the past.

Answer #4 is a little silly. How can you be a self-respecting developer and not know what a business analyst is? I put this answer on purpose with the intention to be chosen for fun and to make the poll more colorful. I believe that this was the intention of the three guys who voted for it. And if they really don’t know what this is - keep on reading here - there will be more posts devoted to the job of the BA.

The most interesting answer for me is answer #3. It has a double meaning. There are companies, on one hand, that work on small projects or such that work on products and don’t use project principles at all. In such companies, every developer, having been working long time on the same product and having been communicating with the field experts from the business area being automated, gradually begins to gain exactly that knowledge and experience, which make him or her a business analyst. And if you add the aspiration of the company for more exploitation of its employees we come to a natural merging of the role of the BA with the role of the software developer in one person.

However, there is another interpretation. The team (or the company) could consist only of “great programmers” - people who think they know, understand, and can do everything. It was the ideal of the past socialist society in Bulgaria - so called “multi-dimensionally developed persons” - people who believe that a developer should be skilled in every aspect of the software business and there is no need of a narrow specialization in particular areas like business analysis, project management, testing, user education, etc. The developer can do everything!

I really would like to know what were the reasons to vote for this answer. I hope some of the voters will post a comment about it. And if you have an opinion about the role of the business analyst in your team - please, share it with me. It will be useful.

Tags: business analyst, poll, role
Filed Under Business Analysis, Polls, Software Development, Teamwork | 2 Comments