CPSC 3720 - DAY 6
JANUARY 25, 2017

================================================================================

CONTENTS OF A USE CASE
----------------------

	.Title
	.Goal Level
	.Main Success Scenario
	.Extensions
	.Primary Actor
		.Has the goal the use case is trying to solve
	.Secondary Actor
		.Also involved in the use case
		.Not driving the goal
		.System may communicate with them
	.Pre-condition, guarantee, trigger

GOAL LEVEL
----------

	.System Use Case
		.Interaction with the software.
		.How the customer would use the software.
	.Business Use Case.
		.How a business responds to a customer or event.
		.Ex. how a business responds to changing prices.
	.Sea Level
		.Interaction between the system and a primary actor
		.Delivers something to the actor
		.Most of your use cases
	.Fish level
		.Use cases that only exist because they are included in Sea
		level use cases
		.Ex. placing a hold on tickets when customer is buying a
		ticket while the sytem is processing.
	.Kite level
		.Shows how sea level use cases fit into wider business
		interactions.
		.Business use cases.
	
IDENTIFYING ACTORS
------------------

	.Actors are external entities that interact with the system
	.Actors can be human or another system.
	.Actors are role abstractions
		.They do not necessarily map to one person
		.The same person could fill different roles at different times
		.So don't use just someones names Ex jim from accounting.
	.Actors access different functionality of the system.
	.To identify actors, you need to identify the system boundry
		.Actors are external to the sytem.
		.Objects are internal.
		.Is this something i'm creating???
	.Most actors already exist before the system does.
	.Which user groups are supported by the system to perform their work?
	.Which user groups execute the system's main functions?
	.Which user groups perform secondary functions such as maintenance
	and administration?
	.With what external hardware or software sytems will the system
	interact?
		.Actors do not have to be people!
		.It is OK to have no primary actors if it is automatically
		completed by the system.
SCENERIOS
---------

	.A scenario what people do and experience as they use the sytem.
	.A scenario is from the viewpoint of an actor.
	.One path through a use case is a scenario
		.A use case includes multiple scenarios with extensions.
		.A scenario is an instance of a use case.
	.What are the tasks that the actor wants the system to perform?
	.What information does the actor access?  Who creates the data?
	Can it be modified or removed? By whom?
	.What external changes does the actor need to inform the system about?
	How often? When?
	.What events does the system need to inform the actor about?
		.Does it need to send daily reports?

MAIN SUCCESS SCENARIO
---------------------

	.List of ordered steps
		.Element of the interaction between actor and the system.
		.Simple statement
			.Who is carrying out the action
	.Each step shows intent, not mechanics of what the actor does
	.Does not describe the user interface
		.Ex DO NOT say the customer clicks a button to submit an order
		.Do say the customer submits an order.
		.Do not talk about the GUI
	.A step can be an entire other use case
		.Denote by underlining
		.One use case includes another. 

EXTENSIONS
----------

	.Variations from the Main success scenario
	.Can still be a success
		.Actor still achieves the goal
		.Extra step required
	.Can be a failure scenario.
	.Branch out at a specific step based on a specific condition
		.Extension is named after that condition
	.Includes where to return to the main success scenerios


	Example:
		MSS:
		System verifies customer is logged in when placed their order
		Extension: if the customer is NOT logged in, show login page,
		redirect back to main success scenario

		Make sure to include where to return back to MSS


PRECONDITION, GUARANTEE, TRIGGER
--------------------------------

	.Precondition (similar to requires clause)
		.What system should ensure is true beginning a use case
		.Tells developer what conditions to check for
	.Guarantee (similar to ensures clause)
		.What the system will ensure at the end of the use case.
		.Success guarantee
			.Hold after a successful scenario
		.Minimal guarantee
			.True after all scenarios
			.Ex. user does not have any items that they do not want
			in their cart when purchasing.
	.Trigger
		.Event that gets the use case started