Comment les exigences sont-elles vérifiées et validées?

La réponse évidente à cette question est en testant. Mais nous devons être attentif aux exigences que nous testons à un instant dans le cycle de test et à ce qui se passe - nous sommes en train de vérifier ou de valider?

Pourquoi devriez-vous définir les exigences?

Il y a un prix élevé à payer si les exigences ne sont pas définies (ou pas correctement définies). Cela peut entraîner des exigences défectueuses. Les types de défauts rencontrés sont des erreurs causées par des exigences incorrectes ou incomplètes. S'il y a des exigences manquantes ou même des exigences contradictoires, celles-ci sont également considérées comme des défauts.

A propos de l'écoute

Lorsque vous êtes en train de recueillir les exigences afin de les rassembler et de les documenter, vous devez écouter les experts métiers sans aucun filtre.

En d'autres termes, vous avez besoin d'écouter ce qu'ils disent, et non ce que vous pensez qu'ils disent.

Que pensez-vous que l'expert métier attende de vous en terme de communication?

Lorsque vous êtes dans le processus de recueil des exigences, et pour le reste du projet, que pensez-vous que les experts métiers attendent de vous, en tant qu'analyste d'affaires, en terme de communication?

Conséquences d'avoir des exigences en retard

Voici le principal problème que nous avons avec les exigences: les experts métiers ne réalisent pas les conséquences qu'entrainent la remise tardive des exigences d'un projet.

Succès et échecs dans les exigences métier

Il y avait une discussion dans le groupe IIBA sur LinkedIn intitulé "Quelle est votre meilleur conseil pour le succès des exigences en analyse d'affaires" et j'ai voulu m'étendre sur ce sujet en regardant également les causes d'échecs.

Qu'est ce qu'un analyste d'affaires?

J'ai vu ces définitions d'un analyste d'affaires dans une présentation de D. Berglund sur Slideshare.net et j'ai pensé que je pouvais y ajouter la mienne.

Diagramme de séquence

Le diagramme de séquences est un diagramme issue d'UML et décrivant les interactions entre les entités et les transactions qui ont lieu.

Exigences métier vs. exigences fonctionnelles

Les processus principaux peuvent être réalisés de différentes manières.

Les processus principaux documentent ce qu'est le besoin métier- le QUOI.

Les exigences fonctionnelles décrivent plutôt COMMENT le processus devrait être réalisé.

Quel est mon titre? Quel est mon rôle?

Analyste d'affaires, analyste des exigences, analyste système métier... différents titres mais qui réalisent le même travail.

Pourquoi tester et quel est l'objectif des tests?

Qu'est ce que les tests logiciels?

Observer l'execution d'un logiciel pour valider s'il se comporte comme attendu et identifier les dysfonctionnements potentiels.

Diagrammes de flux

Un diagramme de flux détaille visuellement un ou plusieurs processus métiers pour clarifier la compréhension ou pour faire des recommandations sur l'amélioration des processus.

Ces diagrammes sont utilisés pour les processus manuels ou automatiques, les agents externes, les attributs, les entités, les règles métiers.

Cycle de vie d'un projet

Chaque projet passe par différentes phases de travail. Ces phases peuvent être considérées comme le cycle de vie du projet .

Défis typiques d'un projet

• durée limitée, parfois très limitée
• incertitude concernant le travail nécessaire, les méthodes, les durées et les coûts
• découpage complexe entre les activités
• les grands projets sont souvent composés de plusieurs petits projets
• la disponibilité des ressources souvent limitées et la charge de travail inégale
• organisation temporaire du projet/de l'équipe avec des membres provennant de divers disciplines, domaines fonctionnels, et organisations
• équipe géographiquement dispersée
• le chef de projet manque d'autorité formelle, permanente à l'égard de membres de l'équipe 
• potentiel pour changer les priorités, une mauvaise communication, la confusion et les conflits
• manque de documentation
• utilisateurs indéçis dans la définition de leurs besoins

source originale: The analyst coach

Entités et attributs de données

Une entité représente un objet du monde réel ou quelque chose d'indépendant qui peut être identifié de manière unique. Les attributs sont des propriétés de ces entités. Les attributs de données sont affectés à des types d'entités.

Réunions post-it

C'est un exercise que vous verrez faire lors de la planification d'un projet de logiciel.

Si vous avez un très gros projet qui prendra plusieurs années, vous pouvez vous concentrer uniquement sur la planification de l'analyse et de la conception à haut niveau puis ensuite avoir une autre session de planification pour planifier la conception détaillée, le développement, les tests et le déploiement.

modélisation de processus vs. cas d'utilisation

Dans le monde des analystes d'affaires, les modèles de processus et les cas d'utilisation décrivent tous les deux le moyen par lequel les personnes atteignent leurs buts ou répondent aux événements.

