Ingeniería de Requisitos

Ingeniería de Requisitos
Abril de 2009

Objetivos Al finalizar esta actividad, los participantes deberán estar en capacidad de: Describir algunos de los desafíos clave del desarrollo de productos en el sector industrial Describir los desafíos de la ingeniería de requisitos Describir en dónde encaja la ingeniería de requisitos dentro del proceso de desarrollo de producto Describir por qué fallan los procesos de requisitos y las razones comunes por las que fallan los productos Describir los beneficios de un enfoque mejorado de la ingeniería de requisitos Listar los componentes de una solución de ingeniería de requisitos Describir las capacidades y beneficios clave de IBM® Rational ® DOORS ®, IBM Rational Requirements Composer y IBM Rational Quality Manager como parte de la solución de Ingeniería de Requisitos de IBM

Agenda Tendencias en el Desarrollo y Entrega de Producto
Desafíos que Resultan de Procesos de Ingeniería de Requisitos Insuficientes Buenas Prácticas para una Ingeniería de Requisitos Exitosa

Las Compañías están Enfrentado una Tasa de Cambio Sin Paralelo La Innovación se Considera Clave para el Éxito Globalización Competencia intensificada Problemas de la fuerza laboral 66% de los CEOs esperan que sus organizaciones sean inundadas con cambios Escalamiento de las expectativas de los clientes Avances tecnológicos Cambios inesperados del mercado Preocupaciones por regulaciones “Lucharemos nuestras batallas, no por la ruta inferior de la mercantilización, sino por la ruta superior de la innovación.” CEO de una de las Principales Compañías de Electrónicos y Entretenimiento Fuente: IBM Global CEO Study, 2006

La Competencia y las Exigencias de los Clientes están Fomentando Cambios en el Desarrollo de Productos Aeroespacial y Defensa La necesidad de reducción de costos/mayor innovación está resultando en asociaciones de diseño a lo largo de los límites legales, tecnológicos y de seguridad Electrónica La necesidad de diferenciación de producto está generando un aumento de la cantidad de software en los productos Sector Automotriz 35% de aumento del valor de la electrónica y el software dentro de los vehículos para el 2010 90% de la innovación se basa en la electrónica y el software incorporado Nuestros clientes en las esferas automotriz, de electrónica y aeroespacial enfrentan desafíos y presión significativos, por un mercado en constante cambio. En esta diapositiva, hemos resaltado algunos de los cambios del mercado y de las exigencias de los clientes que se están dando. Por ejemplo, en el mercado automotriz, hay una gran cantidad de electrónica y software en los vehículos. De hecho, uno de nuestros grandes OEM declaró que considera que para el 2010, 2011, en sus líneas de vehículos más de la mistad del costo, no el 35 ni el 40% sino la mitad del costo, estará en el área de electrónica y software. Usted también puede ver que gran parte de la innovación en los automóviles se está basando en el software y la electrónica—cosas como capacidades de manejo especializadas, control de tracción y otras capacidades sofisticadas La parte electrónica también tiene un incremento significativo en la dependencia en el software. Los dispositivos médicos cada vez dependen más de las capacidades del software. Más – incluso más en las áreas de productos de consumo. Y usted incluso puede ver bastante en el espacio del tipo de equipos de oficina. Así que a lo largo de todos los diferentes segmentos en electrónica, aquí se necesita una gran cantidad, incluyendo semiconductores. Los campos aeroespacial y de defensa han sido siempre grandes proponentes – una gran propuesta de electrónica y de software, pero sólo se están tornando cada vez más complejos, aún cuando hay más asociados utilizándolos, hay más sub-sistemas para integrar. Se está tornando cada vez más complejo, dentro de lo que ya era un entorno bastante complejo. Se han estado generando cambios a lo largo de toda la cadena de suministros - incluso los repuestos de los consumibles requieren ahora software y electrónica sofisticados

Diseño Asistido por Herramientas
El Panorama del Desarrollo de Producto está Evolucionando De Enfocarse en el Costo – a Enfocarse en la Innovación Innovación Reingeniería Diseño Asistido por Herramientas Presente Presente y Más Allá Aumento del enfoque en ingeniería de software Rastreabilidad completa de los requisitos a lo largo del ciclo de vida del producto Diseño holístico del sistema e interacción 3D CAD PDM enfocada en BOM mecánica Mejora de organización y procesos 2D CAD Gestión de datos ad-hoc Sin cambios en organización / procesos Desarrollo de Producto Globalización de proveedores, fuerza de trabajo y mercados Nueva tecnología para costos y tiempo reducidos y mayor flexibilidad Mejora de la productividad mediante la automatización Incentivadores de Negocios Ha habido un enfoque significativo, inversión y gasto el sistemas de Gestión de Ciclo de Vida de Producto con los años—¿pero la inversión produjo resultados? ¿Están prosperando actualmente las compañías que han hecho estas inversiones? ¿Si no, por qué no? En los años ochenta, las compañías comenzaron a utilizar herramientas CAD/CAM para mejorar sus capacidades de dibujo. Pero, a menudo, no hacían los cambios correspondientes en su estructura de negocios para optimizar estas inversiones. En los años noventa, las compañías invirtieron en sistemas de Gestión de Datos de Producto y los integraron con sus sistemas ERP. Ahora, y viendo hacia atrás, las compañías están buscando integrar varias aplicaciones PLM en todas las disciplinas. Pero incluso este intento puede no considerar lo suficiente al software; ni la necesidad de tener una visualización integrada del diseño mediante prácticas optimizadas y aporte de herramientas de ingeniería de sistemas. El reto hoy es lograr los requisitos adecuados para todo el sistema - con el mismo enfoque con que lo han hecho con la gestión de BOM; para desarrollar software con la misma disciplina/enfoque/gobierno que aplicaron a CAD/CAM. Y necesitamos todo esto con un nuevo enfoque interdisciplinario para la colaboración y el diseño, esto es, un enfoque de Gestión Integrada de Cambios de Producto/ ingeniería de Sistemas. Valor de Negocios Rápida innovación donde el software es el principal diferenciador Reducción de tiempo y de costos Producción mejorada con mayor calidad

Desafíos que Resultan de Procesos de Ingeniería de Requisitos Insuficientes Buenas Prácticas para una Ingeniería de Requisitos Exitosa

