Qu'est-ce que l'analyse commerciale?

L'analyse commerciale est l'ensemble des tâches, des connaissances et des techniques nécessaires pour identifier les besoins commerciaux et déterminer les solutions aux problèmes commerciaux de l'entreprise. Bien que la définition générale soit similaire, les pratiques et procédures peuvent varier dans divers secteurs.

Dans l'industrie des technologies de l'information, les solutions incluent souvent un composant de développement de systèmes, mais peuvent également consister en une amélioration des processus ou un changement organisationnel.

Une analyse commerciale peut également être effectuée pour comprendre l'état actuel d'une organisation ou pour servir de base à l'identification des besoins commerciaux. Dans la plupart des cas, cependant, une analyse commerciale est effectuée pour définir et valider des solutions qui répondent aux besoins, buts ou objectifs de l'entreprise.

Qu'est-ce qu'un Business Analyst?

Un analyste commercial est une personne qui analyse une organisation ou un domaine d'activité (réel ou hypothétique) et documente son activité, ses processus ou ses systèmes, évaluant le modèle commercial ou son intégration avec la technologie. Cependant, les titres organisationnels varient tels que analyste, analyste commercial, analyste de systèmes d'entreprise ou peut-être analyste de systèmes.

Pourquoi un Business Analyst?

Les organisations utilisent l'analyse commerciale pour les raisons suivantes -

• Comprendre la structure et la dynamique de l'organisation dans laquelle un système doit être déployé.

• Comprendre les problèmes actuels dans l'organisation cible et identifier les potentiels d'amélioration.

• Pour s'assurer que le client, l'utilisateur final et les développeurs ont une compréhension commune de l'organisation cible.

Dans la phase initiale d'un projet, lorsque les exigences sont interprétées par les équipes de solution et de conception, le rôle d'un analyste métier est de revoir les documents de solutions, de travailler en étroite collaboration avec les concepteurs de solutions (équipe informatique) et les chefs de projet pour s'assurer que les exigences sont claires.

Dans une organisation informatique typique de grande taille, en particulier dans un environnement de développement, vous pouvez trouver des équipes de livraison sur site et offshore ayant les rôles susmentionnés. Vous pouvez trouver un «Business Analyst» qui agit comme une personne clé qui doit relier les deux équipes.

Parfois, il interagissait avec des utilisateurs professionnels et parfois des utilisateurs techniques et enfin avec toutes les parties prenantes des projets pour obtenir l'approbation et un signe de tête final avant de procéder à la documentation.

Par conséquent, le rôle de BA est très crucial dans le démarrage efficace et réussi de tout projet.

Rôle d'un analyste métier informatique

Le rôle d'un analyste métier commence par définir et délimiter les domaines d'activité de l'organisation, puis élucider les exigences, analyser et documenter les exigences, communiquer ces exigences aux parties prenantes appropriées, identifier la bonne solution, puis valider la solution pour déterminer si le les exigences répondent aux normes attendues.

En quoi est-ce différent des autres professions?

L'analyse commerciale est distincte de l'analyse financière, de la gestion de projet, de l'assurance qualité, du développement organisationnel, des tests, de la formation et du développement de la documentation. Cependant, selon l'organisation, un analyste commercial peut effectuer certaines ou toutes ces fonctions connexes.

Les analystes commerciaux qui travaillent uniquement sur le développement de systèmes logiciels peuvent être appelés analystes commerciaux informatiques, analystes commerciaux techniques, analystes commerciaux en ligne, analystes de systèmes commerciaux ou analystes de systèmes.

L'analyse commerciale comprend également le travail de liaison entre les parties prenantes, les équipes de développement, les équipes de test, etc.

Cycle de vie du développement logiciel

Le cycle de vie du développement logiciel (SDLC) est un processus suivi dans un projet logiciel, au sein d'une organisation logicielle. Il consiste en un plan détaillé décrivant comment développer, maintenir, remplacer et modifier ou améliorer un logiciel spécifique. Il définit une méthodologie pour améliorer la qualité des logiciels et le processus de développement global.

• Le SDLC est un processus utilisé par les analystes informatiques afin de développer ou de redéfinir un système logiciel de haute qualité, qui répond à la fois aux exigences du client et du monde réel.

• Il prend en compte tous les aspects associés aux tests logiciels, à l'analyse et à la maintenance post-processus.

Les phases importantes du SDLC sont décrites dans l'illustration suivante -

Phase de planification

Chaque activité doit commencer par un plan. Ne pas planifier est la planification à l'échec. Le degré de planification diffère d'un modèle à l'autre, mais il est très important d'avoir une compréhension claire de ce que nous allons construire en créant les spécifications du système.

Définition de l'étape

Dans cette phase, nous analysons et définissons la structure du système. Nous définissons l'architecture, les composants et la manière dont ces composants s'assemblent pour produire un système fonctionnel.

Stade de conception

Dans la conception du système, les fonctions de conception et les opérations sont décrites en détail, y compris les dispositions d'écran, les règles métier, les diagrammes de processus et d'autres documents. Le résultat de cette étape décrira le nouveau système comme un ensemble de modules ou de sous-systèmes.

Stade de construction

C'est la phase de développement. Nous commençons la génération de code basée sur la conception du système à l'aide de compilateurs, d'interprètes et de débogueurs pour donner vie au système.

la mise en oeuvre

La mise en œuvre fait partie de la phase de construction. Dans cette phase, nous commençons la génération de code basée sur la conception du système à l'aide de compilateurs, d'interprètes et de débogueurs pour donner vie au système.

Phase de test

Au fur et à mesure que différentes parties du système sont terminées; ils sont soumis à une série de tests. il est testé par rapport aux exigences pour s'assurer que le produit répond réellement aux besoins adressés pendant la phase d'exigence.

• Les plans de test et les cas de test sont utilisés pour identifier les bogues et s'assurer que le système fonctionne selon les spécifications.

• Dans cette phase, différents types de tests tels que les tests unitaires, les tests manuels, les tests d'acceptation et les tests système sont effectués.

Suivi des défauts lors des tests

Les rapports de test logiciel sont utilisés pour communiquer les résultats des plans de test exécutés. Cela étant, un rapport doit contenir toutes les informations de test relatives au système en cours de test. L'exhaustivité des rapports sera vérifiée lors de sessions de visite virtuelle.

Tester un projet vise à atteindre deux objectifs principaux -

• Détectez les pannes et les défauts du système.

• Détectez les incohérences entre les exigences et la mise en œuvre.

L'organigramme suivant décrit les Defect Tracking Process -

Pour atteindre les objectifs principaux, la stratégie de test du système proposé comprendra généralement quatre niveaux de test.

Il s'agit des tests unitaires, des tests d'intégration, des tests d'acceptation et des tests de régression. Les sous-sections suivantes décrivent ces niveaux de test, quels rôles de l'équipe de développement sont responsables de leur développement et de leur exécution, et les critères pour déterminer leur exhaustivité.

Déploiement

Une fois la phase de test terminée, le système est libéré et entre dans l'environnement de production. Une fois que le produit est testé et prêt à être déployé, il est officiellement commercialisé sur le marché approprié. Parfois, le déploiement du produit se fait par étapes, conformément à la stratégie commerciale de l'organisation.

