If you really want to stick with Use Cases you'd write one from the System's functional viewpoint rather than that of the end-user. Maybe something like this:
- The systems starts up and zeros out its total and count variables.
- The system receives a number.
- It adds the number to the total and increments the count.
- Steps 2 & 3 repeat until the system is told to stop.
- When told to stop the system divides the total by the count and returns the result.
Have a read of Alastair Cockburns excellent book "Writing Effective Use Cases". It explains about having different levels of Use Case. Your initial example would be considered a User Goal (or Blue) Use Case whilst the steps above would be part of a Sub-Function (or Indigo) Use Case (it's so simple it might even be classed as a Black Use Case and just merged into its parent).
As other people are sure to say, sometimes a Use Case isn't the best way to describe an algorithm and you should fall back to good old flowcharts, state charts, sequence diagrams or whatever. These tools are there for your benefit - don't be constrained by forcing a particular method when it doesn't work for you.
EDIT
@devoured elysium: In response to your comments I've added a few more notes below:
When you're identifying domain objects sometimes you need to think about unwritten objects. It all depends on how it has been written. So, in the example you gave, maybe the "System" is a "Calculator", the variable being used to add the numbers up is an "Accumulator", maybe there's a "Queue" that receives the number. Could be that the number itself is an object of a type "Number" if that can have distinct behaviour like range validation, or input syntax checking. Is there a "Display" object that you need to consider?
It depends on what you consider to be in the bounded context you're dealing with. Maybe, from the User's perspective, there is one context that just deals with "Calculators", but the System's viewpoint there's another that speaks to a lower lever context with "Accumulators", "ALUs", "Bits", "Words", "Registers", "Clocks", "Latches", etc. The further you go down in the Use Case heirarchy by asking "How?" the more technical the language is going to become. You need to decide which are Domain Objects and which are just Implementation Objects and that depends very much on the type of thing you're trying to describe and build (and, to a great extent, who your audience is - ubiquitous langauge and all that!). Conversely, you can go up the stack by asking "Why?" the function is being performed.
The primary actor of a Sub-Function Use Case is generally the same actor as that of the higher-level use case that calls it. For some "technical" Use Cases though, the primary actor will be a system component/subsytem. For example, a system message logging Use Case might have the calling subsystem as the primary actor - i.e. the entity that had the will/need to initiate the action, rather than the actor that was performing the task that caused that subsytem to need to log something.
In this example, where the algorithm is so simple, I'd probably just Embed it into the main Use Case. However, if it was being used in multiple other higher-level Use Cases I'd make it Standalone so I could include it from the other documents. Just a functional decomposition approach.
There are no hard-and-fast rules with this. It's a style of working that you'll evolve over time. As others have said, make sure that you're familiar with the other forms of diagrams so that you can pick the right tool for the job. Remember that although a picture may be worth a thousand words sometimes you actually need those words too so don't just rely on diagrams.