Gestión de requisitos (REQM) (CMMI-

DEV)
Resumen
El objetivo de la Gestión de requisitos (REQM) (CMMI-DEV) es gestionar los requisitos de los
productos y componentes del producto del proyecto y garantizar la alineación entre dichos requisitos
y los planes y productos del proyecto del proyecto.

Descripción
Notas introductorias
Los procesos de gestión de requisitos gestionan todos los requisitos recibidos o generados
por el proyecto, incluidos los requisitos técnicos y no técnicos, así como los requisitos que
la organización impone al proyecto.

En particular, si se implementa el área de proceso Desarrollo de requisitos, sus procesos

generarán requisitos de productos y componentes de productos que también serán
gestionados por los procesos de gestión de requisitos.

A lo largo de las áreas de proceso, donde se usan los términos "producto" y "componente
del producto", los significados previstos también abarcan servicios, sistemas de servicio y
sus componentes. Cuando se implementan todas las áreas de proceso de Gestión de
requisitos, Desarrollo de requisitos y Solución técnica, sus procesos asociados pueden
vincularse estrechamente y llevarse a cabo al mismo tiempo.

El proyecto toma las medidas adecuadas para garantizar que el conjunto de requisitos
aprobados se administre para respaldar las necesidades de planificación y ejecución del
proyecto. Cuando un proyecto recibe requisitos de un proveedor de requisitos aprobado,
estos requisitos se revisan con el proveedor de requisitos para resolver problemas y evitar
malentendidos antes de que los requisitos se incorporen en los planes del proyecto. Una
vez que el proveedor de requisitos y el receptor de requisitos llegan a un acuerdo, los
participantes del proyecto obtienen el compromiso con los requisitos. El proyecto gestiona
los cambios en los requisitos a medida que evolucionan e identifica las incoherencias que
se producen entre los planes, productos de trabajo y requisitos.

Parte de los requisitos de administración es documentar los cambios en los requisitos y su

justificación y mantener la trazabilidad bidireccional entre los requisitos de origen, todos los
requisitos de productos y componentes de productos, y otros productos de trabajo
especificados. (Consulte la definición de "trazabilidad bidireccional" en el glosario).

Todos los proyectos tienen requisitos. En el caso de las actividades de mantenimiento, los
cambios se basan en cambios a los requisitos, diseño o implementación existentes. En los
proyectos que ofrecen incrementos de la capacidad del producto, los cambios también
pueden deberse a la evolución de las necesidades del cliente, la maduración y
obsolescencia de la tecnología y la evolución de los estándares. En ambos casos, los
cambios de requisitos, si los hay, podrían documentarse en las solicitudes de cambio del
cliente o los usuarios finales, o podrían tomar la forma de nuevos requisitos recibidos del
proceso de desarrollo de requisitos. Independientemente de su fuente o forma, las
actividades que son impulsadas por los cambios a los requisitos se gestionan en
consecuencia.

En entornos ágiles, los requisitos se comunican y rastrean a través de mecanismos tales