Le produit peut d'abord être commercialisé dans un segment limité et testé dans l'environnement commercial réel (test d'acceptation UAT-User). Ensuite, en fonction des commentaires, le produit peut être publié tel quel ou avec des améliorations suggérées dans le segment de marché du ciblage.

Processus post-SDLC

Une fois le produit mis sur le marché, sa maintenance est effectuée pour la clientèle existante.

Une fois dans l'environnement de production, le système subira des modifications en raison de bogues non détectés ou d'autres événements inattendus. Le système est évalué et le cycle est répété pour maintenir le système.

Rôle de l'analyste métier pendant le processus SDLC

Comme nous pouvons le voir dans le diagramme ci-dessous, BA est impliqué dans la conduite des besoins commerciaux et leur conversion en exigences de solution.

Il est impliqué dans la traduction des fonctionnalités de la solution en exigences logicielles. Dirige ensuite la phase d'analyse et de conception, dicte le développement du code, puis suit la phase de test pendant la correction des bogues en tant qu'agent de changement dans l'équipe de projet et répond finalement aux exigences du client.

Analyse commerciale - Rôles

Le rôle d'un analyste commercial dans un projet informatique peut être multiple. Il est possible que les membres de l'équipe de projet aient plusieurs rôles et responsabilités. Dans certains projets, le BA peut assumer les rôles d'analyste en intelligence d'affaires, de concepteur de base de données, de spécialiste en assurance qualité logicielle, de testeur et / ou de formateur lorsque les ressources disponibles sont limitées.

Il est également possible pour un coordinateur de projet, ou un responsable du développement d'applications ou un développeur d'assumer le rôle d'analyste métier dans des projets spécifiques.

L'analyse commerciale chevauche fortement l'analyse des exigences de l'entreprise pour fonctionner comme d'habitude et optimiser son fonctionnement. Quelques exemples d'analyse commerciale sont -

• Créer une architecture d'entreprise
• Préparer une analyse de rentabilisation
• Mener une évaluation des risques
• Recueil des exigences
• Analyse des processus métier
• Documentation des exigences

Rôles majeurs d'un BA

L'un des rôles clés de la plupart des analystes commerciaux est d'assurer la liaison entre les développeurs commerciaux et techniques. Les analystes commerciaux travaillent avec les clients commerciaux pour collecter / définir les exigences d'un système ou d'un processus afin d'améliorer la productivité tout en travaillant avec les équipes techniques pour concevoir et mettre en œuvre le système / processus.

En tant que contributeur

La responsabilité principale d'un BA est de contribuer au développement des utilisateurs / utilisateurs clés de l'entreprise en identifiant les problèmes, besoins et fonctions de l'entreprise, comprendre les préoccupations et les exigences des parties prenantes pour identifier les opportunités d'amélioration et contribuer à l'élaboration de l'analyse de rentabilisation de l'informatique. projet de développement de système.

En tant que facilitateur

Un analyste d'affaires est également censé faciliter / coordonner dans l'élicitation et l'analyse des exigences, collaborer et communiquer avec les parties prenantes et gérer leurs attentes et besoins, et s'assurer que les exigences sont complètes, sans ambiguïté et les mapper aux besoins de l'entreprise en temps réel. d'une organisation.

En tant qu'analyste

Un autre rôle important serait d'évaluer le système proposé et l'état de préparation de l'organisation pour la mise en œuvre du système et de fournir un soutien aux utilisateurs et de coordonner avec le personnel informatique.

Aider à examiner et à fournir des contributions à la conception du système informatique proposé du point de vue de l'entreprise, à résoudre les problèmes / conflits entre les parties prenantes, à organiser une UAT complète et de qualité en aidant les utilisateurs à développer des cas de test et à organiser la formation dans le but système informatique déployé capable de répondre aux besoins et aux exigences de l'entreprise et de réaliser les avantages escomptés.

Planifier et surveiller les activités d'analyse commerciale pour le développement de la portée, le calendrier et l'approche pour l'exécution des activités liées à l'analyse commerciale pour le projet de développement du système informatique, suivre les progrès, coordonner avec le chef de projet interne et rendre compte des revenus, de la rentabilité, des risques et des problèmes partout où approprié.

Responsabilités clés d'un analyste commercial

L'ensemble de responsabilités d'un analyste d'affaires l'obligerait à remplir différentes tâches dans différentes phases d'un projet et elles sont expliquées ci-dessous -

Phase d'initiation

Cette phase marquera le début d'un nouveau projet et un analyste d'affaires variera les responsabilités suivantes -

• Aider à effectuer l'analyse coûts-avantages du projet.
• Comprenez l'analyse de rentabilisation.
• Vérifier la faisabilité de la solution / projet / produit.
• Aide à la création de la charte de projet.
• Identifiez les parties prenantes du projet.

Phase de planification

Cette phase impliquera la collecte des exigences et la planification, la manière dont le projet sera exécuté et géré. Ses responsabilités comprendront les fonctions ci-dessous -

• Obtenir les exigences
• Analyser, organiser et documenter les exigences.
• Gérez les exigences en créant des cas d'utilisation, RTM, BRD, SRS, etc.
• Évaluer les solutions proposées.
• Assurer la liaison et améliorer les communications avec les parties prenantes.
• Aider à la formulation des plans de gestion de projet.
• Aide à trouver la portée, les contraintes, les hypothèses et les risques du projet.
• Aider à concevoir l'expérience utilisateur de la solution.

Phase d'exécution

Cette phase marque le développement de la solution selon les exigences recueillies. Les responsabilités comprennent -

• Expliquez les exigences à l'équipe informatique / de développement.

• Clarifier les doutes, les préoccupations concernant la solution proposée à développer.

• Discutez et hiérarchisez les changements de portée du projet et obtenez un accord.

• Créez des scripts de tests bêta pour les tests initiaux.

• Partager les modules en développement avec les parties prenantes et solliciter leurs commentaires.

• Respecter les délais et gérer les attentes des parties prenantes.

• Résoudre les conflits et gérer les communications avec l'équipe de projet.

Phase de surveillance et de contrôle

Dans cette phase, le projet est mesuré et contrôlé pour tout écart par rapport aux plans initiaux. Cette phase se déroule simultanément à la phase d'exécution.

• Développement de scripts de test et réalisation de tests complets de modules et d'intégration.

• Réalisation de l'UAT (utilisation des tests d'acceptation) et création de rapports de test.

• Obtenir l'acceptation / l'approbation des livrables du client.

• Expliquez les demandes de changement à l'équipe de développement.

• Surveiller le développement des demandes de changement et vérifier leur mise en œuvre conformément à l'objectif du projet.

Phase de clôture

Cette phase marque la clôture du projet. Les responsabilités sont -

• Présenter le projet terminé au client et obtenir son acceptation.

• Créez des manuels de formation des utilisateurs, tout matériel fonctionnel et d'autres guides d'instructions.

• Effectuer des tests d'intégration élaborés dans l'environnement de production.

• Créer des documentations sur le produit final, documenter les leçons apprises du projet.

Qu'est-ce qu'un BA est censé fournir?

Un Business Analyst sert de pont entre les utilisateurs métier et les techniciens IT. Leur présence contribuera de manière significative à la réussite des projets informatiques. Il y a de nombreux avantages à avoir un analyste commercial dédié. Un analyste d'affaires dédié peut -

• Fournit une portée claire du projet d'un point de vue commercial.

• Développer des analyses de rentabilisation solides et une estimation plus réaliste des ressources et des avantages commerciaux.

• Prépare de meilleurs rapports sur la portée, la planification et la gestion des projets en termes de coûts et de calendrier, en particulier pour les projets informatiques à grande échelle.

• Produit des exigences claires et concises qui, à leur tour, aident à fournir des exigences plus claires et plus précises, si le projet informatique est externalisé.

• Identifiez les besoins réels des utilisateurs et gérez efficacement les attentes des utilisateurs.

• Améliore la qualité de la conception du système informatique proposé afin qu'il réponde aux exigences des utilisateurs.

• Assure la qualité du système développé avant de le transmettre aux utilisateurs finaux pour examen et acceptation.

• Organise des tests de qualité complets sur les systèmes livrés et fournit des commentaires aux techniciens informatiques.

Analyse commerciale - Outils et techniques

Un analyste commercial doit être familiarisé avec divers outils analytiques et technologies connexes lorsque vous portez le bonnet BA. Je veux dire, si vous occupez ce poste.

Comme nous l'avons déjà appris précédemment, l'analyse commerciale est un processus dans lequel vous essayez de comprendre une entreprise commerciale et d'identifier les opportunités, les domaines problématiques, les problèmes et de rencontrer un large éventail de personnes ayant un large éventail de rôles et de responsabilités tels que PDG, vice-président, directeur et comprendre leurs besoins commerciaux.

Fondamentalement, il existe 3 types d'analyses commerciales que nous pouvons classer en:

• Strategic Analysis- L'analyse stratégique des affaires traite des travaux d'avant-projet. Il s'agit de la méthode ou du processus d'identification des problèmes commerciaux, de l'élaboration de stratégies commerciales, de buts et d'objectifs aidant la direction. Il fournit des rapports d'information de gestion pour un processus décisionnel efficace.

• Tactical Analysis - Il implique la connaissance de techniques d'analyse commerciale spécifiques à appliquer au bon moment dans le projet approprié.

• Operational Analysis- Dans ce type d'analyse commerciale, nous nous concentrons sur l'aspect commercial en tirant parti des technologies de l'information. C'est aussi un processus d'étude des systèmes opérationnels dans le but d'identifier les opportunités d'amélioration des affaires.

Pour chaque type d'analyse, il existe un ensemble d'outils disponibles sur le marché et basés sur les besoins et les exigences de l'organisation, ceux-ci doivent être utilisés.

Cependant, pour matérialiser les exigences commerciales en informations compréhensibles, un bon BA utilisera les techniques d'enquête, d'entrevues, d'examen de la documentation, de questionnaires, d'échantillonnage et de recherche dans leurs activités quotidiennes.

Exigences fonctionnelles et non fonctionnelles

Nous pouvons décomposer une exigence en deux types principaux comme les exigences fonctionnelles et non fonctionnelles.

Pour tous les projets technologiques, les exigences fonctionnelles et non fonctionnelles doivent être séparées et analysées séparément.

Définir l'outil approprié et une technique appropriée peut être un défi de taille. Que vous fassiez une toute nouvelle application ou que vous apportiez des modifications à une application existante. Considérer la bonne technique pour le processus fonctionnel est un art en soi.

Un aperçu des techniques d'analyse commerciale largement utilisées qui sont actuellement sur le marché -

Processus	Techniques	Livrables du processus (résultats)
Pour déterminer les exigences fonctionnelles et non fonctionnelles	Sessions JAD Scénarios et cas d'utilisation Modélisation organisationnelle Modélisation de la portée Décomposition fonctionnelle Interviews Observation (observation au travail) Groupes de discussion Acceptation et évaluation Diagrammes de séquence Histoires d'utilisateurs Brainstorming Storyboarding Prototyping Visite guidée structurée Analyse d'événements Analyse des règles métier Ateliers sur les exigences Analyse de risque Analyse de la cause originelle	Business Requirements Documents - Exigences commerciales et fonctionnelles Prérogatives non fonctionnelles Règles commerciales Matrice de traçabilité des exigences Common Template - Document sur les exigences opérationnelles

Applicabilité des outils et processus

Bien qu'il existe une variété d'outils et de procédures à la disposition des analystes d'affaires, tout dépend des pratiques actuelles de l'organisation et de la manière dont ils aimeraient l'utiliser.

Par exemple, root-cause analysis est utilisé lorsqu'il est nécessaire d'approfondir un certain domaine ou une fonction importante.

Cependant, le document sur les exigences commerciales est le moyen le plus populaire et le plus accepté de mettre les exigences au format documentation.

Dans les chapitres suivants, nous discuterons en profondeur de certaines des techniques ci-dessus.

Analyse commerciale - Session JAD

Le développement d'applications conjoint (JAD) est un processus utilisé pour collecter les exigences métier tout en développant de nouveaux systèmes d'information pour une entreprise. Le processus JAD peut également inclure des approches pour renforcer la participation des utilisateurs, accélérer le développement et améliorer la qualité des spécifications. L'intention d'une session JAD est de mettre en commun un expert en la matière / un analyste métier ou un spécialiste informatique pour faire émerger des solutions.

Un Business analyst est celui qui interagit avec l'ensemble du groupe et rassemble les informations, les analyse et fait ressortir un document. Il joue un rôle très important dans la session JAD.

