Use case: Difference between revisions

Content deleted Content added

Inline

Revision as of 06:31, 26 January 2011

A use case in software engineering and systems engineering is a description of a potential series of interactions between a software module and an external agent, which lead the agent towards something useful.^[1] Use case diagrams are made up of actors and actions, also known as users and uses, which make up the system. ^[2] Uses cases are used as a software modeling technique that helps developers determine which features to implement, and determine how to gracefully resolve errors.^[3]

Within 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 SysML requirement diagrams or similar mechanisms.

(Note that the "use" in "use case" is pronounced as the English noun /ˈjuːs/, not the English verb /ˈjuːz/. Rephrased: this is a case of its use, not a case of using it.)

History

In 1986, Ivar Jacobson, later an important contributor to both the Unified Modeling Language (UML) and the Rational Unified Process (RUP), first formulated the textual, structural and visual modeling techniques for specifying use cases. The use case technique became popular through Jacobson's 1992 book Object-Oriented Software Engineering - A Use Case Driven Approach, co-authored with Magnus Christerson, Patrik Jonsson and Gunnar Overgaard. Originally he used the terms usage scenarios and usage case, which were the more correct translations of the Swedish word "användningsfall" he used, but found that neither of these terms sounded natural in English, and eventually he settled on the term use case.^[4] Since Jacobson originated use case modeling many others have contributed to improving this technique, including Kurt Bittner, Ian Spence, Alistair Cockburn, Gunnar Overgaard, Karin Palmquist, Patrik Jonsson, Magnus Christerson and Geri Schneider.

During the 1990s use cases became one of the most common practices for capturing functional requirements. This is especially the case within the object-oriented community where they originated, but their applicability is not restricted to object-oriented systems.

Use cases and the development process

The specific way use cases are used within the development process will depend on which development methodology is being used. In certain development methodologies ^[which?], a brief use case survey is all that is required. In other development methodologies ^[which?], use cases evolve in complexity and change in character as the development process proceeds. In some methodologies, they may begin as brief business use cases, evolve into more detailed system use cases, and then eventually develop into highly detailed and exhaustive test cases.

Use case focus

"Each use case focuses on describing how to achieve a goal or a task. For most software projects, this means that multiple, perhaps dozens of use cases are needed to define the scope of the new system. The degree of formality of a particular software project and the stage of the project will influence the level of detail required in each use case." ^{[This quote needs a citation]}

Use cases should not be confused with the features of the system. One or more features (a.k.a. "system requirements") describe the functionality needed to meet a stakeholder request or user need (a.k.a. "user requirement"). Each feature can be analyzed into one or more use cases, which detail cases where an actor uses the system. Each use case should be traceable to its originating feature, which in turn should be traceable to its originating stakeholder/user request.

Use cases treat the system as a black box, and the interactions with the system, including system responses, are perceived as from outside the system. This is a deliberate policy, because it forces the author to focus on what the system must do, not how it is to be done, and avoids making assumptions about how the functionality will be accomplished.

A use case should:

Describe what the system shall do for the actor to achieve a particular goal.
Include no implementation-specific language.
Be at the appropriate level of detail.
Not include detail regarding user interfaces and screens. This is done in user-interface design, which references the use case and its business rules.

Degree of detail

Alistair Cockburn, in Writing Effective Use Cases, identified three levels of detail in writing use cases:^[5]

Brief use case -- consists of a few sentences summarizing the use case. It can be easily inserted in a spreadsheet cell, and allows the other columns in the spreadsheet to record priority, duration, a method of estimating duration, technical complexity, release number, and so on.
Casual use case -- consists of a few paragraphs of text, summarizing the use case.
Fully dressed use case -- a formal document based on a detailed template with fields for various sections; and it is the most common understanding of the meaning of a use case. Fully dressed use cases are discussed in detail in the next section on use case templates.

