A BA's understanding of how business stakeholders do their work is very critical to gathering the right requirements to meet their business goals. A BA, like a detective, investigates until he or she has uncovered the details about how the business operates: the good, the bad and the ugly. It's true we need to understand the business vision and high-level business goals but the BA also needs to elicit a detailed understanding of the business processes. If not, this leads to missed requirements, rework, increased costs, and unsatisfied stakeholders. Some BAs may have experience in the business area under analysis while others do not. Whether you start with lots of insights or are completely new to the industry, there are a variety of ways to gain this understanding. Depending on the situation some apply better than others:
- Existing documentation (document analysis)
- Job shadowing/observation
- Facilitated requirements work sessions
- Interviews
- User task analysis or process walkthroughs
- Surveys
- Conference calls using collaboration tools
- Prototypes
- Focus groups
These along with some others are mentioned in the IIBA BABOKTM. The better understanding a BA has about the essential business operations, the more effective he/she can be in assisting the business to create more cost-effective, time-saving, and powerful solutions. Write and tell us about which techniques work best for you and why.
September 4th, 2007 at 11:13 am
Angie, most often the mixture of prototyping and interviews is the way to go for me. I like to include the business representatives early in imagining the final product. Usually I'm trying to avoid the very rough theory and create some tangible solutions on which we can work on later on. Using prototypes you can easily verify whether you have the commons understanding with your business customer.
September 6th, 2007 at 2:51 am
Good old fashioned research is another path. For example research into best practices via google, industry hubs, research firms etc. I've just done this as a first step into researching the functions and design of a new website.
September 8th, 2007 at 2:52 am
Instead of talking about the entire process of Eliciting Requirements I will comment on some of the pitfalls.
I think the biggest mistake that most companies/analysts make is not creating Business Process Flows and Business Use Cases of the current state of the business process. This unifies the understanding of the business process among all of the Subject Matter Experts/Business Users. As I’m sure we have all experienced even the so called SMEs have different explanations and views of the current business process.
Then, from the current business process flows and business use cases we can begin to document the functional and non-functional requirements of a system that facilitates and optimizes the business process. How do we do this? Not by jumping into screen design.
Before creating screen mockups, take the time to document functional requirements and system use cases. This gives everyone an unbiased view and opinion of what the system needs to achieve. Most analysts start creating the screen mockups too soon and then create system use cases. This typically results in screen designs that don’t support the system requirements as elegantly as they could. System Use Cases are written mentioning dropdowns, buttons, and links. Even worse, they mention specific screens instead of allowing a function to be fulfilled across as many or as few screens as makes sense based on the purely logical requirement.
-Chris
ModernAnalyst.com, Core Member
September 12th, 2007 at 8:12 am
Well, I can say I'm lucky. Since my company works on the IT field, it's often easy to jump right to the entity classes with the user and later think about the use cases that affect them. Of course we first map the current process and then work on the new concept. - Kerber ITBA - Digitro Technology www.digitro.com
September 14th, 2007 at 9:07 pm
Thanks for your contributions - These are great. Keep ‘em coming. I hope we get some more folks to comment.
September 14th, 2007 at 9:09 pm
Oh by the way, Chris - may I say "Amen" to your comments about documenting system use cases before moving on to the mock-ups!!!
October 28th, 2007 at 3:27 pm
I find it very helpful to interview the stakeholders one on one before any group settings such as requirement workshops, RAD sessions etc. Materials can then be prepared that address issues already known to be of importance to the group. Conflicts can be identified early and planned for. The group settings can then be orchestrated to keep everyone focused and to minimize rabbit trails. A good BA always maintains control of the analysis process.
October 30th, 2007 at 9:09 pm
Excellent advice, James, to better prepare for any requirements workshop!