Use case
A use case is a list of actions or event steps typically defining the interactions between a role (known in the Unified Modeling Language (UML) as an actor) and a system to achieve a goal.
[3] In 1992 he co-authored the book Object-Oriented Software Engineering - A Use Case Driven Approach,[4] which laid the foundation of the OOSE system engineering method and helped to popularize use cases for capturing functional requirements, especially in software development.
[7] Since then, many authors have contributed to the development of the technique, notably: Larry Constantine developed in 1995, in the context of usage-centered design, so called "essential use-cases" that aim to describe user intents rather than sequences of actions or scenarios which might constrain or bias the design of user interface;[8] Alistair Cockburn published in 2000 a goal-oriented use case practice based on text narratives and tabular specifications;[9] Kurt Bittner and Ian Spence developed in 2002 advanced practices for analyzing functional requirements with use cases;[10] Dean Leffingwell and Don Widrig proposed to apply use cases to change management and stakeholder communication activities;[11] Gunnar Overgaard proposed in 2004 to extend the principles of design patterns to use cases.
[12] In 2011, Jacobson published with Ian Spence and Kurt Bittner the ebook Use Case 2.0 to adapt the technique to an agile context, enriching it with incremental use case "slices", and promoting its use across the full development lifecycle[13] after having presented the renewed approach at the annual IIBA conference.
[10] A use case corresponds to a set of behaviors that the system may perform in interaction with its actors, and which produces an observable result that contributes to its goals.
In the requirement analysis, at their identification, a use case is named according to the specific user goal that it represents for its primary actor.
The case is further detailed with a textual description or with additional graphical models that explain the general sequence of activities and events, as well as variants such as special conditions, exceptions, or error situations.
Writing use cases in templates devised by various vendors or experts is a common industry practice to get high-quality functional system requirements.
"[28] For example, "the owners of the system, the company's board of directors, and regulatory bodies such as the Internal Revenue Service and the Department of Insurance" could all be stakeholders but are unlikely to be actors.
For example, user "Joe" could be playing the role of a Customer when using an Automated Teller Machine to withdraw cash from his own account or playing the role of a Bank Teller when using the system to restock the cash drawer on behalf of the bank.
This tells the project that the "user interface and security clearances" should be designed for the sales rep and clerk, but that the customer and marketing department are the roles concerned about the results.
[30] For example, when user "Joe" withdraws cash from his account, he is operating the Automated Teller Machine and obtaining a result on his own behalf.
Use Case: Edit an article Primary Actor: Member (Registered User) Scope: a Wiki system Level: !
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.
Use case authoring has been an important and valuable analysis tool in the domain of User-Centered Design (UCD) for years.
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.
Quality requirements by structured exploration One of the most powerful things about use cases resides in the formats of the use case templates, especially the main success scenario (basic flow) and the extension scenario fragments (extensions, exceptional and alternative flows).
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.
As the Scrum Primer[39] states, Product Backlog items are articulated in any way that is clear and sustainable.
Use cases will often contain a level of detail (i.e. naming of labels and buttons) which make it not well suited for capturing the requirements for a new system from scratch.Novice misunderstandings.
Each step of a well-written use case should present actor goals or intentions (the essence of functional requirements), and normally it should not contain any user interface details, e.g. naming of labels and buttons, UI operations, etc., which is a bad practice and will unnecessarily complicate the use case writing and limit its implementation.
[citation needed] Spending much time writing tedious use cases which add no or little value and result in a lot of rework is a bad smell indicating that the writers are not well skilled and have little knowledge of how to write quality use cases both efficiently and effectively.
In fact, the use case formats formulated by those popular template styles, e.g. the RUP's and the Cockburn's (also adopted by the OUM method), etc., have been proved in practice as valuable and helpful tools for capturing, analyzing and documenting complex requirements of large systems.
It is possible as well that a quality and comprehensive use case model of a large system may finally evolve into hundreds of pages mainly because of the inherent complexity of the problem in hand, not because of the poor writing skills of its authors.
[citation needed] Text editors and/or word processors with template support are often used to write use cases.
