I received a message from Glenn, who is in need of a software solution and wants to know if I can assist him. He confidently states, “I’ve gathered all the requirements,” and offers to share them.

His certainty is striking: “I’ve gathered all the requirements,” as if he has simply picked them up from the ground. This assertion lingers in my mind, leaving me uncertain about what to expect. Will it be a Word document, an Excel file, a PowerPoint presentation, a mind map, or perhaps a collection of Jira tickets or Trello cards? “All the requirements” could range from broad business objectives (“The system will enable payment processing”) to detailed guidelines for integrating specific payment APIs. They might even include non-functional requirements (“it must be secure”). Will there be user stories? Wireframes? Designs? Or will he merely mention that “design is necessary”? The claim of having gathered <i>all</i> requirements is audacious, suggesting no edge case has been overlooked, no feature neglected. I’m left wondering if Glenn is more knowledgeable than I am or less.

People often speak about requirements with such assurance that I once thought there must be a well-defined, perhaps secret, standard that I was unaware of. I imagined a hidden code used by Business Analysts that clearly outlined the guidelines to follow. However, every time I embark on a new project with someone new, I encounter their unique approach to documenting requirements, and we navigate our way to a completed product. While I’ve come to accept this variability, it still seems odd that we feign a common understanding of “requirements” given the plethora of options available—scaled in T-Shirt sizes or Fibonacci sequences, prioritized as high, medium, low, or via MoSCoW (Must do, Should do, Could do, Won’t do). MoSCoW, in particular, confounds me. The distinction between “Must” and “Should” feels nuanced. “Could” tends to complicate matters. And don’t even get me started on “won’t.” “Won’t operate on Windows 95,” “Won’t be developed in FORTRAN,” “Won’t bring about the end of capitalism.” I’m often surprised this section isn’t more extensive.

Requirements serve different purposes throughout the software development lifecycle. In the initial phases, broad concepts are essential for understanding and clarifying what is being built. In later stages, precise instructions are necessary. Every team has its own preferences and styles. Some individuals only comprehend requirements in the format of “Given I am a user wanting an app, then I will write the requirements,” while others find this format distasteful. When it comes to requirements, opinions abound.

One of my friends is on a quest for a boyfriend, treating her search as if evaluating a significant commercial contract. She claims to have assessed every man aged 28 to 38 on Tinder. Her phone even reached the end of potential matches, she says, having swiped through everyone.

She maintains a requirements list as well. “At least 6 feet tall,” “no back hair,” “wealthy,” and so forth. These are distinctly functional requirements (“<b>Must</b> be tall,” “<b>Could</b> have a vacation property in the South of France,” “<b>Won’t</b> be excessively sweaty”).

Perhaps I’m seeing patterns where none exist, but it’s curious how closely this resembles Glenn’s list. However, this list hasn’t aided her search. She did encounter someone who met every criterion, but he turned out to be a disaster. She now believes her list needs to be expanded, having recently added “Not a jerk.” It seems wise to include some non-functional requirements as well.

Returning to Glenn, he sent his initial email to several people within the organization, casting a wide net to find someone who could assist. One recipient works in IT procurement, while another focuses on internal consulting. The two of them, along with myself, convene to discuss Glenn’s list. My colleagues represent opposing ends of the requirements spectrum: one aims to “clarify the requirements” to determine what needs to be procured, seeking more detail and specificity, while the other wishes to maintain a “higher-level” perspective, returning to the core issue.

“What’s the problem you’re trying to solve?” he inquires.

This reminds me of a requirements-gathering course that introduced the “Five Whys,” a technique crafted by Toyota to uncover the root cause of an issue. It’s just as it sounds: a structured inquiry where one asks “why” five times until a satisfactory answer is reached or frustration leads to project abandonment. During the course, we practiced this method, unearthing numerous root causes.

However, in the wrong hands, the root cause can devolve into “because my boss said so” or “because of the Big Bang.” It’s easy to adopt an overly fundamental approach to root causes.

As we discuss Glenn’s predicament, my colleague probes him about the advantages of the work he intends to accomplish.

“It will enhance the website’s usability,” Glenn asserts.

“That’s not a <i>benefit</i>,” the consultant replies.

“If it’s easier to use, people will be able to complete tasks more quickly?” he tries again.

“That’s still not a benefit.”

Poor Glenn makes another attempt: “If staff can work faster, they’ll have more time to increase productivity and save money.”

This is begrudgingly accepted as a benefit. I can’t help but notice that the requirement hasn’t changed, and I question what we’ve gained.

My other colleague requests additional details regarding the requirements. Glenn attempts to articulate what he wants, but is reprimanded for “solutionizing.”

“We want to remain solution agnostic at this stage,” she explains.

