4 prácticas útiles en la toma de requisitos

Cuatro prácticas útiles en la toma de requisitos

La semana pasada os contábamos por qué es importante realizar una adecuada toma de requisitos a la hora de desarrollar software. Hace unos meses estuvimos analizando buenas prácticas habituales en este tipo de situaciones y encontramos las siguientes herramientas útiles:

Modelo en V

Buscando en Google encontraremos muchas variantes del modelo en V para la toma de requisitos, con más o menos niveles o fases. Con el modelo en V, la toma de requisitos se divide en tres fases, cada una con diferente nivel de detalle:

1. Especificación de requisitos generales: qué objetivo debe cumplir el software a desarrollar?
2. Especificación de requisitos funcionales: qué debe hacer el software a desarrollar?
3. Especificación de requisitos de diseño: por ejemplo, qué es importante que contemple la interfaz de usuario, o cómo debe ser la base de datos para dar el servicio requerido?

El propósito de dividir la especificación en diferentes fases es doble. Por una parte, permite hacer énfasis en diferentes aspectos, y con ello alcanzar el grado de detalle necesario en cada nivel. Por otra parte, establece las partes interesadas de cada nivel, de manera que no tendrá sentido hablar de los requisitos de la fase de diseño con el personal de negocio, sino con el personal técnico que utilizará la herramienta, del mismo modo que no parece ideal hablar con el personal técnico acerca de los objetivos de negocio.

Análisis CATWOE

El análisis CATWOE forma parte de la metodología de sistemas blandos y se centra en la identificación de los factores clave para el éxito de un proyecto, de los cuales se derivan los requisitos del desarrollo. En concreto, CATWOE es un acrónimo que se refiere a:C:Customers (clientes), que son quienes más se beneficiarán del software a desarrollar.A:Actors (actores), que son las partes interesadas que tendrán un rol activo a la hora de utilizar el software.T:Transformation process (proceso de transformación), que se refiere a qué cambios generará el software en la organización.W:Weltanschauung (perspectiva global), que se refiere a los impactos más amplios que tendrá la implementación del software.O:Owner (propietario), que se centra en identificar y conocer las necesidades del propietario del proceso dentro del cual se integrará el software.E:Environmental constraints (restricciones del entorno), que pregunta por posibles aspectos externos que puedan tener un impacto sobre el éxito del mismo.

Diagramas BPMN

Los diagramas BPMN no son específicos de la toma de requisitos, pero constituyen una herramienta muy interesante a la hora de establecer una comunicación productiva con el cliente de negocio. En este contexto, el propósito de un diagrama BPMN es representar los procesos de negocio que debe satisfacer el software. Para ello se representan las actividades como cajas con esquinas redondeadas; los diferentes eventos con círculos (incluyendo el inicio y el final del proceso, pero también tiempos de espera, por ejemplo); y los puntos de decisión u otras alteraciones del flujo de trabajo mediante cuadriláteros con forma de diamante. El responsable de la toma de requisitos deberá identificar aquellos puntos en los cuales el flujo de trabajo habitual puede salirse de lo normal y dar lugar a una excepción, la cual deberá ser modelada y programada según necesario.

Key Performance Indicators (KPIs)

A pesar de que los KPIS (del inglés, Key Performance Indicators, indicadores clave de rendimiento) no son una herramienta o metodología para la toma de requisitos, sí que son fundamentales a la hora de establecer con claridad qué objetivos de negocio debe lograr y cómo se van a medir. Por ejemplo, un KPI de Dropbox será el ancho de banda que los servidores subyacentes son capaces de proporcionar: de nada serviría que Dropbox tuviera un diseño elegante e intuitivo si el ancho de banda del servicio se limita a 1kb/s.

Estas son las cuatro prácticas que más interesantes nos parecieron, además de las 3 C’s de la toma de requisitos: concisión, claridad y concreción. Todo ello, junto con nuestra experiencia en proyectos pasados y presentes, se ha destilado en nuestro proceso de referencia para la toma de requisitos, el cual iremos mejorando con la experiencia. Si os interesan más detalles, ¡no tenéis más que preguntarnos!