Flux de travaux d'association d'exigences

Ces flux de travaux décrivent des scénarios typiques d'utilisation de l'intégration de Rational RequisitePro et des produits IBM® Software Delivery Platform.

Association d'exigences avec des éléments de modèle

  1. Le gestionnaire de produit ou l'analyste utilise Rational RequisitePro pour créer ou modifier les exigences pour un produit logiciel.
  2. L'architecte système démarre un produit IBM Software Delivery Platform prenant en charge la modélisation UML et ouvre le projet Rational RequisitePro dans la vue Explorateur d'exigences. L'architecte système étudie les exigences et développe un nouveau modèle UML qui reflète ces exigences.
  3. L'architecte associe les exigences Rational RequisitePro avec les éléments de modèle UML pour indiquer quelles exigences sont satisfaites par quels éléments de modèle.

    Cette architecture peut s'appliquer à un élément associé à une seule exigence, dans le cas d'une association un à un d'un élément de cas d'utilisation à une exigence de cas d'utilisation, ou à plusieurs exigences, par traçabilité, dans le cas d'une classe unique satisfaisant plusieurs exigences. Plusieurs éléments peuvent également être tracés vers une exigence unique, dans le cas de classes multiples satisfaisant une exigence de fonction par exemple.

  4. L'architecte système ouvre une Matrice de traçabilité ou Arborescence de traçabilité (ou en crée une dans Rational RequisitePro) pour vérifier que toutes les exigences sont satisfaites. Les relations de traçabilité individuelles peuvent être consultées dans les vues Traçabilité des exigences et Résultats de requête d'exigence. Les éléments de modèle et les exigences sans associations ou traçabilité peuvent indiquer une conception inachevée.
  5. Une fois la conception achevée, les programmateurs utilisent le modèle UML pour diriger leur implémentation du code de l'application.
  6. Au fur et à mesure de l'avancement du projet, le gestionnaire de produit ou le gestionnaire de développement continue de surveiller la traçabilité pour vérifier si des changements sont effectués sur des exigences associées. En raison de ces changements, la traçabilité entre des exigences est marquée comme étant "suspecte", ce qui permet d'indiquer que ces exigences doivent être révisées.

Association d'exigences avec des éléments de domaine de développement

  1. Le gestionnaire de produit ou l'analyste utilise Rational RequisitePro pour créer ou modifier les exigences pour un produit logiciel.
  2. L'architecte système démarre un produit IBM Software Delivery Platform et ouvre le projet Rational RequisitePro dans la vue Explorateur d'exigences.
  3. L'architecte système crée les éléments de domaine de développement, des classes ou des beans J2EE par exemple, et les associe à des exigences en relation.
  4. L'architecte système ouvre une Matrice de traçabilité ou Arborescence de traçabilité (ou en crée une dans Rational RequisitePro) pour vérifier que toutes les exigences sont satisfaites. Les relations de traçabilité individuelles peuvent être consultées dans les vues Traçabilité des exigences et Résultats de requête d'exigence. Les éléments de domaine et les exigences sans associations ou traçabilité peuvent indiquer une conception inachevée.
  5. Une fois la conception achevée, les programmateurs utilisent les exigences en relation pour diriger leur implémentation du code de l'application.
  6. Au fur et à mesure de l'avancement du projet, le gestionnaire de produit ou le gestionnaire de développement continue de surveiller la traçabilité pour vérifier si des changements sont effectués sur des exigences associées. En raison de ces changements, la traçabilité entre des exigences est marquée comme étant "suspecte", ce qui permet d'indiquer que ces exigences doivent être révisées.

Vos commentaires