This is the second entry in a series on what constitutes good requirements, regardless of how they are written, stated, shown, or otherwise intended. In this entry, we cover two characteristics that go hand in hand and are generally the responsibility of the customer and user: correct and complete.
You probably haven’t tried my grandmother’s meatloaf, but trust me, it is fantastic. A few weeks ago we decided to make this legendary meal on our own. My wife sent me to the grocery store with a shopping list: carrots, onions, eggs, ground beef.
I picked up everything on the list, but when I returned home we discovered that we were missing one ingredient: bread. I verified that it wasn’t, in fact, written on the shopping list and returned to the store. The list did not meet a key characteristic; it was not complete.
Now that we had all of the ingredients, we set to cooking and then eating. But something just wasn’t right with the meatloaf. We called my grandmother and it turns out that she uses ground veal, not ground beef. The list did not meet another key characteristic; it was not correct.
Think about these characteristics as they relate to software development. In a waterfall approach, you have to be pretty darned good to get all of the requirements exactly right. In an Agile approach, you have to be pretty darned patient to let the iterative process take you down the right path. But no matter what approach you use, you need to be mindful of correctness and completeness. IEEE (in its own formal and, um, charming way) addresses these concerns in STD 830-1998. I’ll leave it to you to read up on their verbiage in section 4.3.
Complete requirements imply that we know the truth, the whole truth, and nothing but the truth. By the time we are done with the product, it includes everything the users need to complete their tasks and accomplish their goals. There are no TBDs – anywhere. Missing requirements are hard to find because they aren’t there. The best way to determine if the requirements are complete is through ongoing exploration of, mining for, and testing of the requirements and system as it progresses.
Questions to ask: What is missing? Have we talked to everyone? Do the requirements satisfy every business scenario and outcome that is in the scope? Are the requirements and components traceable up to some need or business purpose? If my users require a login ID and password, have we defined how they will reset and recover their passwords (you might be surprised how often this gets overlooked)? Are all 11 secret herbs and spices accounted for?
Correct requirements imply that the requirements we actually know about are the right ones, and accurately describe how the product functions so that users can complete their tasks and accomplish their goals. One of the best techniques for ensuring correct requirements is to ensure that the documentation and code is reviewed, validated, and tested on an ongoing basis by the subject matter experts themselves. Writing test cases in conjunction with requirements takes this a step further.
Questions to ask: Is this right? Is this calculation correct when I enter high, low, and out of range values? Does this field hold up in all situations? Is that Eastern Daylight Time or Eastern Standard Time? Did you say “patients” or “patience?”
Again, whether you are writing a comprehensive tome of requirements or you are having a conversation with your users about a prototype you just built, make sure you are getting on the same page with what is complete and correct. And if you are looking for a recipe for Sunday dinner, don’t ask me. Call my grandmother.
This is the perfect website for anybody who wishes to understand this topic. You know so much its almost tough to argue with you (not that I actually would want to…HaHa). You certainly put a brand new spin on a subject which has been written about for many years. Wonderful stuff, just great!