I do not mean to be sarcastic, but this exactly what I heard from a seasoned business analyst when I asked the question “do you provide scenarios with your requirement?” in one of my courses on Scenario-Based Development and Testing. Before I go on and get you too excited let me define what a scenario is from a requirement perspective. Simply stated, a scenario is any situation that could possible happens when the system is operational and a function is being performed. If you try to use your favorite online bookstore to order some books, some possible scenarios are:

• You order a books that is available in stock
• You order a book that is not available in stock
• You order two books one of them is available in stock and the other is not
• You order a book and pay by a valid credit card
• You order a book and pay by an invalid credit card
• You order a book but the system that charges your credit card is down
• You order a book and ship it to an address that is the same as the billing address
• You order a book and request it to be shipped to an address that different from the billing address

Can you imagine how many other possible scenarios are there? Let me for now just pose a number of questions and get your input. I will certainly react to your input and will provide complete answers and even more details on how we can become better requirement writers. Here is some food for thought:

1. Who is supposed to think about these scenarios?
2. At what point in the software lifecycle should we think about these scenarios?
3. Are there techniques and methods to derive those scenarios and what are they?
4. What do we do with these scenarios any way?

Hint: You can learn more about scenario-based development and testing from some of the free webinars posted at http://www.rommanasoftware.com/prerecordedwebinars.php.

You may even have a first hand experience with building scenarios by downloading a free trial of Rommana, a tool that supports a scenario-based requirement process, at http://www.rommanasoftware.com.