El uso de la Stakeholder Collaboration Strategy con Rational Requirements Composer: Parte 1. La audiencia

Este es el primero de una serie de cuatro artículos sobre la configuración y el uso de IBM Rational Requirements Composer. La serie abarca cuatro áreas claves: la audiencia, la organización de proyectos y espacio para depósitos, la estrategia de enlaces y la estrategia de colaboración. Esta refleja la necesidad de determinar la audiencia, decide qué artefactos lo ayudarán a armonizar y validar los requisitos, y la necesidad de planificar una estrategia de colaboración con la audiencia. En la última sección se determina un plan para la revisión y la mejora del proceso para la próxima vez.

Lisa Garrity, IT Specialist, IBM

Author1 photoLisa Garrity trabaja como asesora técnica para IBM Rational software en el Reino Unido. Ha trabajado en el área del desarrollo de software durante 16 años, realizando asesoramiento y ventas técnicas. Entre sus responsabilidades principales se encontraban la determinación, la administración y la documentación de requerisitos empresariales y del análisis de sistemas, así como el soporte de clientes en su búsqueda por el éxito en el desarrollo de software. Lisa es instructora regional de administración y definición de Rational Requirements en el Reino Unido y se unió al Rational software en 2002.



Paula White, Consulting IT Specialist, IBM

Photo of Paula White Paula White es asesora técnica de IBM Rational software en el Reino Unido. Ha trabajado en el área de desarrollo de software durante más de 19 años. Ha trabajado también como arquitecta, ingeniera de software, instructora, coach, mentora, y asesora. Actualmente, trabaja como arquitecta de marcas Rational y dirige el Rational Brand Architects team en el Reino Unido. Es instructora regional de administración y definición de requisitos en el Reino Unido. Se unió al Rational software en 2002.



21-01-2011

Introducción

Hoy en día existen muchos problemas en la definición y la administración de requisitos. Mucha gente está reconsiderando su enfoque sobre el tema. Rational Requirements Composer puede soportar sus esfuerzos. La tabla muestra algunas de las razones subyacentes sobre el motivo por el cual se podría adoptar el RRC.

Tabla 1. Determinación del problema
QuéCómo
Los posibles problemas La determinación, la definición, y la comunicación de los requisitos a lo largo de todo el ciclo de vida son tareas complejas que cubren abarcan varias áreas. Esto puede ocasionar los siguientes problemas:
  • Las empresas y la IT están desalineadas, por lo tanto los proyectos podrían no producir el valor esperado
  • El objetivo, el contenido y el contexto original de las especificaciones pueden malinterpretarse
  • La documentación demasiado textual es difícil de comprender
  • Las partes interesadas no tienen acceso a toda la información cuando toman decisiones
  • Las partes interesadas malinterpretan los documentos que se les pide que revisen porque son demasiado extensos, carecen de técnicas visuales, su contenido no es personalizado, y el escenario o contexto está poco definido.
  • Los autores podrían obtener un feedback importante de una revisión, y procesarlo podría resultar difícil y consumir mucho tiempo.
  • Los proyectos malos implican una visión poco clara, una comunicación poco frecuente, y equipos que se desarrollan sobre presunciones incorrectas
  • Los autores no reciben feedback o el feedback que reciben es insuficiente cuando las partes interesadas con comprenden los dispositivos suministrados o no los ven como su responsabilidad
  • Los desarrolladores no pueden comprender o definir con facilidad el contexto de los requisitos
  • Los equipos tienen dificultades para comunicarse debido a las barreras geográficas
  • Los equipos que desean comunicar las modificaciones encuentran esta tarea difícil.
  • La infraestructura dispar crea una barrera para la colaboración y la definición de requisitos comprensibles
El impacto de todo esto podría dar lugar a alguna de las siguientes circunstancias
  • Surge trabajo adicional relacionado con la reespecificación, el diseño, el desarrollo y la prueba del sistema.
  • Se pierde la posibilidad de reutilizar y producir cuando las partes interesadas no tienen acceso a los dispositivos
  • Las partes interesadas no proporcionan feedback de forma proactiva dado que es difícil encontrar dispositivos relevantes
  • Las partes interesadas a veces no proporcionan feedback o el feedback que proporcionan no es de alta calidad porque es difícil comprender los requisitos
  • Quienes realizan las pruebas no pueden hacer su tarea con facilidad cuando no logran encontrar toda la información relevante
  • Los equipos de los proyectos geográficamente distribuidos son menos productivos y exitosos
  • El cambio y el grado de respuesta a la empresa es restringido
  • Se pueden realizar muchas predicciones sobre requisitos caros y descontrolados que no necesariamente proporcionan valor empresarial
  • Entrega tardía de la solución
  • Costos más altos
  • Calidad inferior y una solución que no suministra a la empresa el valor esperado
  • Confianza reducida y una relación deteriorada entre la empresa y las unidades de IT
  • Credibilidad y reputación de IT reducida