Utilisation d'une session JAD

Les sessions JAD sont des ateliers hautement structurés et animés qui rassemblent les décideurs des clients et le personnel informatique pour produire des livrables de haute qualité en peu de temps.

En d'autres termes, une session JAD permet aux clients et aux développeurs de parvenir rapidement à un accord sur la portée de base, les objectifs et les spécifications d'un projet ou, au cas où, de ne pas parvenir à un accord, ce qui signifie que le projet doit être réévalué.

En termes simples, les sessions JAD peuvent

• Simplify - Il regroupe des mois de réunions et d'appels téléphoniques en un atelier structuré.

• Identify - Problèmes et participants

• Quantify - Besoins d'information et de traitement

• Clarify - Cristalliser et clarifier toutes les exigences convenues lors de la session.

• Unify - La sortie d'une phase de développement est entrée dans la suivante.

• Satisfy- Les clients définissent le système; c'est donc leur système. La participation partagée apporte une part au résultat; ils s'engagent pour le succès des systèmes.

Participants à une session JAD

Les participants impliqués dans une session JAD sont les suivants -

Sponsor exécutif

Un sponsor exécutif est la personne qui pilote le projet - le propriétaire du système. Ils viennent normalement de postes plus élevés et sont capables de prendre des décisions et de fournir la stratégie, la planification et la direction nécessaires.

Expert en la matière

Ce sont les utilisateurs professionnels et les experts extérieurs qui sont nécessaires pour un atelier réussi. Les experts en la matière sont la colonne vertébrale de la session JAD. Ils dirigeront les changements.

Facilitateur

Il préside la réunion; il identifie les problèmes qui peuvent être résolus dans le cadre de la réunion. L'animateur ne fournit pas d'informations à la réunion.

Utilisateurs clés

Les utilisateurs clés ou également appelés en tant que super utilisateurs dans certains cas ont été utilisés de manière interchangeable et diffèrent toujours d'une entreprise à l'autre. Les utilisateurs clés sont généralement les utilisateurs métiers qui sont plus étroitement alignés sur le projet informatique et qui sont responsables de la configuration des profils des membres de leur équipe pendant les projets.

Par exemple: supposons que John soit un utilisateur clé et Nancy, Evan soient des utilisateurs d'un système SAP. Dans ce cas, Nancy et Evan n'ont pas accès pour modifier la fonctionnalité et le profil, tandis que John étant un utilisateur clé a accès pour modifier le profil avec plus d'autorisations.

L'approche JAD, en comparaison avec la pratique plus traditionnelle, est censée conduire à des temps de développement plus rapides et une plus grande satisfaction du client, car le client est impliqué tout au long du processus de développement. En comparaison, dans l'approche traditionnelle du développement de systèmes, le développeur étudie les exigences du système et développe une application, la contribution du client étant constituée d'une série d'entretiens.

Techniques de collecte des exigences

Les techniques décrivent comment les tâches sont exécutées dans des circonstances spécifiques. Une tâche peut avoir aucune ou une ou plusieurs techniques associées. Une technique doit être liée à au moins une tâche.

Voici quelques-unes des techniques bien connues de collecte des exigences:

Réflexion

Le brainstorming est utilisé dans la collecte des exigences pour obtenir autant d'idées que possible d'un groupe de personnes. Généralement utilisé pour identifier les solutions possibles aux problèmes et clarifier les détails des opportunités.

Analyse documentaire

L'examen de la documentation d'un système existant peut aider lors de la création d'un document de processus AS – IS, ainsi que l'analyse des écarts pour la portée des projets de migration. Dans un monde idéal, nous examinerions même les exigences qui ont conduit à la création du système existant - un point de départ pour documenter les exigences actuelles. Des pépites d'informations sont souvent enfouies dans des documents existants qui nous aident à poser des questions dans le cadre de la validation de l'exhaustivité des exigences.

Groupe de discussion

Un groupe de discussion est un rassemblement de personnes représentatives des utilisateurs ou des clients d'un produit pour obtenir des commentaires. Les commentaires peuvent être recueillis sur les besoins / opportunités / problèmes pour identifier les exigences, ou peuvent être recueillis pour valider et affiner les exigences déjà suscitées. Cette forme d'étude de marché se distingue du brainstorming en ce sens qu'il s'agit d'un processus géré avec des participants spécifiques.

Analyse d'interface

Les interfaces d'un produit logiciel peuvent être humaines ou machine. L'intégration avec des systèmes et des appareils externes n'est qu'une autre interface. Les approches de conception centrées sur l'utilisateur sont très efficaces pour garantir que nous créons des logiciels utilisables. Analyse de l'interface - il est important d'examiner les points de contact avec d'autres systèmes externes pour nous assurer de ne pas négliger les exigences qui ne sont pas immédiatement visibles pour les utilisateurs.

Entretien

Les entretiens avec les parties prenantes et les utilisateurs sont essentiels à la création d'un excellent logiciel. Sans comprendre les objectifs et les attentes des utilisateurs et des parties prenantes, il est très peu probable que nous les satisfassions. Nous devons également reconnaître le point de vue de chaque personne interrogée, afin que nous puissions correctement peser et traiter leurs contributions. L'écoute est la compétence qui aide un bon analyste à tirer plus de valeur d'un entretien qu'un analyste moyen.

Observation

En observant les utilisateurs, un analyste peut identifier un flux de processus, des étapes, des points faibles et des opportunités d'amélioration. Les observations peuvent être passives ou actives (poser des questions tout en observant). L'observation passive est préférable pour obtenir des commentaires sur un prototype (pour affiner les exigences), où l'observation active est plus efficace pour comprendre un processus métier existant. L'une ou l'autre approche peut être utilisée.

Prototypage

Le prototypage est une technique relativement moderne de collecte des exigences. Dans cette approche, vous collectez les exigences préliminaires que vous utilisez pour créer une version initiale de la solution - un prototype. Vous le montrez au client, qui vous donne ensuite des exigences supplémentaires. Vous changez d'application et faites à nouveau le tour du client. Ce processus répétitif se poursuit jusqu'à ce que le produit réponde à la masse critique des besoins de l'entreprise ou pour un nombre convenu d'itérations.

Ateliers sur les exigences

Les ateliers peuvent être très efficaces pour recueillir les exigences. Plus structuré qu'une séance de brainstorming, les parties concernées collaborent pour documenter les exigences. Une façon de capturer la collaboration consiste à créer des artefacts de modèle de domaine (comme des diagrammes statiques, des diagrammes d'activité). Un atelier sera plus efficace avec deux analystes qu'avec un.

Ingénierie inverse

Lorsqu'un projet de migration n'a pas accès à une documentation suffisante du système existant, l'ingénierie inverse identifiera ce que fait le système. Il n'identifiera pas ce que le système devrait faire et n'indiquera pas quand le système fait la mauvaise chose.

Enquête

Lors de la collecte d'informations auprès de nombreuses personnes - trop nombreuses pour être interviewées avec des contraintes de budget et de temps - une enquête ou un questionnaire peut être utilisé. L'enquête peut forcer les utilisateurs à choisir parmi des choix, à noter quelque chose («D'accord tout à fait, d'accord…») ou à poser des questions ouvertes permettant des réponses de forme libre. La conception de l'enquête est difficile - les questions peuvent biaiser les répondants.

Document des exigences fonctionnelles

Le document des exigences fonctionnelles (FRD) est une déclaration formelle des exigences fonctionnelles d'une application. Il sert le même objectif qu'un contrat. Ici, les développeurs acceptent de fournir les capacités spécifiées. Le client s'engage à trouver le produit satisfaisant s'il fournit les capacités spécifiées dans le FRD.

Les exigences fonctionnelles capturent le comportement prévu du système. Ce comportement peut être exprimé sous forme de services, de tâches ou de fonctions que le système doit exécuter. Le document doit être adapté aux besoins d'un projet particulier. Ils définissent des éléments tels que les calculs du système, la manipulation et le traitement des données, l'interface utilisateur et l'interaction avec l'application.

Le document des exigences fonctionnelles (FRD) présente les caractéristiques suivantes -

• Cela démontre que l'application apporte de la valeur en termes d'objectifs commerciaux et de processus métier au cours des prochaines années.

• Il contient un ensemble complet d'exigences pour l'application. Il ne laisse aucune place à quiconque pour assumer quoi que ce soit qui ne soit pas indiqué dans le FRD.

• Il est indépendant de la solution. La DRE est une déclaration de ce que l'application doit faire - pas de la façon dont elle fonctionne. Le FRD n'engage pas les développeurs dans une conception. Pour cette raison, toute référence à l'utilisation d'une technologie spécifique est tout à fait inappropriée dans un FRD.

L'exigence fonctionnelle devrait inclure les éléments suivants:

• Descriptions de data à entrer dans le système

• Descriptions de operations effectué par chaque écran

• Descriptions de work-flows effectué par le système

• Descriptions de system reports ou autres sorties

• Qui peut entrer dans le data dans le système?

• Comment le système répond applicable regulatory requirements?

La spécification fonctionnelle est conçue pour être lue par un public général. Les lecteurs doivent comprendre le système, mais aucune connaissance technique ne doit être requise pour comprendre ce document.

Livrables des exigences fonctionnelles

Un Business Requirements Document (BRD) se compose de -

• Functional Requirements- Un document contenant les exigences détaillées du système en cours de développement. Ces exigences définissent les caractéristiques fonctionnelles et les capacités qu'un système doit posséder. Assurez-vous que toutes les hypothèses et contraintes identifiées au cours de l'analyse de rentabilisation sont toujours exactes et à jour.

• Business Process Model - Un modèle de l'état actuel du processus (modèle «tel quel») ou un concept de ce que le processus devrait devenir (modèle «à être»)

• System Context Diagram - Un diagramme de contexte montre les limites du système, les entités externes et internes qui interagissent avec le système et les flux de données pertinents entre ces entités externes et internes.

