Editing Use case (section)

== Advantages ==

Since the inception of the agile movement, the [[user story]] technique from [[Extreme Programming]] has been so popular that many think it is the only and best solution for the agile requirements of all projects. [[Alistair Cockburn]] lists five reasons why he still writes use cases in [[agile development]].<ref>{{cite web|last=Cockburn|first=Alistair|title=Why I still use cases|url=http://alistair.cockburn.us/Why+I+still+use+use+cases|work=alistair.cockburn.us|date=9 January 2008}}</ref>

# The list of goal names provides the ''shortest'' summary of what the system will offer (even then user stories). It also provides a project planning skeleton, to be used to build initial priorities, estimates, team allocation, and timing.
# The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do and what it will not do. It provides the context for each specific line item requirement (e.g. fine-grained user stories), a context that is very hard to get anywhere else.
# The extension conditions of each use case provide a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget. It provides a look-ahead mechanism, so the stakeholders can spot issues likely to take a long time to get answers for. These issues can and should then be put ahead of the schedule so that the answers can be ready when the development team gets around to working on them.
# The use case extension scenario fragments provide answers to the many detailed, often tricky, and ignored business questions: "What are we supposed to do in this case?" It is a thinking/documentation framework that matches the if...then...else statement that helps the programmers think through issues. Except it is done at investigation time, not programming time.
# The full use case set shows that the investigators have thought through every user's needs, every goal they have with respect to the system, and every business variant involved.

In summary, specifying system requirements in use cases have these apparent benefits compared with traditional or other approaches:

'''User focused'''

Use cases constitute a powerful, user-centric tool for the software requirements specification process.<ref>{{cite web|author=Karl Wiegers|title=Listening to the Customer's Voice|publisher=Software Development|website=Process Impact|date=March 1997|url=http://www.processimpact.com/articles/usecase.html}}</ref> Use case modeling typically starts from identifying key stakeholder roles (''actors'') interacting with the system, and their goals or objectives the system must fulfill (an outside perspective). These user goals then become the ideal candidates for the names or titles of the use cases which represent the desired functional features or services provided by the system. This user-centered approach ensures that what has real business value and the user really want is developed, not those trivial functions speculated from a developer or system (inside) perspective.

Use case authoring has been an important and valuable analysis tool in the domain of [[User-centered design|User-Centered Design (UCD)]] for years.

'''Better communication'''

Use cases are often written in natural languages with structured templates. This narrative textual form (legible requirement stories), understandable by almost everyone, and complemented by visual UML diagrams fosters better and deeper communications among all stakeholders, including customers, end-users, developers, testers, and managers. Better communications result in quality requirements and thus quality systems delivered.

'''Quality requirements by structured exploration'''

One of the most powerful things about use cases resides in the formats of the use case [[#Templates|templates]], especially the main success scenario (basic flow) and the extension scenario fragments (extensions, exceptional and alternative flows). Analyzing a use case step by step from preconditions to postconditions, exploring and investigating every action step of the use case flows, from basic to extensions, to identify those tricky, normally hidden and ignored, seemingly trivial but realistically often costly requirements (as Cockburn mentioned above), is a structured and beneficial way to get clear, stable and quality requirements systematically.

Minimizing and optimizing the action steps of a use case to achieve the user goal also contribute to a better [[interaction design]] and [[User experience design|user experience]] of the system.

'''Facilitate testing and user documentation'''

With content based upon an action or event flow structure, a model of well-written use cases also serves as excellent groundwork and valuable guidelines for the design of test cases and user manuals of the system or product, which is an effort-worthy investment up-front. There are obvious connections between the flow paths of a use case and its test cases. Deriving functional test cases from a use case through its scenarios (running instances of a use case) is straightforward.<ref>{{cite web|title=Traceability from Use Cases to Test Cases|author=Peter Zielczynski|publisher=IBM developerWorks|date=May 2006|url=http://www.ibm.com/developerworks/rational/library/04/r-3217/}}</ref>