Qu'est-ce que le «domaine problématique»

Je dois documenter mon programme pour un projet d'école et nous avons une section intitulée «domaine à problème» mais je n'ai aucune idée de quoi discuter dans cette section.

La question est donc la suivante: que faut-il discuter dans le domaine problématique?

J'écris des logiciels embarqués pour les équipements de télécommunications. Mon domaine problématique est les protocoles Ethernet, voix et vidéo. En d'autres termes, tout ce qui n'a rien à voir avec le langage dans lequel je programme, mais que je dois encore comprendre pour écrire le logiciel. Si vous créez un site Web pour vendre des services de photographie, le domaine problématique est la photographie et le commerce électronique. Si vous écrivez un micrologiciel pour des avions militaires, le domaine problématique est les armes, les capteurs et les systèmes de contrôle. Obtenez l'image?

Extrait de l'article Wikipedia sur le domaine problématique :

Un domaine problématique est le domaine d'expertise ou d'application qui doit être examiné pour résoudre un problème. Un domaine problématique examine simplement les sujets qui vous intéressent et exclut tout le reste.

C'est le domaine auquel les problèmes que votre application est censée résoudre appartiennent.

Tout le monde n'écrit pas des compilateurs, des dépisteurs de bogues, des frameworks ou d'autres progiciels informatiques.

Certaines personnes écrivent des logiciels pour l'industrie du sable et du gravier. Certaines personnes écrivent des logiciels pour surveiller les tours de réfraction des raffineries. Certaines personnes écrivent des logiciels pour contrôler la fabrication de sacs d'épicerie en plastique. Certaines personnes écrivent des logiciels pour remplir les paquets de ketchup.

Ce sont tous des domaines problématiques où, pour écrire un bon logiciel, vous devez en savoir un peu plus sur le domaine, par exemple le béton prêt à l'emploi.

Ian K. Bray dans son livre An Introduction to Requirements Engineering (p9) définit le domaine du problème comme suit:

La partie de l'univers dans laquelle le problème existe .

Par exemple, dans le cas d'un système de commande d'ascenseur, il comprendrait tout matériel existant (ascenseurs, moteurs, boutons, indicateurs, capteurs, etc.), les caractéristiques du bâtiment (nombre d'étages et de cages d'ascenseur), le modèle prévu de l'utilisation, les caractéristiques des utilisateurs, la politique d'utilisation des ascenseurs du client (par exemple, les utilisateurs devraient-ils être découragés d'utiliser un ascenseur pour de courts trajets?), etc.

Dans le domaine du problème du contrôle des ascenseurs, le problème, comme indiqué ci-dessus, est «un système de contrôle est nécessaire pour utiliser plus efficacement les ascenseurs de ce bâtiment». En pratique, nous affinons généralement le problème en un ensemble de sous-problèmes mais, pour l'instant, notons simplement que pour résoudre le (s) problème (s), il est clairement nécessaire que le système de solution produise certains effets dans le domaine du problème . Ce sont ces effets souhaités qui constituent les exigences.

Ainsi, le domaine problématique peut également être considéré comme la partie du monde dans laquelle le nouveau système de solution (parfois raccourci en SS) fonctionnera et produira les effets requis. Étant donné que les systèmes de solutions logicielles sont souvent appelés applications, le domaine problématique peut être appelé domaine d'application.

Je le vois comme ça:

Le domaine du problème: la raison pour laquelle le logiciel doit être construit et l'environnement et l'industrie pour lesquels le système construit doit être utilisé.