Hablemos de la Especificación de Requerimientos

Es imposible que el equipo de desarrollo memorice toda la información del producto. A lo largo del proyecto, los miembros del equipo tendrán preguntas, habrá suposiciones y ocurrirán otras situaciones que causarán que haya un entendimiento diferente de lo que debe y no debe hacer el software. No resolver rápidamente las dudas o que haya esa comprensión dispar de los requerimientos nos conducirá a retrabajo, retrasos y descontento entre los stakeholders.

Además, para sistemas ya construidos, es importante que exista información que permita entender cómo y por qué se tomaron las decisiones y qué implica hacerle cambios.

Por eso debemos especificar los requerimientos. Esto significa documentar los acuerdos sobre lo que debe hacer el software y las restricciones existentes.

Ahora, una de las mayores dificultades que enfrentan los equipos de software es saber lo que sí se debe especificar. La información importante que siempre debes registrar en tus especificaciones es la que te permita responder las siguientes preguntas:

• ¿Qué se va a resolver y por qué es importante hacerlo?
• ¿En quiénes estamos teniendo impacto?
• ¿Qué es lo que quieren hacer los usuarios con el software?
• ¿Qué funciones tendrá el software?
• ¿Cuál es el ambiente en que estará operando el software?
• ¿Cómo se usarán las interfaces con otro software y hardware?
• ¿Hay alguna restricción con la tecnología?
• ¿Cómo evaluaremos el cumplimiento de los requerimientos no funcionales?
• ¿A cuáles estándares nos debemos apegar?

¿Qué se va a resolver y por qué es importante hacerlo?

Los requerimientos de negocio, que están en lo más alto de los niveles, marcan la dirección del proyecto, los objetivos que persigue el usuario u organización y una visión de cómo el producto ayudará a alcanzarlos.

Para que los involucrados siempre tengan presente por qué es importante hacer este proyecto, haz un resumen ejecutivo con lo siguiente:

• El estado actual y la problemática que se enfrenta.
• El estado deseado, expresado en objetivos SMART y criterios de éxito
• El enunciado que describe la visión del software
• Las funciones principales que ejecutará
• Los riesgos del proyecto

Recuerda que esta especificación hablará en el lenguaje del negocio, por lo que debes evitar incluir muchos conceptos técnicos y ser muy concreto en la descripción de la visión.

Por ejemplo, tu especificación de la visión y sus funciones principales puede ser: “Un sistema distribuido en web y dispositivos móviles que permitirá registrar clientes, crear rutas de reparto, notificar los cambios de estado de los pedidos y administrar el almacén”. La descripción detallada de cómo se hará cada función se hará, pero es parte de otras especificaciones.

¿En quiénes estamos teniendo impacto?

Todas las decisiones que se toman para el producto tienen un impacto en y reciben influencia de la comunidad de Stakeholders. Debemos establecer un acuerdo de quiénes son y cuál es su rol en la comunidad. En esta especificación, deberás definir:

• Quiénes son los usuarios directos
• Quiénes son los patrocinadores del proyecto
• Quiénes son usuarios indirectos
• Quiénes definen reglamentos, estándares y leyes

Los patrocinadores suelen tener el poder de aceptar o rechazar el proyecto, así que establecen los objetivos del mismo. Los usuarios directos utilizarán las funciones del software. Los usuarios indirectos reciben un beneficio aunque no usen el producto (por ejemplo, para una aplicación de GPS, los restaurantes se benefician de que los conductores puedan llegar a sus locales mediante el mapa y el gps). Los definidores de reglas establecen lineamientos a los que el software debe apegarse (como el Gobierno).

El Stakeholder especificado será el nombre del rol, no debes poner el nombre de cada persona. Como “Director”, “Gerente”, “Empleado”, etc. Puedes agregar información adicional, como los intereses principales, actitudes y restricciones que tienen hacia el proyecto.

¿Qué es lo que quieren hacer los usuarios con el software?

Los usuarios quieren completar actividades usando el software. Estas actividades les permitirán lograr objetivos personales o propios de su rol. En la especificación de los requerimientos de usuario, documentamos los procesos y objetivos que quieren completar nuestros usuarios a través del software. Es importante que aquí entiendas que la especificación debe centrarse en Actividades completas del usuario, en vez de funciones individuales del software.

Por ejemplo, un usuario que llamaremos “publicista” quiere diseñar correos electrónicos para enviar promociones a sus clientes. El objetivo es enviar promociones y la actividad es diseñar el correo. El software debe permitirle completar la actividad y lograr el objetivo, que es enviar este correo a los clientes. Un ejemplo de lo que no debes especificar es “agregar imágenes mediante drag-and drop”.

La especificación de requerimientos de usuario puede hacerse con la herramienta “User Stories”. Si el equipo necesita mayor detalle sobre el proceso (pasos, orden y objetivos intermedios), la herramienta de Casos de Uso le será de utilidad.

¿Qué funciones tendrá el software?

El software debe ofrecer diferentes funciones para permitir que los usuarios completen sus actividades. La especificación de estas funciones nos permite entender qué hará la aplicación en sus diferentes elementos, pero no especifica el cómo lo hará (esta es una decisión de diseño). Retomemos el ejemplo del publicista y el envío de promociones por correo electrónico. Las funciones individuales pueden incluir: Escribir texto, elegir el tipo de fuente, cambiar el tamaño de la fuente, agregar imágenes y videos, alinear el texto, cambiar el color del fondo, guardar un borrador, seleccionar destinatarios, buscar destinatarios registrados, crear un nuevo destinatario, enviar el correo.

