Cuadernos de Calidad y CMMI: Gestión y definición de requisitos

“El cliente no sabe lo que quiere, hasta que se lo muestras”. – Steve Jobs

Nueva edición de los Cuadernos de Calidad y CMMI con información que puede ayudarle en diversos tópicos relacionados con la calidad y el modelo CMMI. En este número se presentan temas relacionados con la gestión y definición de requisitos.

Requisito es la condición o circunstancia necesaria para algo. Requerimiento es la acción y efecto de requerir. Muchas veces se utilizan de manera indistinta, pero hay diferencias en el uso de uno u otro. En este cuaderno se presentan artículos relacionados con el requisito, como condición a cumplir por un producto o servicio y la forma en que se puede garantizar que se cumpla.

Puede obtener el cuaderno directamente al comprar en Amazon.

Aproveche la oferta por tres días y descargue el cuaderno de manera gratuita 
(Válido del 30 de agosto al 1 de septiembre)

JIRA y RMsis dos herramientas en una solución integral

Ronhjones

El uso de herramientas en apoyo a los procesos es fundamental para optimizar los resultados. A partir de la definición del proceso se deben seleccionar y evaluar las herramientas que ayudan a mejorar los resultados que se esperan obtener. Posteriormente, ajustarla adecuadamente y capacitar en el uso efectivo de la herramienta para dar respuesta a las necesidades del proceso y como resultado obtener los beneficios que se esperan para el negocio. Mientras mayor flexibilidad tenga la herramienta, mucha mayor posibilidad de ajustarse a las necesidades que se tienen. 

Inconsistencias con requisitos

Richard Croft

Uno de los cambios que se realizaron con la nueva versión de CMMI tiene que ver con la SP1.5 de REQM. En esta práctica se identifican inconsistencias entre los requisitos establecidos y los planes y productos de trabajo que reflejan esos requisitos.


El cambio básicamente modifica la frase "identificar las inconsistencias" por "asegurar que los planes y productos de trabajo permanecen alineados con los requisitos". Con esta variación se le da más sentido a la práctica, que es una de las más cuestionadas particularmente cuando no se presentan problemas.

Cambios a requisitos y control de cambios

El modelo CMMI establece prácticas para control de cambios en dos áreas de proceso: REQM y CM. En la primera la SP 1.3 gestiona los cambios a requisitos durante el proyecto, mientras que en la segunda la SG2 contiene prácticas para registrar y controlar los cambios a los componentes bajo gestión de la configuración.


Estas prácticas son complementarias y para efectos del modelo se separan para analizarlas con propósitos diferentes. La organización puede determinar un mecanismo de control que le permita cumplir con ambas perspectivas.

Asignación de requisitos a componentes

La SP 2.2 en RD establece la necesidad de asociar los componentes del producto con los requisitos que los definen. De manera que los componentes que se van derivando tienen un requisito asociado que los define. 


Por su parte en REQM, en la SP 1.4 se establece la trazabilidad bidireccional de los requisitos hacia las entidades que se obtienen. Lo cual constituye una herramienta fundamental en la evaluación de impacto de los cambios a requisitos. 


¿Cuál es el sentido de cada práctica, si aparentemente ambas llevan una relación de requisitos a componentes?

Características deseables de un requisito

Dentro de las prácticas de REQM en la SP1.1 se tiene que establecer cuáles son los requisitos que serán acordados. Para lograr esto además de que se tenga una fuente autorizada para definir los requisitos, éstos deben ser adecuadamente definidos. Cuando se implementa en conjunto con RD, en la SP 3.3, se puede revisar el cumplimiento de esas características como elemento para comprobar que los requisitos son necesarios y suficientes. 


Para facilitar la actividad se puede elaborar una lista de verificación con las características que se deben cumplir y considerarlas en la realización de la revisión de los requisitos. Los requisitos que no cumplan con estas condiciones deben ser redefinidos y ajustados antes de ser comprometidos para evitar problemas en el desarrollo del producto.

10 Claves para una adecuada definición y gestión de requisitos

