Simon asks, How do you map requirements to code and presents an idea he had recently, basically tagging certain points in your code with an annotation identifying the requirement related to that specific action.

So, how do I map requirements to code? I don't. I really don't. Explicitly. But if I did, I'd probably tag my acceptance tests instead of the production code because I'm more interested about the reality itself rather than the difference between the reality (observed coverage of a given acceptance test) and my intent (annotation on production code).

I am of the opinion that simply having a suite of acceptance tests written in the domain's language is enough for mapping requirements to tests, and from there we can more or less let the computer figure out which parts of our system are involved in implementing a given feature or an aspect of it.

I don't know if my take on this is any more right or wrong, better or worse than anyone else's. Not to mention that I haven't spent much cycles on thinking about the whole thing in the first place. I would also be interested in finding new perspectives to look at requirements traceability from.