Una solución exitosa Beneficiaría la determinación de los requisitos, la definición, la validación y la colaboración entre las partes interesadas en todo el ciclo de vida de la solución
Conduciría al entendimiento entre las necesidades de las partes empresariales y el acuerdo de las partes interesadas sobre los requisitos que impulsan el desarrollo de una solución en curso que proporciona valor a las partes empresariales interesadas

Introducción a Rational Requirements Composer

IBM® Rational® Requirements Composer software ayuda a definir y administrar requisitos en contexto. La herramienta soporta la colocación de una infraestructura dinámica para los dispositivos de los requisitos y la colaboración entre los mismos. Esta serie de artículos suministra un marco conceptual para que una organización o un proyecto saque el mayor provecho de Rational Requirements Composer mediante:

  • La consideración de las opciones a utilizar
  • La planificación de la configuración en base a las opciones que existen al comienzo del proyecto
  • El alineamiento del uso en curso a medida que el proyecto avanza con las partes interesadas
  • La consideración del modelo de uso para el escenario de desarrollo
  • La revisión y la redefinición del uso para el siguiente nivel o para proyectos futuros

Esto permite a los equipos:

  • Encontrar los dispositivos y requisitos fácilmente
  • Adoptar el conjunto de dispositivos y los tipos de requisitos adecuados
  • Comprender el contexto de los dispositivos y los requisitos de los proyectos
  • Apuntar a la audiencia correcta:
  • Obtener un mayor nivel de transparencia relevante y de feedback proactivo
  • Reutilizar dispositivos en un mismo proyecto o en varios
  • Mejorar la colaboración de los roles del equipo y la organización
  • Obtener un feedback más temprano de un amplio rango de las partes interesadas, particularmente de la empresa

Esto podría ocasionar que disminuya la cantidad de procesos repetidos,y que se produzca una mayor reutilización, una entrega más rápida y un mejor valor empresarial.

Consejo

Algunos pequeños elementos preconfigurados pueden marcar una gran diferencia en cuanto a la productividad y la accesibilidad. Este artículo lo ayudará a identificar estas áreas.

Rational Requirements Composer ofrece una gama de posibilidades que van desde la simple especificación y el proceso suficiente hasta algo más formal. En la práctica, la creación de un enfoque con alguna estructura facilita el uso. El enfoque y la cantidad de estructura varía, dependiendo del proyecto y del equipo. Esta herramienta es por lo general más adecuada para la definición y la administración de los requisitos altamente colaborativos. Resulta particularmente útil en un entorno geográficamente distribuido o tercerizado.

Rational Requirements Composer brinda un entorno de equipos completamente colaborativo que es apropiado para varios escenarios de uso:

  • La elaboración de las necesidades del usuario y las historias de los elementos en una pila de producto o de iteración
  • La producción de ideas
  • El desarrollo de proyectos desde su surgimiento hasta su actualización
  • La creación de documentos contractuales para la contratación y el desarrollo del proyecto

La mayor parte de la funcionalidad de Rational Requirements Composer es intuitiva. Esta serie de artículos suministra una lista de verificación simplemente para ayudar al equipo a comenzar a trabajar en conjunto. En los artículos se ofrecen ejemplos y en el anexo hay un resumen de todo esto.

Estos artículos suponen que los lectores tienen experiencia con Rational Requirements Composer software, la definición de requisitos, y las técnicas de administración y proceso. Estos artículos también mencionan IBM® Rational Team Concert® e IBM® Rational® Quality Manager. En el momento de la publicación inicial, todos estos productos Rational estuvieron en varios releases de la Versión 2.

Nota:
Estos artículos no reemplazan la ayuda o la documentación en línea para ninguno de estos productos.


La Stakeholder Collaboration Strategy

El resultado de la consideración de estas opciones es Stakeholder Collaboration Strategy (SCS) la cual describe el enfoque para la colaboración entre las partes interesadas sobre los requisitos y sobre cómo esta actividad sería soportada usando Rational Requirements Composer (ver Figura 1). Usted puede utilizar sólo las secciones de esta estrategia que agregan valor a su proyecto.

