What the hell are the requirements?

What a delightful question! If it’s asked, then not all is lost, and there’s a fragile chance that you’ll start enjoying your work, your expenses will decrease, and your income will increase. This isn’t utopia or the whimsical imagination of an infantile optimist. These are quite real, predictable consequences of the right approach to problem-solving.

“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”

A quote attributed to Albert Einstein.

Though the great physicist may not have uttered these exact words, he frequently emphasised the significance of posing the correct questions and distinctly defining the essence of the problem.

And it’s hard to argue with that — a problem cannot be effectively solved if it lacks clarity or is improperly formulated. The formalisation of the problem-solving process is what we refer to as a task.

But what exactly is a task?

“No method is more effective than a good example”.

Ingvar Kamprad, the founder of Ikea.

Consider the simplest yet illustrative example. Suppose we need an AI to write code for us:

- // Create a function that returns the difference between dates.

- fn diff<T: Date + PartialOrd>(date1: T, date2: T) -> T { …

- // Oh no, I wanted it in Typescript.

- function diff(date1: Date, date2: Date) : Date { …

- // I want the function to return the difference in milliseconds.

- function diff(date1: Date, date2: Date) : number|null { …

- // The input dates must be in ISO8601 format.

I believe you get the idea. We can keep refining what we want, and the AI will keep generating new results.

However, what if it’s not just a function but an entire project? What if it’s not AI but a software engineer who is developing it? And in most cases, that’s the reality, isn’t it? What would be the costs associated with constant refinement?

To avoid answering this question, it’s important to grasp the essence of a task.

Create a function that returns the difference between dates.

Now, is this truly a task?

No. From this input, we can’t extract a precise solution, as illustrated by the example. It’s merely a prompt — a notion expressed incompletely, akin to a spontaneously conceived idea.

Create a function in Typescript that takes two arguments representing ISO8601-formatted dates and returns the difference between the dates in milliseconds.

This aligns more closely with the concept of a task. The distinction is notable, isn’t it?

In theory, if presented with this prompt, an AI would likely generate the desired solution on the initial attempt, much like a seasoned software engineer. However, when aiming to construct a substantial and intricate project, this method of articulating the problem becomes cumbersome and inefficient. Instead of relying on an artistic form of expression, ingenious individuals have devised a technical representation that greatly simplifies the description and comprehension of tasks.

Consider how the context of our task would appear in a technical documentation format:

Objective:

Develop a function to calculate the difference between dates.

Requirements:

Utilise the Typescript programming language.

The function should accept 2 string arguments.

The arguments should represent dates in the ISO8601 format.

The function’s output should be of numerical type, representing the difference in milliseconds.

Clear and straightforward. Of course, it’s again about the function, but my task is to convey the idea (the concept, the approach) using simple examples and a concise, convincing description.

Finally, we’ve reached the Requirements.

It’s easy to share ideas with people. Even if individuals don’t fully grasp the goal or comprehend the complexities of its execution, they often express a general understanding of how to proceed. Without delving into the nuances of social psychology, let’s acknowledge that this occurs frequently, especially in a working process without a rigid plan and a strictly deterministic project management methodology — in simpler terms, when decisions are made relying on assumptions and verbal agreements.

This raises various concerns. If you abandon the simple and logical practice of requirement elicitation, leading to clear task formulation, you’ll inevitably face a host of issues: filing, twisting, cutting, resoldering, and more. Eventually, this will evolve into a laborious routine and become the norm of the working day.

Hence, requirements aren’t merely vital clarifications shaping the task; they stand as the cornerstone of planning and development.

Nevertheless, gathering requirements is not an inherently simple task.

Firstly, the classification of requirements varies based on the subject area and demands accurate determination. These include business requirements, functional requirements, user requirements, and more. For programmers, the focus leans toward functional and system requirements, while business analysts typically concentrate on business requirements.

Secondly, in the case of large projects involving multiple teams or organisations, utilising third-party solutions, or integrating with other systems, it is imperative to gather not only specific requirements but also those of all project participants, often referred to as stakeholders.

Thirdly, requirements should be straightforward, comprehensible, and sufficient. There’s no need to scrutinise every detail; much like a medical diagnosis doesn’t require a full-body examination, the emphasis should be on precision rather than exhaustive coverage.

However, don’t be discouraged — if you have a good understanding of the subject, the practice turns out to be simple and enjoyable.

If you’re interested in learning more about the types of requirements and how to develop them, subscribe to my blog or leave a comment, and I’ll certainly cover it in the next article.