Use Cases - Revision history

Suhridk: /* Scenario */

2011-11-15T11:39:40Z

Scenario

2011-11-15T11:18:48Z

Intro

2011-11-06T17:16:59Z

Structuring Use Cases

2011-11-06T16:57:39Z

Scenario

2011-11-06T16:49:10Z

Scenario

2011-11-06T12:50:10Z

Intro

2011-11-06T12:46:09Z

2011-10-31T19:43:07Z

Scenario

2011-10-31T19:41:06Z

Structuring Use Cases

2011-10-31T19:36:59Z

Scenario

@@ Line 32: / Line 32: @@
 * The scenarios '''must''' be kept free of design assumptions.
 * A use case is therefore is a set of scenarios tied together by a '''common''' user goal.
 = Structuring Use Cases =

@@ Line 9: / Line 9: @@
 ** e.g. deciding which use cases to include in the current release.
 * Use cases can be used to '''capture''' the systems ''functional'' requirements.
 = Actor =

@@ Line 41: / Line 41: @@
 * The main use case "calls" the inclusion use case.
 * For e.g. use case for "Edit Document" - might have a step called "Modifies Text" which might be a use case by itself.
 == Extension ==
 * Sort of an interruption to to the Main use case.
 * For e.g. if the main use case is "Check Balance" and if the balance > 5000$, the "Enrol as privilege customer" use case can kick in.
 * Note that the main use case has '''no control''' over the special use case.

@@ Line 19: / Line 19: @@
 * A scenario is a description of a '''sequence of actions''' that is a way of achieving a goal.
 * The main success scenario is the usual/main/straightforward way of achieving the goal.
-* All scenarios have
+* All scenarios have (Note: UML does not specify any standard, this is the York recommendation)
 ** A precondition : required condition before starting.
 ** Interaction steps

← Older revision		Revision as of 16:49, 6 November 2011
Line 32:		Line 32:

	* The scenarios '''must''' be kept free of design assumptions.		* The scenarios '''must''' be kept free of design assumptions.
		+	* A use case is therefore is a set of scenarios tied together by a '''common''' user goal.

	= Structuring Use Cases =		= Structuring Use Cases =

@@ Line 1: / Line 1: @@
 = Intro =
 * Use cases can be used to '''capture''' the systems ''functional'' requirements.
 * Defined the systems functional acceptance tests.
 = Actor =

← Older revision		Revision as of 12:46, 6 November 2011
Line 49:		Line 49:
	* Not meant to record details of use cases - for that text is best, but rather as a sort of visual guide to the various use cases in the system.		* Not meant to record details of use cases - for that text is best, but rather as a sort of visual guide to the various use cases in the system.

−	[[Category:REQE]]	+	[[Category:REQE]] [[Category:OODE]]

@@ Line 26: / Line 26: @@
 ** Alternative Scenario: A different way of achieving success (the goal)
 ** Exception Scenario: Something that can go wrong - and can lead to a different postcondition.
 = Structuring Use Cases =

← Older revision		Revision as of 19:41, 31 October 2011
Line 41:		Line 41:
	* Note that the main use case has '''no control''' over the special use case.		* Note that the main use case has '''no control''' over the special use case.

		+	= Use Case Diagrams =

		+	* Is a '''summary''' of the functionality of the '''whole system'''.
		+	* Gives an overview of the relationships between ''all'' the actors and ''all'' the use cases.
		+	* Not meant to record details of use cases - for that text is best, but rather as a sort of visual guide to the various use cases in the system.

	[[Category:REQE]]		[[Category:REQE]]