Entradas etiquetadas como requerimiento

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.

Anuncios

, , , , , , , , , , ,

2 comentarios

Casos de Uso: Flujos de Eventos

Un caso de uso es un escenario de interacción entre el sistema y un ente externo; es decir: es la descripción de una funcionalidad del sistema, visto desde el punto de vista de un ente externo que demanda dicha funcionalidad.

Al ente externo le llamamos actor por cuanto un caso de uso puede ser visto también como un guión, que a la manera de los guiones de una obra de teatro, dice paso a paso lo que el actor ha de hacer.

Es mucho lo que podemos decir de un caso de uso: nombre, descripción, pre condiciones, etc. Sin embargo, el aspecto más interesante de un caso de uso luego de la descripción del mismo es sin duda el flujo de eventos.

Al flujo de eventos lo podemos relacionar con un dialogo. Línea a línea, el flujo de eventos indica quien habla y qué dice. La secuencia se suele iniciar con algo dicho por el actor, y se continua intercalando sucesivamente lo hecho por el sistema con lo dicho por el actor. A cada una de estas líneas o indicaciones, le podemos llamar paso.

Un buen flujo de eventos recoge con detalle la identidad de quien realiza el paso, expresando sin ambigüedad la acción realizada. Es decir, que un buen paso ha de ser siempre una oración con sentido completo, escrita en voz activa, iniciando con el nombre del actor o bien del sistema que realiza la acción e indicando exhaustivamente los elementos de información que se intercambian.

Dichas oraciones con sentido completo, sin ambigüedad y demás características ya mencionadas, no son difíciles de redactar. Son de hecho la forma más directa de decir lo que hay que decir. Y es que a la hora de redactar un flujo de eventos debemos evitar recurrir a formas de redacción en prosa típicas de nuestros textos comunes. No vale sustituir el nombre del actor por un pronombre o demostrativo que le haga referencia. A la larga, dicha omisión del nombre del actor va a ser una fuente de ambigüedad y nos puede traer problemas.

Si bien para quienes acostumbran a redactar con estilo, estas normas para los flujos de eventos pueden sonar extrañas, son normas muy comunes para cuando queremos redactar documentos de requisitos. Básicamente estamos aplicando aquí los mismos consejos que se dan para redactar bien un requisito tradicional, del estilo “el sistema debe…” por lo que en Internet abundan los detalles sobre este particular.

Finalmente, la prosa tiene su refugio en la descripción breve de un caso de uso; y dado que es esta descripción breve la parte más importante del caso de uso, podemos decir que a la final todos vamos a poder estar contentos. Quienes quieren una redacción con estilo van a encontrar lo que buscan en la descripción breve y quienes necesitan los detalles operativos del caso de uso lo van a encontrar en los pasos del flujo de eventos.

, , , , , , , , ,

5 comentarios

Visión del Sistema

Anteriormente habíamos definido a la visión, como la capacidad de prever los detalles de un sistema o proceso desde antes del inicio del mismo.

Dicha capacidad depende de la experiencia y naturaleza de cada quien, por lo que no nos debe sorprender que cada persona relacionada con el proyecto pueda tener una visión enteramente diferente sobre el mismo.

Probablemente quienes tengan formación en Administración de Empresas, tendrán una visión operativa sobre el proyecto, preocupándose por temas de presupuesto y gestión contable.

Quizás, aquellos que tengan una formación en el área de informática y sistemas, tenderán a verlo todo como una aplicación de base de datos con un determino requisito de interfaz de usuario y generación de reportes.

También es probable, que los usuarios del futuro sistema se preocupen por la facilidad de uso y por la conveniencia que el nuevo desarrollo les brindara en sus actividades diarias.

Estas y todas las demás visiones del sistema son correctas. Claramente son diferentes, pero son todas ciertas y correctas al mismo tiempo, ya que el sistema a desarrollar debe responder a las necesidades y requisitos de cada uno de sus usuarios y grupos de decisión.

Es de vital importancia que nuestro proceso de levantamiento de requisitos incluya la captura de estas visiones particulares. A partir de estas opiniones es que se dará forma a los requisitos del sistema y en definitiva, al sistema en si.

Notemos que en este grupo de visiones debemos incluir la nuestra. Nosotros, que somos quienes guiamos el proceso y ejecutamos el desarrollo de lo solicitado, tenemos un visión sobre lo que se va a hacer, y es una opinión tan valida e interesante como la de aquel que ha firmado la orden de compra del proyecto.

Todas estas visiones deben, si me permiten recapitular, ser recogidas en un documento, al que para no pecar de originales, llamaremos Visión del Sistema.

Este es uno de los artefactos claves del Proceso Unificado de Desarrollo (UP), y una vez que le tengamos confianza y le conozcamos mejor le llamaremos simplemente Visión.

El documento de Visión no se queda ahí. Enumerar los puntos de vista de los grupos de decisión es en si algo muy importante, pero es que hay espacio para ejecutar algo mucho más extenso. Desarrollaremos como parte del documento, la seguidilla de los siguientes puntos:

  • Enumeración de los Grupos de Decisión. Identificando claramente quien es el representante de cada quien y cual es el rol o misión que este asumirá dentro del proyecto.

  • Declaración de la visión de cada Grupo de Decisión identificado, incluyéndonos a nosotros mismos como desarrolladores del sistema.

  • Enunciado de los problemas actuales y de las oportunidades que se perciben como posibles a la luz de lo prometido por el proyecto.

  • Elaboración de un listado de macro-características que atacan a los problemas observados.

  • Elaboración de un listado de características individuales que refinan lo dicho en las macro-características.

  • Identificación de los requisitos no funcionales más importantes: tales como consideraciones sobre el entorno de explotación, documentación requerida o ideas sobre el impacto ambiental y social del proyecto.

Considerando que este documento es una plantilla derivada de documento del proceso, veremos que ya tenemos muchos puntos que organizar en alguna forma para generar un documento con sentido. Procuremos utilizar siempre que nos sea posible plantillas profesionalmente desarrolladas como punto de partida de las nuestras. Seguramente podemos hacer un gran trabajo por nosotros mismos, pero es mucho mejor si nos permitimos el tomar provecho de la experiencia acumulada por toda la industria de tecnología de la información.

Un ejemplo de plantilla para documento de visión puede ser encontrada en aquí.

Nos estaremos viendo.

, , , , , , , ,

6 comentarios