Use case flows are not well suited to easily capturing non-interaction based requirements of a system (such as algorithm or mathematical requirements) or non-functional requirements (such as platform, performance, timing, or safety-critical aspects). These are better specified declaratively elsewhere.
- Use cases templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s).
There is a learning curve involved in interpreting use cases correctly, for both end users and developers. As there are no fully standard definitions of use cases, each group must gradually evolve its own interpretation. Some of the relations, such as extends, are ambiguous in interpretation and can be difficult for stakeholders to understand.
Proponents of Extreme Programming often consider use cases too needlessly document-centric, preferring to use the simpler approach of a user story.
Use case developers often find it difficult to determine the level of user interface (UI) dependency to incorporate in a use case. While use case theory suggests that UI not be reflected in use cases, it can be awkward to abstract out this aspect of design, as it makes the use cases difficult to visualize.
Use cases can be over-emphasized. In Object Oriented Software Construction (2nd edition), Bertrand Meyer discusses issues such as driving the system design too literally from use cases and using use cases to the exclusion of other potentially valuable requirements analysis techniques.
Use cases have received some interest as a starting point for test design. Some use case literature, however, states that use case pre and postconditions should apply to all scenarios of a use case (i.e., to all possible paths through a use case) which is limiting from a test design standpoint. If the postconditions of a use case are so general as to be valid for all possible use case scenarios, they are likely not to be useful as a basis for specifying expected behavior in test design. For example, the outputs and final state of a failed attempt to withdraw cash from an ATM are not the same as a successful withdrawal: if the postconditions reflect this, they too will differ; if the postconditions don�t reflect this, then they can�t be used to specify the expected behavior of tests. An alternate perspective on use case pre & postconditions more suitable for test design based on model-based specification