Some software development processes do not require anything more than a simple use case to define requirements. However, some other development processes require detailed use cases to define requirements. The larger and more complex the project, the more likely that it will be necessary to use detailed use cases.

The level of detail in a use case often differs according to the progress of the project. The initial use cases may be brief, but as the development process unfolds the use cases become even more detailed. This reflects the different requirements of the use case. Initially they need only be brief, because they are used to summarize the business requirement from the point of view of users. However, later in the process, software developers need far more specific and detailed guidance.

The Rational Unified Process invites developers to write a brief use case description in the use case diagram, with a casual description as comments and a detailed description of the flow of events in a textual analysis. All those can usually be input into the use case tool (e.g., a UML Tool, SysML Tool), or can be written separately in a text editor.

Actors

A use case defines the interactions between external actors and the system under consideration to accomplish a goal. An actor specifies a role played by a person or thing when interacting with the system.^[6] The same person using the system may be represented as different actors because they are playing different roles. For example, user "Joe" could be playing the role of a Customer when using an Automated Teller Machine to withdraw cash, or playing the role of a Bank Teller when using the system to restock the cash drawer.

Business vs. System Use Cases

Use cases may be described at the abstract level (business use case, sometimes called essential use case), or at the system level (system use case). The differences between these is the scope.

A business use case is described in technology-free terminology which treats system as a black box and describes the business process that is used by its business actors (people or systems external to the process) to achieve their goals (e.g., manual payment processing, expense report approval, manage corporate real estate). The business use case will describe a process that provides value to the business actor, and it describes what the process does. Business Process Mapping is another method for this level of business description.
A system use case describes a system that automates a business use case or process. It is normally described at the system functionality level (for example, "create voucher") and specifies the function or the service that the system provides for the actor. The system use case details what the system will do in response to an actor's actions. For this reason it is recommended that system use case specification begin with a verb (e.g., create voucher, select payments, exclude payment, cancel voucher). An actor can be a human user or another system/subsystem interacting with the system being defined.

Use case notation

In Unified Modeling Language, the relationships between all (or a set of) the use cases and actors are represented in a use case diagram or diagrams, originally based upon Ivar Jacobson's Objectory notation. SysML, a UML profile, uses the same notation at the system block level.

Limitations

Use cases have limitations:

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 case 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. Within software engineering, this difficulty is resolved by applying requirements traceability through the use of a traceability matrix.
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.^[7] 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 alternative perspective on use case pre- and postconditions more suitable for test design based on model-based specification is discussed in.^[8]
Some systems are better described in an information/data-driven approach than in a the functionality-driven approach of use cases. A good example of this kind of system is data-mining systems used for Business Intelligence. If you were to describe this kind of system in a use case model, it would be quite small and uninteresting (there are not many different functions here) but the set of data that the system handles may nevertheless be large and rich in details.

References

^ Bittner, Kurt & Spence, Ian (2003). Use case modeling. Addison-Wesley. p. xvi. ISBN 9780201709131.{{cite book}}: CS1 maint: multiple names: authors list (link)
^ Use Case diagram What is an Application Design - ASPNET Book 2010
^ Patterns for effective use cases. Addison-Wesley. 2002. p. 2. ISBN 9780201721843. {{cite book}}: Cite uses deprecated parameter |authors= (help)
^ Alistair Cockburn, "Use cases, ten years later"
^ A. Cockburn (2001). Writing Effective Use Cases. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc. ISBN 0-201-70225-8.
^ http://www.omg.org/docs/formal/07-02-03.pdf §16.3.1
^ Frank Armour and Granville Miller (2000). Advanced Use Case Modeling: Software Systems. Addison-Wesley Professional. ISBN 0201615924.
^ Richard Denney (2005). Succeeding with Use Cases: Working Smart to Deliver Quality. Addison-Wesley Professional. ISBN 0321316436.

External links

Use Cases (Usability.gov)
Basic Use Case Template by Alistair Cockburn
"An Academic Survey on the Role of Use Cases in the UML"

