What use cases aren't good at
Lets start with the most commonly used form of the use case--the diagram. UML tells you to draw a use case as named ovals, and connect them to their actors, but it does not say much about how to supply details of how the system performs behaviours needed to meet the actor's goals. Though use case diagrams show useful information, without more information on how the system is to do this work, the development effort will stall.
The extra information has to be stored somewhere close to the diagram. Some CASE tools like Rational Rose have text areas for writing and saving such details. This information is sometimes referred to as the use case specification because it used to specify how the system behaves when triggered by actors to do some things for them. The writing of use case specification follows no industrial standards. Different organisations have their own writing formats. Writing partial stories or scenarios of each use case is important to the specifying of desired system behaviour. Lack of guidelines means some incomprehensible, ambiguous and inconsistent specifications can be written. Validating such descriptions can benefit from automated support of a well-thought structure and writing guidelines are used. For this reason, we prefer textual use cases to diagrams, as the latter do not provide much detail of the system's desired behaviour. We also realise that textual use cases suffer from lack of adopted standard writing structure and guidelines. We have designed and adopted our own structure and have used previously well-designed guidelines for authoring. An applications has been developed to automate authoring and validation.