What are some things you do(apart from the popularly discussed, todos, writing etc.) to make complex requirements simple(not easy, simple)?

Breaking them down into several requirements (just like you do with long and complex functions), or if appropriate, putting them in tabular form.

@Fast-Nop How quickly will you do it? I need to sit with the problem and give it a time.

@Fast-Nop For example, let's try to solve this problem: There's this random person, let's call them true-dev, true-dev wants to get $1000 dollars in a month, starting from $10.

@true-dev001 Usually, you have different levels of requirements. It starts out at the top level which are more about WHAT the system is supposed to do, not HOW. That's also the level where you find applicable norms, standards, compliance things.

Then you need to do system level design and design the overall composition of your system, still with no coding at all. What components do you have, what do they do, how do they interact.

And then you arrive at component level where the requirements start to get more specific. Depending on how complex the thing is, you may need one more lowest level requirements, or you can drop that.

Overall, it's a top-down approach of defining your system, and it requires good understanding of what you're doing. There can be a lot of discussions involved because customers often don't know what they want, but try to specify how to achieve it.

@true-dev001 And then you need to trace the requirements downwards and upwards to make sure that

1) each higher level requirement has allocated lower level requirements while also validating that the latter fully implement the former (downward trace).

2) each lower level requirement has a higher level source requirement (upward trace). Sometimes, you need auxiliary lower level requirement without trace, and then you must validate that they at least don't compromise higher level requirements.

You'll usually use a requirement management tool for that so that it becomes manageable.

@true-dev001 In your example, the top level requirement is making $1000 within a month. A system contraint is that you already have $10.

Now you have tons of different ways how to structure the system. A popular trap is to accidentally mirror the company org in the system design - process becomes product, as they say.

So we can divide a month into 30 days (or 31? or 28? what is a month? - discussion needed). Starting at $10, you need to increase that overall by x^30. $1000 = $10 * x^30, i.e. x=1.166.

Requirement 1: Do daily business.
Requirement 2: The operational margin of each business day must be at least 16%.

From there you break it down as to what kind of business you want to do. Let's say you decide to deal in hardtogettium. Then you specify how much of that you buy, where to source it, where to sell it, contract modes and other stuff.

Or you choose a totally different structure. You have one month of time to seduce a hypocritical, super-conservative, married politician. You make up a time line, put that into requirements, and the final requirement is blackmailing him by $990 plus your accumulated expenses.

Convert the requirement to an epic and break it down from there. Screaming at your screen and telling it how much of a loser it is should do the trick

sometimes if it's too difficult you have to stop looking at the requirement and look at the needs.
an example I've read: if your problem is space to fit your books, instead of adding more shelves, you should try e-books

@darksideofyay Or reading the requirements closely with the mindset of how to achieve that with minimum effort. I had one such case.

PM: How long will feature X take?
Me: At least one month.
PM: OMG we have two days!
Me: That's not possible. However, I can bring the project in line with the customer accepted spec within two days.
PM: Oh well?! Then go ahead.

Basically, the spec didn't strictly demand feature X in the way my PM had thought it would.