Preguntas para capturar información (3)

Una vez que ya sabemos lo que queremos saber, debemos plantear las preguntas. Y lo primero es superar el síndrome del papel en blanco, ¿por dónde empiezo?, pues por aquél elemento que es menor en la mayoría de las ocasiones, los actores, después seguiré la relación existente según el diagrama del artículo anterior.

1. Actores: Entendemos como actor aquella persona o sistema externo que interactúa con nuestro sistema, por lo que la pregunta debería ser ¿Quiénes utilizarán el sistema?.
2. Requisitos Funcionales: Queremos conocer qué podrá realizar cada actor en el sistema, por lo que tendremos que hacer tantas preguntas para captar requisitos funcionales como actores hayamos identificado. Si tenemos dos actores, un usuario y un administrador, las preguntas deberían ser ¿Qué podrá hacer el usuario en el sistema?, ¿Qué podrá hacer el administrador en el sistema?.
3. Requisitos No Funcionales: Las características del entorno son muy útiles conocerlas desde un principio. Por regla general están íntimamente relacionadas con dónde tendrán interacción con el usuario, a excepción de ciertos tipos de arquitecturas o entornos, pero la pregunta que se le debe hacer al interlocutor debería ser una por cada actor identificado con la siguiente forma ¿Dónde podrá utilizar el usuario el sistema?, ¿Dónde podrá utilizar el administrador el sistema?.
4. Requisitos de Información: El caso de estos requisitos es compleja, ya que no puedes preguntar a un usuario por conceptos, nos debemos centrar en aquello que conoce, como son las entradas y/o salidas que espera del sistema como son pantallas, consultas e informes, por tanto debemos hacer dos tipos de preguntas, ¿Qué información necesitas introducir en el sistema? y ¿Qué información necesitas que te proporcione el sistema?.
5. Restricciones de los Requisitos de Información: Estas reglas de negocio pueden estar asociadas tanto un único concepto (Requisito de Información), como a la relación de varios, y pueden venir dadas por cuestiones puramente legislativas, como asociadas a la cultura organizativa. Esto conlleva que tengamos dos tipos de preguntas (imaginemos que tenemos persona y cuenta bancaria), las cuales serían, ¿Qué aspectos legislativos ha de cumplir una cuenta bancaria en el sistema? y ¿Qué aspectos legislativos rigen la relación entre cuenta bancaria y persona en el sistema?.

Toda esta información será recogida en las diferentes actas de reunión. Más adelante veremos qué hacemos con dicha información.

Preguntas para capturar información (2)

Es muy común recabar información en las entrevistas de captación que no nos hace ninguna falta, lo cual provoca desorientación en nuestro cliente (a cualquier nivel), por lo que lo primero que debemos saber, es qué información necesito. El tener totalmente claro el tipo de información a recabar es muy útil, y nos permite aclarar las preguntas que tengo que realizar, e ir al grano, de esta manera no existirá esa sensación de pérdida de tiempo, o si es así, será debida a otros factores o entornos, pero no debido a la entrevista para capturar la información. Partiendo del gráfico del artículo anterior, vamos a especificar el tipo de requisitos y elementos son necesarios para cada uno de los enfoques:

• Enfoque funcional: Como este enfoque permite conocer qué realizará el sistema y quién lo hará, definiremos requisitos funcionales y actores.
• Requisitos funcionales (RF): Son aquellas actividades que ha de realizar el sistema.
• Actores (ACT): Son aquellos elementos externos que interactúan con nuestro sistema mediante requisitos funcionales.
• Enfoque estático: En este enfoque prima la información con la que trabajará el sistema y sus restricciones, por lo que son necesarios:
• Requisitos de información (RI): Representan cada concepto con el que trabaja nuestro sistema.
• Restricciones sobre los Requisitos de Información (RRI): Representan dos tipos de limitaciones sobre la información (RI). Tipo de información, o significado, que está obligado a cumplir el RI, o tipifica la relación (número de elementos relacionados), entre dos o más RI.
• Enfoque dinámico: El enfoque dinámico nos muestra la relación entre el enfoque funcional y el estático, y no tiene definido por tanto ningún requisito específico, ya que nos responde al cuándo y cómo.
• Entorno: Las características del entorno son muy importantes, por lo que tiene asociado requisitos no funcionales.
• Requisititos No Funcionales (RNF): Estos requisitos nos permiten especificar características de arquitectura lógica, infraestructura, interfaz gráfica, seguridad, rendimiento y disponibilidad e, integración y portabilidad.