Une manière de trouver quelle technique utiliser est d'appliquer le test de "la pause café".

La communication est une compétence clé pour les analystes d'affaires et les testeurs

Une bonne aptitude à communiquer est absolument nécessaire pour réussir en tant qu'analyste d'affaires et testeur.

Taches liées à l'analyse des exigences métier et compétences requises

Tâches qu'un analyste d'affaires effectue:

• avoir une image claire des points de difficultés actuel
• identifier les besoins métier
• comprendre les exigences en matière de conformité avec la législation
• décrire la vue de haut niveau des fonctionnalités requises dans la solution future
• réutiliser intelligemment les composants existants au sein des environnements métiers et techniques
• interviewer les parties prenantes afin de déterminer les procédures actuelles et les améliorations nécessaires
• communiquer efficacement avec des personnes différentes
• comprendre les diverses fonctions, processus et services métier
• rassembler les exigences, identifier les hypothèses et les contraintes
• organiser et gérer les exigences
• présenter l'information d'une manière accessible
• maintenir l'engagement des parties prenantes
• aider l'équipe de testeurs pour la création des scripts de test et l'accomplissement des tests

Les tests manuels

Les tests manuels sont les plus anciens et les plus rigoureux tests de logiciels. Cela nécessite qu'un testeur effectue les opérations de test manuellement sur le logiciel sans l'aide d'un outil d'automatisation des tests. C'est une activité laborieuse qui demande au testeur de posséder un certain nombre de qualités: patience, attention, spéculation, créativité, innovation, ouverture d'esprit, débrouillardise, sans opinion et habile.

Quel type de test logiciel avez-vous fait?

Les tests logiciels jouent un role vital dans la recherche de défauts.

Les testeurs jouent le rôle d'utilisateur final, et utilisent la majorité des fonctionnalité de l'application pour s'assurer que son comportement soit correct. Pour la complétude des tests, le testeur suit un plan de test rédigé qui le conduit à travers un ensemble de cas à tester.

Pourquoi utiliser un cas d'utilisation?

Les cas d'utilisation sont utilisés pour modéliser des tâches simples qu'un utilisateur du système peut effectuer. Ils donnent une définition un peu plus complexe du processus impliqué dans le système qui est conforme aux exigences fixées.

Analyste d'affaires vs. analyste informatique

Je réalise qu'on peut dire qu'il y a une différence technique, mais le role d'un analyste d'affaires est d'être le pont entre les métiers et l'informatique. Une partie des tâches de l'analyste d'affaires est de se concentrer sur ce que veut le client, l'autre partie est de se focaliser sur la solution qui répond à ses besoins.

Exigences d'un logiciel de test

Les activités de test suivent un cycle de vie qui pourrait vivre en parallèle avec le cycle de vie du développement d'un logiciel.

Cela ne semble pas si difficile

S'assoir avec le client et découvrir ce qu'il veut que le système fasse. Utiliser de nouveaux outils ou languages de programmation qui n'existaient pas il y a quelques années. Créer l'application, utiliser les derniers languages et outils. Simuler et corriger avec efficacité et aplomb. Mettre en production une nouvelle application, s'assoir et laisser venir les félicitations et les récompenses. Prendre des vacances et vérifier que le bonus attendu arrive.

La réalité semble être tout à fait différente.

Quelle est la différence entre un test positif et un test négatif?

Le test positif est une activité visant à évaluer un attribut ou une fonctionnalité d'un système, et de déterminer s'il répond à ses exigences. On s'attend donc à ce que des données valides soient traitées par les voies normales.

Test logiciel basé sur les risques

Lorsqu'il n'y a pas assez de temps et de ressources pour tout tester, que dois-je tester?

Les diagrammes en lignes d'eau (ou couloirs)

Un diagramme en "lignes d'eau" est un type de diagramme de processus (parfois appelé diagramme multifonctionnel) qui présente des divisions ou des "lignes". Chaque ligne est affectée à un acteur (qui peut être un individu, une direction, une division, un groupe, une machine, une entité...), à une phase ou à une étape d'un processus, qui est responsable de cette activité ou du travail décrit dans cette ligne.

Exigences fonctionnelles/non fonctionnelles

Définir la différence entre une exigence fonctionnelle et une exigence non fonctionnelle:

• Une exigence fonctionnelle est typiquement rédigée avec un nom/verbe, par exemple, "le système imprime les rapports".
• Une exigence non fonctionnelle est un adverbe ou une clause de modification, par exemple, "le système imprime les rapports avec confidentialité".

Conception de tests itératifs