El establecimiento de los requisitos para un producto es vital para obtener un excelente resultado. Es la base para arrancar el trabajo de desarrollo y la fuente de muchos de los problemas que se presentan, por lo que una adecuada definición y gestión de los mismos es la clave para evitar contratiempos, retrabajos e incrementos de costos.

 Existen elementos imprescindibles, que se deben tomar en cuenta, para una correcta definición y gestión de requisitos y que son presentados aquí como diez elementos claves. Estos deben ser considerados como parte del sistema de procesos, prácticas, herramientas y disciplinas a integrar para identificar, analizar, especificar, verificar y gestionar los requisitos de un producto

Gestión de requisitos antes que definición de requisitos

El modelo CMMI DEV en su representación por etapas establece REQM a nivel 2 de madurez antes que RD que aparece a nivel 3. Para el orden de implementación de las áreas de proceso, le da mayor prioridad a la gestión de requisitos que a la definición de requisitos. Esto es una duda, sino en todos, en la gran mayoría de los cursos de Introduction to CMMI.
En principio el modelo va de un proceso caótico y reactivo a un proceso de mejora continua definido, controlado y proactivo. En ese orden iniciamos poniendo orden a lo que se está haciendo para luego hacerlo mejor hasta intentar alcanzar la perfección o excelencia en lo que se hace.

Herramientas de apoyo a requisitos

El modelo CMMI no establece como condición el uso de herramientas específicas para la implementación de las prácticas en las áreas de proceso. Aunque la herramienta no hace el proceso, es útil apoyarse en ellas para facilitar las tareas que se requieren. En particular las áreas de proceso de REQM y RD se benefician mucho si el proceso se refuerza con alguna herramienta.
IRQA es una herramienta desarrollada por Visure que permite identificar, analizar y gestionar los requisitos. Una solución completa e integral para el proceso de definición y gestión de requisitos.

Requisitos del cliente, producto, componentes del producto e interfaz

En el modelo CMMI las prácticas de RD consideran básicamente tres niveles de requisitos, del cliente, producto y componentes del producto. Adicionalmente a estos se menciona la identificación de requisitos de interfaz, igualmente importantes. 
Los diferentes niveles de requisitos cubren, durante todo el desarrollo del producto, las diferentes etapas de refinamiento de las necesidades iniciales del cliente que son diseñadas en la solución a nivel de requisitos del producto y a un nivel más bajo de instanciación como requisitos de componentes del producto. Estos niveles de requisitos se van obteniendo a través de diferentes iteraciones y refinamientos donde se detallan, derivan y asignan las dependencias de requisitos de alto nivel hacia los requisitos obtenidos a niveles más bajos. 

Requerimientos vs. requisitos

En diversas situaciones se hace uso indistinto de los términos requerimientos y requisitos. En CMMI se usa en diversas prácticas el término "requirement", pero ¿cúal sería el término correcto a emplear?.
En término generales el requerimiento se refiere a la petición que se hace de algo, se requiere o solicita. Esto estaría más relacionado en inglés con la palabra "request". El requisito es la condición que debe cumplir algo, en general el requisito cumple con lo que se requiere o el requerimiento (la solicitud). La traducción del término "requirement" está asociado con la necesidad por lo que sería más adecuado traducirlo como requisito.
En general se acostumbra usar ambos términos de manera indistinta pero entendiendo un poco el significado y desligándolo del uso de un anglisismo, tendría más sentido en español el uso de requisito para referirse a las prácticas descritas principalmente en RD y REQM. Mientras que el requerimiento quedaría básicamente como la petición que se hace de algo.
Incluso en wikipedia hay dos entradas diferentes para este concepto, existe requerimientos e ingeniería de requisitos. En México se usa más el término requerimientos mientras que en otros países de habla hispana se utiliza más requisitos.

Atributos de calidad en CMMI

El modelo CMMI establece la identificación de los atributos de calidad. A partir de la versión 1.3 se hace un mayor énfasis en su detección y consideración como parte del proceso de desarrollo. 


