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.
domingo, 12 de julio de 2015
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....
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:
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:
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.....
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.
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:
- Una descripción de etiquetas para los datos clara y de acuerdo al negocio.
- Botones de acción al pie de las ventanas con texto y gráficos
- Una ayuda on-line sobre la meta y uso de la ventana que está usando el usuario.
- 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.
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.
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.
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.
Esta es la principal motivación para iniciar este blog.
Suscribirse a:
Entradas (Atom)