Screen mockups can support the requirements gathering process when introduced at the right time, but if introduced too early they can become problematic.   Here are a few key points that an analyst should remember.

1)  Mockups are nice because they help the business representatives or clients visualize the functionality of the system.  This can be a big advantage to help analysts and stakeholders identify problems early on.  However, if introduced too soon in the process the natural tendency is for the business reps/clients to try and be screen designers.  Instead of stating that the system shall support "x", they beginning saying that they need a dropdown to capture "y" and a button to do "z".  The client is not a UI designer, in fact few business analysts truly are, so this can lead to a screen design which does not have an appropriate emphasis on usability.  Similarly, specifying the controls needed on a screen detracts from the true requirements of the system and often results in an inadequate level of discussion around why a system must support certain functionality.

2)  When requirements are captured in screen mockups with no supporting requirements list, it becomes impossible to know whether an early screen design decision was made because it supports a necessary requirement or if it was made for some other reason.  How can the analyst and developers know whether they can eliminate or alter the screen feature without losing an important requirement. Questions like, "Do we really need to have the control on this screen, or can we capture the data at a later point in the process?" becomes unanswerable without going back to the original stakeholders.  And, on complex projects no one stakeholder may be able to answer the question.

3)  Screen mockups alone cannot capture the flow through the system.  Often analysts will accompany screen mockups with a written description of what happens when certain buttons are clicked or when certain values are entered within a field or dropdown.   These descriptions are helpful, but they fall short of describing the end to end processes that the system must support.  Further document such as process flows or use cases are required, but often overlooked when too much emphasis is place on screen mockups during the requirements gathering process.  While analysts and stakeholders who are involved in the screen mockup process may have a basic understanding of the processes supported, developers and testers will not.

Ultimately, the introduction of UI mockups can be very helpful, but this should only occur after an exhaustive list of features and usage scenarios (what business process flows need to be supported by the system) have been documented.  Only then can the UI mockups be generated without introducing major pitfalls.