I empathize with Glenn. He’s engaging in a complex mental exercise, envisioning the desired outcome while avoiding specific implementations. I’m not convinced people can operate at this level of abstraction.

Consequently, Glenn has created a convoluted list—a mix of requirements and app concepts that often conflict with one another. His personal preferences have been elevated to “critical business requirements.” After years of navigating IT bureaucracy, he’s learned that labeling something as “business requirements” is the key to getting what he desires.

Some of these preferences are straightforward. He prefers radio buttons over dropdowns, hence he specifies “Must have radio buttons.” Others are less clear. While accepting payments is a business requirement, when Glenn describes his desired email content, we venture into the ambiguous territory of “business processes.”

What’s lacking is a proficient business analyst. Yet, even with one, achieving clarity is challenging. At times, business analysts must adopt the role of prosecution attorneys, rigorously questioning users about their requirements, striving for a <i>Columbo-</i>like moment that unravels the tangled web of preferences embedded in their “requirements.” It’s not that users are intentionally misleading; often, they’re simply confused or haven’t contemplated their business processes in a manner conducive to application development. And why should they?

As time progresses, individuals become entrenched in their views. Where do software solutions end, and where do business processes begin? It becomes a political battleground as people vie for control over the requirements list.

My friend has finally found someone—not through Tinder, but rather through a friend of a friend when she least expected it.

“How’s his back?” I inquire.

“Surprisingly hairy,” she responds.

Her list is now irrelevant. Not every requirement is truly a requirement.

While requirements are essential when creating a product, how can one code without a clear understanding of what needs to be encoded? I’ve grown increasingly skeptical of <i>requirements documents</i>. Their purpose often leans more towards politics than technicality.

They fail to capture every flow and process within the application. I’ve come to believe that code is the only accurate representation of the entirety of business logic. You can draft a document, but when you actually write code, you uncover edge cases that may have been overlooked.

I’ve heard it said that writing is a form of thinking; that the process of articulating an argument over thousands of words organizes ideas into a coherent structure. The same is true for coding. The code you write serves as the solution to the problem. Any documents produced along the way are merely notes assisting in arriving at that solution.

Creating a product is an ongoing dialogue. The more intricate the product, the more challenging the conversation becomes. The more individuals involved, the more diverse viewpoints must be considered.

Drafting the requirements is part of the intricate dance that brings software to life. While I refer to it as a dance, it can sometimes resemble a war. Not every project unfolds this way, but documents can become akin to treaties for demilitarization. Writing requirements is a defensive maneuver, with each stipulation penned on paper as a result of a drawn-out struggle or negotiation: fine, we won’t use accordions, but I do want dropdowns. Each faction deploys its resources to secure its preferences on paper: the “research” that backs their position, the cost assessments, the business necessities. It’s not that research lacks value, but when faced with a stakeholder insisting on the “friendliness” of Comic Sans, one can see the temptation to select studies that bolster their viewpoint. You can’t afford to A/B test every decision.

Once the list is finalized, a series of immutable decrees are established. Now, the list transforms into a political tool. For changes you desire, allow them as omissions; for changes you oppose, point to their absence on the list. “You approved this. We can incorporate it, but that’ll require a change request, impacting the timeline.” If you’re a third-party vendor, this is an opportune moment to request additional funding. The requirements list may be part of a contract: refer to Schedule 1 for details on deliverables. However, the list never encompasses all necessary deliverables. It serves as a safety net to prevent one side from straying too far off course.

My procurement colleague believes Glenn has provided sufficient detail in his requirements. She has crafted a MoSCoW list.

“We’ll issue an RFP,” she announces. A Request For Proposal will be sent to the market for companies to bid on. Unfortunately, no companies respond. Glenn’s list is overly specific, and no product exists that can meet his criteria. The list has been <i>too</i> detailed. A few companies can meet most of the requirements, but when Glenn examines their systems, he finds the interfaces to be impractical.

I can’t help but wonder about the likelihood that Glenn, much like my friend, will encounter a software application unexpectedly at a social gathering.

I doubt it’s feasible to compile a comprehensive list of requirements and hand it over for delivery, no matter how appealing that may sound. Successful products arise from ongoing dialogues among all parties involved. Consider the Agile Manifesto, the closest thing to a sacred text in software development: “Business people and developers must collaborate daily throughout the project.”

Requirements lists represent a mere shadow of the ideal product; at best, they hint at key areas of importance. When purchasing something, you’re choosing among available market options. When building something, the delivery process must elucidate what’s necessary as the product approaches a state of being “ready for launch.”

Glenn dismisses the RFP. He has come to the realization that he may not need software after all. Having lost faith in the IT Department, he believes he might manage everything through email and a couple of Excel spreadsheets.

“What about the requirements?” I inquire.

“I think we might be able to scale back some of them,” he replies.