Según el glosario, son una propiedad del producto o servicio que determina el punto de vista de calidad de los interesados principales y que son caracterizados por determinadas métricas. No están directamente asociados a funcionalidades del producto o servicio aunque tienen una influencia significativa en la arquitectura. Se consideran como atributos de calidad los relacionados con: la seguridad, confiabilidad, utilización, capacidad de mantenimiento y de respuesta, tiempo de desarrollo y rendimiento. 


RD identifica como parte de los requisitos del cliente los atributos de calidad que se consideran como parte del producto resultante y que deben ser considerados en la descomposición e identificación de requisitos de productos, componentes del producto e interfaz durante la creación de la arquitectura del producto. 


Es parte de la práctica específica 3.2 donde se establece la funcionalidad requerida y los atributos de calidad. Adicionalmente considera el atributo de calidad como uno de los elementos de revisión en la definición de escenarios operativos, evaluación de requisitos y criterios de aceptación. Este mismo criterio se complementa con lo establecido por REQM para aceptar los requisitos que van a ser comprometidos. 


Como parte de las soluciones que se plantean y diseñan en TS se debe considerar los criterios relacionados con los atributos de calidad, de manera que el producto cumpla con los requisitos y propiedades que determinan la aceptación del producto por el cliente e interesados. 


Otras áreas de proceso que consideran de alguna manera los atributos de calidad son: 

• CM revisa mediante las auditorias de la configuración que los componentes que se entregan o desarrollan cumplen con los atributos de calidad como parte de la evaluación de la consistencia. 
• DAR los considera para las guías de decisión en casos que afecte la arquitectura del producto.
• IPM los toma en cuenta para el ajuste y establecimiento de los entornos de trabajo.
• OPM revisa estos atributos como parte de las necesidades del negocio para considerar mejoras a la calidad del producto.
• IPM como consideración de los elementos que debe cubrir el producto integrado, los entornos y criterios de integración. 
• QPM los analiza como parte de los indicadores a controlar cuantitativamente en el proyecto.
• RSKM considera una posible fuente de riesgos y por tanto se identifican riesgos asociados que pueden afectar, o ser afectados por, los atributos de calidad.

Para el caso de los atributos de calidad del software, están definidos en la ISO/IEC 9126 de la que se puede encontrar un resumen en la siguiente dirección http://www.sqa.net/iso9126.html

Resumen de Desarrollo de requisitos en CMMI DEV v1.3

El área de proceso de Requirements Development (RD) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito producir y analizar los requisitos del cliente, del producto y de los componentes del producto.


Las prácticas definidas en esta área de proceso permiten determinar todos los requisitos del proyecto, ya sea para el desarrollo o mantenimiento. Parte de los requisitos del cliente que son derivados en requisitos del producto hasta refinarlos al nivel de requisitos de los componentes del producto, todo esto durante el ciclo de vida del producto. El proceso de obtención y refinamiento de los requisitos va estrechamente vinculado con el diseño del producto por lo que estas prácticas están relacionadas, de manera recursiva, con las establecidas en el área de proceso de Technical Solution (TS).


Los cambios que se requieran a los requisitos establecidos en RD son gestionados por REQM, por lo que RD, TS y REQM están estrechamente relacionados y operan de manera concurrente. La razón por la que REQM está en un nivel de madurez inferior a RD puede estar relacionado con el principio que establece que primero hay que establecer un control y orden en las actividades que se realizan, esto se logra con REQM, para después especializar la forma en que se realizan las actividades, en este caso las prácticas de RD.


RD establece en las primeras metas específicas la definición de los requisitos del cliente y los requisitos del producto y componentes. Con la meta tres complementa las dos anteriores para garantizar que todos los requisitos obtenidos son adecuadamente analizados y validados durante las diferentes etapas del desarrollo del producto. 


En la versión 1.3 del modelo no existen cambios significativos en cuanto a las metas y prácticas específicas para esta área de proceso.


Definir los requisitos del cliente

SG1 Las necesidades, expectativas, restricciones e interfaces de los interesados son recogidas y traducidas a requisitos del cliente.

