A use case identifies some actions that provide value to an actor; it generally does not describe an accumulation of features. For example, the “Enroll Student in Seminar” use case identifies how a college student interacts with the system to join up for a seminar. It doesn’t describe what the user interface appears like or how it operates.

You have other models to spell it out this important info, such as your user interface model as well as your supplementary specs. Object-oriented analysis is complex, which is why you have several models to work with, and you should properly apply each model. A use case is neither a class specification nor a data specification. This is the sort of information that should be captured from your conceptual model, which in the object world is modeled with a UML class model. You are likely to make reference to classes described in your conceptual model, for example, the “Enroll in Seminar” use case includes principles, such as students and workshops, both of which would be referred to by your conceptual model.

System use situations often refer to major interface (UI) elements, called boundary or interface items often, such as HTML reviews and pages. Use cases will sometimes refer to minor UI elements, such as buttons or data-entry fields, although this known degree of details is much less common. Use cases add a fair amount of information, information that can be documented in a common format easily. Common practice is to draw vertically … Read more