The Problem With Requirements
Requirements documents are halfway between a peace treaty and a Christmas list.
I have an email from Glenn. He needs to get a piece of software built and wants to know if I can make it for him. At the end of his email, he says, “I’ve gathered all the requirements,” and offers to send them over.
He says it so confidently: “I’ve gathered all the requirements,” as if they were strewn across the ground and he just picked them up. The phrase sticks with me because I have no idea what to expect. Will it be a Word document, an Excel sheet, a PowerPoint, a mind-map, a set of Jira tickets, or Trello cards? Maybe “all the requirements” will be high-level business priorities (“The system will allow us to take payments”) or maybe they will be low-level descriptions of how to integrate with specific payment APIs. They might cover non-functional requirements (“it will be secure”). Will there be user stories? Wireframes? Designs? Or will he just say “design is required.” All of the requirements is such a bold claim. No edge case left unturned, no feature left behind. I can’t tell if Glenn’s confidence is that of someone who knows more than me or less.
People talk so confidently about requirements that for a long time I thought there was a concrete definition that had been kept secret from me. Perhaps a…
