Fluxos de Trabalho de Associação de Requisito

Esses fluxos de trabalho descrevem cenários típicos para o uso da integração dos produtos Rational RequisitePro e IBM® Software Delivery Platform.

Associando Requisitos a Elementos do Modelo de UML

  1. O analista ou o gerenciador de produto usa oRational RequisitePro para criar ou modificar requisitos de um produto de software.
  2. O arquiteto do sistema inicia um produto IBM Software Delivery Platform que suporta a modelagem UML e abre o projeto do Rational RequisitePro na visualização Explorer de Requisito. O arquiteto do sistema estuda os requisitos e desenvolve um novo modelo de UML que reflete esses requisitos.
  3. O arquiteto associa os requisitos do Rational RequisitePro aos elementos de modelo UML para indicar quais requisitos são atendidos por quais elementos de modelo.

    Esse arquiteto pode relacionar um elemento a um único requisito, por exemplo, em uma associação um-para-um de um elemento de caso de uso e de um requisito de caso de uso, ou pela rastreabilidade para vários requisitos, por exemplo, quando uma única classe atende a vários requisitos. De modo contrário, vários elementos podem ser rastreados para um único requisito, por exemplo, quando várias classes atendem a um requisito de recurso.

  4. O arquiteto do sistema abre uma visualização Matriz de Rastreabilidade ou Árvore de Rastreabilidade (ou cria uma visualização no Rational RequisitePro) para assegurar a cobertura de todos os requisitos. Relacionamentos de rastreabilidade individuais podem ser vistos nas visualizações Rastreio de Requisito e Resultados da Consulta de Requisito. Os elementos e requisitos de modelo sem associações ou rastreabilidade podem representar um design incompleto.
  5. Depois que o design estiver completo, os programadores usam o modelo UML para direcionar sua implementação do código do aplicativo.
  6. Conforme o projeto avança, o gerenciador do produto ou o gerenciador de desenvolvimento continua monitorando a rastreabilidade para observar as mudanças nos requisitos associados. Essas mudanças podem fazer com que a rastreabilidade entre os requisitos seja marcada como "suspeita", indicando que os requisitos devem ser revisados.

Associando Requisitos e Elementos de Domínio de Desenvolvimento

  1. O analista ou o gerenciador de produto usa oRational RequisitePro para criar ou modificar requisitos de um produto de software.
  2. O arquiteto do sistema inicia um produto IBM Software Delivery Platform e abre o projeto do Rational RequisitePro na visualização Explorer de Requisito.
  3. O arquiteto do sistema cria elementos de domínio de desenvolvimento, como classes ou Beans J2EE e associa-os aos requisitos relacionados.
  4. O arquiteto do sistema abre uma visualização Matriz de Rastreabilidade ou Árvore de Rastreabilidade (ou cria uma visualização no Rational RequisitePro) para assegurar a cobertura de todos os requisitos. Relacionamentos de rastreabilidade individuais podem ser vistos nas visualizações Rastreio de Requisito e Resultados da Consulta de Requisito. Os elementos e requisitos de domínio sem associações ou rastreabilidade podem representar um design incompleto.
  5. Depois que o design estiver completo, os programadores usam os requisitos associados para fornecer detalhes de sua implementação do código do aplicativo.
  6. Conforme o projeto avança, o gerenciador do produto ou o gerenciador de desenvolvimento continua monitorando a rastreabilidade para observar as mudanças nos requisitos associados. Essas mudanças podem fazer com que a rastreabilidade entre os requisitos seja marcada como "suspeita", indicando que os requisitos devem ser revisados.

Feedback