How to capture user clicking drop-down menu?

[DMT]

It looks like Mr. Sparks has had the answer all along. It was staring me in the face.  Get this:

A "UI Element" has a "scenarios" tab!

THIS IS PERFECT!

I can drag UI elements onto a UI mock-up, show which class each element is derived from, then write the scenarios that pertain to that UI element RIGHT THERE.

SWEET!

[Tjerk]

Hi DMT,

This is becoming a good discussion, learning with every answer  . Some observations from my side:

• The Use Cases you plan to write seem not to be for the communication with the clients / users, but with the developers;
  
• Use Cases for communication with the client can be written down in a SSS (system specifications);
  
• Then you design the system, make choices on usage, GUIs, sequences, etc., etc. These things go into a SSDD (system design);
  
• The system design should provide you with the content to help introducing and connecting the subsystems / components;
  
• The system specifications and your design thoughts translate to concrete multiple SRSs (software requirements specifications);
  
• My guess is that you sort of misuse (as you said yourself) the Use Cases to work out the details of software requirements;
  
• Instead of Use Cases, I guess you can use custom diagrams for capturing GUIs and sequence diagrams to capture user interactions with the system. These can be your requirement specifications that you hand over to the developers;
  

Greetings,
Tjerk

[DMT]

I'm not sure if I would agree with the observation that I intend the use cases to be consumed only by the development team. It is certainly the case that the use cases are designed to be consumed by the developers, but not limited only to the developers.

They are the driving force behind the design for ALL stakeholders, including clients. Now, our clients would not typically read the use cases directly, but we would explain certain scenarios to clients to validate the system behavior. These scenarios would be the same ones outlined in the use cases.

I didn't feel I was misusing use cases; I just felt that it perhaps didn't seem "absolutely correct" to outline menu and toolbar behavior in a use case.

Of course, "absolutely correct" to me means "whatever it takes to accomplish your goals and ship your product as quickly and easily as possible, and have that product meet your customer requirements." I now believe that it really doesn't matter what the "strict rules" are; if you need to bend them to fit your needs in the most straightforward manner possible, that's what you should do. In fact, the UML was designed to be extensible just for that reason.  No project is a cookie-cutter fit.

It's POSSIBLE I may actually create some "UI-centric" use cases in the UI design that would be used as a "roadmap" into the behavior supported by the UI, but we'll see.  My concern is that, following the ICONIX process, use cases drive the entire development process. From use cases come sequence diagrams and attributes on classes. From sequence diagrams come the operations. From the combination of sequence diagrams and the class model comes the code.

So, in summary, after much discussion among ourselves and consideration of all of the great feedback, here's where I'm at:

1. The bulk of the use cases will focus on the desired behavior of the system, based upon capturing sequences of actions an actor performs to achieve a particular goal.
2. The UI design will focus on the screen layouts and UI control behavior.
3. The UI design will include information about what use cases are invoked by what actions. For example, the UI design for the menus and toolbars would specify that when the user clicks the Open Database toolbar button, the Open Database use case is initiated.
4. If it makes more sense from a communication point of view, I may create some UI-specific use cases to expose the required functionality and drive sequence diagrams for the UI classes.

Thanks again for your input!