If you work in new product development or have participated in maintenance projects, then most likely you have used either the focus group or the brainstorming technique. The brainstorming technique is used to produce ideas and increase creativity. For example, after you’ve defined your problem and are looking for the different solution options, you gather a few folks from your project team (mostly the development team) and ask them about what they think a solution could be.
User stories are sentences created in the language of a software operator, commonly used in computer programming. These user stories are capable of capturing what the end user, or software operator, would like to achieve. Constructed in everyday or business language, user stories are basically a smart way of handling customer requirements, without the additional hassle of having to create elaborate formal documents and keeping up the maintenance needed to update them. The use of user stories, for example, is to be able to respond quickly and with much less overhead to real world, rapidly changing requirements.
Scenarios are defined as a development use for policy planning or organizational development and testing. Forms of planning and crafting scenarios can result in long term plans for organizations, and are flexible in nature. Most scenarios highlight large scale forces to push the future in different directions.
When senior managers of large corporations face a decisional dilemma, they know that their decisions could result in affecting thousands of lives. Simple executions are no longer simple when responsibility looms this big. Scenarios and the planning stages of a scenario help managers and executives to determine the right choice. This could range from the act of buying a competitor, replacing a main product ingredient with something else, and much more. Problems like these are commonly faced with long term results. In developing the right plan, scenarios come into play. Scenarios are also used for personal business use as well as for high level management and organization benefits.
Most of us, Business Analysts, are more familiar with gathering system requirements because they are more interesting to our organizations and customers than the user requirements. But user requirements are absolutely of equal importance if not more important that the system requirements. You may ask me why is that?
Now what are user requirements?
Have you ever been in an elicitation meeting and the users refers to some functionality in your product and you have absolutely no idea what they are talking about? Well, this has happened to me a few times. I was thrown in with the high level description of the product but had never seen the real product because the organization had only the "in-development" products. And, as a débutante in business analysis, I really didn't know what I was doing most of the time. But I have learned my lesson since then.
Part of my job as a Business Analyst, it is my responsibility to facilitate business process analysis meetings with a group of very knowledgeable folks. As I stood in front of my audience, I couldn't stop thinking: "What if I don't understand what is going on here? What if I can't comprehend the issues at hand? What if i steer this group to an outcome that is completely irrelevant to the issues at hand?" I was hired in the public health industry at the time and prior to that, I worked in the gaming industry, healthcare, computer software and hardware.