• SP1.1 Obtener las necesidades, las expectativas, las restricciones, y las interfaces de los interesados para todas las fases del ciclo de vida del producto.
• SP1.2 Transformar las necesidades, las expectativas, las restricciones y las interfaces de las partes interesadas en requisitos del cliente.

Derivar los requisitos del producto y componentes del producto

SG2 Los requisitos del cliente son refinados y elaborados para desarrollar los requisitos del producto y de componentes del producto.

• SP2.1 Establecer y mantener los requisitos del producto y de componentes del producto, los cuáles están basados en los requisitos del cliente.
• SP2.2 Asignar los  requisitos  para cada componente del producto.
• SP2.3 Identificar los  requisitos  de la interfaz.

Analizar y validar los requisitos definidos

SG3 Los  requisitos son analizados y validados, y una definición de la funcionalidad requerida es desarrollada.

• SP3.1 Establecer y mantener los conceptos operativos y los escenarios asociados.
• SP3.2 Establecer y mantener una definición de la funcionalidad requerida y los atributos de calidad.
• SP3.3 Analizar los requisitos para asegurarse de que son necesarios y suficientes.
• SP3.4 Analizar los requisitos para equilibrar las necesidades y las restricciones de los interesados.
• SP3.5 Validar los requisitos para asegurar que el producto resultante se ejecutará según lo previsto en el entorno del usuario.

Resumen de Gestión de requisitos en CMMI v1.3

El área de proceso de Requirements Management (REQM) corresponde al nivel 2 en la representación por etapas y está ubicada dentro de la categoría de proceso de Gestión de proyectos para la representación continua. Tiene como propósito gestionar los requisitos de los productos y de los componentes del producto del proyecto, e identificar inconsistencias entre esos requisitos y los planes y productos de trabajo del proyecto.

Las prácticas de REQM son la base para la definición y ejecución de las actividades del proyecto y constituyen la entrada para PP. Básicamente aquí se garantiza que los requisitos  son válidos, tanto por el contenido como por la fuente de donde se originan, que están comprometidos y que si son modificados se realiza de manera controlada. Para poder determinar el impacto de los cambios es imprescindible contar con una traza de los  requisitos hacia las diferentes entidades del producto y a la inversa.

Dudas sobre la evaluación e implementación CMMI

Roberto Fiadone

Pregunta: ¿Cuál es el costo de evaluación del modelo CMMI para una empresa pequeña (1-50 empleados), mediana (51-200 empleados), grande (más de 200 empleados)? 

Respuesta: El costo es más dependiente del nivel de madurez o la cantidad de áreas de proceso que se van a revisar en el proceso de SCAMPI que del tamaño de la organización. Posiblemente el esfuerzo para las organizaciones no es proporcional al tamaño, la muestra que se toma es básicamente la misma. Posiblemente para el nuevo esquema de muestreo para el SCAMPI en la versión 1.3 se considere algo más adecuado al tamaño de la organización. 

En una organización más grande posiblemente hay independencia de funciones mientras que en las pequeñas se cubren múltiples funciones con una sola persona. Esto para la primera podría representar que se tengan que programar más sesiones de entrevistas que en el segundo caso. 

Sobre el costo es una pregunta difícil porque influyen muchos factores propios de cada organización y evaluador. Si consideramos únicamente los honorarios del evaluador, suponiendo que fueran $200.00/hora. Podríamos considerar para una evaluación de nivel 2 unas 64 a 96 horas que serían entre $12,800.00 y $19,200.00. Para el nivel 3, 4 y 5 se podrían considerar entre 96 y 160 horas. 

En el caso de evaluaciones de niveles 4 y 5 se requiere un perfil más especializado de evaluador y posiblemente la tarifa sea más alta, para realizar el cálculo se podrían considerar $250.00/hora. Estos valores son únicamente como referencia y no corresponden a los costos reales que se pueden incurrir durante un proceso de evaluación, por lo que no deben ser considerados a efectos de comparación. 

