On Jacques, Julia, And How To Whip Up Really “Good” Software Requirements
I love to cook, although I didn't grow up that way; most in my family consider cooking a chore. But somehow I ended up "different." I discovered that cooking can be fun, and I love the fact that it’s both scientific and creative. To make a good dish, you have to embrace both the science of cooking and the tastes of those that will consume and enjoy your dishes. And when my stepdaughter says “Mary, this is good” after a bite of something I’ve cooked, I’m happy.
Unfortunately, what’s “good” for one may not be “good” for another. My husband doesn’t eat anything green except peas and my family’s green dessert, while I love a great salad. One stepdaughter likes avocados but not guacamole; the other likes guacamole but won’t eat whole avocado chunks. (Can someone explain that to me?) Even Jacques Pépin and Julia Child argued about what was "good." I watched a rerun of their show "Julia and Jacques Cooking at Home” in which Julia questioned the doneness of Jacques’ sautéed spinach. “It’s not very tender. It has a slight bitterness to it," she said. In response Jacques took a bite, smiled, and said “I think it’s very tender.” Julia smiled in return and told Jacques: “maybe you have sharper teeth than I do.” They make me smile.
Like chefs, business analysts use both logic and creativity as they work to elicit, analyze, and document software requirements. And I'm often asked how someone knows when requirements are “good.” What do “good” software requirements look like? Food for thought:
· A high quality individual requirement possesses certain attributes. Through my research, I’ve compiled a long list. A “good” requirement is unambiguous, complete, correct, and current. It’s also consistent when partnered with other individual requirements. It’s observable and testable, so you know when you’ve met it. It’s feasible – which is an interesting characteristic because a business analyst must possess a certain level of skill and knowledge to assess this. And it’s mandatory and prioritized, so you know that you’re delivering the most business value.
· Requirements at the product level must also be “good.” When all those high quality individual requirements are packaged together, is the picture you’ve painted complete and through? Did you elicit and analyze and elicit again to drive out all the requirements? Are the requirements artifacts clear, understandable, and easily usable by the intended audiences – stakeholders, developers, and testers? Many don’t consider that these audiences have different informational needs. A business stakeholder may prefer reading a Word document. Your developers may want a combination of documentation and models. And your test lead might prefer the requirements in a database or Excel spreadsheet. Tailoring the artifacts to their consumers increases their quality and usability.
· But the best measure of good software requirements is a positive end result. If you’ve met the business goals, delivered business value, and left happy stakeholders and customers, the requirements have done their job well. And while we often strive to measure the performance of business analysts based on the requirements artifacts they create, good requirements are useless if the delivered product is poorly designed and full of bugs. As Julia would say: “the proof is in the pudding.”
So what do you think makes software requirements “good?” And what skills does a business analyst need to deliver them? I’d love to hear your feedback. Bon appétit and happy cooking!