Vous êtes sur la page 1sur 10

Résultats du test en ligne - Hightest

Vous avez bien répondu à 6 question(s) sur 20, soit 30 % de réussite. Il faudrait monter
jusqu'à 65 %. Courage !

Une exigence est :

1. Une condition ou une capacité requise par un utilisateur pour résoudre un problème
ou atteindre un objectif
2. Une condition ou capacité qui doit être tenue ou possédée par un système ou un
composante pour satisfaire un contrat, un standard, une spécification ou tout autre
document imposé formellement
3. Une représentation documentée d’une condition ou d’une capacité requise
4. Selon le contexte, l’une des trois propositions ci-dessus

Solution

La définition de IEEE 610 de 1990, reprise par le lexique IREB, donne cette triple
définition de l'exigence.

Vous n'avez pas trouvé cette réponse.

Quelle phrase sur l’engagement (ou portée contractuelle) est fausse ?

1. L’engagement est le degré d’obligation pour satisfaire à l’exigence.


2. L’engagement est un attribut pouvant impliquer une responsabilité juridique.
3. Le degré d’engagement est calculé en multipliant l’indice de priorité par l’indice
de criticité.
4. La notation MoSCoW permet d’exprimer le degré requis d’engagement.

Solution

Une manière d'exprimer la portée contractuelle est d'utiliser les verbes 'devoir' (à
l'indicatif ou au conditionnel) et 'pouvoir', ce qui correspond à la notation MoSCoW
(Must, Should, Could, Won't). IREB recommande d'exprimer la portée contractuelle via
des attributs d'exigences (UE 5.2 du syllabus IREB de niveau Fondamentaux).

Vous n'avez pas trouvé cette réponse.


Quel type d’exigence est absent du modèle de Kano ?

1. Les contre-exigences, à savoir les caractéristiques que la solution ne devra


obligatoirement pas présenter
2. Les exigences qui se positionnent comme des seuils ou attributs de base
3. Les attributs de performance, qui améliorent la satisfaction du client
4. Les attributs d’excitation, non prévus par le client, qui répondent à des « besoins
inconnus » et peuvent fournir un avantage concurrentiel significatif

Solution

Le modèle de Kano est cité dans l'UE 3.2 du syllabus IREB de niveau Fondamentaux.
Ce modèle permet de penser les attendus et les centres de satisfaction des utilisateurs
finaux, des aspects décisifs pour la gestion des exigences.

Vous avez trouvé la bonne réponse !

Quelle est la différence entre validation et vérification ?

1. La vérification permet de savoir si on a créé correctement le produit ; la


validation permet de savoir si le produit répond au besoin du client
2. La validation correspond à la somme de toutes les vérifications incrémentales
3. La validation est une vérification en environnement cible
4. La vérification est menée par l'équipe projet, alors que la validation est menée par
des équipes tierces (par exemple lors d'un audit)

Solution

La vérification concerne l'adéquation entre le résultat final et l'objectif qui a été fixé. La
validation permet de confirmer que l'objectif fixé est bien le bon et répond au besoin réel
d'un contexte donné. Ces notions définies notamment dans ISO 9000:2015.

Vous avez trouvé la bonne réponse !


La traçabilité des exigences ne peut pas être mise en œuvre par :

1. Des références textuelles


2. Des références implicites
3. Des hyperliens
4. Des matrices

Solution

La traçabilité des exigences permet notamment d'analyser les impacts, la couverture et


les coûts. Leur traçabilité doit être mise en œuvre de manière claire et systématique.
Cet aspect est détaillé dans l'UE 8.4 du syllabus IREB de niveau Fondamentaux.

Vous n'avez pas trouvé cette réponse.

Il existe trois grands types de prototypes. Lequel n’en fait pas partie ?

1. Le prototype vertical, qui propose un nombre réduit de fonctions, mais où chaque


fonction présente est détaillée
2. Le prototype horizontal, qui contient un grand nombre de fonctions, mais où chaque
fonction est largement incomplète
3. Le prototype diagonal, qui permet de montrer superficiellement un nombre
important de fonctionnalités, et de montrer en profondeur un petit nombre de
fonctionnalités
4. Le prototype de scénario, où toutes les fonctions sont simulées pour une tâche
spécifique, combinant des prototypes verticaux et horizontaux

Solution

Les prototypes horizontaux, verticaux et de scénario sont les 3 types de prototypes


définis par Jakob Nielsen en 1993 dans Usability Engineering. Ils ne sont pas cités tels
quels dans le syllabus IREB de niveau Fondamentaux, mais sont utiles à connaître
dans le sens où le prototypage est présenté comme une technique d'élucidation et de
validation des exigences (UE 3.3 et 7.5).

Vous n'avez pas trouvé cette réponse.


Les défauts résultant d’exigences de faible qualité sont :

1. Globalement plus coûteux que les autres types de défauts


2. Globalement d’ordre non-fonctionnel
3. Généralement peu critiques
4. Généralement simples à identifier

Solution

Cet aspect est évoqué dès l'UE 1 du syllabus IREB de niveau Fondamentaux.

Vous n'avez pas trouvé cette réponse.

Lequel de ces éléments contribue à améliorer la testabilité d’une exigence ?

1. L’implication des parties prenantes, en particulier des clients


2. L’analyse des risques
3. Les éléments en sortie de phase d’élucidation
4. Le ou les critères d’acceptation

Solution

Les critères d'acceptation d'une exigence sont évoqués dans l'UE 4.3 du syllabus IREB
de niveau Fondamentaux. Ils sont précieux en ce qu'ils permettent à toutes les parties
prenantes de déterminer si telle exigence a été remplie.

Vous n'avez pas trouvé cette réponse.

En environnement agile, par l’intermédiaire de quel mécanisme les exigences ne


sont pas communiquées ?

1. Le product backlog
2. Les user stories
3. Les daily scrums
4. Les mockups

Solution

L'agilité n'est pas évoquée dans le syllabus IREB de niveau Fondamentaux, mais il est
intéressant de pouvoir faire le lien entre les pratiques agiles et l'ingénierie des
exigences. L'agilité est étudiée dans le syllabus REQB niveau Fondation.

Vous n'avez pas trouvé cette réponse.

Quelle phrase sur les diagrammes de cas d’utilisation est fausse ?

1. Il est courant d'y représenter les acteurs humains, par exemple en les modélisant par
un petit bonhomme.
2. Dans ce type de diagramme, les cas d’utilisation représentés ne s’enchaînent pas (il
n’y a pas de représentation temporelle)
3. Il est possible d’utiliser un diagramme de cas d’utilisation pour représenter de
manière macroscopique les droits accordés à chaque grand type d’utilisateurs d’une
solution
4. Les pré-requis d’un cas d’utilisation sont exprimés par le mot-clé « extend »

Solution

Dans un diagramme de cas d'utilisation UML, les pré-requis d'un cas d'utilisation sont
exprimés par le mot-clé « include ».

Vous n'avez pas trouvé cette réponse.

Quelle phrase sur les diagrammes d’activité est fausse ?

1. Les diagrammes d’activité mettent l’accent sur les traitements en se focalisant sur les
actions, en opposition avec les objets.
2. Un diagramme d’activité peut être réalisé pour décrire un cas d’utilisation.
3. Dans la représentation d’une transition conditionnelle, les différentes décisions
doivent être mutuellement exclusives.
4. Les actions sont représentées par des arcs et les transitions sont représentées
par des noeuds.

Solution

Dans un diagramme d'activité UML, les actions sont représentées par des noeuds et les
transitions par des arcs.

Vous n'avez pas trouvé cette réponse.

Quelle phrase sur les diagrammes d’état-transition (ou diagrammes de machine à


états, ou statecharts) est fausse ?

1. Ce diagramme offre une vision complète et non-ambiguë de l’ensemble des


comportements de l’élément représenté.
2. Ce diagramme représente un élément du système au sein de son
environnement : les acteurs (humains ou systèmes) y figurent.
3. Les temps d’attente peuvent figurer sur ce type de diagramme.
4. Il est obligatoire de représenter l’état initial, mais pas le ou les états finaux.

Solution

Dans un diagramme d'état-transition UML, la vision globale du système n'apparaît pas ;


on ne représente qu'un seul élément du système indépendamment de son
environnement.

Vous n'avez pas trouvé cette réponse.

Un éditeur de logiciels est en train de développer une application de domotique.


Une réglementation sur la sécurité requise pour ce type de logiciels entre en
vigueur. Pour l’application en développement, cela impacte en premier lieu :

1. Le périmètre du système
2. Les limites du contexte
3. Les exigences fonctionnelles
4. Les processus métier
Solution

Les notions de périmètre du système et de limites du contexte sont expliquées dans


l'UE 2 du syllabus IREB de niveau Fondamentaux.

Vous n'avez pas trouvé cette réponse.

Sur quoi se base-t-on pour procéder à l’élucidation des exigences ?

1. Sur les limites du système et la gestion des exigences


2. Sur le périmètre du système et la priorisation des exigences
3. Sur le contexte du système et les sources d’exigences
4. Sur les sources du système et le contexte des exigences

Solution

Ces notions sont expliquées dans l'UE 3.1 du syllabus IREB de niveau Fondamentaux.

Vous n'avez pas trouvé cette réponse.

Selon IREB, les modèles ont trois caractéristiques essentielles. Laquelle n’en fait
pas partie ?

1. Les modèles représentent la réalité (représentation)


2. Les modèles réduisent la réalité représentée (abstraction)
3. Les modèles sont construits pour une utilisation spécifique (pragmatisme)
4. Les modèles sont maintenables par toutes les parties prenantes
(responsabilité partagée)

Solution

Les trois caractéristiques essentielles des modèles sont indiquées dans l'UE 6.1 du
syllabus IREB de niveau Fondamentaux.
Vous avez trouvé la bonne réponse !

Lequel de ces aspects ne fait pas partie des huit critères de validation du contenu
d’une exigence ?

1. Pas de décisions de conception prématurées


2. Vérifiabilité
3. Nécessité
4. Entente après changement

Solution

L'entente après changement fait partie des trois critères de validation de la facette
'accord' d'une exigence. Les facettes de la qualité des exigences (contenu,
documentation et accord) sont expliquées dans l'UE 7.3 du syllabus IREB de niveau
Fondamentaux.

Vous avez trouvé la bonne réponse !

Laquelle de ces activités ne fait pas partie des 4 activités de la négociation des
exigences ?

1. Analyse du conflit
2. Elaboration de scénarios de résolution
3. Résolution du conflit
4. Documentation de la résolution du conflit

Solution

Les quatre activités de la négociation des exigences (UE 7.6) sont l'identification du
conflit, l'analyse du conflit, la résolution du conflit et la documentation de la résolution du
conflit.

Vous n'avez pas trouvé cette réponse.


Quelles sont les quatre activités principales de l’ingénierie des exigences ?

1. Elucidation – Documentation – Validation/Négociation – Gestion


2. Elucidation – Analyse – Synthèse – Développement
3. Elucidation – Délimitation – Complétion/Epuration - Finalisation
4. Elucidation – Décomposition – Modélisation – Confirmation

Solution

Ces quatre activités sont indiquées dans l'UE 1 du syllabus IREB de niveau
Fondamentaux.

Vous avez trouvé la bonne réponse !

Si on utilise la matrice de priorités de Karl Wiegers (1999), comment calcule-t-on


l’indice de priorité d’une exigence ?

1. Priorité = Valeur en % / Coût en % * coefficient du coût / Risque en % * coefficient du


risque
2. Priorité = Valeur en % / (Coût en % * coefficient du coût + Risque en % *
coefficient du risque)
3. Priorité = Valeur en % / Coût en % * coefficient du coût * Risque en % * coefficient du
risque
4. Priorité = Valeur en % * Coût en % * coefficient du coût * Risque en % * coefficient du
risque

Solution

Cette matrice est évoquée dans l'UE 8.3 du syllabus IREB de niveau Fondamentaux.
Pour plus de détails, consultez l'article de Karl Wiegers.

Vous avez trouvé la bonne réponse !


Selon IREB, il existe trois sortes de changements dans les exigences. Lequel
n’en fait pas partie ?

1. Les changements correctifs


2. Les adaptations
3. Les changements exceptionnels
4. Les changements expérimentaux

Solution

Les trois sortes de changements sont listées dans l'UE 8.6 du syllabus IREB de niveau
Fondamentaux.

Vous aimerez peut-être aussi