Cuando una empresa decide formalizar su proyecto de Business Intelligence, se inicia estableciendo una toma de requerimientos de las áreas/departamentos que van a estar involucrados. Este proceso es el más importante, ya que orientará el resultado de la solución desde una simple automatización de reportes operativos hasta una toma de decisiones estratégicas de negocio por medio de informes analíticos y predictivos.
Regularmente, para la tarea de toma de requerimientos se establece el departamento de sistemas o un subdepartamento especializado en Business Intelligence. Lo importante de esta tarea es que se establece el rumbo que tomará dicha solución en la empresa.
La Importancia de una Buena Administración de Requerimientos
La administración de requerimientos abarca actividades como la recopilación, documentación, validación y control de los requerimientos y sus cambios.
Con el software, y en particular con el desarrollo de software a la medida ocurre con bastante frecuencia algo similar. Pues, no es raro encontrarse con empresas que contratan un desarrollo de software sólo para darse cuenta de que desperdiciaron su dinero y su tiempo, pues no obtuvieron lo que ellos esperaban o necesitaban.
Una de las razones principales por las cuales se da esta situación, y de hecho, una de las causas principales por las cuales los proyectos de desarrollo fracasan o por lo menos no tienen el éxito que deberían, se debe a una mala administración de requerimientos.
Lea también: Tutorial SAT: Cómo Aclarar tus Requerimientos
Para la toma de requerimientos se determinan diferentes formas de hacerlo, aunque el objetivo parece similar, el resultado de cada escenario puede ser totalmente diferente. De esta manera establecemos los escenarios más comunes para dicha toma de requerimientos.
Requerimientos Genéricos vs. Requerimientos Funcionales
En los objetivos de la solución de BI se establecen requerimientos genéricos de dicha solución para lo cual es común encontrarnos con los siguientes puntos:
- … proveer un sistema intuitivo y fácil de usar que permita a los usuarios finales generar sus propios reportes y análisis.
- … tener una sola versión de la información.
- … proveer información de toda la compañía en un solo sistema.
- … que los usuarios puedan accesar la información desde cualquier lugar y en cualquier momento.
Con dichos objetivos de la solución como base de los requerimientos es difícil establecer una forma confiable de medir los resultados de la implementación de la solución de BI.
La toma de requerimientos funcionales se establece en algunos proyectos como la base para tomar decisiones en la secuencia de etapas donde atraviesa un proyecto de BI. En muchos proyectos los requerimientos funcionales dirigen el destino del proyecto, por lo cual es muy común que muchas empresas decidan su proyecto de BI en base a la herramienta seleccionada.
Consultoría de Software y la Identificación del Valor del Sistema
Si queremos realizar una verdadera consultoría de software entonces nos corresponde algo más que escuchar la lista de funciones que el cliente cree que debería de tener su sistema (a menos que nuestro cliente tenga un área con la capacidad de realizar una buena recopilación y análisis de requerimientos).
Lea también: Software contable: requerimientos esenciales
Si nos limitáramos a lo primero entonces en lugar de llamarle consultoría a nuestro trabajo, deberíamos llamarle manufactura de software, donde uno implementa las funciones exactamente como se las solicita el cliente, cuestionando nada o muy poco, tal como se haría en una planta manufacturera donde se reciben las especificaciones del producto a construir.
Si queremos desarrollar el mejor sistema posible debemos realizar un trabajo serio para identificar, en primer lugar, cuál es el valor que el sistema debe proporcionar al negocio. Para lo cual habrá que preguntárselo a las personas que obtendrán alguna clase de beneficio cuando se ponga en operación.
Casos de Uso en UML: Modelando los Requerimientos
Una vez identificados los usuarios del sistema (actores primarios) habrá que preguntarles en qué situaciones valdrá la pena para ellos utilizarlo. La lista identificada de dichas situaciones no debería de tener pequeñas funciones, sino flujos completos que le proporcionen suficiente valor tanto a ellos como al negocio, de manera que “valga la pena usar el sistema” en dichas situaciones.
Ejemplo: un vendedor en cierto sistema de ventas querrá “Registrar venta”, “Registrar pedido”, “Consultar comisiones”, “Administrar prospectos”, “Generar factura” y “Administrar clientes”. Todas ellas son ejemplos de situaciones u objetivos importante que podría necesitar un vendedor para llevar a cabo su trabajo, conocidas y modeladas como casos de uso en UML, tal como se muestra en el diagrama.
Normalmente los casos de uso son iniciados por algún actor, conocido como actor primario. Lo inicia con algún evento, que podría ser tan simple como elegir una opción en el sistema, y continúa como una serie de eventos o interacciones entre actores y sistema, hasta que el objetivo del caso de uso se cumple (el objetivo principal del caso de uso es lo que le da el nombre al mismo).
Lea también: Todo lo que necesitas saber del SAT
Lo que estamos obteniendo así es una especificación de requerimientos funcionales mediante un análisis top-down (de lo general a lo particular), es decir, primero obtenemos los objetivos que hay que cumplir en el sistema descritos con el nombre del caso de uso (p. ej: Realizar una venta) y después buscamos cuáles son las funciones o requerimientos funcionales precisos y ordenados para que el actor cumpla dicho objetivo al utilizar sistema.
Actores Primarios y Secundarios
Hay otro tipo de actores que también hay que modelar; los actores secundarios. Suelen ser otros sistemas, componentes externos o dispositivos con los cuales interactúa nuestro sistema. A diferencia de los actores secundarios, éstos no son los que inician o requieren del caso de uso, sino que nuestro sistema, al llevar a cabo un caso de uso requiere tener algún tipo de interacción con él.
Nuestro sistema de ventas podría requerir enviarle información al sistema de contabilidad cuando se ejecuta la funcionalidad del caso de uso “Generar factura”. En dicha situación el sistema de contabilidad aparecerá como un actor secundario asociado a dicho caso de uso.
La Simplicidad en el Modelado UML
Por experiencia sabemos que, en los modelos de UML, el buen uso de pocos elementos da mejores resultados que el uso de muchos elementos mal aplicados. La esencia de los modelos radica en la simplicidad, ya que facilita el análisis, entendimiento y comunicación entre quienes solicitan el sistema y los que participan en su desarrollo.
En otras oportunidades veremos elementos adicionales para modelar los casos de uso, pero podemos asegurar que la sencillez es parte importante del modelado, y esto implica que en ocasiones, y sobre todo cuando el analista no tiene tanta experiencia en UML, es mejor limitarnos a los elementos más básicos.
tags: #requerimientos #funcionales #sistema #contable