Las Fallas en el Desarrollo de Producto Están Impactando el Resultado Final
Aeroespacial y Defensa Serios problemas financieros y de calidad resultan de la necesidad de entender y gestionar mejor el cambio en todos los equipos Electrónica Retrasos y sobrecostos causados por errores encontrados durante las pruebas de integración de electrónica y software Los costos por garantía se disparan cuando se encuentran errores después del release de producto Sector Automotriz Así que usted está viendo que las garantías ingresan costos, de nuevo, probablemente un automóvil está cercano al 60 por ciento en costos por garantía, ahora son el software y la electrónica una gran cantidad. Y estamos viendo que suceden cosas realmente interesantes, usted sabe, un poco extrañas. Hubo un fabricante de vehículos que tuvo que hacer un llamado a devolución – Creo que fue que cuando se encendía la radio y usted estaba ajustando el control de clima del lado del conductor, se podía bajar la ventana del lado del conductor. Pienso que, en el mundo de la TI, podemos llamar a eso un dispositivo no documentado, pero en lo automotriz, ellos no podían conservar eso y simplemente tuvieron que hacer el llamado a devolución. A las personas no les gusta que se bajen sus ventanillas. En la electrónica pasa lo mismo. Seguimos viendo diferentes excesos en costos, grandes cantidades de costos adicionales en la re-ejecución de chips cuando ((inaudible)) obtuvo el software equivocado construido en ellos, es decir, el re-desarrollo de un chip es bastante costoso. Tenemos bastantes costos por garantía. Usted puede ver en el mercado constantes llamados a devolución. El mismo problema se da en lo aeroespacial y de defensa donde los grandes retrasos cuestan miles de millones de dólares – tanto en el área aeroespacial como en la de defensa. Los programas cancelados cuestan decenas de miles de millones de dólares. Así que un nivel tremendo de impactos está sucediendo, a gran escala, y no en poca medida debido al software y la electrónica de que hablamos. Y, de hecho, aquí estamos viendo algunos impactos interesantes. La mayoría de las personas conocen el 787, usted sabe, tenemos esto – en nuevo avión de Boeing. Y ellos han tenido algunos casos documentados en la prensa, donde la FAA está preocupada por todo el software y por todo el estado de interconexión entre el software y la aeronave, hasta el punto en que ellos estaban realmente preocupados porque un hacker sentado en la parte trasera del avión pudiera filtrarse al sistema y posiblemente controlarlo. Debido a esto, la FAA en efecto está poniendo una gran cantidad de requisitos de certificación adicionales para la aeronave. De esta forma, hay cantidades de problemas diferentes debido a la complejidad del software y nosotros, todas nuestras compañías y todas estas industrias, estamos luchando por la innovación, así como con los elementos de costos y de garantías que se asocian a ella. La complejidad de los sistemas electrónicos conduce a problemas de calidad, retrasos en los proyectos y a costos por garantías Los costos por garantías en EE.UU. y Europa son del 2-3% de los ingresos ~50% de los costos por garantías están relacionados con la electrónica y el software incorporado

Las Fallas en Software y Productos Integrados Aún Abundan en las Compañías A Pesar del Enfoque Permanente en PLM Agencia Aeroespacial Cohete prototipo de mil millones de US$ se auto-destruyó 40 segundos después del despegue, debido a un error del software de dirección a bordo OEM Automotriz Un error de software forzó un llamado a devolución de producto de 75 mil autos que se atascaban a altas velocidades Fabricante de Equipos Médicos Llamaron a devolución 42 mil dispositivos desfibriladores debido a un software pobre Las empresas dependen del éxito del software Usted sabe que su empresa depende cada vez más del software. Usted lo usa para ejecutar sus procesos empresariales. Quizás lo usa para producir sus productos. Quizás el software sea su producto. Pero ¿y el proceso que usa usted para crear este software? ¿Duerme usted bien durante la noche, seguro de que su proceso de entrega de software y sistemas producirá constantemente un software confiable, de alto rendimiento, alineado con la estrategia de negocios de su compañía? Si no lo hace, no está solo. Estudios recientes muestran que la tasa de fracaso de los proyectos de software aún es alarmantemente alta. Según el Standish Group, sólo 34% de los proyectos de software tienen éxito, y sólo cerca de la mitad de las funciones y dispositivos planeados llegan efectivamente al punto de release de software. Las compañías pagan un alto precio por estas fallas. La mitad de de las aplicaciones que llegan a la producción son retrocedidas más tarde, de acuerdo con Gartner. Y hasta 4/5 del presupuesto de TI de una compañía promedio es empleado en el mantenimiento de las aplicaciones ya existentes, de acuerdo con un informe reciente de Intelligent Enterprise. Teniendo en cuenta todo lo dicho, el tiempo de inactividad relacionado con el software consume US$ 300 mil millones en recursos de la industria cada año, según la estimativa de un grupo de estudio de la industria.

Limpiaparabrisas Sensible a la Lluvia: Ejemplo de una Falla de Diseño de Sistema Los Sistemas Individuales Funcionaban, Pero Fallaron Cuando se Integraron Parabrisas suministrado por un proveedor local Incompatible con el rango de operación del sensor No se capturó el requisito para una adecuada calibración del sistema (p. ej., compatibilidad de sensor y de parabrisas) Los autos se enviaron a los clientes con un sistema de limpiaparabrisas que no funcionaba La historia detrás del Limpiaparabrisas Sensible a la Lluvia El desarrollo del primer Limpiaparabrisas Sensible a la Lluvia ilustra cómo una falla clásica por no conceptualizar completamente la arquitectura física de un producto, resultó en el descubrimiento de problemas de integración en el momento del servicio, conduciendo así rápidamente a solicitudes de cambios de ingeniería. El escenario gira en torno a la introducción inicial del dispositivo Limpiaparabrisas Sensible a la Lluvia (RSW) dentro del programa de vehículo de un fabricante de automóviles. Antes de examinar el motivo de la falla del RSW, revisemos brevemente las características del sistema. El RSW contiene componentes mecánicos (dispositivo óptico de montaje), electrónicos (sensores IR y ECU) y de software (algoritmo de visión computarizada), que son aportados por proveedores de nivel uno. Estos componentes son integrados de forma simple por el fabricante. Los principales parámetros del sistema son: (1) las especificaciones ópticas y geométricas del parabrisas, particularmente el grosor y los índices ópticos del vidrio, y (2) los rangos de operación de los sensores ópticos electrónicos. El software de detección también tiene rangos normales de operación relativos a estos parámetros, pero adicionalmente, se apoya en datos sobre valores actuales de los parámetros del parabrisas. El hecho de que las especificaciones de electrónica y de software del RSW incluyan rangos para la propiedades relevantes del parabrisas, es importante, porque esto permite mayor flexibilidad en la elección del parabrisas mismo. Esta es una elección de diseño crítica, siendo los costos de suministro e integración asociados con el parabrisas de un orden de magnitud mayor que el del RSW. Para un desempeño óptimo, los valores reales de las propiedades del parabrisas deben estar cerca del centro de los rangos de operación normales, tanto para los sensores RSW como para el software; no obstante, se debe garantizar una operación aceptable para todo el rango. Desde el punto de vista del suministro, el parabrisas es adquirido simultáneamente de diferentes proveedores. Dependiendo del año de producción y de dónde se haya fabricado el producto, los proveedores pueden modificar el diseño de sus parabrisas. Además, pueden ocurrir uno o más cambios de proveedores durante la fase de producción. En el escenario de la falla, el cual ocurrió durante el primer año de la introducción de RSW, un proveedor local de parabrisas suministró un componente cuyas características eran incompatibles con el rango de operación del sensor. Desafortunadamente, en ese momento no se había capturado para el RSW ningún requisito para la calibración adecuada del sistema (esto es, para verificar que el sensor y el parabrisas son compatibles). Entonces, los autos se enviaron a los clientes con un sistema de limpiaparabrisas que no funcionaba. Los diagnósticos iniciales señalaban al software como el culpable de la falla, puesto que era difícil para los mecánicos comprobar su comportamiento. Los otros componentes, (ECU, sensor y parabrisas) funcionaron normalmente cuando se probaron independientemente. El modo de fallo para el RSW residía al nivel de sus sub-sistemas, lo que hacía que fuera más difícil que el fabricante lo descubriera. Después de descubrir la causa raíz, se capturó un nuevo requisito para asegurar que los nuevos sistemas estuvieran calibrados adecuadamente en la etapa de producción. Los diagnósticos iniciales señalaron al software como el culpable de la falla Los mecánicos no pudieron probar el comportamiento del software Otros componentes (unidad de control electrónico, sensor y parabrisas) funcionaron normalmente cuando se probaron independientemente La falla no fue de componentes individuales, sino de la interacción a nivel de sistema