Lorsque la conception d'un test évolue par itération dans une tendance top-down (du haut vers le bas) à travers les phases de planification-conception-exécution du cycle de vie des tests, cela est considéré comme une conception itérative de test.

Qu'est ce que l'analyse d'un problème?

• L'analyse d'un problème est le processus de compréhension des problèmes réels et des besoins des utilisateurs, et de proposition de solutions qui répondront à ces besoins.
• Le but d'une analyse de problème est d'obtenir une meilleure compréhension du problème à résoudre, avant que les développements commencent.
• Pour identifier la cause première, ou le problème derrière un problème, demander aux personnes directement concernées.
• Identifier les acteurs du système est une étape clé dans l'analyse d'un problème.

source originale: the analyst coach

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

Qu'est ce qu'un cas d'utilisation:

• Créé par Ivar Jacobson (1994).
• Une technique pour capturer les exigences fonctionnelles d'un système.
• Un cas d'utilisation est une séquence de transactions dans un système dont la tâche est de fournir une valeur mesurable à un acteur individuel du système.
• Décrit ce que le système (en tant que boite noire) fait du point de vue de l'utilisateur, l'acteur (le QUOI).
• Représente un comportement complet tel que perçu par un acteur.
• Un cas d'utilisation remplis le but d'un acteur.
• Les cas d'utilisations évitent typiquement le jargon technique, préférant à la place le langage de l'utilisateur final ou de l'expert du domaine.
• Les cas d'utilisations sont souvent coécrits par l'analyste d'affaire et les utilisateurs finaux.

source originale: the analyst coach

Pourquoi des cas d'utilisations devraient être encore créés?

C'est une information qui est venue d'un groupe de discussion sur Linkedin. Ces derniers temps, il y a de nombreuses discussions sur les développements agiles et la diminution de la documentation. Cela montre que les cas d'utilisations sont encore un outil très utile pour les projets informatiques.

Le succès d'un projet

Les éléments principaux d'une gestion de projet comprend:

• La formation de l'équipe projet
• La définition de cadre du projet, des objectifs et des contraintes
• L'analyse du contenu du travail et des livrables
• L'organisation de l'équipe projet et l'affectation des responsabilités
• La planification des développements
• La gestion des effectifs du projet, la planification des ressources
• La prévision des dépenses
• Le contrôle de l'avancement, des coûts et de la qualité

Peu importe que vous planifiez un projet informatique ou tout autre chose, ces éléments sont essentiels, et fonctionnent, pour tous les projets.

source originale: the analyst coach

Les tests automatisés sont-ils bons pour votre projet?

Premièrement, laissez-moi vous dire que j'ai l'expérience des tests manuels et automatiques. J'entends tout le temps que la réponse aux tests de non régression est l'automatisation. Je réponds peut être...

Il y a de nombreux facteurs dans cette prise de décision. L'un d'entre eux est de savoir si l'entreprise sera prête à investir dans un outils d'automatisation. Si vous n'êtes pas la personne qui décide comment dépenser l'argent, vous n'avez pas à prendre cette décision. Vous avez peut être une certaine influence dans cette décision, mais ce n'est pas votre décision au final.

La communication entre les testeurs et l'équipe de développement

C'est là où les compétences en communication sont très importantes. Imaginons que lorsque Brenda fait des tests, elle découvre quelques anomalies. Certaines sont urgentes ou prioritaires; c'est à dire qu'elles l'empêchent de terminer d'autres tests. Elle a besoin de faire savoir à l'équipe de développement qu'il y a des anomalies qui doivent être résolues rapidement. Comment pourrait-elle faire cela?

Le modèle Entité-Relation

Le modèle Entité-Relation peut être utilisé pour les exigences métiers, fonctionnelles et techniques.

Pourquoi l'utiliser:

Définition des mots clés pour la documentation des besoins

Parfois, c'est une bonne idée de prendre du recul et de regarder ce que les mots, que vous utilisez dans votre documentation des besoins métiers, veulent dire. Parfois, c'est une bonne idée également d'ajouter une section "Définitions" dans votre document pour en expliquer leur sens.

DOIT - ce mot, ou bien les termes "NÉCESSAIRE" ou "DEVRA", signifie que la définition est une exigence absolue de la spécification.

Elicitation des exigences

Durant les sessions de recueil des besoins, c'est notre travail en tant qu'analyste d'affaires de ne pas se contenter de noter les besoins qui vous sont donnés, mais de faciliter la discussion à propos de ceux-ci et d'emmener la conversation à un niveau plus profond.

Voici quelques astuces que vous pouvez utiliser pour vous aider dans ce processus.

Comment signaler les anomalies au responsable du développement - qui est également votre responsable

Dans certaines organisations, les testeurs de logiciels rapportent directement au responsable du développement. Ça n'est pas une situation idéale pour d'évidentes raisons, mais c'est une autre discussion.