Teniendo en cuenta estos requisitos y elementos, la relación que existe entre ellos y que la mejor manera de plantear un proyecto, es crear objetivos (ya veremos cómo se hacen), el siguiente gráfico muestra mi propuesta que resume todo lo anterior.

Preguntas para capturar información (1)

Esta una de las partes más difíciles e importante de todo el ciclo de ejecución de una petición, ya que dependiendo de la información que captemos, así realizaremos el resto del trabajo. Por todo esto, las preguntas que realicemos nos han de garantizar:

1. Cubrir todos los aspectos funcionales, es decir, qué realizará el sistema y quién lo hará.
2. Cubrir todos los aspectos informativos, es decir, qué información gestionará el sistema.
3. Cubrir todos los aspectos técnicos, es decir, que las cosas funcionen donde han de funcionar.

Los dos primeros puntos nos proporcionan, en un sistema software, lo que se denomina el enfoque funcional (1) y el enfoque estático (2). Más adelante veremos en qué se convierte todo esto.

El tercer punto nos proporciona información de cómo se relacionan los otros dos enfoques.

Más adelante hablaremos sobre la siguiente capa y profundizaremos un poco más.

Preparar la Reunión

Como decíamos en la publicación anterior, lo primero que debemos hacer es identificar a los interlocutores, y éstos pueden ser:

• Clientes: Principalmente recabaremos información de clientes administrativos y técnicos para el primer acercamiento.
• Expertos en el dominio: Otros analistas de negocio que conozcan bien tanto lo que se hace actualmente como lo que se debería hacer, aunque sea en el caso perfecto (ya analizaremos luego su adecuación e idoneidad).
• Proyectos anteriores: No sólo recabaremos información de personas, sino también de la "documentación" de los proyectos anteriores realizados. Lo mismo estamos realizando un evolutivo o adaptativo de un producto ya realizado por nosotros o no.
• Otros profesionales de IT: Seguramente otros compañeros que estén trabajando en el área de IT habrán hecho proyectos para el mismo cliente. Son una fuente muy importante de información.

Y una vez que los tengo indentificados ¿qué hago?. Cogemos un taco de folios de papel para reciclar, los dividimos en cuartillas, y escribimos en cada una el nombre de la persona con la que nos vamos a reunir.

El siguiente paso dependerá del método elegido, pero me centraré en las entrevistas ya que es el más utilizado. El primer paso será preparar la batería de preguntas a realizar, y se las asignaremos a aquella o aquellas personas a las que se las debamos hacer (Sobre qué y cómo hacer las preguntas hablaremos en otro momento). De este modo tendremos un conjunto de cuartillas con preguntas a realizar, tal y como se puede observar en la siguiente imagen.

El siguiente paso consiste en identificar el orden, es decir, vamos a tener que reunirnos con unas personas antes que con otras ya sea por gerarquía (lo siento mucho pero es así), dependencias funcionales o entre las preguntas.

Con todo esto ¿qué hemos conseguido? Tener una planificación de reuniones y poder lanzar las convocatorias con un órden del día ¿cuál? la batería de preguntas que tiene asignada cada persona.

Lo siguiente, realizar las entrevistas, pero eso lo comentaré más adelante.

El Proceso de Captación

Bien, ya estamos en la primera fase de la ingeniería de requisitos la captación de información. El objetivo de esta fase es recabar, de todas las fuentes requeridas, la información relevante e implicada directamente con la petición. Para conseguir dicho objetivo se han detectado las siguientes actividades:

1. Preparar la Reunión: En esta actividad se identificarán los interlocutores necesarios, el método a utilizar en la realización, se prepararán las preguntas adecuadas y se lanzará la convocatoria.
2. Realizar la Reunión: Dependiendo del tipo de método utilizado, serán individuales o grupales, pero todas ellas han de tener una agenda y los participantes han de asistir preparados.
3. Analizar la Información: Toda información recabada durante las reuniones, ha de ser analizada para conocer si disponemos de información suficiente para pasar a la siguiente fase, o por el contrario hay que realizar otras para concretar o ampliar la información recabada.

¿Cómo saber todas estas cosas? Bueno, eso dependerá de los métodos utilizados, lo cual nos llevará un buen número de artículos.

Por dónde empezar