La Ingeniería de Requisitos Plantea Desafíos Significativos A lo Largo del Ciclo de Vida del Producto y a lo Largo de los Dominios de la Ingeniería Definición pobre de los requisitos de calidad A menudo los requisitos se expresan pobremente Los malos entendidos y las interpretaciones equivocadas suceden frecuentemente Normalmente la Definición de Requisitos es ineficiente Los requisitos son ubicuos e intensivos en trabajo La recopilación de requisitos es compleja e involucra a bastantes interesados La Gestión de Requisitos necesita de un compromiso significativo Muchas actividades son manuales (p. ej. al análisis de cobertura y de dependencia) Establecer y mantener la rastreabilidad puede consumir tiempo y ser propenso a errores La gestión de cambios puede ser difícil en el contexto de los requisitos A menudo los requisitos se validan tarde en el proceso, con vínculos al aseguramiento de la calidad en la última parte En la anterior diapositiva vimos con el limpiaparabrisas sensible a la lluvia (RSW), que una de las principales razones para la falla del RSW fue el hecho de que en ese momento no se había capturado adecuadamente para el RSW un requisito para la calibración adecuada del sistema (esto es, para verificar que el sensor y el parabrisas fueran compatibles). Un requisito faltante causó los problemas que tuvo el fabricante con el RSW. ¿Nadie pensó en este requisito de calibración? ¿En la fase de análisis de requisitos nadie consideró este escenario de un cambio en los parabrisas? ¿O el requisito simplemente se extravió durante el ciclo de vida del desarrollo? ¿O alguien no entendió la relevancia de este requisito? No lo sabemos, pero lo que sabemos y lo que hemos visto en la industria es que la Ingeniería de Requisitos Plantea Desafíos Significativos, a lo largo del Ciclo de Vida del Producto y de los Dominios de la Ingeniería. Proyecto, Configuración, Cambio, Herramientas de Medición y Documentación Herramientas de Ingeniería de Requisitos Herramientas de Análisis y Diseño Modelaje Herramientas Simulación Desarrollo Pruebas

Ingeniería de Requisitos Debe Estar Mejor Integrada al Ciclo de Vida del Producto
Necesidades del Cliente Definir Requisitos de Operación Desarrollo de Concepto Definición Preliminar Compilación de Producto / Sistema Definir Requisitos de Sistema Definición de Detalles Entrega de Producto / Sistema Ejecución / Soporte / Mantenimiento Análisis de negocios: Arquitectura Corporativa, Gestión de Procesos de Negocios, Gestión de Producto, Gestión de Portafolio Gestión de Programa y de Proyecto: Contabilidad de Costos, Planificación, Mediciones, Reportes, Gestión de Riesgo Definición de Requisitos y Diseño de Arquitectura: Particionamiento de Sistema Diseño e Implementación Detallados Ingeniería Mecánica Ingeniería Electrónica Explique el proceso de desarrollo de producto de alto nivel y enfóquese en el nivel de proceso de negocios. La descomposición de los requisitos funcionales es el resultado de un proceso de negocios de alto nivel y de los requisitos de nivel de sistema. La necesidad de integración de la integración de negocios con la descomposición funcional permitirá un desarrollo y entrega de producto acelerados, al tiempo que asegura la alineación con los requisitos del mercado. Resultado… Tiempo al mercado acelerado, reducción de costos de desarrollo, reducción en inversión en proyectos / productos abortados, mayor rentabilidad mediante la reutilización de sistemas y componentes, mayores ingresos debido a la introducción de nuevos productos, reducción del riesgo de negocios y reducción del costo de la calidad. Ingeniería de Software Integración Verificación y Validación Gestión de Requisitos Gestión de Cambios y de Configuración

¿Por qué Fallan con Frecuencia los Procesos de Requisitos
¿Por qué Fallan con Frecuencia los Procesos de Requisitos? Para Entregar los Resultados de Negocios Esperados El proceso de Ingeniería de Requisitos no está totalmente definido ni se hace cumplir Se utilizan múltiples herramientas de creación en el proceso de requisitos Datos inconsistentes de requisitos Falta de una visión unificada de requisitos a medida que cambian y maduran a lo largo del ciclo de vida Falta de comunicación a lo largo de los silos de negocios y funcionales Los grupos individuales interactúan con requisitos que son relevantes para sus procesos individuales Los requisitos deben ser el hilo común que mantenga enfocados a todos los equipos en entregar valor a los clientes A lo largo de todo el ciclo de desarrollo del producto A lo largo de todas las disciplinas de ingeniería – mecánica, electrónica y de software

