Chapter 1: Understanding the Nature of Requirements

The realm of requirements can be likened to a delicate balance between a peace treaty and a wish list.

I recently received an email from Glenn, who is eager to develop a software solution and inquires about my ability to assist him. At the end of his message, he confidently states, "I've gathered all the requirements," offering to share them. This assertion lingers in my mind, leaving me uncertain about what to anticipate. Will it be a Word document, an Excel file, a PowerPoint presentation, a mind map, a collection of Jira tickets, or Trello cards? Perhaps "all the requirements" will consist of broad business objectives ("The system will facilitate payment processing") or detailed specifications on integrating specific payment APIs. They might even include non-functional criteria ("it must be secure"). Will there be user stories? Wireframes? Designs? Or will he simply assert, "design is necessary"? Glenn's declaration feels rather bold—implying that no edge case has been overlooked, no feature disregarded. It’s hard to discern whether his confidence stems from knowledge or ignorance.

People often speak about requirements with such assurance that I once believed there must be a definitive definition hidden from me, perhaps a covert Business Analyst code outlining strict standards to follow. Yet, each new project with different stakeholders reveals their own unique styles of documenting requirements, leading us through a winding path to a completed product. While I’ve come to terms with this reality, it still strikes me as peculiar how we maintain the pretense of a shared understanding of "requirements" amidst the myriad of approaches—whether using T-Shirt sizes, Fibonacci sequences, or SCRUM poker cards, all prioritized through various methods such as high, medium, low, or the MoSCoW model (Must do, Should do, Could do, Won't do). The nuances between "Must" and "Should" are particularly subtle, and "Could" feels like a self-imposed complication. Don't even get me started on "Won't"—"Won't run on Windows 95," "Won't be developed in FORTRAN," or even "Won't lead to the collapse of capitalism." I often find myself surprised that this section isn't more extensive.

The role of requirements shifts significantly throughout the software development life cycle. In the initial phases, you require broad concepts to clarify and validate the project’s direction. Conversely, during later stages, precise instructions are essential. However, each team possesses its own preferences and methodologies. Some individuals prefer a format that starts with "Given I am a user wanting an app, then I will write the requirements," while others find this approach unappealing. The diversity of opinions surrounding requirements is vast.

Interestingly, a friend of mine is on a quest for a boyfriend, approaching the search as if it were a competitive procurement process. She claims to have scoured every man aged 28 to 38 on Tinder, stating that she has exhausted all options.

She has her own requirements list: "At least 6 feet tall," "no back hair," "wealthy," and so forth. These are very much functional requirements ("Must be tall," "Could have a vacation home in the South of France," "Won't be excessively sweaty").

While I may be overanalyzing, there seems to be a strange parallel to Glenn's list. However, her checklist hasn’t proven effective; she matched with someone who met every criterion but turned out to be a disaster. After her latest date, she added "Not a jerk" to her requirements. It’s clear that having some non-functional requirements can also be beneficial.

Returning to Glenn, he initially sent his email to several individuals across the organization, employing a scattergun strategy to locate someone to assist him. One recipient works in IT procurement, while another operates in internal consultancy. The two of them, along with me, gathered to discuss Glenn's list. My colleagues occupy opposing ends of the requirements spectrum: she seeks to "define the requirements" in detail for procurement purposes, while he prefers to remain "high level" to address the core issue at hand.

"What problem are you trying to solve?" he inquires.

This reminds me of a requirements gathering training that introduced the "Five Whys," a method crafted by Toyota to uncover the root cause of issues. The concept is straightforward: akin to a child persistently asking "why" until a resolution is reached, or everyone involved becomes frustrated and abandons the task. During the training, we practiced this technique with one another, uncovering numerous root causes.

In less capable hands, the fundamental cause can be reduced to "because my boss said so" or "due to the Big Bang." It's easy to become too focused on identifying a basic root cause.

As we delve into Glenn's issue, my colleague probes him about the benefits of his intended work.

"It'll enhance the website's usability," Glenn asserts.

"That's not a benefit," the consultant counters.

"If it's easier to use, users will complete tasks more efficiently?" he attempts again.

"That's still not a benefit."

Poor Glenn makes yet another attempt. "If staff can work more quickly, it will free up time for them to handle more tasks and save costs."

This is begrudgingly accepted as a benefit, yet I can't help but notice that the requirement itself hasn’t changed, and I wonder what we truly gained from this discussion.

My other colleague requests further details about the requirements. Glenn tries to elaborate on what he envisions but is reprimanded for "solutionizing."

"We want to remain solution agnostic at this stage," she instructs him.

I empathize with Glenn. He's navigating a complex mental challenge, trying to envision the desired future state while simultaneously avoiding specific solutions. I question whether individuals can genuinely think at such an abstract level.

Consequently, Glenn has created a convoluted list—a mixture of requirements and application ideas, often contradictory. His personal preferences have morphed into "critical business requirements." After years of being dependent on IT, he has learned that the path to getting what he wants is to label his desires as "business requirements."

Some are readily identifiable. He prefers radio buttons over dropdowns, so he specifies "Must have radio buttons." Others are less apparent. The need for payment processing is undoubtedly a business requirement, but when Glenn elaborates on the desired content of emails, we enter the ambiguous territory of "business processes."

What’s lacking is a proficient business analyst. However, even with one, it’s challenging to achieve clarity. Business analysts often find themselves acting as prosecutors, rigorously questioning users about their requirements in hopes of uncovering the truth amid a web of preferences disguised as "requirements." It's not that users are deliberately misleading; often, they are simply confused or haven’t contemplated their business processes in a way that lends itself to application development. And why should they?

As time progresses, individuals become more entrenched in their views. The distinction between software solutions and business processes can become a political battleground, with stakeholders vying for control over the requirements list.

Interestingly, my friend eventually found someone—not through Tinder but through a mutual friend, in an unexpected moment.

"How's his back?" I inquire.

"Surprisingly hairy," she replies.

Her requirements list has been discarded. Not every requirement truly qualifies as essential.

Undoubtedly, requirements are necessary for product development. How can one write code without a clear understanding of what to encode? However, I have grown increasingly skeptical of requirements documents. Their purpose often leans more towards political maneuvering than technical accuracy.

Such documents seldom encompass every flow and process within the application. I have come to believe that writing code is the most precise method to represent the entirety of business logic. While documents can serve a purpose, crafting code reveals edge cases that may have been overlooked.

I've heard it said that writing is a form of thinking; constructing a comprehensive argument can organize ideas into a coherent structure. The same applies to coding. The code produced is the solution to the problem, and any documentation generated along the way serves merely as notes to facilitate that solution.

Developing a product is an ongoing dialogue. The complexity of the product often correlates with the difficulty of this dialogue. The more individuals involved, the more diverse perspectives must be considered.

Documenting requirements is part of the intricate dance that brings software to life. While I refer to it as a dance, in some instances, it resembles a battle. Not every project follows this pattern, but at times, documents become akin to treaties for demilitarization. Writing requirements can be a defensive strategy, each requirement inscribed on paper resulting from an extended negotiation: for instance, we may agree to exclude accordions, but I insist on including dropdowns. Each party employs their resources to advocate for their preferred outcome: research to support their stance, cost evaluations, and business necessities. While research has its merits, facing a stakeholder who insists on the "friendliness" of Comic Sans can lead one to the temptation of selectively citing studies that align with their viewpoint. It’s impractical to conduct A/B testing for every decision.

Once a comprehensive list is compiled, it becomes a political tool. For desired changes, permit them as omissions; for unwanted alterations, cite their absence from the list. "You approved this. We can add it, but it will require a change request and affect the timeline." If you are a third-party supplier, this is a prime opportunity to negotiate additional fees. The requirements list may be incorporated into a contract: refer to Schedule 1 for specifics on deliverables. However, this list never fully encapsulates all the deliverables required. It serves as a backstop to prevent one party from straying too far off course.

My colleague in procurement is satisfied that Glenn has provided sufficient detail in his requirements. She has created a MoSCoW list.

"We'll issue an RFP," she announces—a Request for Proposal. This will be distributed to the market for companies to submit bids. Unfortunately, no companies respond. Glenn's requirements are too specific, and no existing product meets his criteria. The list has been overly detailed. A few companies can fulfill most of the requirements, but when Glenn evaluates their systems, he finds the interfaces to be impractical.

I can’t help but wonder about the likelihood that Glenn, like my friend, might encounter a software solution in an unexpected setting.

I doubt it’s feasible to compile a comprehensive list of requirements and simply hand it over for execution, no matter how appealing that notion may be. Successful products emerge from continuous conversations among all stakeholders. Reflecting on the Agile Manifesto, the closest thing to a religious doctrine in software development: "Business people and developers must collaborate daily throughout the project."

Requirements lists are merely shadows of the ideal product, offering at best a hint of essential areas. When purchasing, you choose among available options; when building, the delivery process must gradually unveil what is necessary as the product approaches a state of being "good enough to launch."

Ultimately, Glenn shrugs off the RFP. He has decided that he may not need a software solution after all. Having lost faith in the IT Department, he believes he can manage everything himself through emails and a few Excel spreadsheets.

"What about the requirements?" I ask.

"I think we might be able to reduce some of them," he responds.

Chapter 2: The Importance of Flexibility in Requirements

In this video, "The Top Five Reasons Why You Can't Write Good Requirements," we explore common pitfalls in writing effective requirements and how to avoid them.

The second video, "Requirements Engineering Challenges," discusses the various hurdles faced in the requirements engineering process and strategies for overcoming them.