1) Requirements are written on a word processor (usually word).
2) The use cases are best communicated as stories.
3) If you want to have a project to be flexible along the lines of the problem domain, then the names of classes/interfaces should match the language of the domain.
4) Use cases for web apps. are easy to describe after the initial discussions, but tend to get very detailed. Click here, then there, etc.
5) If you want to monitor project progress then the only reliable indicator is working code.
6) A measure of working code that both business people and programmers understand is a runnable use case.