Every-so-often the internet has fun twisting and obsessing on something stupid. A recent case is if Pop-tarts are ravioli (a filling inside an enclosed dough). A year or so ago it was if tacos were sandwiches; a sandwich being defined as filling between two pieces of bread: Merriam-Webster Dictionary.
Make no mistake, this argument is stupid, silly fun. Beyond the surface, this type of argument is an interesting look into project communication. If you look at the crux of the two arguments, you see that the point is whether or not an absurd example fits within a definition that is either too vague, incomplete, or just wrong. This happens all of the time with product requirements especially in software.
Requirements from a customer will be given to the team either as direct requirement statements or indirectly user stories (or similar). These user stories often come in the form of how the customer would like the product to interact with the user; the team then derives requirements from that. For example, the user story, “The user picks up their sandwich with their hands and takes a bit out of all layers contained within the bread.” A team can derive the requirements of some form of bread, items inside the sandwich as layers, and not needing utensils. No matter the source, a requirement (like a sandwich definition) can be vague, incomplete, or wrong.
A vague requirement for the above example may look like, “The sandwich should be capable of laying flat without the content spilling out.” What is ‘flat’ the content or the surface the sandwich sits on? If any content spill out does the entire object no longer exist as a sandwich? Vague requirements can be interpreted multiple ways beyond what the customer intended. A better requirement would nail down the meaning so it can only be interpreted one way. Vague requirements can be cleared up with better, narrower wording. Additionally, to combat ambiguity good requirements use strong auxiliary verbs like ‘shall’, ‘must’, or ‘will’ instead of more opinion-based verbs like, ‘may’, ‘should’, or ‘could’. Rewriting this requirement, we can have something like, “The sandwich shall not crumble, lose structural integrity, or otherwise fall apart when on a horizontally level surface without supporting structures.” Notice that bit at the end expressly prohibits other tools being used to prop the sandwich up. Your requirements may need to be expanded to prohibit workarounds or unwanted user behaviors.
Incomplete requirements are similar to vague ones, except they are missing information. Take the potential requirement of, “The sandwich shall be formed with bread capable of supporting any sandwich content.” What is bread? What is ‘sandwich content’? In this case maybe a second requirement that defines what is allowed as sandwich content or maybe make a distinction on the type of bread. Not applicable in our example, but if there were an industry standard for what bread can be used the requirement could refer to it. Rewriting the requirement, we can get to, “The sandwich shall be formed using two slices from a bread loaf or one large bun cut in half. These slices or bun halves must be thick enough to hold sandwich filling material, as outlined in requirement SWH-1234, without structural failure.”
Wrong requirements most often come from interpreting a customer’s user story. Either they were assumptions made, desires of the team that seeped in, or a misunderstanding, in the end the requirement is just wrong and should be corrected or removed. From the user story, “The user picks up their sandwich with their hands and takes a bit out of all layers contained within the bread” a wrong requirement may be, “The sandwich shall be structurally sound as to not spill the content during user biting.” The original user story mentions nothing about the cleanliness of a sandwich. It says nothing about items staying in place, except during the bit all layers (between the bread) must be present. It doesn’t even mention the sandwich being eaten, just bitten into. If your team feels this is a mistake, then the team needs to work with the customer on the user story to include more information or have extra user stories.
So, from the user story “The user picks up their sandwich with their hands and takes a bit out of all layers contained within the bread.” We have several requirements:
- "The sandwich shall not crumble, lose structural integrity, or otherwise fall apart when on a horizontally level surface without supporting structures."
- "The sandwich shall be formed using two slices from a bread loaf or one large bun cut in half. These slices or bun halves must be thick enough to hold sandwich filling material, as outlined in requirement SWH-1234, without structural failure."
- Whatever SWH-1234 requirement is outlining allowable sandwich material, as well as more requirements on biting, content being in layers, and so forth.
Something to keep in mind is that requirements are what the customer requests and once the product is finished that is what they should get. Notice I didn’t say, “what the customer wants.” The customer needs to convey their desires for the product, and the team is responsible for making the product to those specifications. There is a wonderful YouTube video about this topic:
The toy was likely made to the requirements given, but the requirements were either vague, incomplete, or not validated with the customer. Maybe no one looked at the entire scope and said, “You know, all blocks can fit in the square hole.”
Overall, a sandwich is a silly example, a taco is not a sandwich, and a Pop-tart is not ravioli, but please think about your project’s requirements and make sure they are clear, specific, and approved. For reference, here is NASA’s systems engineering requirements checklist: NASA System Engineering Requirements
(image by By Renee Comet (photographer) - https://commons.wikimedia.org/w/index.php?curid=2130014)