Normalmente es complicado saber, cuando nos remiten una petición del cliente, por dónde hemos de empezar. Bien, pues lo primero es establecer el punto de partida y el punto al que se quiere llegar. Y más concretamente, ¿qué deberíamos conocer de ese punto de partida y finalización? ¿qué se encuentra entre medias?


Punto de Inicio
A este punto lo denominaremos "Situación Inicial" y nos permite conocer el estado actual del cliente en relación a la petición que nos ha solicitado. Con el objetivo de conocer todos los aspectos relativos a su situación inicial deberemos recabar toda la información relacionada con:

• Calidad: Estándares de calidad implantados, utilizados,... hasta el momento.
• Procesos: Qué hacen. Esta información nos permitirá conocer cuales son sus procedimientos de trabajo, quién recibe qué, qué hace con ello y a quién se lo pasa.
• Métodos: Cómo lo hacen. Esta información nos permitirá conocer cómo hacen su trabajo (Ejm.: Si el proceso nos dice que tiene que validar los datos de un artículo, aquí nos dirá cómo hace esa validación).
• Herramientas: Con qué contamos. En este punto debemos conocer con qué elementos debemos de realizar los métodos, o el proceso completo. Las herramientas pueden ser de tres tipos:
• Artículos: Los artículos pueden ser artículos físicos, como un sello, o documentos o plantillas.
• Software: Programas informáticos que nos ayudan a automatizar ciertos procesos o métodos.
• Hardware: Máquinas informáticas utilizadas para la realización de operaciones. Es donde funciona el software.

Desarrollo de la Petición
El fin último es el desarrollo de la petición, pero en este punto debemos conocer cuál es la problemática o necesidad, en el ámbito del negocio, de nuestro cliente. Por eso, a este punto, lo llamaremos "Necesidad/Problemética", y contendrá el por qué de la petición a nivel de negocio. En ciertos ámbitos a este punto se le denomina "Justificación de Negocio".

Punto de Finalización
Como punto final de la contextualización, debemos conocer hacia dónde se quiere ir, a este punto lo llamaremos "Situación Final" y contendrá una descripción del estado en el que quedaría el negocio cuando esa problemática y/o necesidad estuviera resuelta. Para ayudarnos, podremos utilizar el mismo patrón que en en el primer punto:

• Calidad: Estándares de calidad implantados.
• Procesos: Procesos implantados, o lo que harán cuando la necesidad/problemática esté cubierta.
• Métodos: Cómo harán su trabajo.
• Herramientas: Artículos, Software y Hardware utilizado una vez se haya finalizado la petición.

Grandes meteduras de pata

Es muy curioso lo que ves y escuchas en muchas organizaciones cuando pasas por la puerta y te cuentan sus experiencias, necesidades, problemática, vivencias, etc..., en la mayoría de los casos soy yo el que más aprende, pero hay ciertos momentos que te dejan huella, y sabes desde ese mismo momento que va a ser un verdadero fracaso y lo único que quieres hacer es levantarte de la silla y correr hacia la salida más cercana.

Uno de los más típicos es el de "vamos a comprar la megaherramienta", pensando que así se arreglará todo, que la herramienta funciona sola, que todo el mundo sabrá manejarla perfectamente, que estará parametrizada según las necesidades específicas de mi organización. Tener una buena herramienta es muy útil, pero no empecemos la casa por el tejado y supeditemos todo lo que debemos atender a una herramienta, tal y como vimos en artículos anteriores.

Otro caso curioso es el de encargar a aquella persona que, por una causa u otra, tiene un método para gestionar los requisitos de las peticiones de los usuarios y le encargan que aleccione al resto de personas que realizan el mismo tipo de rol. ¡¡Cuidado!!, no siempre algo particular puede tener replicación, es igual que si nos ponemos el traje hecho a medida de otra persona, seguramente lo podremos llevar, pero no se ajustará a nuestras necesidades, y será más un estorbo (fracaso) que una utilidad.

En otros sitios no se es totalmente consciente de lo que implica un proceso de cambio, pretendiendo resultados del día a la noche. Señores, cambiar no es sencillo ni fácil, pero claro que se puede hacer.

La última es también muy típica, y es aplicable a otras muchas cosas, el intento de aplicar las cosas como aparecen en los libros o manuales. Cada organización tiene sus particularidades, necesidades, cultura y manera de hacer las cosas. Si queremos implantar un modelo de ingeniería de requisitos en Oz perfecto, pero no en una organización que debe dar respuesta y soporte a las unidades de negocio.