• Flow Diagrams (as-is or to-be)- Les diagrammes représentent graphiquement la séquence des opérations ou le mouvement des données pour un processus métier. Un ou plusieurs organigrammes sont inclus en fonction de la complexité du modèle.

• Business Rules and Data Requirements - Les règles métier définissent ou contraignent certains aspects de l'entreprise et sont utilisées pour définir les contraintes de données, les valeurs par défaut, les plages de valeurs, la cardinalité, les types de données, les calculs, les exceptions, les éléments requis et l'intégrité relationnelle des données.

• Data Models - Diagrammes de relations d'entité, descriptions d'entités, diagrammes de classes

• Conceptual Model - Affichage de haut niveau des différentes entités pour une fonction métier et de leurs relations les unes avec les autres.

• Logical Model - Illustre les entités, attributs et relations spécifiques impliqués dans une fonction métier et représente toutes les définitions, caractéristiques et relations des données dans un environnement commercial, technique ou conceptuel.

• Data Dictionary and Glossary - Une collection d'informations détaillées sur les éléments de données, les champs, les tables et autres entités qui composent le modèle de données sous-jacent à une base de données ou à un système de gestion de données similaire.

• Stakeholder Map- Identifie toutes les parties prenantes qui sont affectées par le changement proposé et leur niveau d'influence / autorité pour les exigences. Ce document est développé au cours de la phase de création de la méthodologie de gestion de projet (PMM) et appartient au gestionnaire de projet, mais doit être mis à jour par l'équipe de projet à mesure que de nouvelles parties prenantes / modifiées sont identifiées tout au long du processus.

• Requirements Traceability Matrix - Un tableau qui illustre les liens logiques entre les exigences fonctionnelles individuelles et d'autres types d'artefacts système, y compris d'autres exigences fonctionnelles, des cas d'utilisation / récits d'utilisateurs, des éléments d'architecture et de conception, des modules de code, des cas de test et des règles métier.

Spécification des exigences logicielles

Une spécification des exigences logicielles (SRS) est un document utilisé comme moyen de communication entre les clients. Une spécification d'exigence logicielle dans sa forme la plus élémentaire est un document formel utilisé pour communiquer les exigences logicielles entre le client et le développeur.

Un document SRS se concentre sur WHAT doit être fait et évite soigneusement la solution (how to do). Il sert de contrat entre l'équipe de développement et le client. Les exigences à ce stade sont rédigées en utilisant la terminologie de l'utilisateur final. Si nécessaire, une spécification d'exigence formelle en sera élaborée ultérieurement.

SRS est une description complète du comportement d'un système à développer et peut inclure un ensemble de cas d'utilisation décrivant les interactions que les utilisateurs auront avec le logiciel.

Objectif du SRS

SRS est un outil de communication entre Client / Client, Business Analyst, Développeurs système, équipes de maintenance. Il peut également s'agir d'un contrat entre l'acheteur et le fournisseur.

• Cela donnera une base solide à la phase de conception
• Prend en charge la gestion et le contrôle de projet
• Aide au contrôle et à l'évolution du système

Une spécification d'exigence logicielle doit être complète, cohérente, traçable, non ambiguë et vérifiable.

Les points suivants doivent être traités dans la spécification du système -

• Définir les fonctions des systèmes
• Définir le partitionnement fonctionnel matériel / logiciel
• Définir la spécification de performance
• Définir le partitionnement des performances matérielles / logicielles
• Définir les exigences de sécurité
• Définir l'interface utilisateur (manuel de l'utilisateur)
• Fournir des dessins / instructions d'installation
• Modèle de spécification des exigences logicielles

Historique des révisions

Date	La description	Auteur	commentaires
<date>	<Version 1>	<Votre nom>	<Première révision>

Approbation des documents

La spécification de configuration logicielle suivante a été acceptée et approuvée par:

Signature	Nom imprimé	Titre	Date
	<Votre nom>	Ingénieur logiciel principal.
	David	Instructeur

Analyse commerciale - Cas d'utilisation

L'un des neuf diagrammes d'UML est le diagramme de cas d'utilisation. Ce ne sont pas seulement des exigences importantes mais nécessaires pour les projets logiciels. Il est essentiellement utilisé dans les cycles de vie des logiciels. Comme nous le savons, il existe différentes phases dans le cycle de développement et la phase la plus utilisée pour les cas d'utilisation serait pendant la phase de collecte des exigences.

Qu'est-ce qu'un cas d'utilisation?

Un cas d'utilisation décrit une séquence d'actions, exécutées par un système qui fournit de la valeur à un acteur. Le cas d'utilisation décrit le comportement du système dans diverses conditions lorsqu'il répond à une demande de l'une des parties prenantes, appelée leprimary actor.

L'acteur est le Who du système, c'est-à-dire l'utilisateur final.

En génie logiciel et système, un cas d'utilisation est une liste d'étapes, définissant typiquement les interactions entre un rôle (connu en UML comme un «acteur») et un système, pour atteindre un objectif. L'acteur peut être un système humain ou externe.

Un cas d'utilisation spécifie le flux d'événements dans le système. Il s'intéresse davantage à ce qui est effectué par le système afin d'exécuter la séquence d'actions.

Avantages d'un cas d'utilisation

Un cas d'utilisation offre les avantages suivants -

• C'est un moyen facile de saisir l'exigence fonctionnelle en mettant l'accent sur la valeur ajoutée pour l'utilisateur.

• Les cas d'utilisation sont relativement faciles à écrire et à lire par rapport aux méthodes d'exigence traditionnelles.

• Les cas d'utilisation obligent les développeurs à penser du point de vue de l'utilisateur final.

• Le cas d'utilisation engage l'utilisateur dans le processus d'exigence.

L'anatomie d'un cas d'utilisation

Nom : nom descriptif qui illustre l'objectif du cas d'utilisation.

Description : décrit ce que fait le cas d'utilisation en quelques phrases.

Acteur : répertoriez tous les acteurs qui participent au cas d'utilisation.

Pré-condition : conditions qui doivent être remplies avant de démarrer le cas d'utilisation.

Flux d'événements : Description de l'interaction entre le système et l'acteur.

Post-condition : Décrivez l'état du système après qu'un cas d'utilisation a suivi son cours.

Guide pour le modèle de cas d'utilisation

Documentez chaque cas d'utilisation à l'aide du modèle donné à la fin de ce chapitre. Cette section fournit une description de chaque section du modèle de cas d'utilisation.

Identification des cas d'utilisation

• Use-Case ID- Donner à chaque cas d'utilisation un identifiant numérique unique, sous forme hiérarchique: XY Les cas d'utilisation associés peuvent être regroupés dans la hiérarchie. Les exigences fonctionnelles peuvent être reliées à un cas d'utilisation étiqueté.

• Use-Case Name- Donnez un nom concis et axé sur les résultats pour le cas d'utilisation. Ceux-ci reflètent les tâches dont l'utilisateur a besoin pour être en mesure d'accomplir à l'aide du système. Incluez un verbe d'action et un nom. Quelques exemples -

  • Afficher les informations de référence.

  • Marquez manuellement la source hypertexte et établissez un lien vers la cible.

  • Passez une commande pour un CD avec la version du logiciel mise à jour.

Historique des cas d'utilisation

Ici, nous mentionnons les noms des personnes qui sont les parties prenantes du document Usecase.

• Created By - Indiquez le nom de la personne qui a initialement documenté ce cas d'utilisation.

• Date Created - Entrez la date à laquelle le cas d'utilisation a été initialement documenté.

• Last Updated By - Indiquez le nom de la personne qui a effectué la dernière mise à jour de la description du cas d'utilisation.

• Date Last Updated - Entrez la date à laquelle le cas d'utilisation a été le plus récemment mis à jour.

Définition de cas d'utilisation

Voici les définitions des concepts clés du cas d'utilisation -

Acteur

Un acteur est une personne ou une autre entité externe au système logiciel spécifié qui interagit avec le système et exécute des cas d'utilisation pour accomplir des tâches. Différents acteurs correspondent souvent à différentes classes d'utilisateurs, ou rôles, identifiés à partir de la communauté des clients qui utilisera le produit. Nommez le (s) acteur (s) qui exécuteront ce cas d'utilisation.

La description

Fournissez une brève description de la raison et du résultat de ce cas d'utilisation, ou une description de haut niveau de la séquence d'actions et du résultat de l'exécution du cas d'utilisation.

Conditions préalables

Répertoriez toutes les activités qui doivent avoir lieu, ou toutes les conditions qui doivent être vraies, avant que le cas d'utilisation puisse être démarré. Numérotez chaque condition préalable.

Examples

• L'identité de l'utilisateur a été authentifiée.
• L'ordinateur de l'utilisateur dispose de suffisamment de mémoire libre pour lancer la tâche.

Conditions postales

Décrivez l'état du système à la fin de l'exécution du cas d'utilisation. Numérotez chaque condition de poste.

Examples

• Le document contient uniquement des balises SGML valides.
• Le prix de l'article dans la base de données a été mis à jour avec une nouvelle valeur.

Priorité

Indiquez la priorité relative d'implémentation de la fonctionnalité requise pour permettre l'exécution de ce cas d'utilisation. Le schéma de priorité utilisé doit être le même que celui utilisé dans la spécification des exigences logicielles.

Fréquence d'utilisation

Estimez le nombre de fois que ce cas d'utilisation sera exécuté par les acteurs par unité de temps appropriée.

Cours normal des événements

Fournissez une description détaillée des actions de l'utilisateur et des réponses du système qui auront lieu pendant l'exécution du cas d'utilisation dans des conditions normales et attendues. Cette séquence de dialogue mènera finalement à la réalisation de l'objectif indiqué dans le nom et la description du cas d'utilisation. Cette description peut être rédigée en réponse à la question hypothétique «Comment puis-je <accomplir la tâche indiquée dans le nom du cas d'utilisation>?» Il est préférable de le faire sous la forme d'une liste numérotée d'actions exécutées par l'acteur, en alternance avec les réponses fournies par le système.

