An alternative name for UserStories, used to slip them in under the RADAR.

An alternative name may be useful because:
	 :	'user' offends some people
	 :	'story' implies non-fact
	 :	the organization is considered more important than the user
	 :	'user story' lacks gravitas

This alternative name avoids the above problems, but at the expense of sounding pretentious.

Examples of generic EnterpriseScenarios are:

	 :	The customer gives us money and we give them stuff.
	 :	We give the customer stuff and they give us money.
	 :	The supplier gives us stuff and we give them money.
	 :	The shareholder gives us money and we give them money.

Examples of specific EnterpriseScenarios are:

	 :	Employees who are sick for more than 3 days go on DAP (Disability Absence Plan). They are paid their full pay for 190 working days, and then 70% pay up through 270 days. DAP dollars paid must be kept separate from regular pay dollars (for accounting purposes). ''(from UserStoryExamples)''

	 :	We have to submit a copy of our audited statutory accounts to Companies House within seven months of the end of our financial year, that is, by the end of July. ''This example indicates that EnterpriseScenarios are applicable to processes for which no computerization is required.''

A useful distinction could be maintained between EnterpriseScenarios, which embody FirstOrderRequirements, and UserStories, which embody SecondOrderRequirements.  A similar distinction exists between TheCustomer, for whom the system should be useful (because it meets their FirstOrderRequirements), and TheUser, who interacts with the software whether it is useful to them or not (the UserIsInTheSystem, though not the software).  TheUser''''''s, who may also be among TheCustomer''''''s, or TheProgrammer''''''s, or even TheRealCustomer''''''s, is the primary source of SecondOrderRequirements
----
See also BusinessStories or BusinessStory

CategoryRequirements