A partir de la versión 1.3 se integra un pago por evaluación al SEI de $1,000.00 que se tendría que considerar en los costos.  

Pregunta: Opinión sobre la implementación del modelo en empresas de software pequeñas y medianas. 

Respuesta: El modelo es ampliamente aplicado en este tipo de organizaciones, según se muestra en los reportes del SEI, el 77.5% de las organizaciones evaluadas son menores de 200 personas y dentro de esa cantidad el 39.3% son menos de 50 personas. 

Estas prácticas le dan la posibilidad a estas organizaciones de competir en igualdad de condiciones con los grandes desarrolladores ya que adoptan prácticas que caracterizan a la industria en general. 

Pueden demostrar una mejor calidad en sus productos, precios competitivos sin presionar a la organización además de un mejor control en su crecimiento. 

Lo que más afecta a estas organizaciones es la fuga de conocimiento por la alta rotación de personal y esto se controla adecuadamente con la definición e institucionalización de procesos, como parte de la cultura de la empresa. 

Algo a considerar en las organizaciones pequeñas y medianas es realmente buscar la eficiencia de las prácticas, más allá de la efectividad. El uso eficiente de los recursos y funciones es vital para estas organizaciones. 

Los ciclos de mejora deben ser cortos, que demuestren beneficios y sobre esta base continuar con otras mejoras sin exponer toda la operación a cambios que no pueden ser mantenidos por la operación. Lo que es bueno para los demás, no necesariamente es bueno para una empresa.

Técnicas para identificación de requisitos

El modelo CMMI en el área de proceso de Requirements Development (RD) establece la necesidad de identificar de manera proactiva las necesidades, expectativas, restricciones y supuestos del cliente. Esas prácticas se reflejan en la meta específica 1 en particular en la práctica específica 1.1. Elicit needs 
Para identificar las necesidades del cliente se utilizan técnicas que permiten determinar de manera explícita, documentada, los requisitos implícitos que tiene el cliente. Esta actividad es continua durante el ciclo de desarrollo y combina, en diferentes puntos, diversas técnicas para obtener la visión más completa de sus necesidades. 

Resumen de Validación

El área de proceso de Validation (VAL) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito demostrar que un producto o componente de producto se ajusta a su uso previsto cuando se sitúa en su entorno previsto. Las prácticas definidas en el área de proceso de VAL, en conjunto con VER, tienen elementos muy similares pero desde diferentes perspectivas. En su aplicación pueden coincidir utilizando las mismas técnicas, pero cuidando que se demuestren ambos enfoques. Mientras que en VER se busca demostrar que los productos de trabajo cumplen con los requerimientos que los definen en VAL se demuestra que el producto generado puede ser utilizado. Una diferencia entre VER y VAL está en que el primero puede ser aplicado a productos internos, no necesariamente dirigidos al cliente, mientras que el segundo está orientado a los productos que serán entregados y utilizados por el cliente o usuarios finales. Una pequeña diferencia que se aprecia al leer detenidamente el propósito y entender la diferencia entre productos de trabajo y componentes del producto, en el glosario del modelo. Lo cual no quiere decir que se aplique hasta el final del desarrollo, sino que por principio son prácticas que se aplican en todas las fases del desarrollo del producto utilizando las diferentes perspectivas que se van obteniendo del producto final. Otro elemento diferente en el momento de aplicar las validaciones es el entorno de operación. Las prácticas de validación deben aplicarse en un ambiente similar, o lo más cercano posible, al ambiente real de operación del producto, que permita ubicar al usuario en el contexto de uso y determinar cualquier problema que se pueda presentar. La creación de este ambiente de validación es un elemento fundamental en la preparación, sobre todo por la cuestión de presupuesto y tiempos para su preparación. La identificación, investigación, exploración y definición adecuada de los requerimientos en RD puede reducir las diferencias de perspectivas entre VER y VAL. Al final cuando los requerimientos implícitos, muchas veces relacionados con el uso y operación, son establecidos de manera explícita la diferencia entre VER y VAL son reducidas considerablemente.