como atrasos de productos, historiales y maquetas de pantallas. Los compromisos con los
requisitos los toma colectivamente el equipo o un líder de equipo empoderado. Las
asignaciones de trabajo se ajustan regularmente (p. Ej., Todos los días, semanalmente) en
función del progreso realizado y de la mejor comprensión de los requisitos y la solución. La
trazabilidad y la coherencia entre los requisitos y los productos de trabajo se abordan a
través de los mecanismos ya mencionados, así como durante las actividades de inicio de
iteración o de final de iteración, como "retrospectivas" y "días de demostración". (Consulte
"Interpretación de CMMI cuando se usa Agile" Enfoques "en la Parte I.)

Referencias
Consulte el área de proceso Desarrollo de requisitos (RD) (CMMI-DEV) para obtener más
información sobre cómo obtener, analizar y establecer los requisitos de los componentes
del producto, cliente y producto.

Consulte el área de proceso de la Solución técnica (TS) (CMMI-DEV) para obtener más
información sobre cómo seleccionar, diseñar e implementar soluciones a los requisitos.

Consulte el área de proceso de Gestión de la configuración (CMM) (CMMI-DEV) para

obtener más información sobre el establecimiento de líneas de base y el seguimiento y
control de los cambios.

Consulte el área de proceso de Control y Monitoreo de Proyecto (PMC) (CMMI-DEV) para

obtener más información sobre el monitoreo del proyecto en relación con el plan y la
gestión de la acción correctiva hasta el cierre.

Consulte el área de proceso Planificación de proyectos (PPM) (CMMI-DEV) para obtener

más información sobre cómo establecer y mantener planes que definan las actividades del
proyecto.

Consulte el área de proceso Gestión de riesgos (RSKM) (CMMI-DEV) para obtener más
información sobre cómo identificar y analizar los riesgos.
Contiene
REQM.SG 1 Administrar requisitos
Los requisitos se gestionan y se identifican inconsistencias con los planes del proyecto y los
productos del trabajo.

REQM.SG 1 Administrar requisitos

Resumen
Los requisitos se gestionan y se identifican inconsistencias con los planes del proyecto y los
productos del trabajo.

Descripción
El proyecto mantiene un conjunto de requisitos actuales y aprobados durante la vida del proyecto al
hacer lo siguiente:

 Gestionar todos los cambios a los requisitos

 Mantener relaciones entre requisitos, planes de proyecto y productos de trabajo
 Garantizar la alineación entre los requisitos, los planes del proyecto y los productos de
trabajo
 Tomando medidas correctivas

Referencias
Consulte el área de proceso Desarrollo de requisitos (RD) (CMMI-DEV) para obtener más
información sobre cómo analizar y validar los requisitos.

Consulte la práctica específica Desarrollar soluciones alternativas y Criterios de selección

en el área de proceso de Solución técnica (TS) (CMMI-DEV) para obtener más información
sobre cómo determinar la viabilidad de los requisitos.

Consulte el área de proceso Control y Control de Proyectos (PMC) (CMMI-DEV) para

obtener más información sobre la gestión de acciones correctivas para el cierre.

Contiene
REQM.SP 1.1 Comprender los requisitos
Desarrollar un entendimiento con los proveedores de requisitos sobre el significado de los
requisitos.

REQM.SP 1.1 Comprender los

requisitos
Resumen
Desarrollar un entendimiento con los proveedores de requisitos sobre el significado de los requisitos.

Descripción
A medida que el proyecto madura y se derivan los requisitos, todas las actividades o disciplinas
recibirán requisitos. Para evitar el arrastre de requisitos, se establecen los criterios para designar los
canales apropiados o las fuentes oficiales desde donde recibir los requisitos. Aquellos que reciben
los requisitos realizan análisis de ellos con el proveedor para garantizar que se alcance un
entendimiento compartido y compatible sobre el significado de los requisitos. El resultado de estos
análisis y diálogos es un conjunto de requisitos aprobados.

Ejemplo de productos de trabajo

1. Listas de criterios para distinguir proveedores de requisitos apropiados

2. Criterios para evaluación y aceptación de requisitos
3. Resultados de análisis contra criterios
4. Un conjunto de requisitos aprobados

Subprácticas

1. Establecer criterios para distinguir proveedores de requisitos apropiados.

2. Establecer criterios objetivos para la evaluación y aceptación de requisitos.

La falta de criterios de evaluación y aceptación a menudo da como resultado una verificación

inadecuada, una reelaboración costosa o el rechazo de un cliente.

Los ejemplos de criterios de evaluación y aceptación incluyen los siguientes:

 Claramente y correctamente indicado
 Completar
 Consistente entre sí
 Identificado de manera única
 De acuerdo con el enfoque arquitectónico y las prioridades de los atributos de calidad
 Apropiado para implementar
 Verificable (es decir, comprobable)
 Trazable
 Realizable
 Atado al valor comercial
  Identificado como una prioridad para el cliente

3. Analice los requisitos para garantizar que se cumplan los criterios establecidos.

4. Llegue a un entendimiento de los requisitos con el proveedor de requisitos para que los
participantes del proyecto puedan comprometerse con ellos.

REQM.SP 1.2 Obtener compromiso con los requisitos

Obtenga compromiso con los requisitos de los participantes del proyecto.

REQM.SP 1.2 Obtener compromiso

con los requisitos
Resumen
Obtenga compromiso con los requisitos de los participantes del proyecto.

Descripción
Consulte el área de proceso Control y Control de Proyectos (PMC) (CMMI-DEV) para
obtener más información sobre los compromisos de monitoreo.

La práctica específica anterior trata de llegar a un entendimiento con los proveedores de

requisitos. Esta práctica específica trata de los acuerdos y compromisos entre quienes
llevan a cabo las actividades necesarias para implementar los requisitos. Los requisitos
evolucionan a lo largo del proyecto. A medida que evolucionan los requisitos, esta práctica
específica asegura que los participantes del proyecto se comprometan con los requisitos
actuales y aprobados y los cambios resultantes en los planes, las actividades y los
productos del proyecto.

Ejemplo de productos de trabajo

1. Evaluaciones de impacto de requisitos

2. Compromisos documentados con los requisitos y cambios en los requisitos

Subprácticas

1. Evaluar el impacto de los requisitos en los compromisos existentes.

El impacto en los participantes del proyecto debe evaluarse cuando cambian los requisitos o al
comienzo de un nuevo requisito.

2. Negociar y registrar compromisos.

Los cambios en los compromisos existentes deben negociarse antes de que los participantes del
proyecto se comprometan con un nuevo requisito o cambio de requisitos.

REQM.SP 1.3 Gestionar cambios de requisitos

Administre los cambios a los requisitos a medida que evolucionan durante el proyecto.

REQM.SP 1.3 Gestionar cambios de

requisitos
Resumen
Administre los cambios a los requisitos a medida que evolucionan durante el proyecto.

Descripción
Consulte el área de proceso de Gestión de configuración (CMM) (CMMI-DEV) para
obtener más información sobre cómo rastrear y controlar los cambios.

Los requisitos cambian por una variedad de razones. A medida que las necesidades
cambien y avance el trabajo, es posible que haya que hacer cambios a los requisitos
existentes. Es esencial administrar estas adiciones y cambios de manera eficiente y
efectiva. Para analizar de manera efectiva el impacto de los cambios, es necesario
conocer la fuente de cada requisito y documentar los motivos del cambio. El proyecto
puede querer rastrear las medidas apropiadas de volatilidad de los requisitos para juzgar si
es necesario un enfoque nuevo o revisado para el control de cambios.

Ejemplo de productos de trabajo

1. Requisitos cambian las solicitudes

2. Requisitos cambian los informes de impacto
3. Estado de los requisitos
4. Base de datos de requisitos
Subprácticas

1. Documente todos los requisitos y cambios de requisitos que se le den o que genere el
proyecto.

2. Mantener un historial de cambios de requisitos, incluida la justificación de los cambios.

Mantener el historial de cambios ayuda a rastrear la volatilidad de los requisitos.

3. Evaluar el impacto de los cambios de requerimientos desde el punto de vista de las

partes interesadas relevantes.

4. Establezca requisitos y cambie los datos disponibles para el proyecto.

REQM.SP 1.4 Mantener la rastreabilidad bidireccional de los requisitos

Mantener la trazabilidad bidireccional entre los requisitos y los productos de trabajo.

REQM.SP 1.4 Mantener la

rastreabilidad bidireccional de los
requisitos
Resumen
Mantener la trazabilidad bidireccional entre los requisitos y los productos de trabajo.

Descripción
El objetivo de esta práctica específica es mantener la trazabilidad bidireccional de los
requisitos. (Consulte la definición de "trazabilidad bidireccional" en el glosario). Cuando los
requisitos se gestionan bien, la trazabilidad se puede establecer desde un requisito de origen hasta
sus requisitos de nivel más bajo y desde los requisitos de nivel más bajo hasta los requisitos de
origen. Dicha trazabilidad bidireccional ayuda a determinar si todos los requisitos de origen se han
abordado por completo y si todos los requisitos de nivel inferior se pueden remontar a una fuente
válida.

La trazabilidad de los requisitos también cubre las relaciones con otras entidades, como productos de
trabajo intermedios y finales, cambios en la documentación de diseño y planes de prueba. La
rastreabilidad puede cubrir relaciones horizontales, como a través de interfaces, así como relaciones
verticales. La rastreabilidad es particularmente necesaria cuando se evalúa el impacto de los cambios
de requisitos en las actividades del proyecto y los productos del trabajo.

Ejemplos de los aspectos de la rastreabilidad a considerar incluyen los siguientes:

 Alcance de la rastreabilidad: los límites dentro de los cuales se necesita rastreabilidad
 Definición de trazabilidad: los elementos que necesitan relaciones lógicas
 Tipo de trazabilidad: cuando se necesita trazabilidad horizontal y vertical

Dicha trazabilidad bidireccional no siempre está automatizada. Se puede hacer

manualmente usando hojas de cálculo, bases de datos y otras herramientas comunes.

Ejemplo de productos de trabajo

1. Requerimientos de trazabilidad matriz

2. Sistema de seguimiento de requisitos

Subprácticas

1. Mantener la trazabilidad de los requisitos para garantizar que se documenta la fuente de

los requisitos de nivel inferior (es decir, derivado).

2. Mantener la trazabilidad de los requisitos desde un requisito hasta sus requisitos

derivados y la asignación a productos de trabajo.

Los productos de trabajo para los que se puede mantener la rastreabilidad incluyen la arquitectura,
los componentes del producto, las iteraciones (o incrementos) de desarrollo, las funciones, las
interfaces, los objetos, las personas, los procesos y otros productos de trabajo.

3. Generar la matriz de trazabilidad de requisitos.

REQM.SP 1.5 Asegurar la alineación entre el trabajo del proyecto y los requisitos
Asegúrese de que los planes del proyecto y los productos de trabajo estén alineados con los
requisitos.
 REQM.SP 1.5 Asegurar la alineación
entre el trabajo del proyecto y los
requisitos
Resumen
Asegúrese de que los planes del proyecto y los productos de trabajo estén alineados con los
requisitos.

Descripción
Esta práctica específica encuentra inconsistencias entre los requisitos y los planes de proyecto y
productos de trabajo e inicia acciones correctivas para resolverlos.

Ejemplo de productos de trabajo

1. Documentación de inconsistencias entre requisitos y planes de proyecto y productos de

trabajo, incluyendo fuentes y condiciones
2. Acciones correctivas

Subprácticas

1. Revise los planes de proyecto, las actividades y los productos de trabajo para mantener la
coherencia con los requisitos y los cambios realizados en ellos.
2. Identifique la fuente de la inconsistencia (si la hay).
3. Identifique cualquier cambio que deba hacerse a los planes y productos de trabajo como
resultado de los cambios en la línea de base de los requisitos.
4. Iniciar cualquier acción correctiva necesaria.

 RD.SG 1 Desarrollar los requisitos del cliente

 RD.SG 2 Desarrollar los requisitos del producto
 RD.SG 3 Analizar y validar requisitos
Desarrollo de requisitos (RD) (CMMI-
DEV)
Resumen
El propósito del Desarrollo de requisitos (RD) (CMMI-DEV) es obtener, analizar y establecer los
requisitos del cliente, del producto y de los componentes del producto.

Descripción
Notas introductorias
Esta área de proceso describe tres tipos de requisitos: requisitos del cliente, requisitos del
producto y requisitos del componente del producto. Tomados en conjunto, estos requisitos
abordan las necesidades de las partes interesadas relevantes, incluidas las necesidades
relacionadas con varias fases del ciclo de vida del producto (por ejemplo, criterios de
prueba de aceptación) y los atributos del producto (por ejemplo, capacidad de respuesta,
seguridad, confiabilidad, facilidad de mantenimiento). Los requisitos también abordan las
limitaciones causadas por la selección de soluciones de diseño (por ejemplo, la integración
de productos comerciales disponibles en el mercado, el uso de un patrón de arquitectura
particular).

Todos los proyectos de desarrollo tienen requisitos. Los requisitos son la base del
diseño. El desarrollo de requisitos incluye las siguientes actividades:
 Elicitación, análisis, validación y comunicación de las necesidades, expectativas y
limitaciones del cliente para obtener los requisitos del cliente priorizados que constituyen
una comprensión de lo que satisfará a las partes interesadas.
 Colección y coordinación de las necesidades de los interesados
 Desarrollo de los requisitos del ciclo de vida del producto
 Establecimiento de los requisitos de atributos funcionales y de calidad del cliente
 Establecimiento de los requisitos iniciales de producto y producto de acuerdo con los
requisitos del cliente

Esta área de proceso aborda todos los requisitos del cliente en lugar de solo los requisitos
a nivel de producto porque el cliente también puede proporcionar requisitos de diseño
específicos.

Los requisitos del cliente se refinan más en los requisitos del producto y del componente
del producto. Además de los requisitos del cliente, los requisitos del producto y del
componente del producto se derivan de las soluciones de diseño seleccionadas. A lo largo
de las áreas de proceso, donde se usan los términos "producto" y "componente del
producto", los significados previstos también abarcan servicios, sistemas de servicio y sus
componentes.

Los requisitos se identifican y refinan a lo largo de las fases del ciclo de vida del
producto. Las decisiones de diseño, las acciones correctivas posteriores y los comentarios
durante cada fase del ciclo de vida del producto se analizan para determinar el impacto en
los requisitos derivados y asignados.

El área de proceso de Desarrollo de requisitos incluye tres objetivos específicos. El

objetivo específico Desarrollar requisitos del cliente aborda la definición de un conjunto de
requisitos del cliente para usar en el desarrollo de los requisitos del producto. El objetivo
específico Desarrollar requisitos del producto aborda la definición de un conjunto de
requisitos de productos o componentes de productos para usar en el diseño de productos
y componentes de productos. El objetivo específico Analizar y validar requisitos aborda el
análisis de los requisitos de los componentes del producto, del cliente y del producto para
definir, derivar y comprender los requisitos. Las prácticas específicas del tercer objetivo
específico están destinadas a ayudar a las prácticas específicas en los primeros dos
objetivos específicos.

Los análisis se utilizan para comprender, definir y seleccionar los requisitos en todos los
niveles de las alternativas de la competencia. Estos análisis incluyen lo siguiente:
 Análisis de necesidades y requisitos para cada fase del ciclo de vida del producto, incluidas
las necesidades de los interesados pertinentes, el entorno operativo y los factores que
reflejan las expectativas y la satisfacción general del cliente y del usuario final, como la
seguridad y la accesibilidad.
 Desarrollo de un concepto operacional
 Definición de la funcionalidad requerida y atributos de calidad

Esta definición de funcionalidad requerida y atributos de calidad describe lo que el

producto debe hacer. (Consulte la definición de "definición de funcionalidad requerida y
atributos de calidad" en el glosario). Esta definición puede incluir descripciones,
descomposiciones y una partición de las funciones (o en el análisis orientado a objetos lo
que se ha denominado "servicios" o "servicios"). métodos ") del producto.

Además, la definición especifica consideraciones de diseño o restricciones sobre cómo se

realizará la funcionalidad requerida en el producto. Los atributos de calidad abordan
aspectos tales como la disponibilidad del
producto; mantenibilidad; modificabilidad; oportunidad, rendimiento y capacidad de
respuesta; confiabilidad; seguridad; y escalabilidad. Algunos atributos de calidad surgirán
como arquitectónicamente significativos y, por lo tanto, impulsarán el desarrollo de la
arquitectura del producto.

Dichos análisis ocurren recursivamente en capas sucesivamente más detalladas de la

arquitectura de un producto hasta que haya suficiente detalle disponible para permitir el
desarrollo del diseño detallado, adquisición y prueba del producto. Como resultado del
análisis de los requisitos y el concepto operacional (incluida la funcionalidad, soporte,
mantenimiento y eliminación), el concepto de fabricación o producción produce más
requisitos derivados, incluida la consideración de lo siguiente:
 Restricciones de varios tipos
 Limitaciones tecnológicas
 Controladores de costo y costo
 Limitaciones de tiempo y controladores de horario
 Riesgos
 Consideración de problemas implicados pero no explícitamente establecidos por el cliente o
usuario final
 Factores introducidos por consideraciones comerciales, regulaciones y leyes exclusivas del
desarrollador

Se establece una jerarquía de entidades lógicas (por ejemplo, funciones y subfunciones,

clases de objetos y subclases, procesos, otras entidades arquitectónicas) a través de la
iteración con el concepto operacional en evolución. Los requisitos se refinan, derivan y
asignan a estas entidades lógicas. Los requisitos y las entidades lógicas se asignan a
productos, componentes de productos, personas o procesos asociados. En el caso del
desarrollo iterativo o incremental, los requisitos también se asignan a iteraciones o
incrementos.
La participación de las partes interesadas relevantes en el desarrollo y análisis de
requisitos les da visibilidad sobre la evolución de los requisitos. Esta actividad
continuamente les asegura que los requisitos están siendo definidos correctamente.

Para las líneas de productos, los procesos de ingeniería (incluido el desarrollo de

requisitos) se pueden aplicar a al menos dos niveles en la organización. A nivel
organizacional o de línea de producto, se realiza un "análisis de homogeneidad y
variación" para ayudar a obtener, analizar y establecer activos básicos para que los usen
los proyectos dentro de la línea de productos. En el nivel del proyecto, estos activos
centrales se utilizan según el plan de producción de la línea de producto como parte de las
actividades de ingeniería del proyecto.

En entornos ágiles, las necesidades e ideas de los clientes se obtienen, elaboran, analizan
y validan de forma iterativa. Los requisitos se documentan en formularios tales como
historias de usuarios, escenarios, casos de uso, acumulaciones de productos y los
resultados de las iteraciones (código de trabajo en el caso del software). Los requisitos que
se abordarán en una iteración determinada se basan en una evaluación del riesgo y en las
prioridades asociadas con lo que queda en la cartera de pedidos del producto. Qué
detalles de los requisitos (y otros artefactos) documentar se basan en la necesidad de
coordinación (entre los miembros del equipo, los equipos y las iteraciones posteriores) y el
riesgo de perder lo que se aprendió. Cuando el cliente forma parte del equipo, aún puede
haber una necesidad de documentación de producto y cliente por separado para permitir la
exploración de soluciones múltiples. A medida que surge la solución, las responsabilidades
de los requisitos derivados se asignan a los equipos apropiados. (Consulte "Interpretación
de CMMI cuando se utilizan enfoques ágiles" en la Parte I).

Referencias
Consulte el área de proceso Gestión de requisitos (REQM) (CMMI-DEV) para obtener más
información sobre la gestión de clientes y requisitos de productos, obtener un acuerdo con
el proveedor de requisitos, obtener compromisos con aquellos que implementan los
requisitos y mantener la rastreabilidad.

Consulte el área de proceso de la Solución técnica (TS) (CMMI-DEV) para obtener más
información sobre cómo se utilizan los resultados de los procesos de desarrollo de
requisitos y el desarrollo de soluciones y diseños alternativos utilizados en los requisitos de
refinación y derivación.

Consulte el área de proceso Integración de producto (PI) (CMMI-DEV) para obtener más
información sobre los requisitos de interfaz y la administración de interfaz.

Consulte el área de proceso Verificación (VER) (CMMI-DEV) para obtener más

información sobre cómo verificar que el producto resultante cumpla con los requisitos.

Consulte el área de proceso Validación (VAL) (CMMI-DEV) para obtener más información
acerca de cómo el producto creado se validará en función de las necesidades del cliente.
Consulte el área de proceso Gestión de riesgos (RSKM) (CMMI-DEV) para obtener más
información sobre cómo identificar y gestionar los riesgos relacionados con los requisitos.

Consulte el área de proceso Gestión de configuración (CMM) (CMMI-DEV) para obtener

información sobre cómo garantizar que los productos clave de trabajo estén controlados y
gestionados.

Contiene
RD.SG 1 Desarrollar los requisitos del cliente
Las necesidades, expectativas, limitaciones e interfaces de los interesados se recopilan y
traducen en los requisitos del cliente.
RD.SG 2 Desarrollar los requisitos del producto
Los requisitos del cliente se refinan y elaboran para desarrollar los requisitos del producto y
del componente del producto.
RD.SG 3 Analizar y validar requisitos
Los requisitos son analizados y validados.

RD.SG 1 Desarrollar los requisitos del

cliente
Resumen
Las necesidades, expectativas, limitaciones e interfaces de los interesados se recopilan y traducen en
los requisitos del cliente.

Descripción
Las necesidades de los interesados (por ejemplo, clientes, usuarios finales, proveedores,
constructores, probadores, fabricantes, personal de apoyo logístico) son la base para determinar los
requisitos del cliente. Las necesidades, las expectativas, las limitaciones, las interfaces, los conceptos
operativos y los conceptos de los interesados se analizan, armonizan, refinan y elaboran para su
traducción a un conjunto de requisitos del cliente.

Con frecuencia, las necesidades, expectativas, limitaciones e interfaces de las partes interesadas
están mal identificadas o son conflictivas. Dado que las necesidades, expectativas, limitaciones y
limitaciones de las partes interesadas deben identificarse y comprenderse claramente, se utiliza un
proceso iterativo a lo largo de la vida del proyecto para lograr este objetivo. Para facilitar la
interacción requerida, un sustituto para el usuario final o cliente se involucra con frecuencia para
representar sus necesidades y ayudar a resolver conflictos. Las relaciones con los clientes o la parte
de marketing de la organización, así como los miembros del equipo de desarrollo de disciplinas tales
como la ingeniería humana o el soporte, pueden usarse como sustitutos. Se deben tener en cuenta las
limitaciones medioambientales, legales y de otro tipo al crear y resolver el conjunto de requisitos del
cliente.
Contiene
RD.SP 1.1 Elicit Needs
Obtenga las necesidades, expectativas, limitaciones e interfaces de las partes interesadas
para todas las fases del ciclo de vida del producto.

RD.SP 1.1 Elicit Needs

Resumen
Obtenga las necesidades, expectativas, limitaciones e interfaces de las partes interesadas para todas
las fases del ciclo de vida del producto.

Descripción
La obtención va más allá de la recopilación de requisitos identificando de manera proactiva los
requisitos adicionales que los clientes no proporcionan explícitamente. Los requisitos adicionales
deben abordar las diversas actividades del ciclo de vida del producto y su impacto en el producto.

Entre los ejemplos de técnicas para obtener necesidades se incluyen los siguientes:
 Demostraciones de tecnología
 Grupos de trabajo de control de interfaz
 Grupos de trabajo de control técnico
 Revisiones provisionales del proyecto
 Cuestionarios, entrevistas y escenarios (operativos, sostenibles y de desarrollo) obtenidos de
los usuarios finales
 Tutoriales operativos, de mantenimiento y desarrollo y análisis de tareas del usuario final
 Talleres de obtención de atributos de calidad con partes interesadas
 Prototipos y modelos
 Reunión creativa
 Despliegue de la función de calidad
 Estudios de mercado
 Prueba Beta
 Extracción de fuentes tales como documentos, estándares o especificaciones
 Observación de productos existentes, entornos y patrones de flujo de trabajo
 Casos de uso
 Historias de usuarios
 Entrega de pequeñas "divisiones verticales" incrementales de la funcionalidad del producto
 Análisis de casos comerciales
 Ingeniería inversa (para productos heredados)
 Encuestas de satisfacción del cliente

Entre los ejemplos de fuentes de requisitos que el cliente no puede identificar se incluyen
los siguientes:
  Políticas comerciales
 Estándares
 Decisiones y principios de diseño arquitectónico anterior
 Requisitos ambientales del negocio (p. Ej., Laboratorios, pruebas y otras instalaciones,
infraestructura de tecnología de la información)
 Tecnología
 Productos heredados o componentes del producto (reutilización de componentes del
producto)
 Estatutos regulatorios

Ejemplo de productos de trabajo

1. Resultados de las actividades de obtención de requisitos

Subprácticas

1. Involucrar a las partes interesadas relevantes utilizando métodos para obtener necesidades,
expectativas, limitaciones e interfaces externas.

RD.SP 1.2 Transformar las necesidades de las partes interesadas en los requisitos del cliente
Transformar las necesidades, expectativas, limitaciones e interfaces de las partes interesadas
en los requisitos prioritarios del cliente.

RD.SP 1.2 Transformar las

necesidades de las partes interesadas
en los requisitos del cliente
Resumen
Transformar las necesidades, expectativas, limitaciones e interfaces de las partes interesadas en los
requisitos prioritarios del cliente.

Descripción
Se deben consolidar los diversos aportes de los actores relevantes, se debe obtener información
faltante y se deben resolver los conflictos a medida que se desarrollan y priorizan los requisitos del
cliente. Los requisitos del cliente pueden incluir necesidades, expectativas y limitaciones con
respecto a la verificación y validación.

En algunas situaciones, el cliente proporciona un conjunto de requisitos para el proyecto, o los

requisitos existen como resultado de las actividades de un proyecto anterior. En estas situaciones, los
requisitos del cliente podrían entrar en conflicto con las necesidades, las expectativas, las
limitaciones y las interfaces de los interesados pertinentes y deberán transformarse en el conjunto
reconocido de requisitos del cliente después de la resolución adecuada de los conflictos.

Las partes interesadas relevantes que representan todas las fases del ciclo de vida del producto deben
incluir tanto las funciones comerciales como las técnicas. De esta forma, los conceptos para todos
los procesos de ciclo de vida relacionados con el producto se consideran al mismo tiempo que los
conceptos para los productos. Los requisitos del cliente son el resultado de decisiones informadas
sobre el negocio, así como los efectos técnicos de sus requisitos.

Ejemplo de productos de trabajo

1. Requisitos del cliente priorizados

2. Restricciones del cliente sobre la realización de la verificación
3. Restricciones del cliente sobre la realización de la validación

Subprácticas

1. Traducir las necesidades, expectativas, limitaciones e interfaces de los interesados a los

requisitos documentados de los clientes.

2. Establezca y mantenga una priorización de los requisitos funcionales y de calidad del

atributo del cliente.

Tener los requisitos del cliente priorizados ayuda a determinar el alcance del proyecto, la iteración o
el incremento. Esta priorización garantiza que los requisitos de atributos funcionales y de calidad,
críticos para el cliente y otros interesados, se aborden rápidamente.

3. Defina restricciones para verificación y validación.

RD.SG 2 Desarrollar los requisitos del

producto
Resumen
Los requisitos del cliente se refinan y elaboran para desarrollar los requisitos del producto y del
componente del producto.

Descripción
Los requisitos del cliente se analizan conjuntamente con el desarrollo del concepto operacional para
derivar conjuntos de requisitos más detallados y precisos llamados "requisitos de productos y
componentes del producto". Los requisitos del producto y componente del producto abordan las
necesidades asociadas con cada fase del ciclo de vida del producto. Los requisitos derivados surgen
de restricciones; consideración de problemas implícitos pero no explícitamente establecidos en la
línea base de requisitos del cliente; factores introducidos por la arquitectura seleccionada, ciclo de
vida del producto y diseño; y las consideraciones comerciales únicas del desarrollador. Los
requisitos se vuelven a examinar con cada conjunto de requisitos y arquitectura sucesivos de menor
nivel y se refina el concepto de producto preferido.

Los requisitos se asignan a las funciones del producto y los componentes del producto, incluidos
objetos, personas y procesos. En el caso del desarrollo iterativo o incremental, los requisitos también
se asignan a iteraciones o incrementos basados en las prioridades del cliente, problemas de
tecnología y objetivos del proyecto. La trazabilidad de los requisitos para funciones, objetos,
pruebas, problemas u otras entidades está documentada. Los requisitos y funciones asignados (u
otras entidades lógicas) son la base para la síntesis de la solución técnica; sin embargo, a medida que
la arquitectura se define o emerge, sirve como la base fundamental para dirigir la asignación de
requisitos a la solución. A medida que se desarrollan los componentes internos, se definen interfaces
adicionales y se establecen requisitos de interfaz.

Consulte el área de proceso Gestión de requisitos (REQM) (CMMI-DEV) para obtener más
información sobre el mantenimiento de la rastreabilidad bidireccional de los requisitos.

Contiene
RD.SP 2.1 Establecer requisitos de componentes de productos y productos
Establezca y mantenga los requisitos de productos y componentes de productos, que se
basan en los requisitos del cliente.

RD.SP 2.1 Establecer requisitos de

componentes de productos y productos
Resumen
Establezca y mantenga los requisitos de productos y componentes de productos, que se basan en los
requisitos del cliente.

Descripción
Los requisitos de atributos funcionales y de calidad del cliente se pueden expresar en los términos
del cliente y pueden ser descripciones no técnicas. Los requisitos del producto son la expresión de
estos requisitos en términos técnicos que pueden usarse para decisiones de diseño. Un ejemplo de
esta traducción se encuentra en la primera Cámara de Despliegue de funciones de calidad, que
mapea los deseos de los clientes en parámetros técnicos. Por ejemplo, la "puerta de sonido sólido" se
puede asignar al tamaño, peso, ajuste, amortiguación y frecuencias de resonancia.

Los requisitos de componentes de productos y productos abordan la satisfacción de los objetivos del
cliente, del negocio y del proyecto y los atributos asociados, como la efectividad y la asequibilidad.

Los requisitos derivados también abordan las necesidades de otras fases del ciclo de vida (por
ejemplo, producción, operaciones, eliminación) en la medida compatible con los objetivos
comerciales.

La modificación de los requisitos debida a los cambios de requisitos aprobados está cubierta por el
aspecto "mantener" de esta práctica específica; mientras que la administración de los cambios de
requisitos está cubierta por el área de proceso de Gestión de requisitos.

Consulte el área de proceso Administración de requisitos (REQM) (CMMI-DEV) para

obtener más información sobre la administración de cambios a los requisitos.

Ejemplo de productos de trabajo

1. Requisitos derivados
2. Requisitos del producto
3. Requisitos del componente del producto
4. Requisitos arquitectónicos, que especifican o limitan las relaciones entre los componentes
del producto

Subprácticas

1. Desarrollar requisitos en términos técnicos necesarios para el diseño de componentes

de productos y productos.

2. Derive los requisitos que resultan de las decisiones de diseño.

Consulte el área de proceso de la Solución técnica (TS) (CMMI-DEV) para obtener más
información sobre la selección de soluciones de componentes de productos y el desarrollo
del diseño.

La selección de una tecnología trae consigo requisitos adicionales. Por ejemplo, el uso de
componentes electrónicos requiere requisitos específicos de tecnología adicional, como los
límites de interferencia electromagnética.
Las decisiones arquitectónicas, como la selección de patrones de arquitectura, introducen
requisitos derivados adicionales para los componentes del producto. Por ejemplo, el patrón
de capas restringirá las dependencias entre ciertos componentes del producto.

3. Desarrollar requisitos arquitectónicos que capturen atributos de calidad críticos y

medidas de atributos de calidad necesarias para establecer la arquitectura y el diseño del
producto.

Entre los ejemplos de medidas de atributos de calidad se incluyen los siguientes:

 Responde dentro de 1 segundo
 El sistema está disponible el 99% del tiempo
 Implementar un cambio con no más de una semana de esfuerzo del personal

4. Establecer y mantener relaciones entre los requisitos para su consideración durante la

administración del cambio y la asignación de requisitos.

Consulte el área de proceso Gestión de requisitos (REQM) (CMMI-DEV) para obtener más
información sobre el mantenimiento de la rastreabilidad bidireccional de los requisitos.

Las relaciones entre los requisitos pueden ayudar a evaluar el impacto de los cambios.

RD.SP 2.2 Asignar requisitos de componentes del producto

Asigne los requisitos para cada componente del producto.

RD.SP 2.2 Asignar requisitos de

componentes del producto
Resumen
Asigne los requisitos para cada componente del producto.

Descripción
Consulte el área de proceso de la Solución técnica (TS) (CMMI-DEV) para obtener más
información sobre la selección de soluciones de componentes de productos.

La arquitectura del producto proporciona la base para asignar los requisitos del producto a
los componentes del producto. Los requisitos para los componentes del producto de la
solución definida incluyen la asignación del rendimiento del producto; restricciones de
diseño; y ajuste, forma y función para cumplir con los requisitos y facilitar la producción. En
los casos en que un requisito de nivel superior especifique un atributo de calidad que será
responsabilidad de más de un componente de producto, el atributo de calidad a veces
puede dividirse para una asignación única a cada componente de producto como un
requisito derivado; sin embargo, otras veces el requisito compartido debería en su lugar, se
asignará directamente a la arquitectura.

Por ejemplo, la asignación de requisitos compartidos a la arquitectura describiría cómo un

requisito de desempeño (por ejemplo, sobre la capacidad de respuesta) se presupuesta
entre los componentes a fin de dar cuenta de manera integral para la realización del
requisito. Este concepto de requisitos compartidos puede extenderse a otros atributos de
calidad arquitectónicamente significativos (por ejemplo, seguridad, confiabilidad).

Ejemplo de productos de trabajo

1. Hojas de asignación de requisitos

2. Asignaciones provisionales de requisitos
3. Restricciones de diseño
4. Requisitos derivados
5. Relaciones entre los requisitos derivados

Subprácticas

1. Asignar requisitos a las funciones.

2. Asigne requisitos a los componentes del producto y la arquitectura.

3. Asigne restricciones de diseño a los componentes del producto y a la arquitectura.

4. Asigne requisitos a los incrementos de entrega.

5. Documente las relaciones entre los requisitos asignados.

Las relaciones incluyen dependencias en las que un cambio en un requisito puede afectar otros
requisitos.

RD.SP 2.3 Identificar requisitos de interfaz

Identificar los requisitos de la interfaz.
RD.SP 2.3 Identificar requisitos de
interfaz
Resumen
Identificar los requisitos de la interfaz.

Descripción
Se identifican las interfaces entre funciones (o entre objetos u otras entidades lógicas). Las interfaces
pueden impulsar el desarrollo de soluciones alternativas descritas en el área de proceso de
Soluciones técnicas.

Consulte el área de proceso Integración de producto (PI) (CMMI-DEV) para obtener más
información sobre cómo garantizar la compatibilidad de la interfaz.

Se definen los requisitos de interfaz entre productos o componentes de productos

identificados en la arquitectura del producto. Se controlan como parte de la integración de
productos y componentes de productos y son una parte integral de la definición de
arquitectura.

Ejemplo de productos de trabajo

1. Requisitos de interfaz

Subprácticas

1. Identifique interfaces externas al producto e internas al producto (es decir, entre

particiones funcionales u objetos).

A medida que avanza el diseño, la arquitectura del producto se verá alterada por los procesos de
solución técnica, creando nuevas interfaces entre los componentes del producto y los componentes
externos al producto.

También se deben identificar las interfaces con los procesos del ciclo de vida relacionados con el
producto.

Ejemplos de estas interfaces incluyen interfaces con equipos de prueba, sistemas de

transporte, sistemas de soporte e instalaciones de fabricación.

2. Desarrollar los requisitos para las interfaces identificadas.

Consulte el área de proceso de la Solución técnica (TS) (CMMI-DEV) para obtener más
información sobre la generación de nuevas interfaces durante el proceso de diseño.

Los requisitos para las interfaces se definen en términos de originación, destino, estímulo,
características de datos para software y características eléctricas y mecánicas para
hardware.

RD.SG 3 Analizar y validar requisitos

Resumen
Los requisitos son analizados y validados.

Descripción
Las prácticas específicas del objetivo específico Analizar y Validar requisitos respaldan el desarrollo
de los requisitos tanto en la meta específica Desarrollar requisitos del cliente como en la meta
específica Desarrollar requisitos del producto. Las prácticas específicas asociadas con este objetivo
específico cubren el análisis y la validación de los requisitos con respecto al entorno previsto del
usuario final.

Los análisis se realizan para determinar qué impacto tendrá el entorno operativo previsto en la
capacidad de satisfacer las necesidades, expectativas, limitaciones e interfaces de los
interesados. Las consideraciones, como la viabilidad, las necesidades de la misión, las limitaciones
de costos, el tamaño del mercado potencial y la estrategia de adquisición, deben tenerse en cuenta,
según el contexto del producto. Los atributos de calidad arquitectónicamente significativos se
identifican en función de los controladores de la misión y del negocio. También se establece una
definición de funcionalidad requerida y atributos de calidad. Se consideran todos los modos de uso
especificados para el producto.

Los objetivos de los análisis son determinar los requisitos de los candidatos para los conceptos del
producto que satisfarán las necesidades, las expectativas y las limitaciones de las partes interesadas y
luego convertir estos conceptos en requisitos. Paralelamente a esta actividad, los parámetros que se
utilizarán para evaluar la efectividad del producto se determinan con base en la opinión del cliente y
el concepto preliminar del producto.

Los requisitos se validan para aumentar la probabilidad de que el producto resultante funcione según
lo previsto en el entorno de uso.
Contiene
RD.SP 3.1 Establecer conceptos y escenarios operativos
Establecer y mantener conceptos operacionales y escenarios asociados.

RD.SP 3.1 Establecer conceptos y

escenarios operativos
Resumen
Establecer y mantener conceptos operacionales y escenarios asociados.

Descripción
Un escenario es típicamente una secuencia de eventos que pueden ocurrir en el desarrollo, uso o
mantenimiento del producto, que se utiliza para hacer explícitas algunas de las necesidades
funcionales o de atributos de calidad de los interesados. Por el contrario, un concepto operacional
para un producto generalmente depende tanto de la solución de diseño como del escenario.

Por ejemplo, el concepto operacional para un producto de comunicaciones por satélite es bastante
diferente de uno basado en líneas fijas. Dado que las soluciones alternativas generalmente no se han
definido al preparar los conceptos operativos iniciales, las soluciones conceptuales se desarrollan
para su uso al analizar los requisitos. Los conceptos operativos se refinan a medida que se toman las
decisiones de la solución y se desarrollan requisitos detallados de menor nivel.

Así como una decisión de diseño para un producto puede convertirse en un requisito para un
componente del producto, el concepto operacional puede convertirse en los escenarios (requisitos)
para los componentes del producto. Los conceptos y escenarios operativos se desarrollan para
facilitar la selección de soluciones de componentes de productos que, cuando se implementen,
satisfarán el uso previsto del producto o facilitarán su desarrollo y mantenimiento. Los conceptos y
escenarios operativos documentan la interacción de los componentes del producto con el entorno, los
usuarios finales y otros componentes del producto, independientemente de la disciplina de
ingeniería. Deben documentarse para todos los modos y estados dentro de las operaciones, el
desarrollo del producto, la implementación, la entrega, el soporte (incluido el mantenimiento y el
mantenimiento), la capacitación y la eliminación.

Los escenarios se pueden desarrollar para abordar secuencias operativas, de sostenimiento,

desarrollo u otras secuencias de eventos.

Productos de trabajo de ejemplo

1. Concepto operacional
2. Conceptos de desarrollo, instalación, operación, mantenimiento y soporte de componentes
de productos o productos
 3. Conceptos de eliminación
4. Casos de uso
5. Escenarios de la línea de tiempo
6. Nuevos requisitos

Subprácticas

1. Desarrollar conceptos operacionales y escenarios que incluyen operaciones, instalación,

desarrollo, mantenimiento, soporte y eliminación según corresponda.

Identifique y desarrolle escenarios, consistentes con el nivel de detalle en las necesidades,

expectativas y restricciones de las partes interesadas en las que se espera que el producto propuesto o
el componente del producto opere.

Aumente escenarios con consideraciones de atributos de calidad para las funciones (u otras entidades
lógicas) descritas en el escenario.

2. Defina el entorno en el que funcionará el producto o componente del producto, incluidos

los límites y las limitaciones.

3. Revise conceptos operacionales y escenarios para refinar y descubrir requisitos.

El concepto operacional y el desarrollo de escenarios es un proceso iterativo. Las revisiones deben

realizarse periódicamente para garantizar que estén de acuerdo con los requisitos. La revisión puede
ser en forma de tutorial.

4. Desarrollar un concepto operativo detallado, a medida que se seleccionan los productos

y componentes del producto, que define la interacción del producto, el usuario final y el
entorno, y que satisface las necesidades operativas, de mantenimiento, de soporte y de
eliminación.

RD.SP 3.2 Establecer una definición de funcionalidad requerida y atributos de calidad

Establecer y mantener una definición de funcionalidad requerida y atributos de calidad.

RD.SP 3.2 Establecer una definición de

funcionalidad requerida y atributos de
calidad
Resumen
Establecer y mantener una definición de funcionalidad requerida y atributos de calidad.

Descripción
Un enfoque para definir la funcionalidad requerida y los atributos de calidad es analizar los
escenarios usando lo que algunos han llamado un "análisis funcional" para describir lo que se
pretende que el producto haga. Esta descripción funcional puede incluir acciones, secuencias,
entradas, salidas u otra información que comunique la forma en que se utilizará el producto. La
descripción resultante de funciones, agrupaciones lógicas de funciones y su asociación con requisitos
se denomina arquitectura funcional. (Consulte las definiciones de "análisis funcional" y "arquitectura
funcional" en el glosario).

Tales enfoques han evolucionado en los últimos años mediante la introducción de lenguajes,
métodos y herramientas de descripción de arquitectura para abordar y caracterizar más
completamente los atributos de calidad, permitiendo una especificación más rica (por ejemplo,
multidimensional) de las restricciones sobre cómo se realizará la funcionalidad definida en el
producto, y facilitando análisis adicionales de los requisitos y soluciones técnicas. Algunos atributos
de calidad surgirán como arquitectónicamente significativos y, por lo tanto, impulsarán el desarrollo
de la arquitectura del producto. Estos atributos de calidad a menudo reflejan preocupaciones
transversales que pueden no ser asignables a los elementos de nivel inferior de una solución. Una
comprensión clara de los atributos de calidad y su importancia en función de las necesidades de la
misión o del negocio es un insumo esencial para el proceso de diseño.

Ejemplo de productos de trabajo

1. Definición de funcionalidad requerida y atributos de calidad

2. Arquitectura funcional
3. Diagramas de actividad y casos de uso
4. Análisis orientado a objetos con servicios o métodos identificados
5. Requisitos de atributos de calidad arquitectónicamente significativos

Subprácticas

1. Determine la misión clave y los controladores comerciales.

2. Identificar funcionalidad deseable y atributos de calidad.

Los atributos de funcionalidad y calidad pueden identificarse y definirse a través de un análisis de

varios escenarios con partes interesadas relevantes, como se describe en la práctica específica
anterior.
3. Determine los atributos de calidad arquitectónicamente significativos basados en la
misión clave y los impulsores del negocio.

4. Analice y cuantifique la funcionalidad requerida por los usuarios finales.

Este análisis puede implicar considerar la secuencia de funciones críticas del tiempo.

5. Analice los requisitos para identificar particiones lógicas o funcionales (p. Ej.,
Subfunciones).

6. Partición de los requisitos en grupos, en base a criterios establecidos (p. Ej.,

Funcionalidad similar, requisitos de atributos de calidad similares, acoplamiento), para
facilitar y enfocar el análisis de requisitos.

7. Asigne los requisitos del cliente a particiones funcionales, objetos, personas o

elementos de soporte para respaldar la síntesis de soluciones.

8. Asigne requisitos a funciones y subfunciones (u otras entidades lógicas).

RD.SP 3.3 Analizar requisitos

Analice los requisitos para asegurarse de que sean necesarios y suficientes.

RD.SP 3.3 Analizar requisitos

Resumen
Analice los requisitos para asegurarse de que sean necesarios y suficientes.

Descripción
A la luz del concepto operacional y los escenarios, los requisitos para un nivel de la jerarquía del
producto se analizan para determinar si son necesarios y suficientes para cumplir los objetivos de
niveles más altos de la jerarquía del producto. Los requisitos analizados proporcionan la base para
requisitos más detallados y precisos para niveles inferiores de la jerarquía de productos.

A medida que se definen los requisitos, debe entenderse su relación con los requisitos de nivel
superior y la definición de nivel superior de la funcionalidad requerida y los atributos de
calidad. Además, se determinan los requisitos clave utilizados para seguir el progreso. Por ejemplo,
el peso de un producto o tamaño de un producto de software se puede monitorear a través del
desarrollo en función de su riesgo o su criticidad para el cliente.

Consulte el área de proceso Verificación (VER) (CMMI-DEV) para obtener más

información sobre el establecimiento de procedimientos y criterios de verificación.
Ejemplo de productos de trabajo

1. Informes de defectos de requisitos

2. Cambios de requisitos propuestos para resolver defectos
3. Requerimientos clave
4. Medidas de rendimiento técnico

Subprácticas

1. Analice las necesidades, las expectativas, las limitaciones y las interfaces externas de
las partes interesadas para organizarlas en temas relacionados.

2. Analice los requisitos para determinar si satisfacen los objetivos de los requisitos de
nivel superior.

3. Analice los requisitos para asegurarse de que sean completos, factibles, realizables y
verificables.

Si bien el diseño determina la viabilidad de una solución en particular, esta subpráctica aborda el
conocimiento de los requisitos que afectan la viabilidad.

4. Identifique los requisitos clave que tienen una fuerte influencia en el costo, el
cronograma, el desempeño o el riesgo.

5. Identifique las medidas de desempeño técnico que se rastrearán durante el esfuerzo de

desarrollo.

Consulte el área de proceso de Medición y Análisis (MA) (CMMI-DEV) para obtener más
información sobre cómo desarrollar y mantener una capacidad de medición utilizada para
respaldar las necesidades de información de gestión.

Consulte el área de proceso de Medición y Análisis (MA) (CMMI-DEV) para obtener más
información sobre el uso de mediciones.

6. Analice los conceptos y escenarios operativos para refinar las necesidades, las
limitaciones y las interfaces del cliente, y para descubrir nuevos requisitos.
Este análisis puede dar como resultado conceptos y escenarios operacionales más detallados, además
de respaldar la derivación de nuevos requisitos.

RD.SP 3.4 Analiza los requisitos para lograr el equilibrio

Analice los requisitos para equilibrar las necesidades y limitaciones de las partes
interesadas.

RD.SP 3.4 Analiza los requisitos para

lograr el equilibrio
Resumen
Analice los requisitos para equilibrar las necesidades y limitaciones de las partes interesadas.

Descripción
Las necesidades y limitaciones de los interesados pueden abordar aspectos como el costo, el
cronograma, el rendimiento del producto o proyecto, la funcionalidad, las prioridades, los
componentes reutilizables, la capacidad de mantenimiento o el riesgo.

Ejemplo de productos de trabajo

1. Evaluación de riesgos relacionados con los requisitos

Subprácticas

1. Use modelos, simulaciones y creación de prototipos probados para analizar el equilibrio

de las necesidades y limitaciones de las partes interesadas.

Los resultados de los análisis pueden usarse para reducir el costo del producto y el riesgo en el
desarrollo del producto.
2. Realice una evaluación de riesgos sobre los requisitos y la definición de la funcionalidad
requerida y los atributos de calidad.

Consulte el área de proceso Gestión de riesgos (RSKM) (CMMI-DEV) para obtener más
información sobre cómo identificar y analizar los riesgos.

3. Examine los conceptos del ciclo de vida del producto para conocer los impactos de los
requisitos sobre los riesgos.

4. Evalúe el impacto de los requisitos de atributos de calidad arquitectónicamente

significativos en los costos y riesgos de desarrollo de productos y productos.

Cuando el impacto de los requisitos en los costos y riesgos parece ser mayor que el beneficio
percibido, se debe consultar a las partes interesadas relevantes para determinar qué cambios pueden
ser necesarios. Como ejemplo, un requisito de tiempo de respuesta muy ajustado o un requisito de
alta disponibilidad podría resultar costoso de implementar. Tal vez el requisito podría relajarse una
vez que se entiendan los impactos (por ejemplo, en el costo).

RD.SP 3.5 Valida los requisitos

Valide los requisitos para garantizar que el producto resultante funcionará según lo previsto
en el entorno del usuario final.

RD.SP 3.5 Valida los requisitos

Resumen
Valide los requisitos para garantizar que el producto resultante funcionará según lo previsto en el
entorno del usuario final.

Descripción
La validación de los requisitos se realiza al principio del esfuerzo de desarrollo con los usuarios
finales para ganar la confianza de que los requisitos son capaces de guiar un desarrollo que dé como
resultado una validación final exitosa. Esta actividad debe integrarse con las actividades de gestión
de riesgos. Las organizaciones maduras generalmente realizarán la validación de los requisitos de
una manera más sofisticada utilizando múltiples técnicas y ampliarán la base de la validación para
incluir otras necesidades y expectativas de los interesados.

Entre los ejemplos de técnicas utilizadas para la validación de requisitos se incluyen los
siguientes:
 Análisis
 Simulaciones
 Prototipos
  Demostraciones

Ejemplo de productos de trabajo

1. Registro de métodos de análisis y resultados

Subprácticas

1. Analice los requisitos para determinar el riesgo de que el producto resultante no

funcione adecuadamente en su entorno de uso previsto.

2. Explore la adecuación e integridad de los requisitos mediante el desarrollo de

representaciones de productos (por ejemplo, prototipos, simulaciones, modelos,
escenarios y guiones gráficos) y obteniendo comentarios sobre ellos de los interesados
pertinentes. Consulte el área de proceso de Validación para obtener más información
sobre cómo prepararse para validar productos y validar productos o componentes de
productos.

Consulte el área de proceso Validación (VAL) (CMMI-DEV) para obtener información sobre
cómo prepararse y realizar validaciones en productos y componentes de productos.

3. Evalúe el diseño a medida que madura en el contexto del entorno de validación de

requisitos para identificar problemas de validación y exponer las necesidades no
declaradas y los requisitos del cliente.