En la especificación también es importante describir el comportamiento de las funciones en escenarios de uso normal, error y excepción. Por ejemplo, si ocurre un error de comunicación, ¿el software debe presentar un mensaje o debe reiniciar?

Esta especificación puede hacerse sobre maquetas de pantallas, en las que agregas notas con los comentarios, en prototipos o en documentación detallada con la descripción de cada función.

¿Cuál es el ambiente en que estará operando el software?

El equipo debe ser capaz de comprender el ambiente en que operará el sistema. En el análisis hablamos del Contexto del sistema, y en la especificación describimos:

• Las características de los dispositivos en que se ejecutará el software
• Las características de las redes de comunicación entre los diferentes dispositivos
• Dónde se localizan los usuarios
• Cuántos son los usuarios estimados
• Cuáles son los días y horarios donde se espera el mayor uso del sistema
• El ecosistema de software con el que convive nuestro producto: programas, versiones, sistemas operativos, etcétera.

En este manual técnico, el equipo basará las decisiones de elección tecnológica y entenderá las limitaciones que enfrentará durante el desarrollo.

¿Cómo se usarán las interfaces con otro software y hardware?

Si tu sistema se comunicará con otras aplicaciones de software y hardware, debes especificar:

• Cuáles son las aplicaciones
• Las características de las interfaces que usarás para comunicarte con ellas (por ejemplo, APIs)
• Cómo deben usarse en los diferentes procesos
• Problemas conocidos con el uso de las interfaces
• Mostrar algunos ejemplos de uso

Donde la especificación ya existe, debes nombrar la referencia y localización donde el equipo puede consultar esta información.

¿Hay alguna restricción con la tecnología?

La información en esta especificación permite que el equipo decida correctamente las herramientas y componentes adecuados para el desarrollo, y prevenga dificultades con la compatibilidad de la aplicación en diferentes dispositivos y programas. En muchas ocasiones, los proyectos inician en ambientes donde ya existe tecnología, la cual no es posible cambiar y es importante saberlo para usarla.

En esta información deberás especificar:

• Dependencias con componentes y bibliotecas de terceros, en qué versión se encuentran 
• Restricción de recursos, como cantidad de memoria, capacidad de procesamiento o ancho de banda
• Resolución de pantallas en dispositivos
• Equipos, sistemas operativos y aplicaciones que se usarán y que no pueden ser actualizados
• Arquitecturas de hardware y sistemas operativos específicos, que no podemos cambiar.

Incluye también la referencia a manuales de operación, bibliotecas de ayuda, foros de apoyo y toda la información que permita entender y operar la tecnología con limitaciones.

¿Cómo evaluaremos el cumplimiento de los requerimientos no funcionales?

Los requerimientos más susceptibles a presentar ambigüedad son los atributos de calidad, o requerimientos no funcionales. ¿Cómo sabemos que hemos hecho un programa “seguro”, “usable”, “rápido”, “libre de fallos” o “de alto desempeño”?

Especifica estos requerimientos con parámetros objetivos y medibles. Por ejemplo, “El sistema debe responder a 1000 peticiones cada segundo”

Idealmente, incluye escenarios de prueba. Colabora con los expertos en testing para esto.

¿A cuáles estándares nos debemos apegar?

Algunos elementos del sistema deben apegarse a estándares. Por ejemplo, cómo será la interfaz gráfica, cómo se escribirán los mensajes de usuario y su documentación de ayuda, cómo se producirán ciertos mensajes entre los diferentes sistemas, etcétera.

Estos estándares pueden ser externos o definidos internamente, debemos especificar lo suficiente de ellos para que el equipo lo use cuando es necesario.

¿Qué no sabemos todavía?

En varios momentos del tiempo existirá información incompleta respecto al sistema. Es importante hacer un apartado en nuestra especificación de los requerimientos para anotar las suposiciones que tenemos y lo que aún no ha sido resuelto. Por ejemplo, anotar que suponemos la existencia de una red de telecomunicaciones funcional, o que el cliente implementará una.

Esta lista debe revisarse continuamente, para eliminar los elementos que ya han sido resueltos y especificados y agregar los que surgen con el tiempo.

Conclusiones

A muchos no nos gusta documentar. Algunos piensan que documentar los requerimientos es inútil por varias razones (toma mucho tiempo y estos cambian constantemente), o que la única documentación necesaria es el código y ahí se podrá entender la aplicación y los requerimientos implementados. Esto sería válido si el tamaño del equipo es de un solo desarrollador que toma todas las decisiones. Sin embargo, el software actual se desarrolla entre varias personas y es necesario tener mecanismos para que todos tengan un entendimiento común del sistema y los acuerdos sobre éste.

Para la especificación de requerimientos no debes escribir miles de páginas. La cantidad y el nivel de detalle debe ser suficiente para que el equipo pueda responder las preguntas que te propuse aquí, que son muy comunes a lo largo de un desarrollo.

Además, la especificación de los requerimientos no está escrita en piedra, sino que cambia y documentar los acuerdos es una actividad continua. Para facilitar esto, utiliza una herramienta con estas características:

• Que facilite la búsqueda de información.
• Que permita la colaboración.
• Que sea fácil de acceder y compartir.
• Que sea rápida para modificar 
• Que administre las versiones de cambios automáticamente

Mi recomendación es que uses una Wiki, pues tiene todas estas características por defecto.

Si aún eres escéptico, responde esta pregunta ¿Qué será útil para que el equipo comprenda los requerimientos en todo momento? Esa será tu forma de especificar los requerimientos.

En el siguiente episodio, hablaremos de cómo validar los requerimientos, para saber que los hemos entendido bien y se encuentran completos.

Nos vemos en la próxima