ANSWER

Use cases are a valuable tool available to the business analyst for documenting functional requirements of a system or business, however they do have limitations.

• Use cases were not created to capture non-functional requirements (e.g performance, platform, scalability, reliability of a system). While use case specification templates have been extended by some in an ad-hoc fashion to list non-functional requirements, this strays from the intended purpose of a use case.  Use cases are functional in nature.  It is this very organization by function that give use cases their many benefits.  Arbitrarily listing non-functional requirements in one use case specification or another can obfuscate the cohesiveness and benefits of the use case specification.
• The non-sequential nature of a use case diagram is often difficult for some audiences to understand.  When one use case includes or extends another, the reader of the diagram often arrives at the incorrect conclusion that the use case diagram is showing a sequence where the first use case is completed before the other begins.  Those who are familiar with use case diagrams know that an included or extended use case can occur or be initiated at any point within the including or extending use case.
• Learning how to write use cases takes time.  Many consider it to be more of an art than a science.  This is because there is no fully defined set of standards for how to write use cases, or what should be included within a use cases specification. And while there have been many different views espoused by authors, still a great deal of commonality has emerged among them. Where this commonality exists there is little disagreement among use case writers and those who consume or read use cases.  However, in some areas there are still a number of differing opinions creating confusion for new use case authors.  Because of this, the learning curve for use cases and use cases specifications is elongated.  Still, over time, use case authors and readers develop a more sophisticated understanding of those areas that are more ambiguous and open for interpretation, such as the “extends” relationship. 
• Use case specifications are not an appropriate tool for describing the user interface of the application.  Use cases should be left as UI independent as possible.  Remember that a use case specification it intended to capture the functional requirements of the system, or in other words, WHAT the system should do in response to a user action.  This is very different than HOW the system should do something.  Any time an analyst captures requirements, the focus should be on the WHAT not the HOW.  This gives the system and UI designer the freedom to develop the best solution possible.  It also makes our use case specifications much more maintainable since a change in screen design doesn’t impact the user-system interaction previously defined.