La aplicación de VER y VAL se da en conjunto con otras áreas de proceso de ingeniería como RD y TS, pero son fundamentales para cumplir la meta específica 3 de PI que tiene que ver con la integración de los componentes y liberación del producto.

VAL requiere por una meta establecer la estrategia de validación y por la otra ejecutar las validaciones definidas en la estrategia y analizar los resultados. Estrategia de validación SG1 La preparación para la validación es llevada a cabo.

• SP1.1 Seleccionar los productos y los componentes de producto a validar y los métodos de validación que serán usados para cada uno.
• SP1.2 Establecer y mantener el entorno necesario para dar soporte a la validación.
• SP1.3 Establecer y mantener los procedimientos y los criterios de validación

Ejecutar las validaciones

SG2 El producto o los componentes de producto son validados para asegurar que sean adecuados para usar en su entorno operacional previsto.

• SP2.1 Realizar la validación sobre los productos y los componentes de producto seleccionados.
• SP2.2 Analizar los resultados de las actividades de validación.

Resumen de Desarrollo de requerimientos

El área de proceso de Requirements Development (RD) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito producir y analizar los requerimientos del cliente, del producto y de los componentes del producto. Las prácticas definidas en esta área de proceso permiten determinar todos los requerimientos del proyecto, ya sea para el desarrollo o mantenimiento. Parte de los requerimientos del cliente que son derivados en requerimientos del producto hasta refinarlos al nivel de requerimientos de los componentes del producto, todo esto durante el ciclo de vida del producto. El proceso de obtención y refinamiento de los requerimientos va estrechamente vinculado con el diseño del producto por lo que estas prácticas están relacionadas, de manera recursiva, con las establecidas en el área de proceso de Technical Solution (TS). Los cambios que se requieran a los requerimientos establecidos en RD son gestionados por REQM, por lo que RD, TS y REQM están estrechamente relacionados y operan de manera concurrente. La razón por la que REQM está en un nivel de madurez inferior a RD puede estar relacionado con el principio que establece que primero hay que establecer un control y orden en las actividades que se realizan, esto se logra con REQM, para después especializar la forma en que se realizan las actividades, en este caso las prácticas de RD. RD establece en las primeras metas específicas la definición de los requerimientos del cliente y los requerimientos del producto y componentes. Con la meta tres complementa las dos anteriores para garantizar que todos los requerimientos obtenidos son adecuadamente analizados y validados durante las diferentes etapas del desarrollo del producto. Definir los requerimientos del cliente

SG1 Las necesidades, expectativas, restricciones e interfaces de los interesados son recogidas y traducidas a requerimientos de cliente.

• SP1.1 Obtener las necesidades, las expectativas, las restricciones, y las interfaces de los interesados para todas las fases del ciclo de vida del producto.
• SP1.2 Transformar las necesidades, las expectativas, las restricciones y las interfaces de las partes interesadas en requerimientos del cliente.

Derivar los requerimientos del producto y componentes del producto

SG2 Los requerimientos del cliente son refinados y elaborados para desarrollar los requerimientos del producto y de componentes del producto.

• SP2.1 Establecer y mantener los requerimientos del producto y de componentes del producto, los cuáles están basados en los requerimientos del cliente.
• SP2.2 Asignar los requerimientos para cada componente del producto.
• SP2.3 Identificar los requerimientos de la interfaz.

Analizar y validar los requerimientos definidos

SG3 Los requerimientos son analizados y validados, y una definición de la funcionalidad requerida es desarrollada.

• SP3.1 Establecer y mantener los conceptos operativos y los escenarios asociados.
• SP3.2 Establecer y mantener una definición de la funcionalidad requerida.
• SP3.3 Analizar los requerimientos para asegurarse de que son necesarios y suficientes.
• SP3.4 Analizar los requerimientos para equilibrar las necesidades y las restricciones de los interesados.
• SP3.5 Validar los requerimientos para asegurar que el producto resultante se ejecutará según lo previsto en el entorno del usuario.