El diagrama siguiente brinda una visión general ilustrativa de algunas de las áreas a tener en cuenta al utilizar Rational Requirements Composer y crear una Stakeholder Collaboration Strategy. Cada área constituye un tema de un artículo subsiguiente en esta serie de cuatro partes (vea los enlaces en "More in this series"):

  • Parte 2. Organización del proyecto y del espacio disponible para el depósito
  • Parte 3. Estrategia de enlace
  • Parte 4. Enfoque de colaboración
Figura 1. Visión general de la Stakeholder Collaboration Strategy
Visión general de la Stakeholder Collaboration Strategy

La Stakeholder Collaboration Strategy (SCS) establece los planes para la determinación, la documentación, la validación, y la administración de requisitos. Esta ayuda a determinar cómo configurar Rational Requirements Composer para que soporte la definición de requisitos y el proceso de administración. El planteo de estas cuestiones puede ayudar a dar forma a SCS:

Partes interesadas
¿Quien tiene interés en la obtención de una solución? ¿Qué responsabilidades tiene cada parte interesada en relación a la obtención de una solución? ¿Las partes interesadas están desarrollando o probando la solución? ¿Están solicitando capacidades y beneficios empresariales? ¿Están suministrando experiencia, validación o aprobación?
Dispositivos
¿Qué dispositivo desarrollarán? (Ejemplos: documentos, guiones gráficos, diagramas de casos de uso, diagramas de procesos empresariales, y glosarios)
Estructura de carpeta
¿Cómo será organizada la información de modo que navegar en ella sea sencillo? (Consulte Rational Requirements Composer roles.) ¿Qué se necesita para que la navegación en la estructura sea sencilla para quienes la revisan y la aprueban?
Enlace
¿Cuál es la estrategia para enlazar los dispositivos? ¿Cómo deben navegar los miembros del equipo, y qué sentido tiene para el equipo? (Ejemplos: escenario de caso de uso a tarea escenario de guión gráfico, o tarea de proceso empresarial a boceto de interfaz)
Información contextual
¿El material de referencia se reunirá y se conservará en Rational Requirements Composer? (Ejemplos; fotografías de tareas en pizarras blancas, documentos, presentaciones que iniciaron el proyecto)
Plantillas
¿Qué plantillas existen para los dispositivos de los requisitos? (Ejemplos: plantilla de caso de uso, sentencia de visión)
Colaboración
¿Qué partes interesadas deben colaborar en los requisitos? ¿Cuál es el plan para colaborar con su parte interesada? ¿Cuándo comenzarán los comentarios? ¿Se están desarrollando? ¿Se realizarán revisiones formales e informales?
Revisiones
¿Qué revisiones son necesarias para cada dispositivo o conjunto de dispositivos, y quién las realizará? ¿Cuál es el nivel de formalidad necesario para cada revisión?
Informes
¿Qué informes pueden entregarse, y deben entregarse en algún formato específico?
Etiquetas
Todos los requisitos y los dispositivos contextuales se encuentran en el proyecto Rational Requirements Composer. ¿Se utilizarán etiquetas para facilitar la marcación de los dispositivos y su búsqueda?
Rastreo
¿Qué atributos serán rastreados para cada requisito? (Ejemplos: fuente, prioridad, complejidad y tipo)
Administración de cambios a los requisitos
¿Cuándo los requisitos dejarán de ser comentarios informales y feedback de revisión para pasar a ser requisitos de administración formal con solicitudes de modificaciones o elementos de trabajo?

Audiencia

La audiencia abarca el equipo más amplio de partes empresariales interesadas, operaciones y soporte, y miembros del equipo del proyecto, incluyendo aquellos roles específicos de Rational Requirements Composer.

Figura 2. "Audiencia" incluye todas las partes interesadas

Partes interesadas

Valor del feedback temprano

Cuando las partes interesadas y las operaciones de la empresa son consideradas desde el comienzo, se obtiene un feedback valioso temprano en el proceso. Las operaciones, en particular, podrían refinar los requisitos que de otro modo podrían perder u ocultar riesgos de arquitectura. La determinación de este feedback temprano puede mejorar la capacidad de respuesta por parte del equipo y desarrollar un sentido compartido de propiedad.