¿Qué Hay Detrás de Estas Fallas y del Aumento de los Costos?
Desafíos de Negocios El producto pasó por alto necesidades de los clientes 46% Llegada tarde al mercado/pérdida de demanda 33% Comercialización / promoción inadecuada 26% Calidad del producto 24% Asignación de precio 23% No hay una diferenciación clara de los productos 19% Guía del CIO para el lanzamiento PERFECTO: Translating Innovation to Business Benefit, AMR Research, 2005 Oportunidades de Ingeniería Mejorar la comunicación y colaboración entre las disciplinas Aumentar la visibilidad del estado de los requisitos Aumentar la capacidad para predecir el comportamiento del sistema antes de las pruebas Implementar o cambiar los procesos de desarrollo de nuevos productos para un enfoque multidisciplinario Aumentar la visibilidad en tiempo real de la Lista de Materiales (BOM) del producto en todo el proceso de desarrollo 71% El nivel superior es bastante obvio. Quiero decir, no vamos a llevar al mercado todo lo que el cliente quiere. Tenemos sobrepeso en lo aeroespacial, tal vez, y estamos tarde. Usted sabe, la electrónica puede no contar con todos los dispositivos o simplemente puede ser demasiado compleja de utilizar. Y obviamente, llegar tarde al mercado es algo grave en algunas de estas industrias. Así que estar detrás de su mejor innovador no es algo bueno. Pero pienso que lo que es realmente interesante aquí es observar en el fondo la visión de la ingeniería. Esta es una nueva encuesta de este año. Y una cosa que simplemente se está tornando bastante clara para todos nuestros clientes es que es claro que la necesidad de colaborar entre las diferentes disciplinas y los diferentes dominios que hacen el producto, que diseñan el producto, la parte eléctrica, el software mecánico, todos estos dominios tienen que comenzar a trabajar juntos de mejor forma. Y usted verá el número uno, 71 por ciento de las personas dicen simplemente que mejoraron la comunicación y la colaboración entre todas las disciplinas. Y esta es una de las áreas en las que contamos con excelentes capacidades de solución y hablaremos sobre ello. La segunda cosa aquí es sobre la visibilidad cada vez mayor del estado de los requisitos. La mayoría de nuestros clientes grandes probablemente han gastado cientos si no miles de millones de dólares, y lo digo literalmente, miles de millones de dólares reuniendo sus PDM, sus sistemas PDM corporativos e integrándolos a sus sistemas de fabricación. Y lo que están haciendo con esto es que realmente están tratando de asegurar que se les está construyendo el material de construcción apropiado. Y gastan una tremenda cantidad de su tiempo, así como todo ese dinero en gestionar esa lista de materiales o compromiso. Y lo interesante es, usted sabe, a quién le importa si en realidad estoy construyendo para el compromiso correcto o para la lista de materiales correcta, si no se está construyendo para el conjunto apropiado de requisitos. Y hay algo que está sucediendo claramente en nuestra industria hoy, y es que los requisitos están separados de lo que estamos construyendo actualmente y llevando al mercado. Así que esta es otra área clave para nosotros, y es que nosotros realmente podemos ayudar con el estado de los requisitos y haciendo a los requisitos parte y elemento de todo el ciclo de vida del diseño. El tercer elemento aquí es el comportamiento para las pruebas – antes de las pruebas. Cómo puedo entender antes de las pruebas cómo funcionará este sistema de forma conjunta, cómo trabajarán juntas estas diferentes piezas y partes. Esto es más que simplemente ser capaz de hacer una representación digital del modelo mecánico. De manera que, ¿cómo puedo hacer análisis predictivo antes de tiempo? Y también tendremos un par de áreas diferentes para esto. Y luego implementemos o alteremos procesos de desarrollo de nuevos productos. Yo pensaba que esto era bastante fascinante. Cuarenta y tres por ciento de las compañías piensan que están desarticuladas en sus procesos inter-disciplinarios de desarrollo de productos. Necesitan cambiar la forma en que están haciendo desarrollo de productos, que es una falla fundamental aquí. Y de nuevo, tenemos algunas grandes ideas y algunas grandes soluciones que pueden ayudar a resolver esto y a llevarles a pasos cortos así como a pasos grandes, a hacer cambios en esta área. 49% 46% 43% 39% Aberdeen Group, System Design: New Product Development for Mechatronics, Michelle Boucher, David Houlihan, enero de 2008

Desafíos que Resultan de Procesos de Ingeniería de Requisitos Insuficientes Buenas Prácticas para una Ingeniería de Requisitos Exitosa Definición de Requisitos Gestión de Requisitos Gestión de Calidad orientada por Requisitos Hay tres buenas prácticas para una ingeniería de requisitos exitosa – definir los requisitos, la gestión de requisitos y la gestión de calidad orientada por requisitos.

¿Qué Son los “Requisitos”?
Un requisito es “una necesidad individual documentada, de lo que un producto o servicio particular debe ser o hacer”* Los Requisitos Funcionales describen ciertos comportamientos (o funciones) de “lo que el sistema deberá hacer” Los Requisitos No Funcionales describen qué tan bien deberán ejecutarse estos comportamientos (o funciones), p. ej., MTBF Los requisitos guían el desarrollo completo de un sistema Los requisitos se originan desde numerosas fuentes Los requisitos deben ser cohesivos, completos, consistentes, correctos, actualizados, factibles, no ambiguos y verificables Necesidades de Mercado Nivel Superior Especificación Funcional Especificaciones Especificaciones No Funcionales Sistemas Requisitos Especificaciones de Producto Estructural Interfaz De Wikipedia: „Requisitos en ingeniería de sistemas y de software En la ingeniería de sistemas, un requisito puede ser una descripción de lo que un sistema debe hacer, lo cual se conoce como un Requisito Funcional. Este tipo de requisitos especifica algo que el sistema entregado debe poder hacer. otro tipo de requisito especifica algo sobre el sistema en sí y qué tan bien efectúa sus funciones. A menudo tales requisitos son llamados Requisitos no funcionales, o 'requisitos de desempeño' o 'requisitos de calidad de servicio.' Algunos ejemplos de tales requisitos incluyen la disponibilidad, la capacidad de someterse a prueba, el mantenimiento y la facilidad de uso. Una colección de requisitos define las características o dispositivos del sistema deseado. Una 'buena' lista de los requisitos generalmente evita decir cómo debe implementar el sistema los requisitos, dejando tales decisiones al diseñador de sistema. La descripción de cómo se debe implementar el sistema se conoce como "solucionaría". En la ingeniería de software aplican los mismos significados de requisitos, excepto que el foco de interés es el software en sí.“ *Fuente: Wikipedia 2008

Es Necesario un Enfoque en la Ingeniería de Requisitos Para Lograr Productos que Respondan Mejor a las Necesidades del Cliente Cierra las brechas y enlaza el ciclo de vida de desarrollo del producto Cierra las brechas en la comunicación y el intercambio de datos entre el marketing, la ingeniería y el intercambio del producto Evita que ‘se pasen por alto’ dispositivos requeridos por el cliente Reduce el trabajo adicional, demoras y costos por garantía; mejora la satisfacción del cliente Lleva a ingenieros mecánicos, eléctricos y electrónicos a ‘la misma página’ de los ingenieros de sistemas y de software Permite que los problemas se descubran mucho más rápido en el ciclo de vida del desarrollo, resultando en menores llamados a devolución Establezca disciplina y gobierno para la ingeniería de requisitos a lo largo de todo el ciclo de vida del proyecto: Proporcione visibilidad de requisitos a lo largo de todas las disciplinas de ingeniería, a lo largo de todo el producto, no sólo en silos 19 19