Cours alternatifs

Documentez les autres scénarios d'utilisation légitimes qui peuvent avoir lieu dans ce cas d'utilisation séparément dans cette section. Énoncez le cours alternatif et décrivez les différences dans la séquence des étapes qui ont lieu. Numérotez chaque cours alternatif en utilisant l'ID du cas d'utilisation comme préfixe, suivi de «AC» pour indiquer «Cours alternatif». Exemple: XYAC.1.

Exceptions

Décrivez toutes les conditions d'erreur anticipées qui pourraient se produire pendant l'exécution du cas d'utilisation et définissez la manière dont le système doit répondre à ces conditions. Décrivez également comment le système doit répondre si l'exécution du cas d'utilisation échoue pour une raison imprévue. Numérotez chaque exception en utilisant l'ID de cas d'utilisation comme préfixe, suivi de «EX» pour indiquer «Exception». Exemple: XYEX.1.

Comprend

Énumérez tous les autres cas d'utilisation qui sont inclus («appelés») par ce cas d'utilisation. Les fonctionnalités communes qui apparaissent dans plusieurs cas d'utilisation peuvent être divisées en un cas d'utilisation distinct qui est inclus par ceux qui ont besoin de cette fonctionnalité commune.

Besoins spéciaux

Identifiez toutes les exigences supplémentaires, telles que les exigences non fonctionnelles, pour le cas d'utilisation qui peuvent devoir être traitées pendant la conception ou la mise en œuvre. Celles-ci peuvent inclure des exigences de performance ou d'autres attributs de qualité.

Hypothèses

Énumérez toutes les hypothèses qui ont été faites dans l'analyse qui ont conduit à l'acceptation de ce cas d'utilisation dans la description du produit et rédigez la description du cas d'utilisation.

Notes et problèmes

Répertoriez tous les commentaires supplémentaires sur ce cas d'utilisation ou tout problème restant en suspens ou à déterminer (à déterminer) qui doit être résolu. Identifiez qui résoudra chaque problème, la date d'échéance et quelle sera la résolution finale.

Gestion des changements et contrôle de version

Le contrôle de version est la gestion des modifications apportées aux documents, aux grands sites Web et à toute autre collecte d'informations. Les modifications sont généralement identifiées par un code numérique ou alphabétique, appelé numéro de révision ou niveau de révision. Chaque révision est associée à un horodatage et à la personne effectuant la modification.

Diagrammes de cas d'utilisation

Une partie importante du langage de modélisation unifié (UML) est la possibilité de dessiner des diagrammes de cas d'utilisation. Les cas d'utilisation sont utilisés pendant la phase d'analyse d'un projet pour identifier et partitionner les fonctionnalités du système. Ils séparent le système en acteurs et en cas d'utilisation. Les acteurs représentent des rôles qui peuvent être joués par les utilisateurs du système.

Ces utilisateurs peuvent être des humains, d'autres ordinateurs, des éléments matériels ou même d'autres systèmes logiciels. Le seul critère est qu'ils doivent être externes à la partie du système partitionnée en cas d'utilisation. Ils doivent fournir des stimuli à cette partie du système et doivent en recevoir des extrants.

Les cas d'utilisation représentent les activités que les acteurs exécutent avec l'aide de votre système dans la poursuite d'un objectif. Nous devons définir ce que ces utilisateurs (acteurs) ont besoin du système. Le cas d'utilisation doit refléter les besoins et les objectifs des utilisateurs et doit être initié par un acteur. Les entreprises, les acteurs, les clients participant au cas d'utilisation métier doivent être connectés au cas d'utilisation par association.

Dessin de diagrammes de cas d'utilisation

La figure ci-dessous montre à quoi un cas d'utilisation peut ressembler à une forme schématique UML. Le cas d'utilisation lui-même ressemble à un ovale. Les acteurs sont dessinés comme de petites figures de bâton. Les acteurs sont connectés au cas d'utilisation avec des lignes.

Use-case 1 - Le vendeur vérifie un article

• Le client place l'article sur le comptoir.
• «Utilise» Swipe UPC Reader.
• Le système recherche le code UPC dans la base de données fournissant la description et le prix de l'article
• Le système émet un bip sonore.
• Le système annonce la description de l'article et le prix via la sortie vocale.
• Le système ajoute le prix et le type d'article à la facture actuelle.
• Le système ajoute le prix pour corriger le sous-total des taxes

Ainsi, la relation «utilise» ressemble beaucoup à un appel de fonction ou à un sous-programme.

Le cas d'utilisation utilisé de cette manière est appelé un cas d'utilisation abstrait car il ne peut pas exister seul mais doit être utilisé par d'autres cas d'utilisation.

Exemple ─ Cas d'utilisation de retrait

L'objectif d'un client par rapport à notre distributeur automatique d'argent (GAB) est de retirer de l'argent. Donc, nous ajoutonsWithdrawalcas d'utilisation. Retirer de l'argent du distributeur automatique peut impliquer une banque pour les transactions à effectuer. Donc, nous ajoutons également un autre acteur -Bank. Les deux acteurs participant au cas d'utilisation doivent être connectés au cas d'utilisation par association.

Le distributeur automatique d'argent fournit un cas d'utilisation de retrait pour le client et les acteurs de la banque.

Relations entre acteurs et cas d'utilisation

Les cas d'utilisation peuvent être organisés en utilisant les relations suivantes -

• Generalization
• Association
• Extend
• Include

Généralisation entre les cas d'utilisation

Il peut y avoir des cas où les acteurs sont associés à des cas d'utilisation similaires. Dans ce cas, un cas d'utilisation enfant hérite des propriétés et du comportement de l'utilisation parent. Il faut donc généraliser l'acteur pour montrer l'héritage des fonctions. Ils sont représentés par une ligne continue avec une grande pointe de flèche triangulaire creuse.

Association entre cas d'utilisation

Les associations entre acteurs et cas d'utilisation sont indiquées dans les diagrammes de cas d'utilisation par des lignes pleines. Une association existe chaque fois qu'un acteur est impliqué dans une interaction décrite par un cas d'utilisation.

Étendre

Certaines fonctions sont déclenchées en option. Dans de tels cas, la relation d'extension est utilisée et la règle d'extension lui est attachée. Ce qu'il faut retenir, c'est que le cas d'utilisation de base doit être capable d'exécuter une fonction seul même si le cas d'utilisation d'extension n'est pas appelé.

La relation d'extension est représentée par une ligne en pointillé avec une pointe de flèche ouverte dirigée du cas d'utilisation d'extension vers le cas d'utilisation étendu (de base). La flèche est étiquetée avec le mot-clé «étendre».

Comprendre

Il est utilisé pour extraire des fragments de cas d'utilisation qui sont dupliqués dans plusieurs cas d'utilisation. Il est également utilisé pour simplifier un grand cas d'utilisation en le divisant en plusieurs cas d'utilisation et pour extraire les parties communes des comportements de deux ou plusieurs cas d'utilisation.

Incluez la relation entre les cas d'utilisation qui est indiquée par une flèche en pointillé avec une pointe de flèche ouverte entre le cas d'utilisation de base et le cas d'utilisation inclus. La flèche est étiquetée avec le mot-clé «inclure».

Les cas d'utilisation ne concernent que les exigences fonctionnelles d'un système. D'autres exigences telles que les règles métier, les exigences de qualité de service et les contraintes d'implémentation doivent être représentées séparément.

Le diagramme ci-dessous est un exemple de diagramme de cas d'utilisation simple avec tous les éléments marqués.

Principes de base pour une application réussie des cas d'utilisation

• Restez simple en racontant des histoires
• Soyez productif sans perfection
• Comprenez la vue d'ensemble
• Identifier les opportunités de réutilisation pour les cas d'utilisation
• Focus sur la valeur
• Construisez le système en tranches
• Livrer le système par incréments
• S'adapter pour répondre aux besoins de l'équipe

Modèle de cas d'utilisation

Ici, nous avons montré un exemple de modèle de cas d'utilisation qu'un analyste métier peut remplir afin que les informations puissent être utiles à l'équipe technique pour obtenir des informations sur le projet.

ID de cas d'utilisation:
Nom du cas d'utilisation:
Créé par:		Dernière mise à jour par
Date créée:		Date de la dernière mise à jour
Acteur:
La description:
Conditions préalables:
Conditions postales:
Priorité:
Fréquence d'utilisation:
Cours normal des événements:
Cours alternatifs:
Exceptions:
Comprend:
Besoins spéciaux:
Hypothèses:
Notes et problèmes:

Analyse commerciale - Gestion des exigences

La collecte des exigences logicielles est la base de tout le projet de développement logiciel. Solliciter et rassembler les besoins de l'entreprise est une première étape essentielle pour chaque projet. Afin de combler le fossé entre les exigences commerciales et techniques, les analystes commerciaux doivent bien comprendre les besoins commerciaux dans le contexte donné, aligner ces besoins sur les objectifs commerciaux et communiquer correctement les besoins aux parties prenantes et à l'équipe de développement.

Les principaux intervenants souhaitent que quelqu'un puisse expliquer les exigences des clients / clients dans un anglais simple. Cela les aidera-t-il à comprendre la valeur à un niveau élevé? Ce sera le domaine principal, car ils essaieront de cartographier la documentation avec les exigences et la manière dont BA pourrait communiquer de la meilleure façon possible.

Pourquoi les projets échouent

Il y a de nombreuses raisons pour lesquelles les projets échouent, mais certains des domaines communs incluent les suivantes:

• Échec du marché et de la stratégie
• Échecs d'organisation et de planification
• Échecs de qualité
• Échecs de leadership et de gouvernance
• Échecs de compétences, de connaissances et de compétences
• Engagement, travail d'équipe et échecs de communication

Au cœur du problème est que les projets sont de plus en plus complexes, que des changements se produisent et que la communication est difficile.

Pourquoi les équipes qui réussissent font la gestion des exigences

La gestion des exigences consiste à garder votre équipe in-sync et fournir visibility à ce qui se passe dans un projet.

Il est essentiel pour la réussite de vos projets que toute votre équipe comprenne ce que vous construisez et pourquoi - c'est ainsi que nous définissons la gestion des exigences. Le «pourquoi» est important car il fournit un contexte aux objectifs, aux commentaires et aux décisions prises concernant les exigences.

Cela augmente la prévisibilité du succès futur et des problèmes potentiels, permettant à votre équipe de corriger rapidement les problèmes et de mener à bien votre projet dans les délais et dans les limites du budget. Pour commencer, il est important que toutes les personnes impliquées aient une compréhension de base de ce que sont les exigences et comment les gérer.

Commençons par les bases

Une exigence est une condition ou une capacité dont une partie prenante a besoin pour résoudre un problème ou atteindre un objectif. Une condition ou une capacité qui doit être satisfaite ou possédée par un système ou un système. Composant pour satisfaire un contrat, une norme, une spécification ou d'autres documents formellement imposés.

Une exigence peut être exprimée par du texte, des croquis, des maquettes ou des modèles détaillés, quelles que soient les informations qui communiquent le mieux à un ingénieur ce qu'il faut construire et à un responsable QA ce qu'il doit tester. En fonction de votre processus de développement, vous pouvez utiliser une terminologie différente pour capturer les exigences.

Les exigences de haut niveau sont parfois appelées simplement needs ou goals. Dans les pratiques de développement de logiciels, les exigences peuvent être appelées «cas d'utilisation», «fonctionnalités» ou «exigences fonctionnelles». Plus précisément dans les méthodologies de développement agile, les exigences sont souvent capturées commeepics et stories.

Indépendamment de ce que votre équipe les appelle ou du processus que vous utilisez; les exigences sont essentielles au développement de tous les produits. Sans définir clairement les exigences, vous pourriez produire un produit incomplet ou défectueux. Tout au long du processus, de nombreuses personnes peuvent être impliquées dans la définition des exigences.

Une partie prenante peut demander une fonctionnalité décrivant comment le produit apportera de la valeur pour résoudre un problème. Un concepteur peut définir une exigence en fonction de l'apparence ou des performances du produit final du point de vue de la convivialité ou de l'interface utilisateur.

Un analyste commercial peut créer une exigence système qui adhère à des contraintes techniques ou organisationnelles spécifiques. Pour les produits et applications logicielles sophistiqués d'aujourd'hui en cours de construction, il faut souvent des centaines ou des milliers d'exigences pour définir suffisamment la portée d'un projet ou d'une version. Par conséquent, il est impératif que l'équipe puisse accéder, collaborer, mettre à jour et tester chaque exigence jusqu'à son achèvement, car les exigences changent et évoluent naturellement au cours du processus de développement.

Maintenant que nous avons défini la valeur de la gestion des exigences à un niveau élevé, approfondissons les quatre principes fondamentaux que chaque membre de l'équipe et chaque partie prenante peuvent bénéficier d'une compréhension -

• Planifier de bonnes exigences: «Que diable construisons-nous?»
• Collaboration et adhésion: "Il suffit d'approuver les spécifications, déjà!"
• Traçabilité et gestion du changement: "Attendez, les développeurs savent-ils que cela a changé?"
• Assurance qualité: "Bonjour, est-ce que quelqu'un a testé cette chose?"

Est-ce que tout le monde sait ce que nous construisons et pourquoi? C'est la valeur de la gestion des exigences.

Collaboration et adhésion des parties prenantes

Tout le monde est-il au courant? Avons-nous une approbation sur les exigences pour aller de l'avant? Ces questions se posent au cours des cycles de développement. Ce serait formidable si tout le monde pouvait s'entendre sur les exigences, mais pour les grands projets avec de nombreuses parties prenantes, cela ne se produit généralement pas. Essayer de mettre tout le monde d'accord peut retarder ou, pire, ne pas prendre des décisions. Obtenir un consensus sur chaque décision n'est pas toujours facile.

En pratique, vous ne voulez pas nécessairement de «consensus», vous voulez «l'adhésion» du groupe et l'approbation des personnes en contrôle afin que vous puissiez faire avancer le projet. Avec le consensus, vous essayez d'amener tout le monde à faire des compromis et à s'entendre sur la décision. Avec l'adhésion, vous essayez d'amener les gens à soutenir la meilleure solution, à prendre une décision intelligente et à faire le nécessaire pour aller de l'avant.

Vous n'avez pas besoin que tout le monde convienne que la décision est la meilleure. Vous avez besoin de tout le monde pour soutenir la décision. La collaboration d'équipe peut aider à recevoir un soutien sur les décisions et à planifier de bonnes exigences.

Les équipes collaboratives travaillent dur pour s'assurer que tout le monde a un intérêt dans les projets et fournit des commentaires. Les équipes collaboratives partagent en permanence des idées, ont généralement une meilleure communication et ont tendance à soutenir les décisions prises car il y a un sentiment partagé d'engagement et de compréhension des objectifs du projet.

C'est lorsque les développeurs, les testeurs ou d'autres parties prenantes se sentent «hors de la boucle» que des problèmes de communication surviennent, que les gens sont frustrés et que les projets sont retardés. Une fois que tout le monde a adhéré à la portée des travaux, il est impératif que les exigences soient claires et bien documentées. Garder une trace de toutes les exigences est là où les choses se compliquent.

Imaginez avoir une liste de tâches d'un kilomètre de long qui implique de collaborer avec plusieurs personnes. Comment garderiez-vous tous ces éléments en ordre? Comment suivriez-vous comment une modification apportée à un élément affecterait le reste du projet? C'est là que la traçabilité et la gestion du changement ajoutent de la valeur.

Planification de bonnes exigences

Alors, qu'est-ce qui fait une bonne exigence? Une bonne exigence doit être valable et exploitable; il doit définir un besoin et fournir une voie vers une solution. Tout le monde dans l'équipe doit comprendre ce que cela signifie. Les exigences varient en complexité.

• Un bon document d'exigences peut faire partie d'un groupe avec des exigences de haut niveau décomposées en sous-exigences.

• Ils peuvent également inclure des spécifications très détaillées qui incluent un ensemble d'exigences fonctionnelles décrivant le comportement ou les composants du produit final.

• Les bonnes exigences doivent être concises et spécifiques et doivent répondre à la question «de quoi avons-nous besoin?» Plutôt que «comment répondre à un besoin?»

• De bonnes exigences garantissent que toutes les parties prenantes comprennent leur part du plan; si les pièces ne sont pas claires ou mal interprétées, le produit final peut être défectueux ou tomber en panne.

La prévention des échecs ou des interprétations erronées des exigences peut être facilitée en recevant des commentaires de l'équipe en continu tout au long du processus à mesure que les exigences évoluent. Une collaboration continue et l'adhésion de tous sont la clé du succès.

Collecte et analyse des exigences

Une exigence est une condition ou une capacité dont une partie prenante a besoin pour résoudre un problème ou atteindre un objectif organisationnel; une condition ou une capacité qui doit être remplie ou possédée par un système.

L'analyse des exigences en génie logiciel couvre les tâches qui entrent dans la détermination des besoins ou des conditions à satisfaire pour un produit nouveau ou modifié en tenant compte des éventuelles exigences conflictuelles de diverses parties prenantes, l'analyse, la documentation, la validation et la gestion des exigences logicielles ou système.

Les exigences devraient être -

• Documented
• Actionable
• Measurable
• Testable
• Traceable

Les exigences doivent être liées aux besoins ou aux opportunités métier identifiés et définies avec un niveau de détail suffisant pour la conception du système.

Un analyste métier recueille des informations en observant les systèmes existants, en étudiant les procédures existantes, en discutant avec les clients et les utilisateurs finaux. L'analyste doit également avoir des compétences imaginatives et créatives en l'absence d'un système fonctionnel. L'analyse des exigences collectées pour trouver les liens manquants est une analyse des exigences.

Approche de sollicitation

Pour obtenir les objectifs, posez les questions suivantes à l'expert métier, au responsable du développement et au parrain du projet:

• Quels objectifs commerciaux de l'entreprise ce projet contribuera-t-il à atteindre?

• Pourquoi faisons-nous ce projet maintenant?

• Que se passera-t-il si nous le faisons plus tard?

• Et si nous ne le faisons pas du tout?

• Qui bénéficiera de ce projet?

• Est-ce que les personnes qui en bénéficieront la considèrent comme l'amélioration la plus importante qui puisse être apportée en ce moment?

• Devrions-nous plutôt faire un projet différent?

Les objectifs possibles pourraient être la réduction des coûts, l'amélioration du service client, la simplification du flux de travail, le remplacement d'une technologie obsolète, le pilotage d'une nouvelle technologie et bien d'autres. Assurez-vous également de bien comprendre comment le projet proposé aidera à atteindre l'objectif déclaré.

Différents types d'exigences

Les types d'exigences les plus courants qui intéressent un analyste commercial sont les suivants:

Besoins de l'entreprise

Les exigences métier sont les activités critiques d'une entreprise qui doivent être réalisées pour atteindre les objectifs organisationnels tout en restant indépendant de la solution. Un document des exigences commerciales (BRD) détaille la solution commerciale pour un projet, y compris la documentation des besoins et des attentes des clients.

Besoins des utilisateurs

Les exigences de l'utilisateur doivent spécifier les exigences spécifiques que l'utilisateur attend / souhaite que le logiciel soit construit à partir du projet logiciel. Une exigence d'un utilisateur doit être vérifiable, claire et concise, complète, cohérente, traçable, viable.

Le document des exigences de l'utilisateur (URD) ​​ou la spécification des exigences de l'utilisateur est un document généralement utilisé en génie logiciel qui spécifie ce que l'utilisateur s'attend à ce que le logiciel soit capable de faire.