Resumen de Gestión de requerimientos

El área de proceso de Requirements Management (REQM) corresponde al nivel 2 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito gestionar los requerimientos de los productos y de los componentes del producto del proyecto, e identificar inconsistencias entre esos requerimientos y los planes y productos de trabajo del proyecto. Las prácticas de REQM son la base para la definición y ejecución de las actividades del proyecto y constituyen la entrada para PP. Básicamente aquí se garantiza que los requerimientos son válidos, tanto por el contenido como por la fuente de donde se originan, que están comprometidos y que si son modificados se realiza de manera controlada. Para poder determinar el impacto de los cambios es imprescindible contar con una traza de los requerimientos hacia las diferentes entidades del producto y a la inversa. Cuando se presentan cambios a requerimientos, y es algo que sucederá en la gran mayoría de las ocasiones, pueden presentarse inconsistencias particularmente por problemas de comunicación dentro del equipo que desconoce los cambios que han sido aprobados. REQM debe identificar esas situaciones y tomar acciones correctivas para garantizar su solución. Gestionar los requerimientos SG1 Los requerimientos son gestionados y las inconsistencias con los planes y productos de trabajo del proyecto son identificadas.

• SP1.1 Desarrollar una comprensión del significado de los requerimientos con los proveedores de los requerimientos.
• SP1.2 Obtener el compromiso de los participantes de proyecto sobre los requerimientos.
• SP1.3 Gestionar los cambios a los requerimientos a medida que evolucionan durante el proyecto
• SP1.4 Mantener la trazabilidad bidireccional entre los requerimientos y los productos de trabajo
• SP1.5 Identificar las inconsistencias entre los planes del proyecto, los productos de trabajo y los requerimientos.

Requerimientos

Los requerimientos, según el glosario de CMMI, es la condición o capacidad necesaria por un usuario para resolver un problema o alcanzar un objetivo. También se define como la condición o capacidad que se debe cumplir o cubrir por un producto o componente para satisfacer un contrato, estándar, especificación, u otro documento formal. Es la representación documentada de la condición o capacidad para cubrir los puntos anteriores. Deben considerar que todos los proyectos tienen requerimientos, sino no tendrían sentido de existir. El área de proceso de Requirements Management (REQM) administra los requerimientos del proyecto, tanto técnicos como no técnicos (aquí podemos considerar costo y calendario). Las prácticas definidas aquí no están orientadas a desarrollar los requerimientos, más bien garantizan que todos en el proyecto trabajen con requerimientos autorizados. Por su parte Requirements Development (RD) genera los requerimientos del cliente, producto y componentes y Technical Solution (TS) implementa las soluciones a los requerimientos. Para lograr controlar la interrelación entre todos es imprescindible contar con una matriz de rastreabilidad, la que es un elemento crítico para RD y TS y que es mantenida con las prácticas de REQM. Necesitamos la matriz para cubrir con:

• REQM SP 1.1 Acordar que los requerimientos son de una fuente adecuada y que son los acordados
• RD SP3.3 Analizar los requerimientos para determinar si son necesarios y suficientes. Esta práctica contribuye a REQM SP1.1
• REQM SP1.4 Mantener la rastreabilidad bidireccional de los requerimientos y productos de trabajo. Esto contribuye a determinar si satisface los requerimientos a nivel superior RD SP3.3

La rastreabilidad bidireccional, requerida por REQM SP1.4, es la capacidad de rastrear los requerimientos hacia los productos finales y en sentido inverso. La idea es poder determinar que todos los requerimientos han sido cubiertos y que los productos corresponden a un requerimiento válido. Esto se conoce como rastreabilidad vertical y es suficiente para cubrir la rastreabilidad direccional. Existe otra traceabilidad horizontal que se da entre componentes o grupos de trabajo con el propósito de evitar conflictos potenciales entre las interfaces y que es fundamental para cubrir las prácticas de Product Integration (PI), en particular las prácticas específicas relacionadas con SG2. Las interfaces, internas y externas, de los componentes del producto son compatibles. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor