Many people who define requirements use some form of documentation to organize their requirements. Too often, that documentation is in the form of a text document. Because text is so bad at describing what a user interface does, the text becomes a design document for the user interface. Then the developers and testers are stuck trying to implement and test someone else’s dicussion of the user interface.
Writing the UI description in text is a poor choice. Instead of writing the UI, try a paper prototype. Paper prototypes are (low cost, low fidelity, and high return) a technique to discuss the UI without the words in the way. At the end of a prototyping session, you know where you stand. You either have a prototype, or you need more discussion. But no one’s trying to figure out why the requirements demand a drop-down menu instead of a text box.
In many of the assessments I perform, requirements are a big deal. Too often, the monolithic requirements documents are too hard to read, too detailed, and insufficiently detailed, all at the same time. I try to build levels of requirements documents, where document doesn’t have to be text. In the case of a GUI, pictures are worth much more than thousands of words.