It's clear to me that as a BA you don't want to get into UI design.  What is unclear is who is responsible for user interaction design?  If you leave it to the engineers they will tend to design user interaction that is system-centric, not user-centric - a recipe for user discontent.  You've seen this before:  systems where frequently executed tasks take the user many steps to complete because the functions weren't well-placed in the right screens with the right linkages to other screens.  So unless your organization has a user interaction designer who knows what they're doing, I'd rather see the responsibility fall on the BA than a developer - the BA is much closer to the user and understands what they're trying to accomplish in their work.

I like testing mockups on users to validate requirements which means, as Chris pointed out, that you have to think about separating UI elements from requirements.  I've successfully documented a highly user-interactive system the following way:

1.  Create a crude Visio drawing of the user-tested mockup screens and clearly point out that it's for illustration only to graphically show how functions are grouped.  I make it ugly enough to get the point across that I'm not trying to do UI design.

2.  Under each screen drawing I document a user-centric "focus area" which is a textual description of the functions in each mockup screen.  I can even add related business rules and UI advice from the user tests such as how fields should be named.  Simple example (o = system invoked function, . = user invoked function, > = link to other focus area):

 Focus Area:  Enter account information

 Functions
 . Enter or change customer name and address
       [here you can also specify the fields, how fields should be named, # of characters, etc.]
 o See available account managers
       Business Rule:  only show account managers assigned to the customer zip code
 . Assign account manager to customer

 Links
 > Enter new order
 > See past orders

 Business objects
   Customer
   Account Manager

3.  Provide use cases that show the dynamics of how users use the functions in the focus areas and in what order.  The focus areas provide a system "floor plan" of grouped functions and the use cases show how users move about in the system to get something done.

The focus areas are what communicate the functional requirements, but it also includes elements of interaction design:  how functions should be grouped to coherently support a task and how users want to navigate the system.

If your engineers design like that then try to specify some non-functional usability requirements. Ideally in an organisation there should be some suitable for re-sue, but application specific ones need to be defined, especially when the functions required for a task haven't been explained before. Task specific use cases should help here.

Jim,

Let me suggest that if you are only thinking about cases where people use a screen interface when doing the  requirements, this will affect the requirements as you describe.

However, consider that not every interface/interaction with a system is through a screen/window, and not every actor interacting with a system has to be a human being. As simple as it sounds, I find that keeping this in mind helps avoid the problem you are having. If your Use Case is about Creating a Customer, the business requirements will be the same if it is done by a person, another system, or even a batch process creating a lot of customers in one execution.

Anyway, it works for me...