La importancia de la nomenclatura en la gestión de requisitos

 

Requirements Consultants

Cuando hablamos de la necesidad de completar el conjunto de requisitos de un proyecto TI solemos asumir que todos los stakeholders entienden el término requisito de la misma manera.

Sin embargo, la utilización de la misma palabra (requisito) en español, para referirse tanto a las necesidades del negocio como a las necesidades del usuario y a las funcionalidades requeridas del software, puede llevar a malentendidos en la ejecución del proyecto.

Por ejemplo, si en una reunión del equipo de proyecto alguien lanzara la siguiente propuesta: "Necesitamos un analista que pueda aplicar la metodología AGILE porque carecemos del tiempo necesario para analizar todos los requisitos y tenemos que priorizar"  cabría preguntarse si por priorizar requisitos el proponente se refiere a priorizar la definición funcional o a priorizar con el negocio los requisitos de usuario.

Aplicar un enfoque AGILE para acelerar un diseño funcional sí adelantaría la entrega del proyecto, pero si aún no se han validado los requisitos de usuario con negocio, el cuello de botella no se desatasca aplicando la metodología AGILE.

Para evitar la confusión que pueda generar esta nomenclatura consideramos recomendable revisar con los todas las partes interesadas el plan de validación de requisitos, aclarando a la vez lo que entenderemos por dicho término en cada hito del proyecto.

En Leverforce vemos los requisitos como cinco conjuntos claramente diferenciados y que el BA va definiendo de manera secuencial en entregables, manteniendo la trazabilidad entre ellos: 

 requirements lifecycle

Leverforce Necesidad de NegocioiterationLeverforce Requisito de usuarioiterationLeverforce Requisitos FuncionalesiterationLeverforce Especificaciones

Como mostramos en el gráfico, según progresa el proyecto, desde el caso de negocio hasta la certificación, nos vamos moviendo del ámbito del negocio (esferas azules) al ámbito de la solución (esferas verdes).

Siguiendo con el ejemplo antes citado, en la declaración "...carecemos del tiempo necesario para analizar todos los requisitos y tenemos que priorizar"  el proponente podría entender por requisitos el conjunto 2 (requisitos de usuario), en cuyo caso el análisis no se ha centrado aún en el ámbito de la solución sino que los stakeholders están validando los casos de uso que aportarían más valor al negocio. Qué software o tecnología se va aplicar para hacer posible estos casos de uso aún no es relevante en este análisis y el área técnica poco puede aportar en dicha validación.

En contraposición, si por requisitos el proponente se refiere a los conjuntos 4 y 5 (especificaciones y criterios de aceptación necesarios para la ejecución del proyecto) entonces el conjunto 2 ya ha sido validado por los usuarios y sí estamos hablando de la necesidad de priorizar los recursos técnicos para agilizar la entrega de un diseño y ejecutar el proyecto (Añadir un enfoque BA AGILE, por ejemplo).

En resumen, el BA debe asegurarse que los stakeholders se están centrado en entregar el conjunto de requisitos que les es relevante según la fase en la que se encuentre el proyecto:

 

requirements agile

 

Añadimos una descripción detallada de cada conjunto de requisitos al pie de este artículo, pero si el lector puede reconocer claramente esta nomenclatura en sus iniciativas, pasemos a examinar las implicaciones que la confusión del término "requisito" puede generar en la ejecución de un proyecto.

Business Process Model Analysts Gestión de expectativas divergentes en el proyecto: Cuando el equipo de desarrolladores habla de requisitos normalmente se refiere al conjunto 4, es decir a las especificaciones necesarias para gestionar la entrega del desarrollo. Por otro lado, cuando el negocio habla de requisitos, se suele referir al conjunto de requisitos de usuario (conjunto 2). Un analista de negocio efectivo debe optimizar y filtrar las comunicaciones de tal manera que el equipo técnico y el negocio no pierdan el tiempo ni en malentendidos generados por las distintas expectativas que puedan tener de la definición de requisitos, ni en revisar entregables que no les sean relevantes. 

Business Analysis Consultants El enfoque AGILE: Un Analista de Negocio AGILE será un experto en definir requisitos de muy bajo nivel, necesarios para gestionar la certificación del desarrollo (Conjunto 5). En ocasiones un analista AGILE tendrá que remitirse al requisito funcional de alto nivel (Conjunto 3) para renegociar las prioridades durante la ejecución, o para asegurarse que las especificaciones son trazables a la intención y el valor original del requisito.

