Un pilar fundamental en cualquier tipo de proyectos, y en especial en la creación de sistemas analíticos, es la toma de requisitos de soluciones de BI. Durante esta etapa hay que obtener las necesidades de los usuarios del sistema a construir. Para llevar a cabo este proceso debemos de seguir una metodología que nos guíe y ayude durante todo el proceso, que básicamente consiste en entrevistar a los actores del sistema, entender sus necesidades y plasmarlas en la documentación, para a partir de ahí diseñar y desarrollar un sistema de BI que responda a las necesidades de dicha empresa.
En nuestro caso lo haremos varias iteraciones, en base a pequeños y continuos ciclos de desarrollo con entregas al usuario para su validación y uso.
A continuación tenéis una imagen muy descriptiva de la problemática ocasionada por una mala toma de requisitos de soluciones de BI y que en todo momento debemos evitar:
En general, en toda toma de requisitos debemos tener claro que nuestro objetivo es plasmar tanto los requisitos funcionales como los no funcionales, de cara a un correcto desarrollo del sistema y éxito final del mismo. Deberemos diferenciar, por tanto, entre los funcionales (aquellos que describen aquello que el sistema ha de ser capaz de hacer) y los no funcionales (aplican a las limitaciones que puedan aplicar al sistema, como por ejemplo tecnología a utilizar, tiempos de respuesta, seguridad, escalabilidad, etc.).
En esta entrada nos centraremos en describir en primer lugar los pasos a tener en cuenta para obtener toda la información relevante a nuestro sistema, y posteriormente, cómo plasmarlo en un documento de toma de requisitos adecuadamente.
Obtención de requisitos de soluciones de BI
Como punto de partida, nos encontraremos en nuestro sistema de BI con el primer paso a dar en cualquier proyecto que aspire a tener éxito. Será la piedra angular del proyecto, y se puede resumir en conocer nuestro negocio. Un buen lugar para comenzar, por tanto, será analizando el negocio de cara a la toma de requisitos, mediante el acercamiento a los usuarios de negocio implicados en el proceso final. Sólo así lograremos tener claras cuáles son las necesidades pasadas, presentes y futuras (en la medida de lo posible) de cara a que el nuevo sistema las resuelva del mejor modo posible.
Una estrategia a seguir, de cara a plasmar esta etapa inicial de la toma de requisitos, sería por tanto recopilar esa experiencia de usuario de negocio y tratar de reflejarla, por ejemplo, mediante mapas conceptuales.
Por ejemplo, en el mapa conceptual anterior, podemos observar cómo se ha detectado que a partir de un conjunto de datos base, se quiere extraer una serie de informes (bien nuevos, bien replicar y optimizar informes ya existentes) con unas condiciones de acceso concretas (por ejemplo, podríamos tener una biblioteca de informes en un SharePoint corporativo) y con información actualizada en un plazo determinado (esto determinará la ventana de tiempo que tenemos para manejar los datos). Estaríamos reflejando aquí tanto requisitos funcionales como no funcionales.
Como comentábamos, es importante hablar con los usuarios, en plural, ya que habrá que identificar si no a todos ellos, al menos todos los perfiles de usuario que va a tener el sistema. Habrá representantes de diversas áreas de negocio (por ejemplo Control de Gestión, Recursos Humanos, etc.) y dentro de cada una distintos roles que adoptan, que requieren de un uso determinado del sistema (habrá quien necesite un informe cada 24 horas como comentábamos en el ejemplo, otros cada 2 horas de otro aspecto en concreto…). Es por ello importante identificar y representar los perfiles de usuario. Es decir, qué tipo de usuario vamos a tener presente en el sistema (quién genera la información, quién la va a consumir, nivel de conocimientos que tienen de las herramientas, etc.).
Otro de los aspectos en que nos pueden ayudar estas reuniones con los distintos actores implicados, es a conocer la nomenclatura que se utiliza para cada perfil de usuario. De este modo, se podrá plasmar el requisito, y la futura implementación, con términos amigables, con los que están familiarizados, que sean sencillos de utilizar y permitan explotar con facilidad el dato. Por ejemplo, deberemos ser capaces de determinar si lo que para un usuario es un “empleado” y lo que para otro es un “recurso”, son equivalentes. O por ejemplo, cuál es la fórmula acertada para calcular el beneficio neto. Estas y otras muchas dudas pueden surgir, especialmente cuando se trata de un entorno con muchos usuarios implicados, pertenecientes o no a una misma área.
Hasta aquí la primera entrega de Toma de requisitos para la creación de soluciones de BI. Esperamos que haya servido para sentar las bases en las que nos apoyaremos en las siguientes entradas, en donde buscaremos dejar claro las opciones a la hora de obtener los requisitos del proyecto.
