[adrianN]

I've found that writing (pseudo-)code is absolutely necessary to find problems in the requirements. Often enough the requirements are self contradictory or just contain too many unnecessary corner cases. I've seen requirements that sounded really simple in the requirement doc, but turned out to be extremely hard to test because they implicitly defined a state machine with dozens of transitions.

[beat]

Yes, definitely. This applies a lot to infrastructure issues, too. But pseudocode or extremely simple test case code can do this a lot better than tossing something into production to find out if it sucks.

I suspect a lot of the HN hostility to proper requirements analysis is coming from writing trivial systems.

[carlmr]

Especially because English is often a terrible language to express requirements.

[adrianN]

Especially when it's written by people who aren't native speakers but work in a "we're a modern company now" environment.