As I look out onto the landscape of software currently, something is missing. It’s REQUIREMENTS! 15 years ago, testing was in a similar position. What slipped first in a hurried project? Testing. But then came along Agile, Kent Beck, and xUnit. Testing now has its own methodologies like TDD, BDD, and the like.
Can you imagine if someone created a methodology called “Requirements Driven Development”?!?! They’d be laughed out the door…. 🙂
So why are Requirements being given such short shrift now? They are given lip service from the Agile community at best.
Use Cases? “Oh my god, I’m going to throw up!”
User Stories? “Yeah, just write it on a card, we’ll figure it out later, and make sure to rip it up at the end. That crap is useless.”
Really!?! Are you f’ing kidding me! This stuff matters! Well, it definitely matters when things go south on a Software Project, you know, like “we’re going to court” south. But by then it’s too late. Everyone’s trying to reverse engineer the requirements from the present software. It’s a tragic charade.
So here’s to Software Requirements. They matter. Don’t believe me? Well, when a lawyer asks you, “Was that an enhancement or a bug?” and you answer, “Uh, it was in the user story….”. Well, then we can talk 🙂
Woody Press 
Preach it! In their antipathy to Big Design Up Front, too many teams have forgotten that Requirements are not Design.
Agile (as opposed to fragile) should encourage this. Every requirement should be expressible as one or more tests. If you can’t describe it as a test, send it back to the requirements team with questions about what it means. This way, requirements become tests, and tests drive code.
Exactly! You can’t test what you don’t know! How do you know if your test is correct? Requirements!