User-Generated Requirements - Part I
A few weeks ago, I was talking to a friend of mine who is employed with one of the leading web portals in the world. Besides discussing other things, our chat ventured into the realm of customers, how to work with them better and what has changed in requirement extraction in the recent days, etc. One thing lead to another and not long into the conversation, my friend threw in an interesting statement – “Its relatively easier for us, we have got just one customer – our own company”. There was something odd about this statement that was making it hard to digest but I could not pin point it for a few minutes. When my thoughts caught up with me, I replied –“Hmmm, instead of just one customer, shouldn’t the whole world be the customer for you? After all, your apps are used by the whole world and I am sure a lot of people out there have ideas of about how to make them better. How can a bunch of business analyst think on behalf of the whole world and draw requirements for you?”
“Interesting, I didn’t look at it that way”, said my friend. “But let’s say for a second that I agree with you. How do you propose we go about collecting requirements from the whole wide world?” At this point, the consultant with in me rose to the occasion and said, “Blogs! You can collect your requirements from Blogs!” The conversation did not go much beyond “Yeah, right!” But later that week I gave it some more thought. Why can’t it be done, what could be the concerns, is it really that farfetched an idea? I am sure it has been done already by someone, somewhere.
In this post, I have tried to outline an approach on how to use discussion forums and blogs in a disciplined manner to extract user requirements. It will also throw some light on some projects that have already used this concept successfully. We will try to crystal gaze and see what common problems could surface when you try to knit blogging web into the Software Development Life Cycle (SDLC) cycle.We will also extend the discussion to plant some thought about knowing our customer’s customers. We will look at how to help our customers reap the thoughts and ideas of their customers in order to build best of breed applications.
About Requirements
Some people hate them, some are obsessed by them and some abuse them, but none of us can ignore them. Requirements and scope are by far the most talked about subjects of the SDLC. Traditionally, requirements used to be extracted during the begining of the project, finalized and then brought to life through the remainder of the development cycle. A few decades ago, the realm of requirements changed first with the advent of iterative development and then with agile methodology. Iterative development gave the business a chance to build requirements in steps to have a better control on the end solution. With Agile methodology, the business analysts became part of the development team, validating and rehashing requirements for high risk project to keep bring some certainty into what they were going to get.
With Web 2.0’s advent, the stage is set to change yet again. Commercial portals these days are more aware of the need to meet the customer’s expectation and more importantly evolve with them. In this new world, it is quite hard to imagine having the same business analysts of 2003 era churning up requirements to stay competitive. Even with the best of the class business analysts, there are no guarantees that your number one portal will continue to remain number one. With traditional business analysts, the trend gradually leads to aping other portals rather than evolving with customers. The businesses can either start employing some psychics to read the customer’s mind and help them retain the number one slot or start asking the customers what they want. For my money, I will wager my bet on the latter.
Requirements & SDLC
Let’s us refresh our concept of SDLC as it applies to a dotcom, before we move further. Irrespective of what methodology is applied in a project, it will go through at least four main phases.
This contextualized depiction of SDLC phases adds another phase – support for dotcom portals. The inception phase is primarily anchored by the business sponsors to make a case for what is needed and why. Traditionally, requirements are extracted in the elaboration phase, before the construction begins. The other phases are used for implementing the requirements as intended, validating it and then supporting your customers in using what you developed.
For a dotcom portal, the case is little different. Most of these portals are not built to solve a business problem. In this world, the more appropriate SDLC would be:
For this life cycle, I have separated the requirement gathering into three phases to communicate the idea. They could also be clubbed as three different activities in one phase. In addition, I have added another phase called “monitoring” which will run in parallel with the support phase to ensure that the delivered functionality is actually being used. The three new requirement activities are:
- Float an Idea
- Facilitate Discussion
- Collect & Rationalize Feedback
These phases are the ones where a collaboration utility like blogs or discussion forums could be employed really effectively. In the new world, when a dotcom portal is launched, it will also have a blogging facility for all its users. They can start a new thread here, post comments to existing posts, etc. And here is the twist, along with all your end users, these blogs will also be used by your business analysts. The new age business analysts will be responsible for floating new ideas, collecting user comments, rationalizing the collected data, take the most sought after features to the drawing board. These blogs will also act as the launching pad for releasing new features and soliciting feedback.
In the next few parts of this post, we will take a look at how blogs can be effectively employed to collect requirements.
Comments
It is really good to collect ideas using blogs. I have gone through the parts I,II and III and found very useful for giving a complete thought to RA done by BA/RA group and points observed from the blog.
Blog feedback can work as a trigger on the following :-
1. Public interest and changes, which may help us in check risk in maintenance.
2. Extension to requirement analysis done, may be few good points come out from opinion and that will help us to make RA almost complete.
3. Beware - Blog opinions should not be the base for designing or implementation. They are the input or trigger points. Decision should be taken with respect to vision of the product.
4. Blog feedback can help us in identifying the ease of acceptability. In this case educating the people ( a different concept ), Advertisement planning, etc can also be planned in advance.
It is always a better idea to think of more options but choosing the best feasible and suitable solution should remain with BA group.
Posted by: Vinod Vaya | October 30, 2008 05:32 AM
Thanks for the encouraging words, Vinod. I concur with all of your points. In fact, the BA will always have the final word on what goes in a release. He can employ blogs as one of the means of soliciting opinion for some of the issues which are non-obvious.
Thanks for taking time out for reading the post,
Amit Jnagal
Posted by: Amit Jnagal | November 3, 2008 05:58 AM