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.

Transformado requerimientos no verificables en verificables

Un cliente llama al teléfono temprano en la mañana del lunes y dice:

-- No te olvides que el "programa" debe tener una mayor seguridad.

Desafortunadamente colgó antes de poder reaccionar o re-preguntarle.
¿Qué habrá querido decir con mayor seguridad?

Cuando ocurre un caso como este, lo mejor es esperar, no adelantarse y reconocer que se debe investigar un poco más.

Pensemos:

• Restringir el acceso a la aplicación a usuarios autorizados.
• Establecer permisos y roles para el acceso a la funcionalidad.
• Encriptar los datos de la base de datos
• Establecer un control de accesos realizados por los usuarios

Adelantemos el tiempo, imaginemos e idealicemos que sucedió realmente:

Se le pregunta al cliente que quiso significar con mayor seguridad. El cliente comenta:

-- Durante años quise tener una aplicación, pero ahora tengo miedo que alguien entre por internet y me robe los datos.

Al comprender mejor, se entienden mejor los requerimientos. Se puede afirmar que mayor seguridad es: impedir el acceso por internet a los datos de la organización por personas no autorizadas.

Por supuesto y sin dudarlo esto debe quedar registrado en algún documento, más tarde se deberá volver sobre el requerimiento para asegurar su cumplimiento. Si es posible demostrar que no es posible acceder a los datos de la organización a través de internet, entonces el requerimientos será verificable.

Para determinar que se cumple con el requerimiento debe poder ser verificado. Dicho de otro modo, debe ser posible demostrar que existe y se ajusta a la especifificación. Un requerimiento no verificable trae problemas siempre.

Algunos ejemplos malos

1. La aplicación debe ser rápida. --> ¿qué es rápido?
2. Las interfaces de usuario deben ser fáciles.  --> ¿qué es fácil?
3. El código debe ser mantenible.--> ¿qués mantenible?

Ejemplos mejorados y verificables

1. Las respuestas de la aplicación deben ser menores a 3 segundos en el 80% de los casos en horario diurno. Nota: el horario abarca desde las 9:00 am y hasta las 4:00 pm
2. Las interfaces de usuario deben tener homogeneidad presentando los títulos, datos y acciones en las posiciones definidas en minuta 05/12/2014. Ver estándar versión 1.04 de IU.
3. El código usa una sólo instrucción por línea, las variables locales comienzan con el prefijo l_, las variables globales con el prefijo g_.

Facilidad de aprendizaje. Un aspecto de usabilidad

Uno de los requerimientos más populares es la usabilidad. 

Se define como el grado  en el cual un producto puede ser utilizado por sus usuarios para lograr metas con efectividad, eficiencia y produciendo una satisfacción en un determinado contexto de uso.

Fíjate que también podés encontrar utilizabilidad en alguna norma.

La usabilidad no es un requerimiento sino que se trata de una categoría de requerimientos no funcionales.
Entre otras definiciones podés encontrarlo como que es la capacidad de uso que tiene un producto. Decir que un producto debe ser usable no lo hace requerimiento, simplemente te pone en atención para que explores y descubras los requerimientos de usabilidad que son parámetro del cliente o usuarios o ambos.

Los requerimientos en general tienen muchos niveles de detalle y este tipo de requerimientos no es excepción.. No pensés en vos cuando pensás en usabilidad; pensá en tu prójimo.

Algunos autores dividen la usabilidad en sub-categorias o atributos. Y hablan del aprendizaje, facilidad para aprender una aplicación, etc.

Dar el lugar que corresponde a cada requerimiento. No seas fanático al momento de pensar en los requerimientos de usabilidad, pensalo fácil y sobre todo comunicalo fácil.

Para no irme por las ramas, les tiro una lista de cosas que me han sido útiles al momento de pensar en facilidad de uso; lista que fue armándose con los años.

• Elementos comunes en GUI
• Material auxiliar (guías, ayudas) para usuarios
• Usar buenas experiencias de otros sistemas de la organización cliente o proveedora
• cercanía con estándares o tendencias firmes
• homogeneidad de GUI
• Identificabilidad de UI: ¿Puede el usuario, por sus propios, medios identificar que está viendo y que está haciendo, dentro de la aplicación. ¿Sabe hacia donde va?
• Ayuda externa. Soporte
• Visibilidad  como sabe el usuario que existe la posibilidad de usar un botón derecho
• Transición. Estoy viniendo de un sistema y voy hacia otro como aprendo las diferencias
• Naturalidad del sistema con respecto al negocio
• Capacidades de la persona para hacer uso de una tecnología. 
• Experiencia
• Migracionalidad  --> ¿Cuáles son los cambios de versiones? versión 1 del sistema a versión 2
• El usuario debe reconocer que existe una diferencia que debe aprender.
• Multiples miradas del lado de la organizacion respecto de que es usable

Veamos un ejemplo

Me convocan para realizar un desarrollo de una aplicación. Actualmente existe una aplicación funcionando. La tecnología que usa mi equipo es similar a la de su aplicación.
Una pregunta que tengo que hacer (o hacerme) es: ¿Qué cosas (elementos UI) tiene la aplicación actual que parecen destacarse, según los usuarios?
Si nadie manifiesta nada ventajoso, pregúntate si: los elementos de IU que tiene la aplicación actual son coincidentes con estándares en productos públicos o masivos. Si no coinciden, propone prototipos de UI para ver la reacción y las opiniones. No te quedes con la visión de un solo usuario, búscate una mezcla de opiniones; usuarios con y sin experiencia, con y sin trayectoria, detallistas versus generalistas, etc.

Algún requerimiento de usabilidad

Utilizar una estructura de menús similar a la de OpenOffice 4.1, ya que esté es un producto oficial dentro del ámbito de trabajo.
Indicar mediante un marcador los cuadros de dialogo que posee ayuda adicional. el marcador debe estar en el borde superior derecho del cuadro.
Mantener los botones de acción que aplican al cuadro de dialogo en la zona inferior. Los botones con mayor frecuencia de uso deben estar a la izquierda, el resto más a la derecha.

Requerimientos, macros y micros requerimientos

Cuando se capturan los requerimientos, estos se obtienen de muchas formas y en distintos niveles. Así, por ejemplo, en una reunión se puede conseguir que:

El sistema debe ser capaz de administrar la facturación (1) o hacer factura (2) o registrar factura nueva (3) o generar un número de comprobante de factura (4) o ingresar el cliente (5) o tomar la fecha de factura como la fecha del día.(6)

Obsérvese que algunos de los requerimientos mencionados están contenidos en otros.

Así el requerimiento (1) es muy grande y resulta muy dificil acordar sobre lo que se quiere sginficar con él, el usuario puede tener una visión del mismo, otro usuario otra, el analista se puede disparar e ir hacia otras regiones. El requerimiento termina siendo muy macro. Debe ser bajado de nivel.
Por otro lado el requerimiento (2) estaría contenido en el requerimiento (1), si bien la idea es más concreta, pueden aparecer al menos media docena de interpretaciones.
Sin preámbulos los otros requerimientos estarían contenidos en el requerimiento (2). Ejemplos de ello son (3), (4), (5) y (6); pero debo decir que seguramente no son los únicos. Y quizás alguno que otro no lo sea.

La experiencia te va a ayudar a difenciarlo o cuestionarlo.

Un requerimiento como el (6) es muy bajo y es poco probable que el cliente lo enuncie.

Entonces: ¿Para qué se necesita conocer sobre los niveles?
Quizás para alguien con experiencia no resulte relevante, pero para alguien con poca experiencia poder reconocer que puede existir una posibilidad de no haber llegado a un nivel de comprensibilidad de los requerimientos puede ser fundamental.
Un requerimiento debe estar en un nivel adecuado para ser comprendido, un requerimiento muy macro genera demasiada variabilidad en su comprensión.

Si el nivel del requerimiento es macro aún se tienen muchas ideas flotando, un marco, una intención; pero nada concreto.
Cuando se logra un nivel micro, seguramente estamos en un nivel de detalle, quizás es momento de producir código o hacer diseño.

El nivel adecuado facilita el debate con el cliente. Tarde o temprano Alcántara el nivel adecuado. Sino lo hace algo está sucediendo.

Oportunidad de Mejora

Definición
Denomino oportunidad de mejora a la incorporación, modificación de ciertas cualidades y/o características del negocio y/o sistema que le proveen de una optimización significativa, mejorando algún aspecto del negocio y/o sistema actual.

Las oportunidades de mejora se presentan a lo largo del estudio del sistema al compartir con terceros la visión, los problemas actuales, el objetivo y los requerimientos del sistema de información.

Es muy común que al describir expresiones de deseo encontremos nuevas ideas por el solo hecho de compartir nuestra forma de ver/pensar un sistema, un componente, etc.

La oportunidad de mejora es, parafraseándola, encontrar una mejora a lo que ahora se realiza o se va a realizar.

Las oportunidades de mejora se ven restringidas por posibilidades técnicas o tecnológicas, de costo, de recursos o de tiempos, entre otras.

Ejemplos

1. En un sistema de ventas  con atención en mostrador, podría sugerirse que las personas que son clientes y realizan periódicamente los mismos pedidos, lo hagan por la web. Así la organización tiene dos mecanismos de ventas aumentando las oportunidades del negocio y mejorando la atención de cierto grupo de clientes.

2. Actualmente el sector de ventas realiza presupuestos, los imprime y se los remite por correo tradicional al cliente, previa llamada telefónica.
Hoy el presupuesto podría generarse como un archivo PDF, enviarse por correo electrónico al cliente y si se  posee el celular del responsable se le comunica mediante un SMS del envío.

3. En un negocio pequeño, el tomador de pedidos realiza la solicitud el pedido en forma manual en papel, repitiendo gran cantidad de datos del cliente en cada ocasión que este realiza un pedido. A través de un sistema automatizado ciertos datos ,como los personales, no serían obligatorios cada vez que se realiza la toma de un pedido.

Los ejemplos son numerosísimos... agregá otros....

Un requerimiento no funcional verificable

Los requirimientos deben tener ciertas caracteristicas, una de ellas es que deben ser verificables. Esto es, el requerimiento debe ser contrastable en la realidad por el usuario y antes debería serlo por alguien ( o alguienes) del equipo de desarrollo.
Un requerimiento funcional es mas fácil de verificar que uno no funcional. Así que en esta oportunidad me encargaré de los no funcionales

Miremos algunos ejemplos de requerimientos no verificables, luego mostraré un ejemplo:

• El sistema debe tener interfaces de usuarios amigables.
• La aplicación debe ser ligera.
• Los listados deben ser generados rápidamente.
• El software debe ser seguro.
• La aplicación WEB correspondiente al sector ventas-online debe funcionar en todos las navegadores.

Los requerimientos mencionados arriba son especificaciones que traerán problemas en el corto plazo para el proyecto y /o el producto.

Tomemos el primer requerimiento:
¿Qué significa que las interfaces de usuario sean amigables? ¿Qué significado tiene en la expresión la palabra "amigable"?¿Cómo está seguro el equipo de desarrollo, que ha realizado interfaces amigables?¿Se puede estar seguro que hemos conseguido el requerimiento?¿Se cumplen las expectativas del usuario?
Y por último, ¿qué diablos es una interface de usuario amigable?

En nuestro proyecto una interface de usuario  amigable es un interface fácil de usar y aprender y conseguirá estos objetivos si cumple con:

1. Una descripción de etiquetas para los datos clara y de acuerdo al negocio.
2. Botones de acción al pie de las ventanas con texto y gráficos
3. Una ayuda on-line sobre la meta y uso de la ventana que está usando el usuario.
4. Cada ventana tiene un titulo.

Las etiquetas serán provistas por el stakeholder definido en la organización cliente. 

Los gráficos serán tomados de las aplicaciones utilizadas actualmente por los stakeholders-usuarios representativos de cada sector.

El título será propuesto por el analista y verificado por el stakeholder definido en la organización.

Ahora sí, está descripción que acompaña al enunciado del requerimiento lo completa y en un principio lo hace verificable. Dejo en negrita señalando todo el requerimiento.

Ejemplifiquemos:
Tomemos un caso, si las ventanas no tienen títulos entonces no son amigables. Si los títulos no son los establecidos por el stakeholder definido por la organización entonces no se cumple con el requerimiento.
Si el título dice a, b, o c según lo definido por el stakeholder ( y se cumple con el resto de los criterios) entonces la interface es amigable.

Debo reconocer que algunas descripciones son débiles, por ejemplo cuando se considera una etiqueta clara....pero el impacto de equivocarse será menos.

Anímate a pensar el resto.....

02 ¿Qué es un requerimiento?

La forma más simple de definir un requerimiento es la siguiente:
Un requerimiento (requisito) es una característica (capacidad) que debe (debería) poseer el sistema bajo estudio.
Decirlo, escribirlo resulta fácil, pero es el principio de algunos problemas...

Durante algunos años, sobre todo cuando comencé a estudiar y más tarde trabajar, el debate que existía (y existe) era sobre si tal o cual cosa se trataba de un requerimiento o no.

Esto fue el principio del fin; en lugar de enfocarte en el problema a resolver, te enfocaste en la validez académica del concepto y, comenzaste a determinar lo correcto o incorrecto de lo enunciado como requerimiento.

En el corto plazo aparecieron las clasificaciones, estas comenzaron a dividir aguas de los requerimientos, enfocarte en diferentes tratamientos de los requerimientos, pero en el corto plazo se perdió la idea que tiene una clasificación y se volvió al principio básico de lo correcto o incorrecto, lo blanco o lo negro.
La discusiones se centraron en si el requerimiento es funcional o no lo es, en si el requerimiento correspondía al tipo de portabilidad o internacionalización o usabilidad. Perdimos otra vez el centro.

Luego aparecieron otras cuestiones...

Mantengámoslo simple, si reconocemos que entender el significado de los requerimientos y sus distintas clasificaciones nos permitirá decidir, a los fines prácticos, con cuales de los requerimientos nos quedamos, entonces habremos encontrado el centro.

Un requerimiento refiere a  cuales son las capacidades que debe tener el sistema, entonces contestemos esa pregunta. tan simple como eso.

Que el sistema permita calcular los impuestos, que los botones sean de fondo color rosa, que se pueda correr la aplicación en varios navegadores, que se muestre en una ventana el estado de una transacción, que las ventanas sean "amigas", que se registren los datos a, b y c. Todos, absolutamente todos son requerimientos....todos; pero si no son claros y no se entienden entonces no sirven, o bien, traen otros problemas; en cambio si se entienden y son claros, seguramente tendremos la capacidad para saber que hacer con ellos, debatirlos, descubrirlos o mejorarlos. Y ese, ese es el centro.

Así que las palabras claves serán claridad, entendibilidad y simpleza. Escribamos requerimientos que las cumplan.

historial de cambios
Creado el 03/04/2015. Correcciones de expresiones 26/07/15.

01. Introducción - Motivación

El mundo de los requerimientos es un mundo explorado, un mundo reconocido. Para algunos no hay más nada que decir, sin embargo pienso que no es un mundo recorrido; por lo menos no de la reflexión práctica.

Profesionalmente saber que existe no es suficiente te tenés que empapar. Este blog pretende hacer eso, sumergirte entre los requerimientos para entenderlos y trajarlos.

Después de todo si quieres desarrollar sistemas son tu punto de partida.
Esta es la principal motivación para iniciar este blog.