Establezca Prioridades
Es Necesario un Proceso de Requisitos Sistemáticos Para Entregar Productos que Sean Exitosos y Rentables Consulte las notas del ponente para más información Definición de Requisitos +Gestión de Requisitos = Ingeniería de Requisitos Inspire ¿Estamos resolviendo el problema correcto? Obtenga, capture, elabore, revise y discuta sobre los requisitos usando una variedad de técnicas y notaciones. Conceptualice Definición de Requisitos Analice Haciendo Posible que Expertos en Negocios y en Tecnología Colaboren en los Requisitos Note los problemas que se resuelven mediante la definición y gestión de requisitos: Definición de requisitos – ¿Estamos resolviendo el problema correcto? Y note cómo este problema se resuelve dentro de la solución Rational: Obtenga, capture, elabore, revise y discuta sobre los requisitos usando una variedad de técnicas y notaciones. Administración de requisitos – ¿Estamos resolviendo el problema correctamente? Y note cómo este problema se responde al problema en la solución Rational: Ponga los requisitos en estructuras y relaciones usando atributos, enlaces y señales. Gestione el cambio usando análisis de impacto y de cobertura. Analice ¿Estamos resolviendo el problema correctamente? Gestión de Requisitos Ponga los requisitos en estructuras y relaciones usando atributos, enlaces y señales. Gestione el cambio usando análisis de impacto y de cobertura. Establezca Prioridades Comprenda

Solución de Ingeniería de Requisitos de IBM Para Programas, Proyectos, Productos, Sistemas y Sistemas-de-Sistemas Solución de Ingeniería de Requisitos de IBM Captura • Análisis de Compensación • Validación • Gestión de Cambios • Rastreabilidad • Análisis de Impacto • Reportes y Mediciones • Monitoreo Análisis de Negocios Análisis e Implementación de Sistemas/Productos Prueba y Mantenimiento Análisis Ideas Implementación Definición de Requisitos Gestión de Requisitos Llevando a todos a la misma página Incluye proveedores y sub-contratistas Alcance de la gestión, además de evaluación y control del impacto del cambio Asegurando rastreabilidad de punta a punta – ¡una característica clave de un buen proceso de AR! Desde ideas, definición de características, especificaciones de producto y modelos... Hasta implementación, pruebas y mantenimiento de elementos mecánicos, eléctricos/electrónicos y software incorporado Asegurando la conformidad con los acuerdos contractuales Demostrando cumplimiento de las regulaciones Explique la diferencia entre Requisitos para Programas, Proyectos, Productos, Sistemas y Sistemas-de-Sistemas Los programas se originan en las necesidades de negocios y de los Procesos de Negocios de nivel superior. Por ejemplo, en el sector automotriz, la plataforma de desarrollo de un nuevo vehículo se maneja como un “Programa” Nuestra solución es “asegurar la rastreabilidad de punta a punta, desde ideas, definición de requisitos y dispositivos, especificaciones de producto/sistema y modelos, hasta la implementación, pruebas y mantenimiento de lo mecánico, eléctrico/electrónico y del software incorporado”. ¡La rastreabilidad es una característica clave de un buen proceso de AR! De nuevo: Ingeniería de R. = Definición de R. + Gestión + una gran cantidad de otras actividades específicas como análisis de compensaciones, gestión de cambios, etc. Las cuatro flechas “Ideas”, “Análisis”, “Implementación” y “Prueba y Mantenimiento” son sólo 4 fases ejemplares de cualquier proyecto de desarrollo.

Buenas Prácticas de la Ingeniería de Requisitos
Mejores compañías en su clase... Requisitos de ingeniería: Desde el comienzo del ciclo de vida de producto y sistema A través de cada fase del desarrollo A lo largo de todas las disciplinas en mecánica, electrónica y software Asegurar la rastreabilidad a lo largo de todos los niveles de requisitos Madurar de un entorno aislado hacia uno colaborativo Invertir el mismo enfoque y rigor en los requisitos de ingeniería que en la gestión de una Lista de Materiales mecánica Integrar estrechamente la Ingeniería de Requisitos con la Gestión de Cambios, Productos y Portafolio y el Aseguramiento de la Calidad • • Asegúrese de que la audiencia comprenda que allá afuera hay compañías que ya han adoptado este tipo de Buenas Prácticas. Tal vez usted desee emplear algo de tiempo para explicar que la Gestión “no es suficiente – Estamos buscando „Ingeniería“, la cual cubre un espectro más amplio que „simplemente“ preocuparse por las listas y por la rastreabilidad de los elementos lineales de las listas. Este aspecto se verá más claramente cuando avancemos por las siguientes diapositivas. „ Invierta el mismo enfoque y rigor en gestionar requisitos que el que invierte en manejar listas de materiales (BOM) mecánicas” puede tornarse en algo delicado si en su audiencia hay personas que tengan responsabilidades en cuanto a BOM. Pero necesitamos aclarar desesperadamente a nuestros clientes que la Ingeniería de Requisitos tiene un impacto incluso mucho mayor en el éxito de los negocios que la gestión de BOM: Si una compañía construye productos con base en los requisitos equivocados, no importará qué tan bien se gestione la BOM. „a lo largo de todas las disciplinas Mecánicas, Electrónicas y de Software” también es un enunciado clave que necesita entregarse. Si los requisitos sólo son gestionados para SW y no son gestionados para todos los otros Sistemas – incluyendo Mecánicos, Eléctricos, Electrónicos, Hidráulicos, etc. – ¡entonces el resultado final del desarrollo de producto será más que incierto! Consulte las notas del ponente para más información

Desafíos que Resultan de Procesos de Ingeniería de Requisitos Insuficientes Buenas Prácticas para una Ingeniería de Requisitos Exitosa Definición de Requisitos Gestión de Requisitos Gestión de Calidad orientada por Requisitos

Tendencias de la Industria
Todo Comienza con el Proceso Correcto de Definición de Requisitos Defina los Requisitos mediante un Enfoque Colaborativo e Iterativo Colabore e itere con las partes interesadas Fomente el diálogo en torno a limitaciones y compensaciones Establezca prioridades y gestione cambios Logre un mutuo entendimiento sobre los requisitos Elabore para conocimiento de soluciones Defina alcance y límites Para el problema y para la solución sugerida Usando visualizaciones y escenarios Identifique los riesgos de la solución Tendencias de la Industria Ventas Asociados Regulaciones Clientes Proveedores

