How do you do software requirements?

A lot of what I read online suggests there are 2 main approaches to developing requirements:

• pure agile, where you don’t do much upfront requirements development and instead focus on shipping software asap to elicit true requirements from users (who often don’t know what they want, or can’t articulate it), or
• traditional, where you spend ages engineering your requirements upfront, trying to make sure they’re complete, consistent, unambiguous etc, and defer shipping to later.

I think this dichotomy, whilst not false, is misleading, and reflecting on this in the context of a past project I worked on, I decided to think about an approach that combines aspects of both agile and traditional approaches for developing requirements, and that worked well in some important respects on this project. I wrote this down in a blog, if you’re interested: https://hackernoon.com/foo-xv1x3278.

I wondered what other people’s experiences have been, what approaches they’ve used, what has and hasn’t worked, and what challenges they’ve found hardest to deal with.