Las partes interesadas incluyen cualquiera que pudiera verse afectado económicamente por la implementación de un nuevo sistema o de una nueva aplicación (vea la segunda cita en Resources). Aunque algunas partes interesadas podrían convertirse en usuarios finales, muchos otros se ven afectados por el resultado empresarial del suministro del sistema. Como resultado, entre las partes interesadas encontramos a todos aquellos que desarrollan y proporcionan el sistema. Los terceros que interactúan con el sistema o regulan la empresa están incluidos, al igual que la gente del rubro que esponsorea la solución pero no necesariamente la utiliza.

La participación insuficiente de las partes interesadas puede ocasionar la falta de requisitos que se descubren más tarde en la etapa de desarrollo o cuando el sistema se activa. Esto a menudo da como resultado un sistema que no funciona como es necesario o como se pretende.

La Stakeholder Collaboration Strategy debe establecer:

  • Quiénes son las partes interesadas
  • Cuáles son sus responsabilidades en Rational Requirements Composer
  • Si son colaboradores, cómo colaborarán
  • Si no son colaboradores, cómo se tratarán e incluirán los requisitos y las preocupaciones
  • Cuáles son los roles de las partes en Rational Requirements Composer

Utilice fotografías

Las fotografías son útiles para alentar la colaboración. Dado que las fotografías son cargadas a través del sitio de administración web de Jazz, el administrador del servidor puede hacer esto como parte de la creación de cuentas de los usuarios.

Los roles en Rational Requirements Composer

En la Tabla 1 se describen los posibles roles que pueden tener las personas en los procesos de Rational Requirements Composer. Se espera que la mayoría de las partes interesadas retengan el acceso como revisor para la revisión de solo lectura y las capacidades de comentarios completos. Algunas partes interesadas pueden necesitar acceso de Autor para crear dispositivos.

Tabla 2. Roles y responsabilidades estándar de Rational Requirements Composer
RolResponsabilidades
Comentaristas Revisan (leen) y comentan sobre los dispositivos de requerimientos específicos y las descripciones (por omisión solamente tienen acceso de solo lectura)
Autores Escriben dispositivos de requisitos o descripciones o modifican los existentes
Administradores Crean proyectos, agregan y eliminan usuarios en un proyecto, acceden a la etiqueta de administración, y administran las integraciones a las otras herramientas
Administradores de capturas de pantalla del proyecto Crean capturas de pantalla del proyecto.
Administradores del servidor* Son responsables por el mantenimiento y el soporte del servidor de Rational Requirements Composer mediante el uso de IBM® Rational® Jazz™ Team Server interface. Esto podría incluir la creación de nuevos proyectos y la asignación de personas a los proyectos. Si corresponde, este rol administra las integraciones a otras herramientas, como Ravenflow, iRise, IBM Rational Team Concert, IBM® Rational® Quality Manager, IBM® Rational® DOORS®, e IBM® Rational® RequisitePro®. Este usuario tiene derechos de administrador de JazzAdmin y Rational Requirements Composer.

* Administrador de servidor no aparece como rol formal en la herramienta Rational Requirements Composer, pero es útil asignarla. Este rol asume varias actividades de administrador fuera del entorno de Rational Requirements Composer.

Consejo:
Usted puede además crear roles personalizados y definirlos en SCS.

Los roles de las partes interesadas del proyecto

Cualquier solución suministrada debe agregar valor a la empresa, de modo que vale la pena reiterar la necesidad de incluir roles de línea de negocio. La Tabla 2, a continuación, brinda ejemplos de posibles roles de partes empresariales interesadas y de desarrollo.

LosComentaristaspodrían principalmente utilizar la interfaz web para revisar y comentar los requisitos. La ventaja del uso de un navegador es el fácil acceso y la falta de necesidad de instalación de una herramienta de cliente. Los autores y los administradores de los requisitos utilizan la interfaz rica de cliente para crear y modificar proyectos y dispositivos. Es útil especificar el tipo de acceso en la Tabla de partes interesadas de modo que Rational Requirements Composer puede configurarse para reflejar las necesidades de las partes interesadas.

LosAutores pueden incluir cualquier rol relacionado con el desarrollo o la empresa. Las organizaciones deberían considerar en que grado desean utilizar Rational Requirements Composer para el análisis de la empresa y los requisitos y también en que grado les gustaría utilizarlo para el análisis de sistemas, el diseño y la arquitectura. Esta decisión afectará a las partes interesadas que son autores en Rational Requirements Composer y a los dispositivos que definen.

La Tabla 2 describe ejemplos de muchos roles posibles y las responsabilidades correspondientes. Aunque los roles de administrador de Rational Requirements Composer se marcan como opción para varios roles de proyecto, una persona específica debe asumir estos roles. Hay flexibilidad para todos los roles. Todo depende del equipo y de cómo funciona.

