use case a very simple use case diagram of a wiki system software development core activities processes requirements design engineering construction testing debugging deployment maintenance paradigms and models agile cleanroom incremental prototyping spiral v model waterfall methodologies and frameworks asd devops dad dsdm fdd iid kanban lean sd less mdd msf psp rad rup safe scrum semat tsp up xp supporting disciplines configuration management documentation software quality assurance sqa project management user experience practices atdd bdd cco ci cd ddd pp standup tdd tools compiler debugger profiler gui designer modeling ide build automation release automation infrastructure as code testing standards and bodies of knowledge babok cmmi ieee standards iso 9001 isoiec standards pmbok swebok itil glossaries artificial intelligence computer science electrical and electronics engineering vte in software and systems engineering a use case is a list of actions or event steps typically defining the interactions between a role known in the unified modeling language as an actor and a system to achieve a goal the actor can be a human or other external system in systems engineering use cases are used at a higher level than within software engineering often representing missions or stakeholder goals the detailed requirements may then be captured in the systems modeling language sysml or as contractual statements use case analysis is an important and valuable requirement analysis technique that has been widely used in modern software engineering since its formal introduction by ivar jacobson in 1992 use case driven development is a key characteristic of many process models and frameworks such as iconix the unified process up the ibm rational unified process rup and the oracle unified method oum with its inherent iterative incremental and evolutionary nature use case also fits well for agile development history in 1986 ivar jacobson first formulated textual structural and visual modeling techniques for specifying use cases in 1992 his coauthored book objectoriented software engineering a use case driven approach since then other experts have also contributed a great deal to the technique notably alistair cockburn larry constantine dean leffingwell kurt bittner and gunnar overgaard in 2011 jacobson published an update to his work called use case 20 templates there are many ways to write a use case in text from use case brief casual outline to fully dressed etc and with varied templates writing use cases in templates devised by various vendors or experts is a common industry practice to get highquality functional system requirements cockburn style the template defined by alistair cockburn in his popular book writing effective use cases has been one of the most widely used writing styles of use cases design scopes cockburn suggests annotating each use case with a symbol to show the design scope which may be blackbox internal detail is hidden or whitebox internal detail is shown five symbols are available scope icon organization blackbox filled house organization whitebox unfilled house system blackbox filled box system whitebox unfilled box component screw or bolt other authors sometimes call use cases at organization level business use cases goal levels hierarchy of goal levels cockburn suggests annotating each use case with a symbol to show the goal level101 goal level icon symbol very high summary cloud summary flying kite user goal waves at sea subfunction fish too low seabed clamshell sometimes in text writing a usecase name followed by an alternative text symbol etc is a more concise and convenient way to denote levels eg place an order login fully dressed cockburn describes a more detailed structure for a use case but permits it to be simplified when less detail is needed his fully dressed use case template lists the following fields title an activeverb goal phrase that names the goal of the primary actor primary actor goal in context scope level stakeholders and interests precondition minimal guarantees success guarantees trigger main success scenario extensions technology data variations list in addition cockburn suggests using two devices to indicate the nature of each use case icons for design scope and goal level cockburns approach has influenced other authors for example alexander and beusdukic generalize cockburns fully dressed use case template from software to systems of all kinds with the following fields differing from cockburn variation scenarios maybe branching off from and maybe returning to the main scenario exceptions ie exception events and their exceptionhandling scenarios casual cockburn recognizes that projects may not always need detailed fully dressed use cases he describes a casual use case with the fields title goal primary actor scope level story the body of the use case is simply a paragraph or two of text informally describing what happens fowler style martin fowler states there is no standard way to write the content of a use case and different formats work well in different cases101 title goal the use case is trying to satisfy101 main success scenario numbered list of steps101 step a simple statement of the interaction between the actor and a system101 extensions separately numbered lists one per extension101 extension a condition that results in different interactions from the main success scenario an extension from main step 3 is numbered 3a etc101 the fowler style can also be viewed as a simplified variant of the cockburn template actors actor uml a use case defines the interactions between external actors and the system under consideration to accomplish a goal actors must be able to make decisions but need not be human an actor might be a person a company or organization a computer program or a computer systemhardware software or both similarly a person using a system may be represented as different actors because of playing different roles 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 actors are often working on behalf of someone else cockburn writes that these days i write sales rep for the customer or clerk for the marketing department to capture that the user of the system is acting for someone else 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 a stakeholder may play both an active and an inactive role for example a consumer is both a massmarket purchaser not interacting with the system and a user an actor actively interacting with the purchased product 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 cockburn advises to look for actors among the stakeholders of a system the primary and supporting secondary actors of a use case the system under design sud itself and finally among the internal actors namely the components of the system under design business use case a business use case diagram depicts a model of several business use cases goals which represents the interactions between a restaurant the business system and its primary stakeholders business actors and business workers visual modeling uml diagram types structural uml diagrams class diagram component diagram composite structure diagram deployment diagram object diagram package diagram profile diagram behavioral uml diagrams activity diagram communication diagram interaction overview diagram sequence diagram state diagram timing diagram use case diagram vte use cases are not only texts but also diagrams if needed in the unified modeling language the relationships between use cases and actors are represented in use case diagrams originally based upon ivar jacobsons objectory notation sysml uses the same notation at a system block level in addition other behavioral uml diagrams such as activity diagrams sequence diagrams communication diagrams and state machine diagrams can also be used to visualize use cases accordingly specifically a system sequence diagram ssd is a sequence diagram often used to show the interactions between the external actors and the system under design sud usually for visualizing a particular scenario of a use case use case analysis usually starts by drawing use case diagrams for agile development a requirement model of many uml diagrams depicting use cases plus some textual descriptions notes or use case briefs would be very lightweight and just enough for small or easy project use as good complements to use case texts the visual diagram representations of use cases are also effective facilitating tools for the better understanding communication and design of complex system behavioral requirements examples below is a sample use case written with a slightlymodified version of the cockburnstyle template note that there are no buttons controls forms or any other ui elements and operations in the basic use case description where only user goals subgoals or intentions are expressed in every step of the basic flow or extensions this practice makes the requirement specification clearer and maximizes the flexibility of the design and implementations use case edit an article primary actor member registered user scope a wiki system level user goal or sea level brief equivalent to a user story or an epic the member edits any part the entire article or just a section of an article heshe is reading preview and changes comparison are allowed during the editing stakeholders postconditions minimal guarantees success guarantees the article is saved and an updated view is shown an edit record for the article is created by the system so watchers of the article can be informed of the update later preconditions the article with editing enabled is presented to the member triggers the member invokes an edit request for the full article or just one section on the article basic flow the system provides a new editor areabox filled with all the articles relevant content with an informative edit summary for the member to edit if the member just wants to edit a section of the article only the original content of the section is shown with the section title automatically filled out in the edit summary the member modifies the articles content till satisfied the member fills out the edit summary tells the system if heshe wants to watch this article and submits the edit the system saves the article logs the edit event and finishes any necessary post processing the system presents the updated view of the article to the member extensions 23 a show preview the member selects show preview which submits the modified content the system reruns step 1 with addition of the rendered updated content for preview and informs the member that hisher edits have not been saved yet then continues b show changes the member selects show changes which submits the modified content the system reruns step 1 with addition of showing the results of comparing the differences between the current edits by the member and the most recent saved version of the article then continues c cancel the edit the member selects cancel the system discards any change the member has made then goes to step 5 4a timeout 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 agile requirements of all projects alistair cockburn lists five reasons why he still writes use cases in agile development the list of goal names provides the shortest summary of what the system will offer even than 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 eg finegrained 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 that are 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 thinkingdocumentation framework that matches the ifthenelse 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 users needs every goal they have with respect to the system and every business variant involved in summary specifying system requirements in use cases has these apparent benefits comparing with traditional or other approaches user focused use cases constitute a powerful usercentric tool for the software requirements specification process 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 usercentered approach ensure that what has the 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 usercentered 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 complemented by visual uml diagrams foster better and deeper communications among all stakeholders including customers endusers 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 especially the main success scenario basic flow and the extension scenario fragments extensions exceptional andor 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 of the system facilitate testing and user documentation with content based upon an action or event flow structure a model of wellwritten use cases also serves as an excellent groundwork and valuable guidelines for the design of test cases and user manuals of the system or product which is an effortworthy investment upfront there is 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 limitations limitations of use cases include use cases are not well suited to capturing noninteraction based requirements of a system such as algorithm or mathematical requirements or nonfunctional requirements such as platform performance timing or safetycritical 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 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 overemphasized 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 use cases are a starting point for test design though use cases include goals and contexts whether these goals and motivations behind the goals stakeholders concerns and their assessments including noninteraction conflict or negativelypositively affect other system goals are subject of goal oriented requirement modelling techniques such as bmm i kaos and archimate armor misconceptions this section needs expansion you can help by adding to it july 2015 common misunderstandings about use cases are user stories are agile use cases are not agile and scrum are neutral on requirement techniques as the scrum primer states product backlog items are articulated in any way that is clear and sustainable contrary to popular misunderstanding the product backlog does not contain user stories it simply contains items those items can be expressed as user stories use cases or any other requirements approach that the group finds useful but whatever the approach most items should focus on delivering value to customers use cases are mainly diagrams craig larman stresses that use cases are not diagrams they are text use cases have too much uirelated content as some put it use cases will often contain a level of detail ie 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 wellwritten use case should present actor goals or intentions the essence of functional requirements and normally it should not contain any user interface details eg 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 as for capturing requirements for a new system from scratch use case diagrams plus use case briefs are often used as handy and valuable tools at least as lightweight as user stories writing use cases for large systems is tedious and a waste of time as some put it the format of the use case makes it difficult to describe a large system eg crm system in less than several hundred pages it is time consuming and you will find yourself spending time doing an unnecessary amount of rework spending much time in 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 use cases should be authored in an iterative incremental and evolutionary agile way applying use case templates does not mean that all the fields of a use case template should be used and filled out comprehensively from upfront or during a special dedicated stage ie the requirement phase in the traditional waterfall development model in fact the use case formats formulated by those popular template styles eg the rups and the cockburns 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 the quality of a good use case documentation model should not be judged largely or only by its size 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 tools this section does not cite any sources please help improve this section by adding citations to reliable sources unsourced material may be challenged and removed august 2013 learn how and when to remove this template message text editors andor word processors with template support are often used to write use cases for large and complex system requirements dedicated use case tools are helpful some of the wellknown use case tools include casecomplete enterprise architect magicdraw rational softwares requisitepro one of the early wellknown use case and requirement management tools in the 1990s wiki software good tools for teams to author and manage use cases collaboratively most uml tools support both the text writing and visual modeling of use cases software testing portal abuse case business case event partitioning feature list of uml tools misuse case requirement requirements elicitation scenario storyboard test case use case points alexander ian and beusdukic ljerka discovering requirements how to specify products and services wiley 2009 alexander ian and maiden neil scenarios stories use cases wiley 2004 armour frank and granville miller advanced use case modeling software systems addisonwesley 2000 kurt bittner ian spence use case modeling addisonwesley professional aug 20 2002 cockburn alistair writing effective use cases addisonwesley 2001 larry constantine lucy lockwood software for use a practical guide to the essential models and methods of usagecentered design addisonwesley 1999 denney richard succeeding with use cases working smart to deliver quality addisonwesley 2005 fowler martin uml distilled third edition addisonwesley 2004 jacobson ivar christerson m jonsson p vergaard g objectoriented software engineering a use case driven approach addisonwesley 1992 jacobson ivar spence i bittner k use case 20 the guide to succeeding with use cases iji sa 2011 dean leffingwell don widrig managing software requirements a use case approach addisonwesley professional dec 7 2012 kulak daryl and eamonn guiney use cases requirements in context addisonwesley 2012 meyer bertrand object oriented software construction 2nd edition prentice hall 2000 schneider geri and winters jason p applying use cases 2nd edition a practical guide addisonwesley 2001 wazlawick raul s objectoriented analysis and design for information systems modeling with uml ocl and ifml morgan kaufmann 2014 alistair cockburns use case column use cases usabilitygov basic use case template by alistair cockburn application of use cases for stakeholder analysis project icarus stakeholder scenarios for an interstellar exploration program jbis 64 224233 an academic survey on the role of use cases in the uml search use case in ibm developerworks vteunified modeling languageactors organizations object management group uml partners persons grady booch ivar jacobson james rumbaugh conceptsobject oriented objectoriented programming objectoriented analysis and design objectoriented modeling structure actor attribute artifact class component interface object package profile diagram behavior activity event message method state use case relationships association composition dependency generalization or inheritance extensibility profile stereotype other multiplicity diagramsstructure class component composite structure deployment object package behaviour activity state machine use case interaction communications sequence interaction overview timing derived languages systems modeling language sysml uml exchange format uxf xml metadata interchange xmi executable uml xuml other topics glossary of uml terms rational unified process list of unified modeling language tools object modeling in color vtesoftware engineeringfields computer programming requirements engineering software deployment software design software maintenance software testing systems analysis formal methods concepts data modeling enterprise architecture functional specification modeling language orthogonality programming paradigm software software archaeology software architecture software configuration management software development methodology software development process software quality software quality assurance software verification and validation structured analysis orientations agile aspectoriented object orientation ontology service orientation sdlc modelsdevelopmental agile eup executable uml incremental model iterative model prototype model rad up scrum spiral model vmodel waterfall model xp other spice cmmi data model er model function model information model metamodeling object model systems model view model languages idef uml usl sysml softwareengineers victor basili kent beck grady booch fred brooks barry boehm peter chen danese cooper ward cunningham tom demarco edsger w dijkstra delores m etter martin fowler adele goldstine margaret hamilton c a r hoare lois haibt mary jean harrold grace hopper watts humphrey michael a jackson ivar jacobson alan kay nancy leveson stephen j mellor bertrand meyer david parnas trygve reenskaug winston w royce james rumbaugh mary shaw peri tarr elaine weyuker niklaus wirth edward yourdon related fields computer science computer engineering project management risk management systems engineering category commons 