Je discute ici de la manière de signaler les anomalies à la personne qui a probablement rédigée une partie du code ou à la personne qui est responsable des développements... et à qui vous rapportez personnellement.

Les maquettes d'interfaces

Est ce qu'un analyste d'affaires devrait faire la conception des interfaces utilisateurs? Bien que certains d'entre eux en seraient capable grâce à leurs expériences précédentes, je ne crois pas que la modélisation des interfaces utilisateurs devrait être de leur responsabilité. Cependant, ils peuvent fournir un point de départ pour l'équipe de développement et les designers de l'interface utilisateur.

Les 3 secrets de la réussite des analystes IT

Ralentir

La vitesse n'est pas le but du jeu ici. Vous aurez, bien sûr, des jalons à respecter dans votre projet, mais vous avez également besoin de prendre du temps pour être sûr que vous avez couvert tous les besoins qui ont besoin d'être couverts. Avez vous noté toutes les exigences du métier? Est ce que les cas de tests sont terminés? avez-vous identifié toutes les exigences du système?

Retravailler un projet - mieux analyser les besoins

J'ai trouvé un article "As if re-work wasn't enough" qui donne des statistiques intéressantes et de bonnes informations sur les raisons qui font que nous dédions fréquemment une grande partie de notre budget à revoir des projets. En tant qu'analyste d'affaires, nous devons nous assurer que nous ne recueillons pas seulement des exigences claires et concises, mais également des exigences nécessaires.

Définition simple des méthodes agiles

Un projet qui se fait selon une méthode agile signifie que vous réalisez celui-ci par petits cycles itératifs de développement. 

Construire des scripts de test

Des scripts de test sont définis par 5 caractéristiques:

• L'état initial du système avant l'exécution du test
• Les données du système (exemple, les valeurs dans la base de données)
• Les entrées
• Les résultats attendus
• L'état du système après l'exécution du test

De la difficulté de prendre des notes durant une session de recueil des besoins

Si vous avez une salle de 15 personnes, experts métiers et partenaires, très bavardes, il peut être difficile d'à la fois prendre des notes et maîtriser le déroulement de la réunion.

Récupérer des données pour votre environnement de test

Il y a 4 moyens pour avoir des données dans votre environnement de test: un échantillon des données de production, partir de rien, semer des données, ou les générer.

Bénéfices et défis liés à la création de cas d'utilisation

Bénéfices:

• Les cas d'utilisation nous aident à comprendre et à définir le problème que nous essayons de résoudre ainsi que la solution à celui-ci.
• Les cas d'utilisation captent les besoins opérationnels du point de vue des utilisateurs.
• Ils donnent une description claire et consistante de ce que le système devrait faire et est compréhensible par toutes les parties prenantes: utilisateurs, développeurs, partenaires.
• Les cas d'utilisation sont une excellente source pour les équipes de tests. Ils aident les testeurs dans la rédaction des scripts de tests et comme source d'information durant les tests.
• Les cas d'utilisation fournissent la possibilité de suivre les exigences fonctionnelles à travers les classes et opérations actuelles du système.

Définir les critères d'achèvement des tests d'un logiciel

Vous ne pouvez pas tester partiellement un logiciel. Par conséquent, tout projet qui a été testé devrait avoir des critères bien définis pour indiquer si les tests ont été correctement menés.

Chaque test devrait avoir des objectifs quantifiables spécifiques.

Par exemple, "100% des scripts d'une nouvelle fonctionnalité doivent être exécuté durant les tests d'intégration du système". Ceci est un objectif. Il devrait y avoir un objectif pour les scripts de régression également. Vous pouvez aussi avoir des objectifs qui soient spécifiques pour tester certains types de fonctionnalités si pour une raison ou une autre vous n'avez pas de scripts de test.

Maintenant, voici une chose à considérer: est ce que les tests sont terminés lorsque tous les tests ont été exécutés, ou bien le sont-ils lorsque tous les scripts se sont correctement exécutés?

Se préparer pour une session de recueil d'exigences

En tant qu'analyste d'affaires, vous êtes souvent dans la position où vous êtes dans une salle de réunion avec 5 personnes que vous connaissez, ou avec qui vous avez déjà travaillé auparavant, et environ 10-15 autres personnes que vous n'avez jamais rencontré ou à qui vous n'avez jamais parlé... et maintenant, c'est votre responsabilité de faire en sorte que chacun partage ses connaissances avec vous et tout les autres participants.

Lorsque votre but est de recueillir les besoins d'experts métiers et d'utilisateurs, il y a quelque chose que vous pouvez faire pour vous préparer à la réunion et qui aidera à vous sentir moins nerveux et plus productif.