Requisitos no funcionales como User Stories
En el Product Backlog se registran los requisitos de un producto. Si se quieren formular desde la perspectiva del usuario, se utiliza frecuentemente el formato de User Story. Aquí se recogen de manera clara y específica los requisitos funcionales del producto. Pero, ¿qué pasa con los requisitos no funcionales? Estos también deben incluirse en un Product Backlog. Aquí descubrirás por qué los requisitos no funcionales son importantes y cómo pueden integrarse mejor en el Product Backlog, por ejemplo, mediante el formato de User Story.
Las diferencias entre requisitos funcionales y no funcionales
Desde hace mucho tiempo se distingue en la gestión de productos entre requisitos funcionales y no funcionales. También en la gestión ágil de requisitos se diferencian ambos conceptos. A continuación presentamos brevemente las diferencias.
Requisitos funcionales
Estos requisitos describen funciones y especificaciones concretas del producto. Como User Story, los requisitos que son importantes para el usuario se enumeran de la manera más precisa y completa posible. Se trata de requisitos específicos del producto que, por lo general, no pueden transferirse a cualquier otro producto. Estos ejemplos son requisitos funcionales típicos:
Como usuario de un programa de procesamiento de texto, quiero poder insertar una tabla.
El programa debe poder calcular el contenido calórico del menú basándose en una fórmula.
Requisitos no funcionales
Los requisitos no funcionales son menos específicos. Describen, por ejemplo, una calidad, una condición o una propiedad del producto. Estos requisitos no son necesariamente específicos del producto. Pueden ser válidos de forma general para varios productos o incluso para todo el diseño o la arquitectura de un software:
Interfaz fácil de usar
Tiempos de respuesta rápidos
Debido a su carácter inespecífico, existe el peligro de que estos requisitos sean tratados de manera secundaria al crear el Product Backlog. Sin embargo, estos requisitos deben estar incluidos, ya que son de gran interés para el usuario. Si la calidad, la fiabilidad o la rapidez no se orientan a las necesidades de los clientes, es muy probable que el producto no se utilice, porque la funcionalidad por sí sola no es suficiente para satisfacer a los usuarios. Por eso surge la cuestión de cómo integrar los requisitos no funcionales en el desarrollo del producto. Formularlos como User Story es útil para poder priorizar este tipo de requisitos.
Así puedes describir requisitos no funcionales en Scrum como User Stories
- Los requisitos no funcionales deben describirse de forma medible
- Considerar los requisitos no funcionales desde la perspectiva del cliente
- ¿Es mejor incluir el requisito no funcional en la "Definition of Done"?
Los requisitos no funcionales deben describirse de forma medible
La afirmación de que tu página debe tener un tiempo de respuesta lo más rápido posible es demasiado imprecisa para el equipo de desarrollo. Aquí no se describen requisitos medibles. "Rápido" es una declaración imprecisa que prácticamente cada desarrollador define de manera diferente.
Para el equipo, en este ejemplo es útil recibir indicaciones exactas. Estas pueden elaborarse conjuntamente. Un medio puede ser una restricción respecto al requisito. De esta manera, las propiedades se vuelven más tangibles y pueden implementarse sin problemas. Aquí, el requisito podría ser, por ejemplo:
La página debería cargar en menos de x segundos.
El consumo de calorías debe mostrarse en menos de 8 segundos después del clic.
Considerar los requisitos no funcionales desde la perspectiva del cliente
Al crear las User Stories, los participantes deben ponerse en la perspectiva del cliente. Para crear la User Story, puede ser útil imaginar el producto de manera concreta con la ayuda de un formato:
"Como <usuario> quiero <objetivo>, para que <razón>"
Este formato simple puede ayudarte a ti y a tu equipo a preguntar por la razón del requisito. ¿Por qué puede ser importante para un usuario que el consumo calórico del menú se muestre en menos de 8 segundos? Porque así el usuario tiene rápidamente un valor de referencia con el que puede completar el menú en su propia planificación de tiempo. Sin embargo, debes cuestionar el resultado y considerar la fórmula solo como una "herramienta de pensamiento". Si la respuesta al "por qué" resulta demasiado complicada o confusa, entonces debes buscar la conversación directa con el cliente o usuario. Pregunta a las personas por qué esta propiedad es personalmente importante para ellos. A veces resulta que un requisito no funcional no es tan inespecífico, sino que simplemente está formulado de manera imprecisa.
¿Es mejor incluir el requisito no funcional en la "Definition of Done"?
¿Se trata de aspectos transversales como, por ejemplo, los tiempos de respuesta de un programa? Entonces puede tener sentido incluirlos en la "Definition of Done". Junto con tu equipo y posiblemente los stakeholders, pueden considerar si un tiempo de respuesta rápido no debería ser un criterio fundamental para todo el sistema.
La inclusión de un requisito no funcional en la Definition of Done tiene como consecuencia que cada ítem debe cumplirlo. Esto es ventajoso cuando se trata, por ejemplo, de un diseño y su conformidad con la identidad corporativa, etc.
Convertir requisitos no funcionales en requisitos funcionales
Los requisitos no funcionales pueden formularse como User Stories, al igual que los requisitos funcionales. Y deberían hacerlo, para que no se pasen por alto ni se descuiden. Es importante que se formulen de forma medible y que se limiten de alguna manera. Si no puedes establecer una limitación por ti mismo, la fórmula presentada anteriormente te ayudará. Pregunta por el "por qué" y así puede servirte como ayuda para pensar. De lo contrario, la conversación directa con tu equipo, los usuarios o los stakeholders te será de ayuda.
Puedes encontrar información inicial sobre Scrum y User Stories en nuestra página web. ¿Quieres adquirir conocimientos profundos sobre Scrum? Entonces inscríbete en una formación de Scrum y aprende los fundamentos del trabajo ágil.
