Sweet Meeting Smells:Three Things That SHOULD Be Said in a Software Requirements Meeting
This second installment of Meeting Smells is a catalog of sweet smells. These are some key phrases that are good to hear in a requirements meeting. If you have any meeting smells of your own to offer, fair or foul, I'd love to hear about them in the comments."I Want"
This is the essence of a requirement, but business folk often sugar coat this with phrases like "is it possible to..." or "can we..".
Many engineers give the smartass response, "Anything is possible. How much time and money do you have?" Don't say this. It's confrontational and makes you sound like a jerk.
Requirements are all about desire. Desire to make new things. Desire to make better things. Don't stifle that creative energy.
Let people ask for the sun and the moon: "I want a shopping experience that faster than our competitors' ", "We want to process all three million records before the next billing cycle", "I want a webserver on the moon".
"Requirement" is such a harsh term, we should call them Desire Meetings.
"Maybe"
I use this one all the time to de-rail attempts to architect the project in the requirements meetings. It's very easy to begin solving problems as soon as possible, and so requirements meetings very often turn into debates over implementation.
Whenever someone asks me a question like "Will we host this with our current billing provider", or "Can this go into a spreadsheet somewhere, right?", I simply answer, "maybe".
You have no idea what the best solution is going to be this early in the project. Discussing details at this point is almost irresponsible. A noncommittal answer reinforces the dynamic nature of things at this point. Bite your tongue and be vague.
"I Get The Idea"
You don't need every detail in requirements meeting. The goal is communication, not accounting. If you understand what the business owners are driving at, you're fine.
Nobody can predict the future, so pressing for details at this point breeds conflict. Besides, the answers you get will be invalid in a week, when everyone changes their mind. Try to understand the overall business goals. You'll find yourself anticipating the business's needs before they ask. It's like magic.
5 Comments
Leave a comment
I like this series. It never hurts programmers to be reminded how to operate human-human interfaces.
Anyhow, Henry Ford said "If I'd asked people what they wanted, they would have asked for a better horse."
I've been in a lot of requirements meetings where the client comes in and says "We want a better horse."
How do you handle that?
Matt, I actually just attended a conference where Tom Kelly gave a keynote on innovation on just this topic. His message that your customers won't ask for the next big thing, you need build it and bring it to them.
In the case of Henry Ford and the horse, this is certainly the case. If your client is in the innovation business ("I want to make a video search engine", "We want to build a search engine that beats Google and Yahoo!", I think your first question should be "why a horse?". Help them innovate.
However, if your client isn't into innovation, and just needs to solve a problem ( "We need a billing system that supports PayPal", "I want a blog for my sales force"), then trying to innovate might be a bad idea. In this case, the first question might be "What three things would make the horse better for you?", and go from there.
I also think that the word "No" is sometimes in order.
If the customer says "Can we build a webapp that reanimates dead corpses when you scream YYYYYY-M-C-A!!! at the screen while wearing an Indian headdress?" The correct answer would be "No", followed by a quick call to HR.
[picture of dancing corpses]
Thanks for telling everyone my idea dave
u7xmagjl2tg072jr