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.
Los requisitos del cliente son obtenidos del análisis y priorización de las necesidades, expectativas, restricciones e interfaces identificadas con diferentes técnicas de investigación de requisitos.
Los requisitos del producto y componentes del producto son analizados y derivados a partir de los requisitos del cliente. Estos nuevos requisitos son obtenidos a partir de la arquitectura y diseño de solución de los requisitos obtenidos previamente y que son iterados y refinados en fases sucesivas del ciclo de desarrollo. Los requisitos del producto son la expresión técnica de las necesidades establecidas por el cliente en términos “no técnicos” y que son utilizadas como base para las decisiones relacionadas con el diseño y que implica cuestiones tecnológicas.
Los requisitos de interfaz entre productos o componentes del producto son parte de la arquitectura de solución y constituyen elementos fundamentales para establecer las alternativas de solución como parte de TS. Como parte de los requisitos de interfaz se identifican también interfaces con equipos de prueba, sistemas de transporte o de apoyo, así como con instalaciones de producción. Los requisitos de interfaz, que posteriormente son diseñados como parte de la solución, son gestionados como parte de PI para garantizar la adecuada integración de los componentes del producto.
En general todos los requisitos deben ser adecuadamente documentados, relacionados y priorizados, así como, deben estar involucrados los diferentes interesados en su análisis y desarrollo para asegurar que están siendo adecuadamente definidos. Una buena definición de requisitos garantiza las bases para el diseño y desarrollo del producto y, eventualmente, la aceptación final por el cliente.
Saludos Carlos,
ResponderEliminarMe surge una inquietud con relación a la imagen que adjunta al artículo. La entrada al proceso RD -Procces Input- de que proceso cmmi proviene?.
Mi pregunta es porque actualmente estamos definiendo nuestro proceso RD en la empresa donde trabajo, y esto de la identificación de las necesidades del cliente, objetivos/requerimientos, lo involucramos dentro del mismo RD, es decir, lo comenzamos con una etapa de INICIO que tiene actividades como:
1.cliente invita a cotizar.
2.se verifica iniciativa del cliente. válida o no...
3.se genera el repositorio de la iniciativa.
después de dos o tres actividades mas, es que comenzamos con una etapa que es la de análisis e identificación de requerimientos.
Entonces creo que hemos incluido algo que no debe ir en RD, según la imagen adjunta.
Podría ud ayudarme a aclararla?, de antemano le agradezco por tu tiempo.
Saludos.
Hola Pao, gusto en saludarte y muchas gracias por el comentario.
ResponderEliminarEn principio las imágenes que selecciono mayormente son de dominio público para ilustrar un poco lo que escribo. Lo interesante de esta imagen es que muestra como los procesos de ingeniería son iterativos y se va avanzando por ciclos. Al final no es el modelo, simplemente es una abstracción que alguien hizo y publicó en la red.
Lo que comentas es perfectamente válido si así lo requiere tu proceso, sea como se llame (coincidentemente es tu proceso de RD que no se debe confundir con el área de proceso del modelo).
En el caso que quieras mapearlo a RD entonces puede que existan cosas en tu proceso que no se relacionen con lo que el modelo requiere para RD. Habría que ver si es importante para otra área de proceso X, lo cual no quiere decir que lo quites de tu proceso actual sino que en el mapeo lo consideres cubierto para esa área de proceso X. Si no se relaciona con ningún área de proceso, pues no lo relacionas pero no lo quites de tu proceso porque es importante para tu organización aunque el modelo no te lo pida.
Espero haber aclarado tu duda. Seguimos en contacto.