Tabla 3. Los roles y responsabilidades del equipo correspondientes a los roles de Rational Requirements Composer
Rol del equipoResponsabilidades del proyectoRol de Rational Requirements Composer
Los espónsores de la solución Responsables de guiar el proyecto para lograr los objetivos empresariales.
El suministro de soporte organizacional necesario mediante la búsqueda de fondos o la asistencia en la conducción de la organización.
Comentarista
Expertos en la materia Responsables de la validación y la especificación de las necesidades empresariales para la solución, así como la decisión de lo que es adecuado para el objetivo empresarial. Comentarista
Usuarios finales Usuarios directos o indirectos del sistema (consulte la primera cita en Resources si desea más información) Comentarista
Autor (opcional)
Informantes Administradores de usuarios, administrador de programa o cartera, desarrolladores que trabajan en los sistemas que integran o interactúan con él en el desarrollo, el mantenimiento de profesionales posiblemente afectados por el desarrollo y/o despliegue de su sistema, auditores (consulte la primera referencia en Resources) Comentador
Autor (opcional)
Administrador de proyecto o líder del equipo Responsable de la entrega del proyecto. dirige y administra el equipo del proyecto.
Debe comprender los requisitos para el alcance y la planificación del proyecto junto con otros miembros del equipo. Podría tener conocimiento de cuando tomar una captura de pantalla (por ejemplo, cuando los dispositivos han alcanzado un nivel de madurez o al final de una iteración o del ciclo de revisión).
Comentarista o autor
Administrador (opcional)
Administrador de captura de pantalla de proyecto (opcional)
Dueño del producto Define y promueve la visión, los objetivos y las capacidades del producto de modo que el equipo pueda tomar decisiones. Determina el alcance y el contenido del release. Define el criterio de aceptación para el release y determina cuando el sistema está listo para el release. Autor
Administrador (opcional)
Administrador de captura de pantalla de proyecto (opcional)
Analistas empresariales Tradicionalmente responsable de la traducción de las necesidades empresariales como capacidades que se puedan entregar. Documenta el problema empresarial y la visión de la solución de un modo claro para las partes interesadas correctas. Clarifica los detalles de la solución a la empresa y a los miembros del equipo de entrega de la solución de modo que todos lleguen a un acuerden razonable de lo que se entregará (y de lo que no). El analista empresarial líder podría estar al tanto de cuando tomar una captura de pantalla (por ejemplo, cuando los dispositivos han alcanzado un nivel de madurez o al final de una iteración o del ciclo de revisión). Autor
Administrador (opcional)
Administrador de captura de pantalla del proyecto (opcional)
Arquitecto Responsable de la arquitectura de soluciones integrales; esto supone asegurar que los requisitos sean alcanzables y que se puedan entregar. Revisa los requisitos con esto en mente. Los arquitectos pueden decir si es posible entregar la solución solicitada y las alternativas presentes para superar los puntos técnicos de fricción. Estas consideraciones deben incorporarse a los requisitos. Podría tener conocimiento de cuando tomar una captura de pantalla (por ejemplo, cuando los dispositivos han llegado a un nivel de madurez o al final de una iteración o la revisión de un ciclo de revisión). Autor
Administrador (opcional)
Administrador de captura de pantalla de proyecto (opcional)
Probador Responsable de validar que los requisitos sean comprobables y asociados con los planes y las pruebas. Los requisitos de las revisiones con la comparabilidad en mente y hacer reomendaciones o cambios en consecuencia. Los probadores se encargan de asegurar que los requisitos que prueban sean comparables y estén actualizados con los requisitos que suministrarán los equipos de desarrollo. Comentarista
Desarrollador Responsable por la comprensión de los requisitos descriptos lo suficiente para el diseño, la escritura, la prueba de unidades, y los códigos de entrega de las tareas asignadas de una forma oportuna. Comentarista
Autor
Miembro del equipo Otros deberes. Muchos miembros del equipo tienen varios de los roles mencionados anteriormente, en lugar de las capacidades de especialista. Autor
Comentarista
Personal de operaciones Responsable por mantener los sistemas operativos y por mantener los sistemas del entorno de producción. Comentaristas
Autor (opcional)
Técnico de soporte Responsable por el soporte a los usuarios finales que utilizan sistemas en producción. Comentarista
Autor (opcional)

La tabla 3 representa un ejemplo de muchas descripciones posibles de partes interesadas que forman parte de SCS. El objetivo de esto es documentar los roles de las partes interesadas, las responsabilidades y el aporte que se espera del proyecto. Mediante la definición de estos roles, usted puede comenzar a incentivar una mejor colaboración. Hablaremos de la colaboración y los roles más tarde en esta misma serie.

Tabla 4. Ejemplo de subconjunto de Stakeholder Collaboration Strategy de una tabla de partes interesadas
Rol empresarialNombre Área Detalles de contactoOrganización, departamentoRol de Rational Requirements Composer Tipo de colaboración
SME Lisa Nuevos negocios xxxxx.xxx.xxx Ventas Comentarista Comentarios proactivos en curso, revisiones informales y formales
Esponsor del proyecto Paula All xxxxx.xxx.xxx CFO Comentarista Sólo informes
Arquitecto empresarial Vivanne Todo xxxxx.xxx.xxx Cambios empresariales Autor Revisiones de iniciativas, participación en revisiones de por pares, colaboración diaria
líder empresarial de nuevos desarrollos Daniel Nuevas empresas xxxxx.xxx.xxx IT Autor Revisión de iniciativas, participación en revisión por pares, colaboración diaria
Parte interesada empresarial Claire Nuevas empresas xxxxx.xxx.xxx Ventas Comentarista Comentarios proactivos en curso, revisiones informales y formales
Arquitectura de despliegue Robin Todo, conformidad con estrategia técnica grupal xxxxx.xxx.xxx Infraestructura técnica grupal Comentarista Comentarios proactivos en curso, revisiones informales y formales

Agradecimientos

Los autores agradecen a Robin Bater, Rational Requirements Definition and Management Community of Practice Architect, y Daniel Moul, Market Management Offering Manager for Requirements Definition and Management, por sus revisiones e incentivos técnicos.


Descargar

DescripciónNombretamaño
Stakeholder_Collaboration_Strategy_template.docStakeholder_Collaboration_Strategy_template.zip105 KB

Recursos

Aprender

  • Lea:
    • Managing Software Requirements: A Unified Approach, 2da edición, de Dean Leffingwell y Don Widrig (The Addison-Wesley Object Technology Series, 2003)
    • Outside-In Development (OID) es un método desarrollado por el IBM Software Group. Se lo describe e el libro Outside-In Software Development: A Practical Approach to Building Successful Stakeholder-based Products de Carl Kessler y John Sweitzer (IBM Press, 2007)
    • Capturing Architectural Requirements, de Peter Eeles, (The Rational Edge, 2005).
  • Aprenda más en Jazz.net:
  • Comience aquí a aprender más sobre Rational Requirements Composer en IBM.com:
  • Aprenda sobre otras aplicaciones en la IBM Rational Software Delivery Platform, incluyendo las herramientas de colaboración para el desarrollo paralelo y los equipos geográficamente dispersos, además del software especializado para la administración de arquitectura, la administración de activos, la administración de modificaciones y release, administración de requisitos integrados, administración de procesos y cartera, y administración de calidad. Usted puede encontrar manuales de productos, guías de instalación, y otra documentación en el IBM Rational Online Documentation Center.
  • Visite el Rational software area on developerWorks para acceder a los recursos técnicos y a las mejores prácticas para los productos de Rational Software Delivery Platform
  • Explore Rational computer-based, Web-based, and instructor-led online courses. Perfeccione sus capacidades y aprenda más sobre las herramientas de Rational con estos cursos, los cuales van desde el nivel introductorio hasta el avanzado. Los cursos en este catálogo se pueden adquirir como capacitación basada en computadora o capacitación basada en la Web. Algunos de los cursos "Getting Started" pueden adquirirse de forma gratuita.
  • Subscríbase al IBM developerWorks newsletter, una actualización semanal de los mejores tutoriales, artículos, descargas, actividades comunitarias, webcasts y eventos de developerWorks.
  • Navegue en el technology bookstore para encontrar libros sobre estos y otros temas técnicos.

Obtener los productos y tecnologías

Comentar

  • Únase a la discusión en Rational Requirements Composer forum sobre todos los aspectos de la definición de requisitos, incluyendo los general, conceptos independientes de la herramientas e información específica de las herramientas.
  • Verifique los developerWorks blogs y participe en la developerWorks community.

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Rational
ArticleID=619181
ArticleTitle=El uso de la Stakeholder Collaboration Strategy con Rational Requirements Composer: Parte 1. La audiencia
publish-date=01212011