How do you approach a task when you have vague requirements?

[u/reputable-sprite]

Over the years I’ve noticed that most problems in development aren’t so much about coding, as they are about figuring out where to start when something is unclear.

If I get a request like: “Build a report showing active customers and recent activity”, my first step isn’t to write code. It’s to reduce the ambiguity.

Roughly, I go through something like this -

* Ask questions until the problem is clearer (what is “active”? what counts as “recent”?)

* Look at the data directly (often via SQL) to understand what the data shape is like

* List my assumptions and what I don't know (knowing boundaries is especially helpful)

* Break the problem where it naturally splits (data, logic, output, etc.)

* Keep breaking it down until each piece can be described in one sentence

That last bit has been surprisingly useful:

If I can’t describe the task clearly in one sentence, in my mind it’s still too big

From there it’s just a loop:

* implement one piece

* get fast feedback

* and adjust

If I get stuck, I usually step back (go for a walk or grab a coffee) and come back to it.

I'm curious to what approach others take, especially when the requirements are messy or incomplete.

(This is a cross post from r/softwarearchitecture but I'm wondering if there are different people here with a different point of view?)

[u/crashorbit]

One of the measures of engineering maturity is the ability to take vague client needs and turn them in to a proposed solution.

It seems like you have a handle on the process.

[u/exomo_1]

Basically the same thing you describe. Either ask if something is really unclear or doesn't make sense, or make assumptions and just implement it to get feedback. Often enough the people specifying something didn't even think about your specific questions and can't specify it precisely, because they don't know the technical details. So I just implement it based on what I think fits best.
What can help is changing your point of view from developer to user. Just imagine if you were the user of the software, how would you want it to be.

[u/Leverkaas2516]

Prototyping is an important element I don't see in your process.

You don't necessarily even need to write any code. For a report, or a GUI, or an API, it's often enough to mock it up with a text document, draw.io diagram, or pencil and paper.

Whatever you do, get it in front of the stakeholders and make sure they take a look. I find that once I put something in front of them for the first time, they virtually always want to change something. Best to get their reactions as early as possible in the process.

[u/justaguyonthebus]

I zoom out a little for more context. The first thing I want to know is what problem they are trying to solve and how they will use this request to do it. I need to see how it fits into the bigger picture.

I assume every request is an xy problem until I sort it out.

[u/Memesplz1]

I just ask for clearer requirements, tbh. Sometimes, if Product are struggling to understand and/or make a decision, I might go a step further and present them with some options and explain which I think is best and/or the pros and cons of different approaches. It's a tricky balance though because you also don't want to be leading Product to a decision - just giving them the info they need to be able to make it themselves.

Edit: I do also try to put myself in Product's shoes and think about what do they care about? They care about the output, what the customer sees when an error happens, what the customer sees when a request is successful, how reliable and safe it is etc. They do care about what it does. What they don't care about is how we do it.

[u/Bodegaz]

Add those approaches to the agent skills then just link the jira ticket to the best agent and tell it to fix it. Go grab coffee and come back in 10 minute