¿Cuáles son los ‘Requisitos’ para Definir Exitosamente los Requisitos?
Acuerdo entre todas las partes interesadas sobre el proceso para definir los requisitos Herramientas capaces de capturar percepciones, conocimiento y comunicación Repositorio Central Persiste todos los requisitos y datos relacionados tales como discusiones y comentarios Permitiendo acceso a todas las partes involucradas Infraestructura de TI que permite la colaboración Colaboración interna y externa Soporte de diferentes formatos adecuados para personas de negocios y técnicos Texto, gráficos, tablas, diagramas Capacidad para hacer cumplir un flujo de trabajo definido Incluyendo aprobaciones, acreditaciones, etc. Glosarios Compartidos Reducen la ambigüedad en cuanto a terminología

Servidor de Colaboración
La Definición Efectiva de Requisitos se Basa en la Colaboración Para Juntar Múltiples Puntos de Vista Dispares Uso de Texto enriquecido, imágenes, y enlaces para capturar y organizar información estructurada y no estructurada Servidor de Colaboración Colaboración en tiempo real usando discusiones tipo Wiki, para alcanzar rápidamente el fin de sesión Construya Modelos de Caso de Uso y dé más detalles sobre procesos, actores y actividades Captura del propósito actual de un estado futuro con Diagramas de Procesos de Negocios Eliminación de la ambigüedad en terminología de negocios y tecnología con Glosarios Compartidos Visualice la experiencia del usuario con Bosquejos y Guiones Gráficos de Interfaz de Usuario Las metas y objetivos de negocios son las motivaciones para mejorar y optimizar los procesos de negocios. Las innovaciones en TI, incluyendo buenas prácticas, nuevas tecnologías como Web 2.0, nuevas plataformas y herramientas de desarrollo de software y proyectos TI, son los medios para soportar los procesos de negocios Las nuevas tecnologías también se presentan como nuevas oportunidades de negocios. Alinear los Negocios y la TI es la forma de lograr flexibilidad y agilidad de negocios mejorada. Analogía: Mapa de Google… usted debe tener una comprensión general de su roadmap (Vista de Negocios)… luego usted se acerca y mira los detalles sobre cómo ir del Sitio A al Sitio B. (Vista del Proceso)… usted puede profundizar un poco más para ver imágenes satelitales de las calles y de su destino (visión de TI) De forma similar al Mapa de Google, en el desarrollo de software orientado por negocios hay diferentes niveles de abstracción con diferentes enfoques. En esta charla nos estamos enfocando más en gestionar requisitos y procesos de negocios. 26

Rico Entorno de Creación Revisión Web y Aprobación
Rational Requirements Composer Definición de Requisitos y Colaboración Basada en Jazz Colaboración mejorada entre interesados de negocios y equipos de proyecto Lleva más pronto al proceso al equipo de desarrollo de sistemas Ofrecimiento basado en Jazz™ y enfocado en colaboración de equipo Rico Entorno de Creación Revisión Web y Aprobación Bosquejo de Procesos Interfaz de Usuario de Bosquejos y Guiones Gráficos Glosarios Casos de Uso Interfaz estilo wiki Categorice / Etiquete Comente Revise / Apruebe Integración Visio Requisitos de Texto Enriquecido Hoy Rational Requirements Composer (RRC) es beta, abierto y disponible gratuitamente. El RRC permite la definición y obtención de requisitos colaborativos para el desarrollo orientado por negocios. Construido sobre tecnología Jazz, RRC se convertirá en parte integral de la solución de Ingeniería de Requisitos de IBM Rational basada en Rational DOORS. ¡Tenga cuidado sí muestra esta diapositiva tanto como si no lo hace! ¡RRC es un Beta abierto, todavía no es un producto! En cuanto RRC esté a disposición, se integrará primero con Rational RequistePro. Este no se integrará inmediatamente después de GA con DOORS. Servidor de Colaboración Comparta el trabajo instantáneamente Usuarios / equipos / autorizaciones Conexión entre todos los artefactos Asignación de Versiones Rational DOORS

La Buena Administración de Requisitos Se Basa en un Enfoque Estructurado
Descomponga los requisitos en jerarquías Desde arquitectura de alto nivel hasta diseño de bajo nivel Desde el sistema completo hasta las disciplinas mecánica, de hardware y de software Gestione las relaciones entre requisitos De un nivel hacia otro y entre ellos Agregue atributos a los requisitos Autor, Historial, Prioridades, Riesgos, etc. Haga visibles los requisitos a lo largo de todo el ciclo de vida Proporcione acceso a los requisitos a todos los participantes en el proceso Necesidades de Mercado Especificación De Nivel Superior Especificaciones Funcionales Especificaciones No Funcionales Requisitos De Sistemas Especificaciones de Producto Estructurales De Interfaz Mantenga la visibilidad y la rastreabilidad de los requisitos a lo largo de todo el proceso

Requisitos del Usuario
La Gestión de Requisitos Debe Proporcionar Rastreabilidad del Ciclo de Vida Desde la Idea Hasta el Final del Ciclo Requisitos del Usuario Requisitos Técnicos Diseño Casos de Prueba La rastreabilidad es la clave para el cumplimiento Los requisitos iniciales serán descompuestos, lo cual crea relaciones de rastreabilidad Otras relaciones también pueden rastrearse, tales como “consiste en”, “verifica”, etc. Se debe hacer cumplir la rastreabilidad con el fin de asegurar la consistencia y que todo esté completo La rastreabilidad desde los requisitos del cliente y a través del desarrollo del producto para pruebas y entrega, permite a las organizaciones: Conocer cuáles requisitos se implementan y prueban y cuáles no Gestionar y defenderse frente a la ampliación del alcance

La Buena Gestión de Requisitos Permite un Análisis Profundo
Consulte los atributos para encontrar propiedades específicas “¿Cuántos requisitos están listados como de alto riesgo?” Use los reportes de rastreabilidad para verificar dependencias Antes de que se confirmen los cambios Encuentre enlaces “extraviados” “¿Cuáles requisitos detallados no están relacionados con un requisito de usuario de nivel superior?” Análisis de cobertura “¿Qué requisito de nivel superior no tiene requisitos de nivel inferior?” Análisis de impacto “¿Qué requisitos de nivel inferior son afectados si cambia un requisito de nivel superior?” Mantenga la rastreabilidad Para cada incremento, si usted desarrolla incrementalmente con fases concurrentes Para cada variante, si usted maneja variantes y líneas de producto Note cómo cada función le ayuda a resolver problemas específicos, por ejemplo usted puede consultar atributos para ver los datos de requisitos de forma específica que sea significativa para usted, por ejemplo, cuántos requisitos tienen alto riesgo, o que se pueda mantener la rastreabilidad para cada incremento si usted desarrolla incrementalmente o para cada variante si usted desarrolla múltiples variantes.