Gap Analysis Risks El enfoque AGILE puede no ser suficiente para reconducir un proyecto: Si los requisitos no son definidos de manera secuencial como lo describimos en los gráficos (Por ejemplo, si el alcance del proyecto (conjunto 4) no ha sido negociado en base a un análisis funcional validado (conjunto 3) o si el análisis funcional no se ha basado en requisitos de usuario validados (conjunto 2) el analista AGILE no podrá representar a los stakeholders durante la certificación. Los dueños del producto o del proceso tendrán que estar disponibles durante los sprints  (En lo que sería el enfoque AGILE más puro, pero también el menos conveniente y el más caro para muchas organizaciones). 

   Larry Velarde, CBAP®

Conjuntos de requisitos en detalle:

(1) Necesidad de negocio: Cada necesidad define lo que el cliente o el impulsor de la iniciativa (sponsor) busca obtener con los cambios solicitados en servicios TI, en términos de eliminación de problemas, mitigación de riesgos o aprovechamiento de oportunidades en su negocio. La necesidad es el por qué de la petición (el por qué de los requisitos de usuario relacionados).

2) Requisito de usuario: Un requisito de usuario explica un comportamiento o condición que el usuario necesita de un servicio TI para satisfacer la necesidad de negocio. Ejemplo: El usuario necesita... (requisito de usuario) para que el negocio pueda...(necesidad de negocio).

3) Requisito Funcional: Un requisito funcional es la propuesta inicial del proveedor de TI que explica lo que hay que construir/cambiar en un servicio para que el usuario pueda disponer del comportamiento o condición solicitado en el requisito de usuario.

4) Especificación: Una especificación es un requisito funcional que se ha formalizado en un acuerdo (Un requisito funcional que es incluido en el alcance del proyecto) y que incluye definiciones finalizadas y validadas por el cliente y el proveedor TI o desarrollador.

5) Criterios de aceptación: Una certificación permite organizar los distintos criterios de aceptación de usuario que deben ser cumplidos por el proveedor de TI antes de dar por concluido el sprint. Un criterio de aceptación es un requisito expresado en el más bajo nivel  y necesario para certificar la entrega del producto. Un criterio de aceptación puede estar expresado en diversas formas: Historia de usuario, Guión de aceptación, especificaciones funcionales y no funcionales (Casos de uso, UML, parametros de configuración, diagramas de clase, etc.). La posibilidad de descomponer una certificación en múltiples criterios de aceptación permite priorizar la ejecución del proyecto siguiendo metodologías AGILE. 

 Sobre el nivel de definición de requisitos en enfoques AGILE: La metodología AGILE requiere mantener una definición limitada de los requisitos funcionales y las especificaciones durante la preparación del proyecto, de tal manera que las definiciones más precisas se faciliten durante el sprint (en la forma de criterios de aceptación del sprint: guiones de aceptación, historias de usuario, etc.). Esta flexibilidad en el enfoque AGILE permite agilizar el proyecto priorizando incrementos del producto durante el desarrollo. Lamentablemente, algunos proveedores de TI confunden la necesidad de mantener una definición limitada de los requisitos funcionales (conjuntos 3 y 4) y la extienden erroneamente al análisis de los requisitos de usuario (Conjunto 2). AGILE aplica sólo al ámbito de la solución no al del negocio. 

Leverforce  Copyright 2016 Leverforce Inc. Reservados todos los derechos. CBAP® es una marca registrada perteneciente al International Institute of Business Analysis. La marca de esta certificación es utilizada por los analistas de negocio que poseen la certificación CBAP, con el permiso expreso del International Institute of Business Analysis. IIBA®, el logo IIBA®, BABOK® y Business Analysis Body of Knowledge® son marcas registradas pertenecientes al Institute of Business Analysis. Estas marcas son utilizadas con el permiso expreso del International Institute of Business Analysis. 

Condiciones legales de uso y acceso a este sitio web

Módulos SAAS

  • Módulo: Necesidad de Negocio +

    Este módulo permite gestionar un listado de las necesidades de negocio asociada al análisis. Cada necesidad define lo que el cliente o el impulsor de la iniciativa (sponsor) busca obtener con los cambios solicitados en servicios TI, en términos de eliminación de problemas, mitigación de riesgos o aprovechamiento de oportunidades en su negocio. Read More
  • Módulo: Requisito de Usuario +

    Este módulo permite gestionar un listado de los requisitos de usuario asociados a una o varias necesidades de negocio. Un requisito de usuario explica un comportamiento o condición que el usuario necesita de un servicio TI para satisfacer la necesidad de negocio. Read More
  • Módulo: Requisito Funcional +

    Este módulo permite gestionar un listado de los requisitos funcionales asociados a uno o varios Requisitos de usuario. Un requisito funcional (Prefijo SLR) es la propuesta inicial del proveedor de TI que explica lo que hay que construir/cambiar en un servicio TI para que el usuario pueda disponer del comportamiento o condición solicitado en el requisito de usuario.. Read More
  • 1
  • 2
  • Modelio UML Tool +

    Leverforce permite la entrada de elementos UML (Casos de uso, Actividades, Actores, etc) desde la herramienta de modelado Modelio, vía la importación de archivos XMI. Read More
  • JIRA Issues +

    Set up JIRA projects from Leverforce’s SLA or Product Increment Modules. Read More
  • 1