Configuration requise

Les exigences système concernent la définition des exigences en matière de ressources logicielles et des prérequis qui doivent être installés sur un ordinateur pour assurer le fonctionnement optimal d'une application.

Exigences fonctionnelles

Les exigences fonctionnelles capturent et spécifient le comportement spécifique prévu du système en cours de développement. Ils définissent des éléments tels que les calculs du système, la manipulation et le traitement des données, l'interface utilisateur et l'interaction avec l'application, et d'autres fonctionnalités spécifiques qui montrent comment les besoins des utilisateurs sont satisfaits. Attribuez un numéro d'identification unique à chaque exigence.

Prérogatives non fonctionnelles

L'exigence non fonctionnelle est celle qui spécifie des critères qui peuvent être utilisés pour juger du fonctionnement d'un système plutôt que des comportements spécifiques. L'architecture du système parle du plan de mise en œuvre des exigences non fonctionnelles.

Les exigences non fonctionnelles parlent de la façon dont le système devrait ressembler ou peuvent être mentionnées comme «le système doit être». Les exigences non fonctionnelles sont appelées qualités du système.

Exigences de transition

Les exigences de transition décrivent les capacités que la solution doit remplir afin de faciliter la transition de l'état actuel de l'entreprise à l'état futur souhaité, mais qui ne seront pas nécessaires une fois la transition terminée.

Ils se distinguent des autres types d'exigences, car ils sont toujours de nature temporaire et parce qu'ils ne peuvent pas être développés tant qu'une solution existante et nouvelle n'est pas définie. Ils couvrent généralement la conversion de données à partir de systèmes existants, les lacunes de compétences qui doivent être comblées et d'autres changements connexes pour atteindre l'état futur souhaité. Ils sont développés et définis par l'évaluation et la validation de la solution.

Traçabilité et gestion du changement

La traçabilité des exigences est un moyen d'organiser, de documenter et de suivre toutes vos exigences, de la génération de l'idée initiale à la phase de test.

La matrice de capacité de suivi des exigences (RTM) fournit une méthode de suivi des exigences fonctionnelles et de leur mise en œuvre tout au long du processus de développement. Chaque exigence est incluse dans la matrice avec son numéro de section associé.

Au fur et à mesure de l'avancement du projet, le RIM est mis à jour pour refléter l'état de chaque exigence. Lorsque le produit est prêt pour le test du système, la matrice répertorie chaque exigence, quel composant du produit y répond et quel test vérifie qu'il est correctement implémenté

Inclure des colonnes pour chacun des éléments suivants dans le RTM -

• Description de l'exigence
• Référence de l'exigence dans FRD
• Méthode de vérification
• Référence d'exigence dans le plan de test

Example- Reliez les points pour identifier les relations entre les éléments de votre projet. C'est un connecteur de flux aval commun.

Idée Exigences Conception Test Objectifs commerciaux

Vous devez être en mesure de retracer chacune de vos exigences jusqu'à son objectif commercial d'origine.

En traçant les exigences, vous pouvez identifier les changements d'effet d'entraînement, voir si une exigence a été remplie et si elle est testée correctement. La traçabilité et la gestion du changement apportent aux managers la tranquillité d'esprit et la visibilité nécessaire pour anticiper les problèmes et assurer une qualité continue.

Assurance qualité

Obtenir les exigences correctement satisfaites du premier coup peut se traduire par une meilleure qualité, des cycles de développement plus rapides et une plus grande satisfaction des clients à l'égard du produit. La gestion des exigences vous aide non seulement à bien faire les choses, mais aide également votre équipe à économiser de l'argent et de nombreux maux de tête tout au long du processus de développement.

Des exigences concises et spécifiques peuvent vous aider à détecter et à résoudre les problèmes tôt, plutôt que plus tard, lorsqu'ils sont beaucoup plus coûteux à résoudre. De plus, cela peut coûter jusqu'à100 times plus pour corriger un défaut plus tard dans le processus de développement après son codage, que pour corriger tôt tout en étant une exigence.

En intégrant la gestion des exigences dans votre processus d'assurance qualité, vous pouvez aider votre équipe à gagner en efficacité et à éliminer les retouches. De plus, la reprise est là où se produisent la plupart des problèmes de coût.

En d'autres termes, les équipes de développement gaspillent la majorité de leurs budgets sur des efforts qui ne sont pas exécutés correctement la première fois. Par exemple, un développeur code une fonctionnalité sur la base d'un ancien document de spécification, pour savoir plus tard, que les exigences pour cette fonctionnalité ont changé. Ces types de problèmes peuvent être évités grâce aux meilleures pratiques de gestion des exigences efficaces.

En résumé, la gestion des exigences peut sembler une discipline complexe, mais lorsque vous la résumez à un concept simple, il s'agit d'aider les équipes à répondre à la question: «Est-ce que tout le monde comprend ce que nous construisons et pourquoi?» Des analystes commerciaux, des chefs de produit et des chefs de projet aux développeurs, aux responsables de l'assurance qualité et aux testeurs, en passant par les parties prenantes et les clients impliqués - si souvent la cause première de l'échec d'un projet est une mauvaise compréhension de la portée du projet.

Lorsque tout le monde collabore et dispose d'un contexte et d'une visibilité complets sur les discussions, les décisions et les changements liés aux exigences tout au long du cycle de vie du projet, c'est lorsque le succès se produit de manière cohérente et que vous maintenez une qualité continue. De plus, le processus est plus fluide avec moins de frictions et de frustration en cours de route pour toutes les personnes impliquées.

Note- La recherche a montré que les équipes de projet peuvent éliminer 50 à 80% des défauts du projet en gérant efficacement les exigences. Selon l'institut de génie logiciel Carnegie Mellon, «60 à 80% du coût du développement logiciel est en cours de retouche.»

Obtention de l'approbation des exigences

La signature des exigences officialise l'accord des parties prenantes du projet que le contenu et la présentation des exigences, tels que documentés, sont exacts et complets. Un accord formel réduit le risque que, pendant ou après la mise en œuvre, une partie prenante introduise une nouvelle exigence (auparavant non rencontrée).

L'obtention de l'approbation des exigences implique généralement un examen final en face à face des exigences, tel que documenté, avec chaque partie prenante du projet. À la fin de chaque examen, l'intervenant est invité à approuver formellement le document d'exigences examiné. Cette approbation peut être enregistrée physiquement ou électroniquement.

L'obtention de l'approbation des exigences est généralement la dernière tâche de la communication des exigences. L'analyste d'affaires exigera les résultats des examens des exigences formelles, y compris la prise en compte de tous les commentaires ou objections soulevés au cours du processus d'examen.

Analyse commerciale - Modélisation

Un modèle d'entreprise peut être défini comme une représentation d'une entreprise ou d'une solution qui comprend souvent un composant graphique ainsi que du texte de support et des relations avec d'autres composants. Par exemple, si nous devons comprendre le modèle commercial d'une entreprise, nous aimerions étudier les domaines suivants tels que -

• Valeurs fondamentales de l'entreprise
• A quoi ça sert?
• Qu'est-ce qui distingue?
• Ses ressources clés
• Relations majeures
• Ses canaux de distribution

À l'aide de techniques de modélisation, nous pouvons créer une description complète des structures organisationnelles, des processus et des informations existants et proposés utilisés par l'entreprise.

Le Business Model est un modèle structuré, tout comme un modèle pour le produit final à développer. Il donne une structure et une dynamique à la planification. Il fournit également la base du produit final.

Objectif de la modélisation commerciale

La modélisation commerciale est utilisée pour concevoir l'état actuel et futur d'une entreprise. Ce modèle est utilisé par l'analyste métier et les parties prenantes pour s'assurer qu'ils ont une compréhension précise du modèle «tel quel» actuel de l'entreprise.

Il est utilisé pour vérifier si les parties prenantes ont une compréhension commune du «futur de la solution» proposé.

L'analyse des exigences fait partie du processus de modélisation métier et constitue le principal domaine d'intérêt. Les exigences fonctionnelles sont rassemblées pendant l '«état actuel». Ces exigences sont fournies par les parties prenantes concernant les processus métier, les données et les règles métier qui décrivent la fonctionnalité souhaitée qui sera conçue dans l'état futur.

Effectuer une analyse des écarts

Après avoir défini les besoins de l'entreprise, l'état actuel (par exemple les processus commerciaux actuels, les fonctions commerciales, les caractéristiques d'un système actuel et les services / produits offerts et les événements auxquels le système doit répondre) doit être identifié pour comprendre comment les personnes, les processus et la technologie, la structure et l'architecture soutiennent l'entreprise en sollicitant les commentaires du personnel informatique et d'autres parties prenantes, y compris les propriétaires d'entreprise.

Une analyse des écarts est ensuite effectuée pour évaluer s'il existe un écart qui empêche de répondre aux besoins de l'entreprise en comparant l'état actuel identifié avec les résultats souhaités.

S'il n'y a pas d'écart (c'est-à-dire que l'état actuel est adéquat pour répondre aux besoins de l'entreprise et aux résultats souhaités), il ne sera probablement pas nécessaire de lancer le projet informatique. Sinon, les problèmes / questions à résoudre pour combler le fossé doivent être identifiés.

Des techniques telles que l'analyse SWOT (forces, faiblesses, opportunités et menaces) et l'analyse de documents peuvent être utilisées.

Pour évaluer le système proposé

BA devrait aider l'équipe de projet informatique à évaluer le système informatique proposé pour s'assurer qu'il répond aux besoins de l'entreprise et maximise les valeurs fournies aux parties prenantes. BA devrait également examiner l'état de préparation de l'organisation à soutenir la transition vers le système informatique proposé afin d'assurer une mise en œuvre harmonieuse du système.

