Los casos de uso no son "funciones"

Volvemos a situarnos a ras de tierra, para comentar un tema que me parece importante en los inicios del diseño con UML. Los casos de uso son una buena herramienta para que el cliente sea capaz de ver representado los requerimientos que nos pide. Pero al principio es fácil usarlos mál. Para mi, fue muy ilustrativo el artículo: Why usecases are not functions
El artículo destaca el concepto equivocado que se suele tener de los casos de uso: un cso de uso por cada acción del usuario. Pero no es así.

I like to regard a use case as a story about some way of using a system to do something useful.

Si una acción del usuario debe realizarse en varios pasos, debemos tener en cuenta cual es el objetivo del usuario, y convertir en un caso de uso aquella que sea útil y de un valor medible al usuario. Debemos tener en cuenta que no existe orden en los casos de uso, y que romper estos en miles de subcasos nos creará mayor complejidad para la fase del diseño en la que nos encontramos.
Debemos pensar en los actores del sistema y en qué es lo que realmente esperan obtener del sistema. Seguramente no esperan poder añadir algo al carrito de la compra, o borrarlo, o dar los datos de pago. Lo que realmente esperan es poder hacer un pedido de compra. Así, en global. Los refinamientos deberán venir después.
Los casos de uso no deben representar la explosión de las funcionalidades que nos va a permitir el sistema, si no que deben ayudarnos a centrarnos en qué es realmente lo que quiere el cliente.