USE CASES

Summary and exploration:

Use cases are created and used to explain systems both in context of their own interaction, but also in their interaction with the external systems and environment. They should be started with a strong verb, named aptly, and describe a set of scenarios and steps inside of a system. The process is incremental, identifying each actor and process or trigger.

Use cases can be found in formal templates or in less formal environments that usually involve an institutional development (or company/organization specific format). The use case, proper, explains this interaction of systems and environments through a series of diagrams and language definitions which articulate the mission, structure, and dependencies of a system or set of systems. The details include scope, actors, preconditions, postconditions, scenarios, and products. The use case should have a specific order, and should be arrange in an appealing way that describes the interaction of the systems and stakeholders/actors.

Use cases can be found in various levels of complexity or difficulty, although the design scope itself is well developed, after a fairly extensive evolution. Use case diagrams use a system of icons and descriptions which can be interpreted across organizations- reducing the need for re-word explanations, re-trainings, and new evaluations of templates.
Source = Dedeke, A., & Lieberman, B. (2006). Qualifying Use Case Diagram Associations. IEEE Computer Society, 1(1), 1-29

Source = Cockburn, A. (2002). Writing Effective Use Cases. Technical Communication, 49(2), 240-242.

Source = http://www.csci.csusb.edu/dick/samples/usecases.html

Source = http://tynerblain.com/blog/2007/04/09/sample-use-case-example/

Individuals must refine their requirements by starting with the scope and working towards processes and solutions towards the end product.

Source = http://www.wirfs-brock.com/PDFs/Art_of_Writing_Use_Cases.pdf

Use cases add value by explaining the behavior and providing a list of benchmarks and requirements.

Source = http://www.usability.gov/how-to-and-tools/methods/use-cases.html

Use Cases vs Task descriptions:

It is important to differentiate task descriptions and use cases. Task descriptions are quite useful for the actors, and even policy makers, but does not encompass the entire system interaction. Task descriptions also do not allow for flexibility or feedback to improve systems or tasks. However, the use case ignores problems or tasks with no solution or system in place to solve the issue. The figure below explains the difference cogently:
Source = Lauesen, S. (2001). Task descriptions versus use cases. Requirements Engineering, 17(1), 3-18.

It is also notable that task descriptions and use cases have entirely different amounts of resource allocations:

Source = Lauesen, S. (2001). Task descriptions versus use cases. Requirements Engineering, 17(1), 3-18.

Therefore, it's imperative to differentiate which is required early, and plan appropriately. There is a common solution for specific usage models in use case development.

UML Use Case

A “UML” use case is then a model for specific usage that enables identification of complete requirements and the analysis of a collection of scenarios to understand the entire system, its actors and its subsystems.

Source = http://www.uml-diagrams.org/use-case-diagrams-examples.html

Using the use case model, an analyst can better combine the needs of users and the behavior of the system during its operation. Additionally, use cases can identify testing scenarios and dependencies that may not be immediately apparent without the diagramming (use cases and testing.pdf). Unfortunately, in many businesses, use cases are still being developed in office products like MS Word.

Source = Dey, Pradip Peter, & Et al. (2012). Augmenting Use Case View for Modeling. World Academy of Science, Engineering and Technology, 72(1), 5.

There are also tools to model your UML use case, such as Microsoft's guidelines here:http://msdn.microsoft.com/en-us/library/dd409432(v=vs.100).aspx

Source = http://msdn.microsoft.com/en-us/library/dd409432(v=vs.100).aspx

Concept

To begin the use case, the unique pieces of the project must first be resolved.In doing so, their roles, responsibilities, and resolutions can also be described.

Actors are external entities that interact with the system User task is a work unit which is meaningful to the system Use case describes a sequence of interactions with the system to achieve a goal System services describe the input and out of individual system functions An illustration from can be found below:

Source = Dutiot, A., & Paech, B. (n.d.). Rationale-Based use Case Specifications. Requirements Engineering, 7(1), 3-19.

It is important that these disparate parts do not get "entangled" in the process of integrating the various parts of what initially appears to be a well built use case. Source = D'Amorim, F., & Borba, P. (2012). Modularity of Use Case Implementations. The Journal of Systems and Software, 85(1), 1012-1027.

Definitions and Questions

A glossary should be included with an entry that defines an important concept relevant to the user tasks or the system services (use case specifications). A decision is the resolution of set of dependencies inside of the system, either internally or in its relationship with the external environment (arguably stills a system in a system, but perhaps not in the scope of the particular use case). It’s important to also justify the project, the specifications, and the activities. It is also common practice request clarifications on the specifications and challenges those requirements (use case specifications.pdf). Where a challenge is presented, (use case specifications.pdf) provides some actions to resolve the challenge.

Source = Dutiot, A., & Paech, B. (n.d.). Rationale-Based use Case Specifications. Requirements Engineering, 7(1), 3-19.

Testing

The testing of the system in the early stages is invaluable, as it reduces later expenses and robust reworking of the design itself. System testing verifies performance and functionality before extensive production tasks are completed (use cases and testing.pdf). Testing of the system also allows for increased requirements measurement and verification that existing requirements are adequately performing the desired goal (use cases and testing.pdf). Abstract modeling of this interaction with use cases and testing has been described (use cases and testing.pdf): And follows the following approach (approach is misspelled in the article):

Source = Mahmood, A., & Et. Al. (2013). An Approach to generate test goals from Use Case scenarios. Information Technology Journal, 12(8), 1600-1606.

Approach and recommendations

Source = Mahmood, A., & Et. Al. (2013). An Approach to generate test goals from Use Case scenarios. Information Technology Journal, 12(8), 1600-1606.

Each use case needs to be evaluated individually for the emphasis of this path. However, entering into testing at the analysis level of the use case provides both appropriateness of edits to the system, and savings in both time and cost to the overall project (use cases and testing.pdf). Once testing and submission of logical challenges has been resolved, the dependencies and boundary classes handle the next step.

Source = https://community.ja.net/library/janet-services-documentation/example-use-cases

Although there are no formal next steps, the interaction between the actors and the system or environment determine which extension of the use case should be resolved or triggered. It is best to design a use case scenario when the system is transform, transaction, device or web server centered(use case patterns.pdf). It is difficult to describe a use case where the system is not specified algorithmically (use case patterns.pdf).

Source = http://www.slideshare.net/MaoelanaNoermoehammad/use-casediagrams-9607334

It is also important that the actor or system must trigger the signal to create and complete the system action: This aforementioned interaction can be described visually by (patterns for developing Use cases.pdf):

Source = Diaz, I., Losavio, F., Matteo, A., & Pastor, O. (2004). A specification patter for use cases. Information and management, 41(1), 961-975.

The stakeholders, including those actor, developers, and maintainers of the system need to be engaged in a manner not unlike CRISP-DM to understand each system and user are represented in the basic requirements of the use case.

It is also important to recognize that "Your use case and requirements are only as good as the the individuals and communicators deriving them."

Source = http://www.gatherspace.com/static/use_case_example.html

However, new approaches emerge. Please continue on to "mis-use cases" tab, or back to the home page here:

Misuse Cases

Home