Requerimientos versus casos de uso

Lo que voy a comentar puede no ser una novedad, pero es importante no perderlo de vista.
Un caso de uso con alcance sistema es una descripción de un conjunto de requerimientos organizados y pensados para ayudar a cumplir las metas de un actor. Si necesitas especificar requerimientos te sirven los casos de uso de alcance sistema.

Las definiciones enunciadas son parciales y mejorables, aunque espero te ayuden a entender hacia donde vamos. Como se dice por ahí: "los casos de uso son requerimientos y esencialmente de requerimientos funcionales"

Hoy en día no dudo en utilizar casos de uso como un método para especificar requerimientos y luego ir desarrollándolos (o completándolos).

Los casos de uso vinieron a cubrir ciertas necesidades de especificación y trabajo con los requerimientos, abandonando o dejando de lado la lista de requerimientos; pero la lista de requerimientos no ha muerto.

Hoy los casos de uso se han transformado en los favoritos de los analistas en sistemas de información, teniendo sobradas razones para serlo, pero la lista de requerimientos se sostendrá por mucho tiempo.

Los casos más significativos en donde la lista de reqeurimientos suele ser mejor especificación que los casos de uso se ven en:
no hay workflow, cuando los procesos no pueden precisar secuencias, cuando se trata de una serie de sub-características que debe poseer una aplicación, o cuando los requerimientos no funcionales son la razón de la aplicación, entonces allí la lista de requerimientos domina el territorio.

Pero atención no tienes que decidirte por una, puedes elegir cual usar según el momento, y por supuesto existirán variantes.

Ejemplo 1
Suponga que un actor, el recepcionista de una organización, en su trabajo diario debe escribir gran cantidad de texto sobre campos VARCHAR. El recepcionista en pos de mejorar su trabajo y mejorar el resultado solicita poder copiar y pegar texto, agregar negritas, itálicas, subrayados y cambios de tamaño.
Este tipo de requerimientos  o características es  mejor especificarlos en listas de requerimientos. Intentar organizar estos requerimientos bajo la imagen de un caso de uso no sirve.

Ejemplo 2
Un líder de proyecto indica que desea crear un proyecto y,  para ello define las tareas, luego los recursos, asigna recursos a tareas, las tareas a recursos, borra tareas, cambia recursos, indica costos, a veces decide calcularlos, otras no.
Este caso presenta otra complejidad. Aquí armar un caso de uso  presenta múltiples escenarios y se torna muy engorroso plantearlos a todos. Es más práctico una lista de requerimientos.

Debo reconocer que prefiero los casos de uso a la lista de requerimientos, pero no siempre es aplicable.
Es importante decidir cuando conviene una cosa y cuando otra.