BA devrait aider l'équipe de projet informatique à déterminer si l'option système proposée et la conception de système de haut niveau pourraient répondre aux besoins de l'entreprise et fournir une valeur commerciale suffisante pour justifier l'investissement. S'il existe plus d'une option système, BA doit travailler avec le personnel informatique pour aider à identifier les avantages et les inconvénients de chaque option et sélectionner l'option qui offre la plus grande valeur commerciale.

Principes directeurs de la modélisation commerciale

Le rôle principal de la modélisation d'entreprise est principalement pendant la phase de démarrage et les étapes d'élaboration du projet et il s'estompe pendant la phase de construction et de transition. Il s'agit principalement des aspects analytiques de l'entreprise combinés à la cartographie technique de l'application ou de la solution logicielle.

• Domain and User variation- L'élaboration d'un modèle d'entreprise révélera fréquemment des zones de désaccord ou de confusion entre les parties prenantes. L'analyste d'affaires devra documenter les variations suivantes du modèle tel quel.

• Multiple work units perform the same function- Documentez les écarts dans le modèle AS-IS. Il peut s'agir de différentes divisions ou zones géographiques.

• Multiples users perform the same work- Différentes parties prenantes peuvent effectuer un travail similaire différemment. La variation peut être le résultat de différents ensembles de compétences et d'approches des différentes unités commerciales ou le résultat de besoins différents des parties prenantes externes desservies par l'entreprise. Documentez les écarts dans le modèle AS-IS.

• Resolution Mechanism- L'analyste métier doit documenter si la solution ToBe tiendra compte des incohérences du modèle commercial actuel ou si la solution nécessitera une normalisation. Les parties prenantes doivent déterminer quelle approche adopter. Le modèle To-Be reflétera leur décision.

Exemple de rôle BA dans la modélisation de systèmes ERP

Un analyste métier est censé définir un processus métier standard et le mettre en place dans un système ERP qui est d'une importance clé pour une mise en œuvre efficace. Il est également du devoir d'un BA de définir la langue des développeurs dans un langage compréhensible avant la mise en œuvre, puis d'utiliser les meilleures pratiques et de les cartographier en fonction des capacités du système.

Une exigence du système est l'analyse d'ajustement GAAP, qui doit équilibrer entre -

• La nécessité des changements techniques, qui sont les améliorations afin de s'identifier à la pratique existante.

• Changements efficaces, qui sont liés à la réingénierie des processus métier existants pour permettre la mise en œuvre de la fonctionnalité standard et l'application des modèles de processus.

Analyste d'affaires fonctionnel

L'expertise du domaine s'acquiert généralement sur une période en étant dans le «métier» de faire des choses. Par exemple,

• UNE banking associate acquiert des connaissances sur les différents types de comptes qu'un client (particulier et entreprise) peut exploiter ainsi que sur le flux de processus métier détaillé.

• Un insurance sales representative peut comprendre les différentes étapes de la souscription d'une police d'assurance.

• UNE marketing analyst a plus de chances de comprendre les principales parties prenantes et les processus commerciaux impliqués dans un système de gestion de la relation client.

• Un Business Analyst impliqué dans capital marketsLe projet est censé avoir une expertise en la matière et une solide connaissance des actions, des titres à revenu fixe et des produits dérivés. En outre, il devrait avoir géré le back-office, le front office, l'exposition pratique dans l'application de modèles de gestion des risques.

• UNE Healthcare Business Analyst doit avoir une compréhension de base des mesures financières et d'utilisation des soins de santé aux États-Unis, une expérience technique et une compréhension de l'EDI 837/835/834, des directives HIPAA, de la codification ICD - 9/10 et des codes CPT, LOINC, connaissances SNOMED.

Certains analystes métier acquièrent des connaissances du domaine en testant des applications métier et en travaillant avec les utilisateurs métier. Ils créent un environnement d'apprentissage propice grâce à leurs compétences interpersonnelles et analytiques. Dans certains cas, ils complètent leurs connaissances du domaine avec quelques certifications de domaine proposées par l'AICPCU / ​​IIA et LOMA dans le domaine des assurances et des services financiers. Il existe d'autres instituts qui proposent des certifications dans d'autres domaines.

Autres activités majeures

Après un examen approfondi des processus métier actuels, vous pouvez offrir une assistance hautement professionnelle pour identifier l'approche optimale de modélisation du système.

• Organiser la préparation d'une description formalisée et uniforme des processus métier de manière à garantir une automatisation efficace du système.

• Assistance à vos équipes dans le remplissage de questionnaires standards pour le système concerné qui peuvent être fournis par les développeurs.

• Les exigences de participation aux réunions de travail envers les développeurs sont définies.

• Vérifiez et contrôlez si les exigences définies par vous ont été correctement «reproduites» et enregistrées dans les documents décrivant le futur modèle dans le système (Blueprints).

• Préparation des données et assistance au prototypage du système.

• Aide à la préparation des données pour la migration des listes et des soldes dans le format requis par le système.

• Examen du prototype de configuration pour vérifier sa conformité aux exigences définies par les responsables des processus métier.

• Agir en tant que ressource de support auprès de vos équipes informatiques dans la préparation des données et la performance réelle des tests fonctionnels et d'intégration dans le système.

Dans la section suivante, nous discuterons brièvement de certains des outils de modélisation d'entreprise populaires utilisés par les grandes organisations dans les environnements informatiques.

Outil 1: Microsoft Visio

MS-Visio est un logiciel de dessin et de création de diagrammes qui aide à transformer des concepts en une représentation visuelle. Visio vous fournit des formes, des symboles, des arrière-plans et des bordures prédéfinis. Faites simplement glisser et déposez des éléments dans votre diagramme pour créer un outil de communication professionnel.

Step 1 - Pour ouvrir un nouveau dessin Visio, accédez au menu Démarrer et sélectionnez Programmes → Visio.

Step 2 - Déplacez votre curseur sur «Business Process» et sélectionnez «Basic Flowchart».

La capture d'écran suivante montre les principales sections de l'application MS-Visio.

Parlons maintenant de l'utilité de base de chaque composant -

A- les barres d'outils en haut de l'écran sont comme d'autres programmes Microsoft tels que Word et PowerPoint. Si vous avez déjà utilisé ces programmes, vous remarquerez peut-être quelques fonctionnalités différentes, que nous explorerons plus tard.

La sélection de la galerie de diagrammes d'aide est un bon moyen de se familiariser avec les types de dessins et de diagrammes qui peuvent être créés dans Visio.

B- Le côté gauche de l'écran affiche les menus spécifiques au type de diagramme que vous créez. Dans ce cas, nous voyons -

• Formes de flèche
• Backgrounds
• Formes d'organigramme de base
• Bordures et titres

C - Le centre de l'écran montre l'espace de travail du diagramme, qui comprend la page de diagramme réelle ainsi qu'un espace vide adjacent à la page.

D- Le côté droit de l'écran affiche certaines fonctions d'aide. Certaines personnes peuvent choisir de fermer cette fenêtre pour augmenter la surface de l'espace de travail du diagramme et de rouvrir les fonctions d'aide si nécessaire.

Outil 2: Architecte d'entreprise

L'architecte d'entreprise est un outil de modélisation et de conception visuelle basé sur UML. La plate-forme prend en charge la conception et la construction de systèmes logiciels, la modélisation des processus métier et la modélisation de domaines basés sur l'industrie. Il est utilisé par les entreprises et les organisations non seulement pour modéliser l'architecture de leurs systèmes. Mais pour traiter la mise en œuvre de ces modèles tout au long du cycle de vie de développement des applications.

L'intention de l'architecte d'entreprise est de déterminer comment une organisation peut atteindre le plus efficacement ses objectifs actuels et futurs.

L'architecte d'entreprise a quatre points de vue qui sont les suivants -

• Business perspective - La perspective commerciale définit les processus et les normes selon lesquels l'entreprise fonctionne au jour le jour.

• Application Perspective - La perspective applicative définit les interactions entre les processus et les standards utilisés par l'organisation.

• Information Perspective - Cela définit et classe les données brutes comme les fichiers de documents, les bases de données, les images, les présentations et les feuilles de calcul dont l'organisation a besoin pour fonctionner efficacement.

• Technology Prospective - Cela définit le matériel, les systèmes d'exploitation, les solutions de programmation et de mise en réseau utilisés par l'organisation.

Outil 3: Rational Requisite Pro

Le processus d'obtention, de documentation, d'organisation du suivi et de modification des exigences et de communication de ces informations à travers les équipes de projet pour garantir que les changements itératifs et imprévus sont maintenus tout au long du cycle de vie du projet.

Surveiller l'état et contrôler les modifications de la base de référence des exigences. Les principaux éléments sont le contrôle des changements et la traçabilité.

Requisite Pro is used for the above activities and project administration purposes, the tool is used for querying and searching, Viewing the discussion that were part of the requirement.

In Requisite Pro, the user can work on the requirement document. The document is a MS-Word file created in Reqpro application and integrated with the project database. Requirements created outside Requisite pro can be imported or copied into the document.

In Requisite Pro, we can also work with traceability, here it is a dependency relationship between two requirements. Traceability is a methodical approach to managing change by linking requirements that are related to each other.

Requisite Pro makes it easy to track changes to a requirement throughout the development cycle, so it is not necessary to review all your documents individually to determine which elements need updating. You can view and manage suspect relationships using a Traceability Matrix or a Traceability Tree view.

Requisite Pro projects enable us to create a project framework in which the project artifacts are organized and managed. In each project the following are included.

• General project information
• Packages
• General document information
• Document types
• Requirement types
• Requirement attributes
• Attribute values
• Cross-project traceability

Requisite Pro allows multiple user to access the same project documents and database simultaneously hence the project security aspect is to very crucial. Security prevents the system use, potential harm, or data loss from unauthorized user access to a project document.

It is recommended that the security is enabled for all RequisitePro projects. Doing so ensures that all changes to the project are associated with the proper username of the Individual who made the change, thereby ensuring that you have a complete audit trail for all changes.