In answer to number 1) - The Use Case does not represent the requirements (or shouldn't). It represents what the actor (and the actor can be a person, a role, another program etc etc) needs to perform. It doesn't say how it is performed, just what the actor needs to do. So, it doesn't describe the UI OR the business requirement. It is a requirement that needs to occur. Business requirements shouild have been defined before the Use Case... They driver the Use Case.

2) Sure... You can have several Use Cases that may be combined into the same Gui page or form or whatever. Given an example from the mechanical world... A DVD player has an interface with lots of controls on the same "User Interface". Use cases may be Play the DVD, Record the DVD, Navigate through the DVD... etc etc... but one UI is used. Hopefully one can design a UI that is "user friendly".

3) Detail design such as??? Class Diagrams, Sequence Diagrams??? From a Use case to a Class Diagram, go through and look at all the nouns... Collect the nouns that refer to the same thing. You might have a Class. Look at the things that describe the noun or compose the noun... those are the attributes of the Class. A collection of classes is a class diagram. Now look at what those classes do and how they interact... Now you have an Colaboration Diagram... By looking at the order these things need to be done in, you then have a sequence diagram...

Does that help?

Good luck.

Stephen McConnell