Estructuras de especificación de requerimientos

Cuando nos enfrentamos a la etapa de especificación de requerimientos (descripción completa del comportamiento del sistema que se va a desarrollar) son muchas las técnicas con las que los podemos dejar reflejados en el SRS (Software Requirements Specification).

La que más he visto usar es la transcripción, es decir, poner por escrito y de forma textual aquello que se requiere que cumpla el sistema que estamos especificando.

El problema que he observado con el uso de esta técnica es que muchas veces se lleva a cabo sin tener en cuenta 2 elementos fundamentales:

1. Utilizar unas estructuras preestablecidas de especificación textual (patrones o estructuras de especificación de requerimientos)
2. Garantizar el cumplimiento de las características que deben tener los «buenos requerimientos»

Si bien cada uno puede definir su propia estructuras de especificación de requerimientos, lo cierto es que ya existen algunas de uso general que podemos utilizar, o reutilizar, adaptándolas a nuestras necesidades si fuere necesario.

He aquí las estructuras de especificación de requerimientos que suelo utilizar. En todas ellas en mayúsculas se expresan los elementos constituyentes que, si van entre corchetes, indican opcionalidad. Junto a cada una de estas partes constitutivas de la estructura encontraréis un texto a modo de ejemplo para representar esa parte del requerimiento.

IEEE 1233

IEEE 1233-1998 es una Guía para el Desarrollo de Especificaciones de Requerimientos de Sistemas. Esta guía, que habitualmente vinculamos a ciclos de de vida de tipo ‘waterfall’ (cascada), nos dice cómo debe de ser un requerimiento bien formado:

ACTOR: The invoicing system
CAPABILITY: shall create an invoice
[CONDITION]: when an order is shipped to the customer
[CONSTRAINT]: unless the order term is “prepaid”

EARS

Easy Approach to Requirements Syntax (EARS) fue desarrollada por Rolls-Royce y presentada públicamente en 2009. Concebida para reducir los problemas acsociados con el lenguaje natural en la especificación de requerimientos, proporciona un conjunto de estructuras para la especificación de la operación normal de un sistema y de su respuesta a comportamientos no deseados, es decir, desviaciones a lo que sería el comportamiento normal esperado.

He tratado de resumir esas distintas estructuras en una sola, aunque os recuerdo que son hasta 5 las existentes:

[TRIGGER]: When an order is shipped to the customer
ACTOR: the invoicing system
ACTION: shall create
OBJECT: an invoice from the order
[CONDITION/CONSTRAINT]: unless the order term is “prepaid”

Como recurso adicional, creo que vale la pena consultar la página del creador de EARS.

User Stories

Las historias de usuario aparecieron dentro del paradigma del ‘Extreme Programming’ a finales de los 90, y son uno de los elementos fundamentales dentro de las denominadas metodologías ágiles.

Su esencia es la de centrarse en el usuario, poniendo el foco sobre qué es lo que requiere el usuario y no sobre lo que el sistema debe hacer, haciendo mención explícita al resultado a obtener.

Desde mi punto de vista humaniza la toma de requerimientos, pero no son en sí mismos requerimientos, sino que son más bien temas de conversación para un posterior entendimiento en profundidad.

PERSONA: As a sales person
ACTION: I want invoices to be created automatically
EXPECTED OTCOME: so that I can safe time

Aquí ACTION necesita expresar que la factura se va a generar de forma automática o, de otro modo, podríamos entender que la va a generar la PERSONA; necesitamos no peder el vínculo con el EXPECTED OUTCOME.

Este modelo, tal cual, no establece condiciones o restricciones al requerimiento, cosa que echo de menos con respecto a los modelos anteriores, ni sabemos qué parte del sistema es la que debe realizar la acción. Los detalles de esa historia se encuentran en sus subhistorias (al romper la historia) y en las condiciones de satifacción.

Job Stories

Existe una corriente crítica hacia las ‘user stories. Las ‘user stories’ parten de la PERSONA y acaban en el EXPECTED OUTCOME. Esto plantea 2 problemas:

1. Estamos especificando cómo debe ser un producto en base a PERSONA, y esas PERSONA tienen unos atributos que las definen (no tienen los mismos atributos definitorios los empleados de un pequeño comercio que los dueños de grandes cadenas alimenticias, ¿verdad?). Así pues, PERSONA supone un sesgo a la hora de definir el producto (seguro que tanto a empleados como a grandes empresarios les gusta comer una buena pizza, por tanto, ¿por qué nos deberíamos dejar llevar por el hecho de pensar que sólo comen pizza los menos pudientes?)
2. Adolecen de falta de contexto, del porqué (la causa) de la necesidad expresada y se centra mucho en la acción concreta (ACTION). El conocer el porqué de las cosas permite tener la mente más abierta a la hora de buscar posibles soluciones y no centrarnos tanto en la acción. Las condiciones o restricciones podemos expresarlas en SITUATION

SITUATION: When an order with no “prepaid” terms is shipped to the customer
MOTIVATION: I want to safe time sending the invoice to the customer
EXPECTED OTCOME: so I can avoid to create it manually from the order

La cosa no va sobre metodologías ágiles

Si bien las estructuras de ‘user story’ y las ‘job story’ se asimilan a metodologías ágiles, mientras que las IEEE 1233 y EARS se asocian a ciclos de vida tipo cascada, no creo que eso sea así necesariamente. Pienso que se trata de una barrera impuesta por algunas líneas de pensamiento, barrera perfectamente franqueable.

Echadle un vistazo a este contenido sobre metodologías ágiles y, tras su lectura, decidid vosotros mismos si existe o no la susodicha barrera.

¿Por cuál de las estructuras me decanto?

Creo que uno tiene que sentirse a gusto con la o las estructuras de especificación de requerimientos que utilice (tanto a nivel personal como a nivel corporativo), pues al final lo que importa es ser productivo y eficiente, minimizando las vueltas atrás en el ciclo de vida por una deficiente redacción de requerimeintos, cosa que se consigue, sobre todo, cumplimiento con las características que deben tener los buenos requerimientos.

En función del tipo de proyecto y tipo de requerimiento que necesito redactar opto por una u otra:

• User Story: las uso para redactar ‘business needs’ (pero sin usar ACTOR) y realizar estimación de esfuerzos en proyectos donde los usuarios participan en mayor o menor grado de la solución.
• Job Story: las uso más bien poco, siempre para expresar ‘business needs’ y realizar estimación de esfuerzos en proyectos donde los usuarios no se implican en la solución.
• IEEE 1233 / EARS: las uso para expresar  ‘user requirements’ y ‘solution requirements’ a la hora de romper ‘business needs’ en requerimientos de mayor detalle; así puedo vincular estos ‘solution requirements’ al porqué de la necesidad que los origina. EARS se adapta más a mis gustos personales, así que es mi primera oopción.