El Desarrollo de Sistemas Orientado por Modelo Mejora la Ingeniería de Requisitos Vinculando Requisitos a Modelos Gráficos “Las Mejores [compañías] en Su Clase reconocen que es crítico cumplir con los requisitos de diseño para llegar al producto final deseado… ellas planean el diseño a nivel de sistema y luego atan estos requisitos a cada aspecto del diseño.” “En la práctica, lo que esto implica no es simplemente asegurar que los requisitos estén anticipados correctamente, sino manejarlos a lo largo de todo el ciclo de vida del diseño.” Notas al ponente: Tal vez usted se pregunte por qué hay una referencia al enlace MDSM, Desarrollo de Sistemas Orientado por Modelo. Bien, simplemente porque nuestras capacidades para hacer MDSD dentro de (!) RE claramente nos diferencia en el mercado. Aberdeen Group, System Design: New Product Development for Mechatronics, Michelle Boucher, David Houlihan, enero de 2008

Requisitos del Usuario
Rational DOORS Gestione Todos los Requisitos A lo Largo del Ciclo de Vida y de las Disciplinas Requisitos del Usuario Requisitos Técnicos Casos de Prueba Diseño Visualizaciones combinadas de documento y hoja de cálculo Interfaces simples e intuitivas para una fácil adopción Historial y líneas de bases Navegador Requisitos Contexto Validación visual de punta a punta en una sola vista Entrada y resultado desde/hacia varios formatos comunes Resuelve el problema correcto porque los requisitos están visibles todo el tiempo Grabando los Requisitos dentro del Contexto

Rational DOORS Ofrece un Rico Conjunto de Dispositivos Comprobados Permitiendo una Fácil Adaptación de la Gestión de Requisitos Rastreabilidad mediante vinculación con arrastrar y soltar Enlace de documento a documento o dentro de un documento “Vinculación” automática para rastreabilidad de arriba a abajo, desde los requisitos hasta el código Escalable para proyectos grandes con muchos usuarios Espacio para Discusiones DOORS que permite procesos de revisión Acceso Web DOORS como una forma alternativa para acceder a sus datos Un número virtualmente ilimitado de atributos, en una vista tipo hoja de cálculo

Rational DOORS está Estrechamente Integrado con Rational Rhapsody
Rational Rhapsody® y Rational DOORS ofrecen Ingeniería de Requisitos y de Sistemas Orientadas por Modelo Los modelos facilitan la rastreabilidad de requisitos y de sistemas y la validación temprana del diseño; captura los problemas de forma más temprana en el ciclo de vida para reducir el costo de los errores Soporte completo UML 2.1 y SysML Tal vez usted se pregunte por qué aquí aparece esta referencia y enlace a MDSM, Desarrollo de Sistemas Orientado por Modelo. Bien, simplemente porque nuestras capacidades para hacer MDSD dentro de (!) RE claramente nos diferencia en el mercado.

Artefactos Gestionados Órdenes de Implementación
Rational DOORS Permite una Implementación Orientada por Requisitos Vinculando Requisitos a Configuraciones y Conjuntos de Cambios 1) Rational DOORS Los requisitos se enlazan con las órdenes de implementación Las órdenes de implementación se enlazan con las tareas de ingeniería Las tareas de ingeniería se enlazan con los artefactos gestionados Gestión de Cambios, Historial y Líneas de Base 2) Rational Change™ o Rational ClearQuest® 3) Rational Synergy™ o Rational ClearCase Artefactos Gestionados Órdenes de Implementación Tareas de Ingeniería 36

La Gestión de Calidad Inicia con la Ingeniería de Requisitos La Gestión de Calidad Necesita Fuertes Vínculos con los Requisitos Requisitos de interesado Especificaciones Diseño del sistema de Aceptación Integración y pruebas de Unidad Satisface Pruebas Los requisitos son la materia prima para todas las especificaciones de calidad y para las pruebas Un Requisito Funcional define “Lo Que” el objeto de prueba debe hacer Un Requisito No Funcional define “Qué Tan Bien” debe hacerlo el objeto de prueba Gestión de Calidad vinculada a la Gestión de Requisitos Incorpora los requisitos a planes de calidad y de pruebas Relaciona casos de prueba, suites de prueba, ejecuciones de prueba y resultados de prueba con los requisitos Muestra cuáles requisitos son comprobados y cuáles no Proporciona rastreabilidad entre y dentro de jerarquías de requisitos y de pruebas

Mejore la Gestión de la Calidad Con un Enfoque en Colaboración, Automatización y Reportes
Colabore Automatice Reporte Define claramente roles y responsabilidades en la Gestión de Calidad Crea y actualiza dinámicamente los planes de calidad y pruebas Comparte activos para la gestión de la calidad y de los requisitos Soporta casos de prueba orientados por requisitos y la definición de suites de prueba Ejecuta y evalúa pruebas de forma iterativa y temprana, manual o automáticamente Genera reportes de prueba Permite ejecución host y objetivo Comunica el estado de los proyectos eficientemente Mide el avance Proporciona tasas de cobertura incluyendo la cobertura de requisitos Colaboración, Automatización y Reportes son los tres pilares/disciplinas principales en las que se enfoca la RQM Eso es por lo que se eligieron estos 3 elementos aquí.

Gestión de Calidad Orientada por Requisitos Integra la Gestión de Calidad y la Ingeniería de Requisitos Rational Requirements Composer Rational Quality Manager Ingeniería de Requisitos *) Bosquejos y Guiones Gráficos *) Identifique y gestione requisitos a lo largo de su ciclo de vida Alinee la colaboración de equipo en torno a objetivos y resultados de negocios *2do trimestre de 2009 *2do trimestre de 2009 Procesos de negocios Casos de uso Rational DOORS Texto Enriquecido Planeación y configuración de la calidad más tempranas Requisitos vinculados con los planes de calidad Ejecución de pruebas más rápida Criterios de aceptación de objetivo Cobertura de pruebas de requisitos

IBM Rational Quality Manager
Rational Quality Manager Entregando Innovación Directamente en las Manos de los Profesionales de la Calidad Coordinación entre participantes y equipos Menos reuniones, menos trabajo adicional usando un plan de pruebas dinámico Flujo de trabajo de proceso automatizado Reduce las tareas intensivas en trabajo, mejora el tiempo del ciclo Capture problemas de calidad temprano, con colaboración de ciclo de vida IBM Rational Quality Manager Mejora del proceso en curso Historial y tendencias de versión dentro y a lo largo de los proyectos Gestión proactiva de riesgos y toma de decisiones Reportes automatizados, filtrados y con prioridad asignada Tome decisiones con confianza con reportes sin esfuerzo