Requirement Management Tools

Open source requirement management tool

[1] Bittner, Kurt & Spence, Ian (2003). Use case modeling. Addison-Wesley. p. xvi. ISBN 9780201709131.{{cite book}}: CS1 maint: multiple names: authors list (link)

[2] Use Case diagram What is an Application Design - ASPNET Book 2010

[3] Patterns for effective use cases. Addison-Wesley. 2002. p. 2. ISBN 9780201721843. {{cite book}}: Cite uses deprecated parameter |authors= (help)

[cockburn-4] Alistair Cockburn, "Use cases, ten years later"

[5] A. Cockburn (2001). Writing Effective Use Cases. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc. ISBN 0-201-70225-8.

[6] ttp://www.omg.org/docs/formal/07-02-03.pdf §16.3.1

[7] Frank Armour and Granville Miller (2000). Advanced Use Case Modeling: Software Systems. Addison-Wesley Professional. ISBN 0201615924.

[8] Richard Denney (2005). Succeeding with Use Cases: Working Smart to Deliver Quality. Addison-Wesley Professional. ISBN 0321316436.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

Revision as of 16:55, 21 January 2011 edit 190.149.115.168 (talk) →‎Herramientas de administración de requerimientos ← Previous edit		Revision as of 06:31, 26 January 2011 edit undo 112.134.100.66 (talk) No edit summary Next edit →
Line 1:		Line 1:
	A '''use case''' in [[software engineering]] and [[systems engineering]] is a description of a potential series of interactions between a software [[Modular programming\|module]] and an external [[agent]], which lead the agent towards something useful.<ref>{{cite book\|author=Bittner, Kurt & Spence, Ian\|title=Use case modeling\|publisher=Addison-Wesley\|year=2003\|isbn=9780201709131\|page=xvi\|url=http://books.google.com/books?id=bD0VNcVjIp0C&pg=PR16}}</ref> Uses cases are used as a [[software modeling]] technique that helps developers determine which features to implement, and determine how to gracefully resolve errors.<ref>{{cite books\|authors=Adolph, Steve et al.\|title=Patterns for effective use cases\|publisher=Addison-Wesley\|year=2002\|isbn=9780201721843\|page=2\|url=http://books.google.com/books?id=FGdXBs5uCxMC&pg=PA2}}</ref>		A '''use case''' in [[software engineering]] and [[systems engineering]] is a description of a potential series of interactions between a software [[Modular programming\|module]] and an external [[agent]], which lead the agent towards something useful.<ref>{{cite book\|author=Bittner, Kurt & Spence, Ian\|title=Use case modeling\|publisher=Addison-Wesley\|year=2003\|isbn=9780201709131\|page=xvi\|url=http://books.google.com/books?id=bD0VNcVjIp0C&pg=PR16}}</ref> Use case diagrams are made up of actors and actions, also known as users and uses, which make up the system. <ref>[http://www.aspnetbook.com/basics/app_design_application_design.php Use Case diagram] What is an Application Design - ASPNET Book 2010</ref> Uses cases are used as a [[software modeling]] technique that helps developers determine which features to implement, and determine how to gracefully resolve errors.<ref>{{cite books\|authors=Adolph, Steve et al.\|title=Patterns for effective use cases\|publisher=Addison-Wesley\|year=2002\|isbn=9780201721843\|page=2\|url=http://books.google.com/books?id=FGdXBs5uCxMC&pg=PA2}}</ref>

	Within systems engineering, use cases are used at a higher level than within software engineering, often representing missions or [[Project stakeholder\|stakeholder]] goals. The detailed requirements may then be captured in [[SysML]] requirement diagrams or similar mechanisms.		Within systems engineering, use cases are used at a higher level than within software engineering, often representing missions or [[Project stakeholder\|stakeholder]] goals. The detailed requirements may then be captured in [[SysML]] requirement diagrams or similar mechanisms.