When writing the flow consider actual interactions with the system. Think in terms of what information, commands or events are going in and out of the system and describe each interaction in a single numbered sentence. Don't combine sentences with commas or 'ands'. This implies that interactions have been combined. If necessary, create a prototype of the screen or user interface in order to ensure that the text of the use case matches actual interactions with the system. This does not mean 'designing' the user interface as the prototype is only a suggestion, unless the detailed design of the user interface is important to the user, in which case it is a requirement and not just design.

Follow the following guidelines:

	Initially include only actual interactions across the system boundary
	Try to make every interaction part of a 'thread' that will be implemented in the system. Remember that the system is event driven and so everything it does will be a response to an incoming interaction. All interactions that produce outputs from the system must relate to interaction going in. Think in terms of pairs, as per the graphic, though there may be more than one outgoing interaction for each incoming interaction.
	Internal functionality that does not cross the system boundary may be included if it is essential to specifying what the system should do. E.g. the system should save a record of the order. However, when specifying internal functionality use the fewest number of words possible. If it requires more than one sentence then this algorithm should be specified in the System Analysis Model.

	Be consistent in terminology. If you use different words for the same thing then when you create a data model for the system there will be aliases. Use a Dictionary for the system to define each word in order to produce an unambiguous specification.
	Don't be tempted to include 'out of scope' interactions that do not cross the system boundary just to provide 'scope' for the developer. These belong in the business model only.