Requirements elicitation skills are something I most enjoy learning from my colleagues at ArgonDigital. There is a certain appeal in being able to enter a room, effectively ask all the right questions, and get all the right answers quickly and easily. And I can almost hear the business analysts and product managers reading this chortling right now, because it hardly ever works out that way. More often than not when a business analyst or product manager enters a room, eliciting business requirements from the subject matter experts or stakeholders will meet with some friction.
So how do we overcome friction in eliciting business requirements, and get the actual information needed?
There is one way that works out perfectly on a psychological level, as well as an analytical one: get things wrong.
It seems crazy, right? However, if you can get over the discomfort of being purposefully wrong, this is a great tool for software requirements definition and business requirements. In my opinion, the effectiveness of this approach revolves around human nature:
1) People love to be right.
2) People love to help.
3) People can more easily spot things that are wrong than spot things that are correct.
One way to facilitate this style of requirements gathering is with what we call straw-man models. Similar to a straw-man in a corn field, this is a model that you create that looks right, but isn’t, and is therefore easy to knock aside.
Whether it’s deliberately dropping a major step in a process flow, or putting in the specific name of a CRM system in a System Context Diagram despite not knowing whether it’s the actual system in use, subject matter experts and stakeholders will find straw-man issues like these quickly. They can immediately point out the issues and say, “No, that’s not right;” and that’s when you get to ask a very useful question in the elicitation toolbox: “Well, tell me, how should it go?”
When you present something to be fixed, something that is wrong that you know the other person knows about, it can help foster a collaborative environment; with a careful use of the straw-man approach, you can very quickly turn an elicitation desert into a requirements oasis.
A caveat: use the straw-man software requirements elicitation method wisely. You may not want to open a meeting with “we’re wrong,” because that can undo some of the confidence the subject matter experts or stakeholders have in your understanding their business objectives and needs.
