Todo requisito debe ser preciso y legible

La especificación de un sistema es un trabajo retador. En él participan no solo los desarrolladores de aplicaciones, sino también los clientes. Esto significa que la especificación de requisitos, ya sea como casos de uso o como declaraciones tradicionales tipo “el sistema debe…” ha de ser entendida a la vez, por lo clientes y por los desarrolladores. Dicho en otras palabras: la especificación contiene detalles técnicos que los clientes luchan por entender, a la vez que incluye información sobre el negocio que es nueva y potencialmente confusa para los desarrolladores.

Esta situación nos obliga a luchar por dos atributos básicos en todo nuestro sistema de requisitos: la claridad y la precisión.

Precisión de un requisito. Un requisito es preciso cuando indica sin ambigüedad lo que se desea especificar. Debe ir directo al punto y evitar todo adorno en el lenguaje. Debe documentar solo un aspecto del sistema y lo debe de hacer en forma exacta.

Y también

Claridad o legibilidad de un requisito. Un requisito es legible cuando el lenguaje en el que esta escrito es fácil de entender, tanto por los clientes como los analistas. La legibilidad se extiende no solo a la especificación escrita, sino también a los formalismos gráficos como los diagramas de casos de uso.

Es curioso observar que en los cursos universitarios sobre el tema, los profesores tengan la presión de explicar métodos y técnicas avanzadas, como las relaciones de extensión e inclusión de casos de uso, forzando al estudiante a adoptar estar técnicas en forma demasiado temprana. Esto causa una deformación profesional en el estudiante, quien sale del curso con la creencia que es mejor una especificación sofisticada que haga uso de todo lo visto en el curso, en lugar de una aproximación más informal y relajada que puede en verdad ser entendida por el cliente.

El lugar correcto para la extensión y la inclusión, así como para todas las técnicas de modelado de requisitos más sofisticadas, es en aquellos dominios de aplicación donde los requisitos reales sean muy complejos. Es decir por lo tanto, que en la práctica el analista ha de hacer esfuerzos por mantenerse sencillo, normalmente no vale la pena la complejidad del modelo de requisitos.

También es de hacer notar, que en mi experiencia la mayoría de los clientes intentan hacer otro tanto. Ellos suelen expresar lo que necesitan en la forma más directa que tienen disponible, sin embargo dado que los clientes son a su vez profesionales en un área especifica, la forma correcta en la ellos se expresan suponen tensión a los desarrolladores, quienes deben luchar por desarrollar un vocabulario común con el cliente para poder comprender sin errores lo que este pide.

En conclusión: lo sencillo se entiende más y la especificación de un sistema ha de entenderse bien. Cuan sofisticado hagamos nuestro modelo de casos de uso o nuestro documento de especificación, no es ni de lejos lo que en verdad importa. Es mucho mejor un caso de uso sencillo pero que captura valor de negocio, que uno sofisticado que haga un uso abundante de las técnicas más esotericas de modelado.

, , , , , , , , , , ,

  1. #1 por wigahluk el 29-09-08 - 3:03 am

    Iván,

    Justo acabo de comentar respondiéndote que una de las cosas que hemos tomado de RUP/UP son los casos de uso, sobre todo los detallados. Veo que debí leer esta nota antes de contestar.

    En efecto, el mejor modelado es aquel que expresa sus requerimientos de la forma más sencilla que sea posible. Los buenos modelos son ejemplos de abstracción en la medida en que logran reflejar la cultura de dominio en palabras claras, explicitas y sin ambigüedades.

    Incluso un caso de uso detallado debe cumplir con esta característica. Llenar un caso de uso de aplicaciones de receta escolar es un error en cualquier caso, cuando me refería a una receta, no me refería a aplicar todo lo que nos enseñan en la escuela, sino a aplicar un método de descubrimiento de requerimientos simple pero completo. La abstracción, como también menciono, es algo difícil de alcanzar y los desarrolladores poco experimentados suelen tener problemas en esta parte.

    Respecto al lenguaje común, como también comentas, lo importante es incorporar el lenguaje del cliente al lenguaje del proyecto. Soy un creyente del desarrollo orientado a dominio (DDD) y estoy convencido de que el lenguaje del dominio, aquel que usan los usuarios, es el mismo que debe reflejarse en el desarrollo del sistema. La parte técnica procuro ahorrárselas, no es que crea que el cliente no es capaz de entenderlo, sino que a veces no le dan mucha importancia y es fácil perderlos. Sin embargo, a veces es importante que ellos entiendan algún tecnicismo y no hay que tenerle miedo tampoco.

    Un saludo

  2. #2 por Iván Garcerant el 29-09-08 - 5:02 pm

    Saludos!

    Creo que estamos nuevamente en la misma pista. Comprendo tu idea de plantilla para casos de uso como un medio para mejorar la calidad de la especificación así como incrementar la productividad del analista. Lo único que creo prudente decir aquí es que a diferencia de otras plantillas, las de casos de uso no deben ser únicas, en un proyecto dado pueden y de hecho recomiendo, que coexistan diversas plantillas de casos de uso.

    Ahora que si me permites la publicidad, mi ejemplo de casos de uso es mi post más popular, lo cual interpreto como una señal de lo importante que son los casos de uso en la profesión. Todo lo relacionado con ellos es muy buscado por los estudiantes e incluso, a manera de referencia, por profesionales.

    Así que si tienes un tiempo, déjate caer por el post de Ejemplo de casos de uso. No es perfecto, pero creo que es claro.

    Estamos en contacto.

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: