viernes, 10 de abril de 2015

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....

jueves, 9 de abril de 2015

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.....

viernes, 3 de abril de 2015

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.