Rational Quality Manager Rational Requirements Composer
Solución de Ingeniería de Requisitos de IBM En Palabras de los Clientes Rational Quality Manager “Pienso que… ahora las organizaciones tienen más opciones… No están obligadas a usar HP si no funciona bien en su entorno de desarrollo… Y con la buena integración con el sistema de control de versiones, mi opinión es que actualmente ellos [Rational] tienen una oferta de prueba mejor integrada que la de sus competidores.” Compañía de Servicios de TI Rational Requirements Composer Rational DOORS Cotización de compañía de Servicios de TI de la presentación de ventas RQM en XL Cotización de RCC de la presentación de ventas RCC en XL Cotización de DOORS de una presentación de ventas “ DOORS mejora la comunicación del equipo de desarrollo, lo cual ayuda a cumplir con los requisitos del cliente, más rápido y con mayor precisión.” Fabricante de Partes Automotrices “ Vemos buenas oportunidades para mejorar nuestros proyectos de TI con un excelente retorno de la inversión en el Requirements Composer” Banco

¿Por qué IBM para Ingeniería de Requisitos?
“DOORS nos permite planear, ejecutar y realizar seguimiento del progreso de las prácticas que hemos mejorado para nuestros miembros... DOORS nos ayuda a proporcionar un buen ejemplo de buenas prácticas en la ingeniería de sistemas.“ Pat Hale, Presidente electo, Consejo Internacional de Ingeniería de Sistemas (INCOSE) Business Wire, 15 de mayo de 2007 “DOORS (Telelogic) ofrece la mejor cobertura de nuestra lista de requisitos. Se destaca en nuestras cuatro dimensiones de evaluación. DOORS demuestra fortalezas en la captura, enlace y análisis de los requisitos durante todo su ciclo de vida.” Yphise Desarrollo Ágil Orientado por Requisitos, Yphise, Marzo de 2008

Aporte de Herramientas de Ingeniería de Requisitos
IBM Ofrece las Mejores Soluciones en su Clase para Ingeniería de Requisitos Aporte de Herramientas de Ingeniería de Requisitos A lo largo de las disciplinas de ingeniería Con base en Rational DOORS Enriquecido con ofrecimientos basados en Jazz Mejorado con integraciones y capacidades para gestión de configuración y de cambios Servicios de Ingeniería de Requisitos y Soporte Adicional Servicios de Mejora de Procesos, incluyendo evaluaciones, consultoría, educación y tutorías Fuerte liderazgo y extensiones de producto por parte de IBM Global Business Services y Asociados IBM (p. ej., Buenas Prácticas de Línea de Producto de Ingeniería) Soporte de Estándares (p. ej., CMMI) Dos flechas expresan que nuestros ofrecimientos en términos de Productos están estrechamente vinculados con nuestros ofrecimientos en términos de Servicios. Esto nos diferencia de otros: Nosotros contamos con ambos, herramientas y servicios. ¡Con IBM Global Business Services tenemos disponible para nuestros clientes uno de los equipos de expertos más grandes del mundo! GBS puede hacer más de lo que las organizaciones Rational Services pueden hacer, p. ej., pueden ofrecer AMS – servicios gestionados de aplicación, donde p. ej., GBS opera todo el entrono de TI incluyendo nuestros productos Rational. GBS puede ofrecer servicios específicos de ingeniería, pero también consultoría de alto nivel de gestión de cambios. ¡Debemos usar esta oportunidad para diferenciarnos frente a otros proveedores de herramientas!

Puntos de Aprendizaje Al finalizar esta actividad, los participantes deberán estar en capacidad de: Describir algunos de los desafíos clave del desarrollo de productos en el sector industrial Describir los desafíos de la ingeniería de requisitos Describir en dónde encaja la ingeniería de requisitos dentro del proceso de desarrollo de producto Describir por qué fallan los procesos de requisitos y las razones comunes por las que fallan los productos Describir los beneficios de un enfoque mejorado de la ingeniería de requisitos Listar los componentes de una solución de ingeniería de requisitos Describir las capacidades clave y los beneficios de Rational DOORS, Rational Requirements Composer y Rational Quality Manager como parte de la solución de Ingeniería de Requisitos de IBM

Información de Copyright
IBM Latin America HQ One Alhambra Plaza Coral Gables, FL USA La página de presentación de IBM puede encontrarse en: ibm.com IBM, el logotipo IBM, ibm.com y Rational son marcas registradas de International Business Machines Corporation en Estados Unidos, otros países o ambos. Si estos y otros términos con marca registrada de IBM están identificados en su primera ocurrencia en esta información con el símbolo de marca registrada (® o ™), estos símbolos indican marcas registradas o marcas registradas de derecho consuetudinario en EE. UU. de propiedad de IBM en el momento que se publicó esa información. Dichas marcas registradas también pueden ser marcas registradas o marcas registradas de derecho consuetudinario en otros países. Una lista actualizada de marcas registradas de IBM está disponible en la Web en "Copyright and trademark information", en: ibm.com/legal/copytrade.shtml Otros nombres de compañías, productos o servicios pueden ser marcas registradas o marcas de servicios de otros. Las referencias en esta publicación a productos o servicios de IBM no implican que IBM pretende ponerlos a disposición en todos los países donde IBM opera. La información contenida en este documento se facilita sólo para fines informativos y es provista "tal como está", sin garantías de ninguna clase, expresas o implícitas. Además, esta información se basa en los planes y en la estrategia actuales de IBM respecto a los productos, que pueden ser cambiados por IBM sin aviso. Sin limitación a lo mencionado arriba, todas las declaraciones respecto a los rumbos futuros o a la intención de IBM están sujetas a cambio o retractación sin aviso y representan solamente metas y objetivos. Nada de lo contenido en esta documentación tiene la intención o tendrá el efecto de generar ninguna garantía o declaración de IBM (o bien de sus proveedores o concedentes de licencias) o de cambiar los términos y condiciones del acuerdo de licencia referente al uso del software de IBM. Los clientes de IBM son responsables de asegurar su propia conformidad con los requisitos de la ley. El cliente es el único responsable de obtener asesoría jurídica competente respecto a la identificación e interpretación de las leyes y requisitos normativos relevantes que puedan afectar la empresa del cliente y las actitudes que el cliente pueda tener que tomar para cumplir con dichas leyes. Producido en los Estados Unidos de América © Copyright IBM Corporation Todos los Derechos Reservados 47

Ingeniería de Requisitos

Presentaciones similares

Presentación del tema: "Ingeniería de Requisitos"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Ingeniería de Requisitos

Presentaciones similares

Presentación del tema: "Ingeniería de Requisitos"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback