In any system, the most important thing is whether it's doing what it's supposed to do for all of the use cases that it's supposed to support. Code has to be written for each of those use cases, and each use case corresponds to one or more business processes or rules, so it's only logical that each of those use cases needs to be defined and documented to whatever extent is appropriate for the development process. As with the logical and physical architecture, it's possible to execute those definitions as either text or some sort of diagram, and those approaches have the same advantages and drawbacks that were noted before.

The Unified Modeling Language (UML) provides a high-level diagramming standard for use cases, useful mostly for capturing the relationship between specific types of users (actors, in UML's terminology) and the processes that they are expected to interact with. That's a good start, and may even be sufficient all by itself if the process itself is very simple, already extensively documented, or known across the development team. The use case diagram for the Refuel-Tracker application concept that was discussed earlier in Use Cases section is, so far, very simple, and harks back to the system goals that were established for it in the Chapter 2, The Software Development Life Cycle. This time, though, we'll attach some names to them for reference in the diagram:

• Refuel: Various users can log refueling's, providing the current odometer reading and the quantity of fuel involved:
  • Delivery drivers (at local fuel-stations)
  • Fleet maintenance staff (at the main office, where there is a company fuel station)
• Maintenance Alert: Fleet maintenance staff will be alerted when a truck's calculated fuel efficiency drops to lower than 90% of its average, so that the truck can be scheduled for an examination.

• Route Review Alert: Office staff will also be alerted when a truck's calculated fuel efficiency drops to lower than 90% of its average, so that the truck's delivery rounds can be examined.

Those three use cases are simple to diagram, if that's the preferred documentation. The following list of processes is also a viable option. In some ways it's actually better than a standard diagram, since it provides some business rules of the system that a standard use case diagram doesn't capture:

Even if the diagram were modified to include some of the missing information (what a refueling is, and what the rules around the two «trigger» items are), it still only tells part of the story: who is expected (or allowed) to use specific process functionality. The balances, the actual processes underneath the use cases, are still unknown, but need to be exposed so that code can be written around them to actually make them work. This also can be handled either as plain text of some sort, or through a diagram. Looking at the Refuel process that's been identified, it breaks down to something as follows:

• A Driver or Fleet Tech logs a refuel of a truck, providing:
  • The current odometer reading
  • The amount of fuel used to fill the truck
• Those values are stored (probably in an application database, though that may not be part of the actual requirements) with an association to the truck (how that gets specified has yet to be determined).

• The application calculates the fuel efficiency for the refueling: (current odometer reading minus previous odometer reading) ÷ quantity of fuel.
• If the efficiency is less than or equal to 90% of the most recent efficiency value for that truck, the Route Review alert is triggered .
• If the efficiency is less than or equal to 90% of at least half of the previous four efficiency values for that truck, the Maintenance alert is triggered.

Whether a diagram (such as the following flowchart) would add any value to the documentation will likely depend on the process being described, and on team or even personal preferences. These five steps, as a simple flowchart, are simple enough that going any further than a text description of them is probably not going to add any value, but more complex processes might benefit from a diagram: