Un buen caso de uso captura valor de negocio

Una de las principales dificultades a la hora de desarrollar un cuerpo de requisitos para un sistema es el hecho innegable de la diferencia de formación entre los profesionales del desarrollo de software y los clientes de estos.

En tanto los desarrolladores cuentan con experiencia en algoritmia, análisis o modelado, los clientes suelen tener formación en contabilidad, finanzas, construcción o quien sabe en qué. Esta diferencia se extrapola a los puntos de vista de cada lado de la mesa, por lo que a la hora de definir el sistema que se desea es inevitable que el desarrollador note vacíos o faltas en la especificación (puntos como: seguridad, gestión de datos y otros aspectos técnicos) a la vez que el cliente puede hacer mucho hincapié en aspectos que a primera vista y desde el punto de vista del desarrollador son menos urgentes o se explicaron ya con unas pocas palabras.

Un poco por lo anterior es la muy conocida queja contra los clientes “no saben lo que quieren” pero en verdad la queja es debida a un fallo en el análisis del profesional de computación: los clientes especifican lo que les preocupa y esto no es ni de lejos, una especificación completa para una aplicación.

Paradójico quizás, en el sentido en que es contrario a la intuición de algunos, pero es que los clientes deben ver que los sistemas que solicitan responden a sus necesidades y aspectos técnicos que son del conocimiento del desarrollador los ven como parte de la solución técnica propuesta por este; lo que el cliente especifica es de valor para él y lo que no especifica es el margen de maniobra que se usa en la busqueda de la mejor solución técnica posible.

De todo lo anterior se desprende una regla básica para obtener un buen requisito y de ahí, un buen caso de uso: todo caso de uso ha de capturar valor de negocio. No hacemos casos de uso para especificar el comportamiento técnico del sistema, por lo que no tenemos casos de uso para indicar el ingreso al sistema o la generación de copias de seguridad. Si tales cosas no son del interés directo del cliente lo mejor es dejarlas por fuera del modelo de casos de uso. En cambio, aspectos quizás irrelevantes como la generación de un reporte o la aprobación de un supervisor a un paso del flujo de trabajo de la aplicación ha de representarse como caso de uso ya que es de interés para el cliente y le ayuda a decir lo que quiere decir sobre el sistema.

, , , , , ,

  1. Deja un comentario

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: