Editing Use case (section)

== Limitations ==

Limitations of use cases include:

* Use cases are not well suited to 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.
* As there are no fully standard definitions of use cases, each project must form its own interpretation.
* Some use case relationships, such as ''extends'', are ambiguous in interpretation and can be difficult for stakeholders to understand as pointed out by Cockburn (Problem #6)<ref>{{cite web|url=http://alistair.cockburn.us/Structuring+use+cases+with+goals|title=Alistair.Cockburn.us - Structuring use cases with goals|website=alistair.cockburn.us|access-date=16 March 2018}}</ref>{{citation needed|date=October 2013}}
* 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. In software engineering, this difficulty is resolved by applying [[requirements traceability]], for example with a [[traceability matrix]]. Another approach to associate UI elements with use cases is to attach a UI design to each step in the use case. This is called a use case storyboard.
* Use cases can be over-emphasized. [[Bertrand Meyer]] discusses issues such as driving system design too literally from use cases, and using use cases to the exclusion of other potentially valuable requirements analysis techniques.<ref>Meyer, 2000. (page needed)</ref>
* Use cases are a starting point for test design,<ref>Armour and Miller, 2000. (page needed)</ref> but since each test needs its own success criteria, use cases may need to be modified to provide separate post-conditions for each path.<ref>Denney, 2005. (page needed)</ref>
* Though use cases include goals and contexts, whether these goals and motivations behind the goals (stakeholders' concerns and their assessments including non-interaction) conflict or negatively/positively affect other system goals are subject of goal-oriented requirement modeling techniques (such as [[Business Motivation Model|BMM]], [[I*]], [[KAOS (software development)|KAOS]] and [[ArchiMate]] ARMOR).