I simply have to comment on James McGovern's latest post on requirements where he says:
When will we acknowledge that implementation are little decisions made all over and that requirements documentation only decide certain aspects?
This is the result of failing to realize that "technical requirements" cannot be made separate from functional requirements since a function includes the notion of acceptable/predictable behavior. This is where the analysts can borrow a technique from developers: Test-Driven Development (TDD). For lack of a better term, let's call it Test-Driven Analysis.
What would TDA include? It would include a description of the function plus sample inputs, outputs and expected results, including expected failures (samples of say, SQL injection attack code that must be rejected). Moreover, this wouldn't just be data-focused. Other properties such as the range of acceptable response times, expected feedback, etc. need to be determined. Now we have embedded those "technical requirements" directly into the functional requirements plus have added measurable quality attributes that further serve as acceptance tests/criteria.
It's not like this can't be done, it's just a lot of hard work.