How to understand requirements as a software engineer

Hi everyone, my name is Douglas Acosta. I'm a backend software engineer. This is my first article in a series that will become my profesional portfolio. Given that my previous work is subject to confidential agreements, I have created this space to share insights and perspectives about software development.
Hope this is useful for you, thanks for joining. Let's kick off the today one. Requirements

Why requirements are key?

The most beautiful and elegant solution isn't worth anything if:
It doesn't provide value
Isn't right for the given problem

For the first point, I'm going to give details in a future article. Let's focus on the right solution for the problem.

A problem can be solved in multiple ways. Don’t get me wrong, I’m not trying to say that there is only one way of solving something (Of course, optimal solutions are a different discussion👀), but it’s easy to see in software a “Brute force” solution. I have been that developer. Sometimes it’s just try after try, and for example, for a single code function, that will “work” eventually (the time it took you is only going to be based on luck), but when the problem to be solved needs several functions, a database connection, and multiple data structures, you need to take a more structured approach.

The requirement of a project is (in the best state possible) a detailed and complete list of premises that compose the problem itself. Without the lingo, if your problem is, for example, an apple, a requirement is the color of the apple, the weight, the taste, the length, the type (yes, there are different types of apples, like breeds of dogs. For plants, it is called variety and cultivar), etc. You can feel where I’m going. It is all the characteristics that involve the problem. And you could say, well, I know an apple, yes, surely you do, but I’m pretty sure that you have eaten apples that taste different. For problems, it is the same, and knowing apples prior will surely help you to identify patterns more easily, but still, they are apples without seeds. I didn’t know that until I just Googled it.** Assuming I fully understand the problem without investigation will likely lead to poor decisions.** I need to know the problem the most completely possible way.

Understanding the problem

So, enough fruits for now. How do we get that detailed list of characteristics? Well, if you’re lucky, sometimes the client (the person who has the needs for the solution) knows everything about the problem itself, and has it written on a piece of paper and can even lecture you about it. That’s the best case. But other times, the client also knows everything about the problem itself, but they don’t know it yet. They know, they always know because they live with it.

Here is when the most useful (and underrated if you ask me) skill of a software developer comes into play: ask questions.
There is a rule (that I just made up) that your capacity of being proficient in writing code is proportional to how good questions you ask. How so? Well, for the developers, do you remember when you started writing code and it gave you a big error that you had to copy and paste on Google? Not all the answers were helpful, right? What did we do next? Give more context to our question.

It’s the same for requirements. The client is us, and we are Google, with the difference that we need to ask the client for that context.

What are some good questions?

1. What is currently the most hard and painful process right now?
2. What is that thing that your users ask and the answer usually is not yet?
3. What is the most costly process right now?
4. What are those processes that never click with the business but are still in place because they work?

Practical Case: Automating an Order Processing Workflow

Real example incoming.
I was talking with this client, and she stated the next phrase, “I don’t know where or how to start”. This is the most common human response ever. Remember the first premise? That solutions need to provide value? Full circle here. I’m going to start asking you questions about what it’s that provides value to your company (for this case specifically, it can actually be a personal project that needs a software solution).
For my client, the most valuable solution was automating order processing. And this is really important because at the beginning we were also talking about a hub to centralize communications of the business. That was useful, but does it give more value? It wasn’t. How we recognize and prioritize value? We will talk about that in other article in deep, but , look for breadcrumbs that the client leave in his answers, usually the things that most get repeated will guide you to the deeper objectives.

The list of details that describe the problem in the best way possible, that also provide value to the person that has the problem, is what we call requirements. The way to find out about them is asking questions, the what is actually an easy question (I need to automate some processes in my company), that usually have different possible answers, but the how (the context questions) is what is really going to put us into the most likely solutions, and this is the best way we can provide value to somebody.

Thanks for joining. For the next one, we will talk about how to talk to clients. Leave any questions or thoughts in the comments!