Organización de la Información (I)

Una vez que ya tenemos recabada cierta información, nos asaltan siempre las siguientes dudas, ¿tengo toda la información?, ¿seguro que no me he dejado algo?, ¿la información que tengo es correcta?, ¿y completa?, ¿y no excluyente?...

Después de mucho pensar, a Alfredo Zurdo de Entel IT Consulting, se le ocurrió una técnica para organizar los requisitos que presenta los siguientes beneficios:

• Sencillez: Se basa en el principio de divide y vencerás. Si tienes un concepto o problema grande, divídelo.
• Adaptable: Se puede analizar el sistema mediante dos enfoques, ya que se puede utilizar un criterio funcional o estructural.
• Relacionado: Gracias a las asociaciones entre elementos se puede conocer qué está relacionado con qué.
• Global: Permite obtener una visión de los todos sus elementos y sus relaciones.
• Verificable: Gracias a sus reglas de balanceo y sus reglas de relación, podemos conocer si el resultado obtenido es correcto, falta o sobra información.
  

La técnica

• Para desarrollar la técnica necesitaremos los siguientes materiales e información previa:
• La petición de la unidad de negocio.
• Las actas de las reuniones de captación de requisitos.
• Un taco de tarjetas de cartulina de 5x3".
• Rotulador, goma de borrar y lapicero.
• Una mesa despejada.

Pasos a seguir

1. Divide y vence: Siguiendo un criterio funcional o estructural.
2. Crear las tarjetas PRC: Por cada partición creamos una tarjeta.
3. Asignar responsabilidades a cada tarjeta.
4. Buscar las colaboraciones necesarias para cada responsabilidad.
5. Aplicar las reglas de balanceo a las tarjetas creadas: Balanceamos tanto por exceso como por defecto.
6. Iterar los pasos anteriores hasta la condición de parada.

Como podéis comprobar es una técnica sencilla, de todas formas en siguientes publicaciones daremos cuerpo a cada uno de los pasos especificados.

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.

Definición de Herramientas

Qué entendemos por herramientas
Las herramientas son aquellos elementos que nos ayudan, o proporcionan soporte, para hacer ciertas cosas; en ciertos ámbitos les denominan “elementos facilitadores”. Responden a la pregunta, ¿con qué lo haremos?

Uno de los principales errores es pensar que se trata únicamente de un programa informático, sobre todo en el entorno de sistemas de información. Este concepto es mucho más amplio y, además de poder ser software, también podría ser una plantilla, hardware, etc.

Herramientas a utilizar
Tipificaremos las herramientas que podemos utilizar no por la fase en la que se usan, ya que se suelen utilizar en dos o más fases, sino atendiendo a su naturaleza:

• Documento: Entendemos por documento todos los elementos escritos o que sirven de guías para otros (plantillas). A este grupo atienden, actas de reunión, peticiones de trabajo, documento de requisitos de usuario, documentos de verificación y validación, correos electrónicos,… ya se encuentren en formato físico o digital.
• Software: Es el conjunto de programas informáticos que facilitan la gestión y desarrollo de documentos, la comunicación entre las personas que participan en la ingeniería de requisitos. El software puede ser generalista, como un procesador de textos o un cliente de correo electrónico, o específico, como un software para la gestión de requisitos, de los cuales ya hablaremos.
• Hardware: Es la máquina sobre la que funciona el software según las especificaciones indicadas, incluyendo especificaciones de comunicaciones físicas, almacenamiento en disco, teléfonos, webcams, etc.