De Maarch MoReq2.
Complet
Liste
Également :
Conventions de lecture
- Les numéros d'exigence en gras dans la liste et en rouge dans le détail indiquent des exigences retenues par M.-A. Chabin.
- Les phrases en italique dans la colonne Observations sont les commentaires extraits directement du MoReq2.
- Les phrases en bleu dans la colonne Observations sont des commentaires, des réflexions ou des questions de l'équipe projet MoReq2.Maarch.
- Les liens sur la qualité des tests (O, N ou P) permettent d'accéder à ceux-ci.
Exigences générales
Complet
Remarque : Il n'existe pas d'exigence en 12.1.x, le premier sous-chapitre de ce chapitre étant consacré à une sous-explication (...).
Dans les tableaux, lire :
| Exigence : Texte de l'exigence
| Test : N (non testable)/P (partiellement testable) / O (testable)
| Observations : Observations éventuelles
|
↑
12.2.1
| Le SAE ne doit en aucune façon limiter le nombre de métadonnées autorisées pour chaque entité (série, dossier, sous-dossier, volume, document).
| P
| Cette notion de limite peut varier selon l’application. Par exemple, les organisations ayant adopté un plan de classement modeste n’auront pas besoin d’autant de métadonnées que celles qui se seront dotées d’un plan de classement complexe.
L'intégration de cette exigence dans le modèle physique de données peut être problématique, s'il est considéré qu'un administrateur - sous-entendu fonctionnel - peut de lui-même modifier le nombre de ces métadonnées. Une solution envisageable serait par exemple d'avoir deux tables supplémentaires, l'une listant ces métadonnées et l'autre liant la métadonnée, l'entité, et la valeur prise. Un inconvénient serait l'absence de typage de la valeur. Les conséquences sur l'utilisation de ces métadonnées dans le fonctionnement courant du logiciel est à étudier avec beaucoup d'attention.
Voir également la 3.2.2.
|
↑
12.2.2
| Si le contenu d’une métadonnée peut être lié à une action dans le SAE, le SAE doit renseigner cette métadonnée au lancement de cette action.
| P
| Par exemple, si le SAE stocke la date d’ouverture des dossiers, il doit renseigner cette métadonnée automatiquement à chaque ouverture de dossier plutôt que demander à un utilisateur de le faire. À noter que cette exigence générique est valable pour de nombreuses métadonnées. MoReq2 ne prétend pas identifier tous les cas de figure.
|
↑
12.2.3
| Le SAE doit permettre de définir différents jeux de métadonnées pour différents types de documents au moment de la configuration.
| O
| Par exemple, les métadonnées requises seront :
- pour les factures, des numéros de compte ;
- pour le courrier, des champs destinataires multi-valeurs ;
- pour les documents numérisés, des données relatives à la numérisation et à l’indexation.
Définir « à la volée » un champ multi-valué dans des métadonnées impliquerait dans le modèle physique la création d'une nouvelle table de correspondance (dans notre cas DESTINATAIRES(id_document,id_destinataire), ce qui est pour ainsi dire impossible.
|
↑
12.2.4
| Le SAE doit permettre à l’administrateur de préciser lors de la configuration si une métadonnée est obligatoire ou facultative.
| O
|
|
↑
12.2.5
Le SAE doit accepter au minimum les formats de métadonnées suivants :
- alphabétique,
- alphanumérique,
- numérique,
- date,
- logique (OUI/NON, VRAIX/FAUX, etc.).
| O
|
Voir également la 12.2.14.
|
↑
12.2.7
| Le SAE doit accepter tous les formats de date définis dans ISO 8601.
| O
|
|
↑
12.2.8
| Lors de la configuration, le SAE doit permettre de préciser la source des données pour chaque métadonnée.
| O
| Les sources possibles sont décrites aux points 12.2.9, 12.2.10, 12.2.11 et 12.2.12.
|
↑
12.2.9
| Le SAE doit permettre à un administrateur de préciser quelles métadonnées doivent être saisies et mises à jour manuellement ou sélectionnées dans un vocabulaire contrôlé.
| O
|
Voir également la 12.2.8.
|
↑
12.2.14
Le SAE doit être capable de valider des métadonnées saisies par les utilisateurs ou importées. La validation doit utiliser au minimum les mécanismes suivants :
- format des contenus ;
- plage de valeurs ;
- validation par rapport à une liste de valeurs gérée par un administrateur.
| O
| Exemple de validation du format : tous les contenus sont numériques ou au format date (selon 12.2.5.). Exemple de validation par rapport à un ensemble de valeurs : les contenus sont compris entre le 1er janvier 1999 et le 31 décembre 2001. Exemple de validation par rapport à une liste de valeurs : vérification que le nom exporté figure sur une liste.
|
↑
12.2.15
| Le SAE doit être capable de valider des métadonnées en interrogeant d’autres applications (un système de ressources humaines en vérifiant si un matricule a été attribué, ou une base de données de codes postaux) ou en utilisant une table de conversion interne.
| O
|
Cela ne peut être obligatoire que si ces applications proposent un mode d'interrogation.
|
↑
12.2.16
| Le SAE doit permettre à un administrateur de paramétrer la validation pour chaque métadonnée (voir 12.2.14 et 12.2.15).
La validation dépend du type de métadonnée : les dates demanderont une
validation de format alors que les descriptions n’ont pas besoin d’être validées.
| O
|
Les contraintes sur la validation viennent principalement des spécifications de la base de données (si c'est une technologie utilisée).
|
↑
12.2.21
| Le SAE doit permettre aux administrateurs de restreindre le droit de modifier les valeurs des métadonnées (voir le modèle de contrôle d’accès section 13.4).
| O
|
|
↑
12.2.22
| Le SAE doit permettre à un administrateur de reconfigurer le modèle de métadonnées et tracer l’opération dans l’historique des événements.
| P
| Par exemple, on peut avoir besoin d’ajouter une métadonnée « identifiant du département » à certains types de documents à la suite d’une réorganisation.
Opération sensible s'il en est. Après l'ajout d'une métadonnée, quelle valeur donner aux millions de documents déjà capturés ? Ce type d'opération ne devrait s'envisager sereinement qu'avec un intégrateur.
|
↑
12.2.23
| Le SAE doit permettre de paramétrer les métadonnées lors de la configuration de sorte que les valeurs issues d’autres logiciels applicatifs, du système d’exploitation ou du SAE (par exemple, la messagerie électronique) ne puissent être modifiées par l’utilisateur après la capture.
| O
|
Question : après la capture, qu'est-ce qui peut être modifié par un utilisateur ? Dans le sens de la 12.2.24 : rien.
|
↑
12.2.24
| Le SAE doit permettre de paramétrer les métadonnées lors de la configuration de sorte que, une fois saisies, l’utilisateur ne puisse plus les modifier.
| O
|
|
↑
Notes
↑
