Exigences obligatoires du MoReq2/Chapitre 9 : Fonctions d'administration
De Maarch MoReq2.
Exigences
- Ch. 3 : Plan de classement
- Ch. 4 : Sécurité
- Ch. 5 : Conservation et destruction
- Ch. 6 : Capture
- Ch. 7 : Identification
- Ch. 8 : Recherche et restitution
- Ch. 9 : Administration
- Ch. 11 : Non fonctionnel
- Ch. 12 : Métadonnées
Tests
Incomplet
Liste
| Administration générale | Reporting | Modification, suppression et masquage |
|---|---|---|
É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.
Administration générale
Incomplet
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
Reporting
Incomplet
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
9.2.1
| Le SAE doit permettre aux administrateurs de produire des rapports périodiques (journaliers, hebdomadaires, mensuels, trimestriels) et de définir des rapports ad hoc. | O |
Redondance avec une exigence du chap. 3. À référencer. |
9.2.12
Si l’option de GED décrite en 10.3 existe, le SAE doit pouvoir fournir des rapports sur :
| O |
À reclasser dans les exigences optionnelles. |
9.2.18
Le SAE doit permettre aux administrateurs d’effectuer des requêtes sur l’historique des événements. Ces rapports doivent porter au minimum sur une des entités suivantes :
| O |
|
9.2.20
| Le SAE doit pouvoir produire un rapport d’exécution du processus de destruction, avec la liste des séries, dossiers, sous-dossiers, volumes et documents détruits, et les anomalies. | O |
|
9.2.21
| Le SAE doit pouvoir produire un rapport d’exécution du processus d’export, avec la liste des séries, dossiers, sous-dossiers, volumes et documents exportés, et les anomalies. | O |
|
9.2.22
| Le SAE doit pouvoir fournir aux administrateurs un rapport sur les opérations de révision, mentionnant les actions en attente. | O |
|
9.2.27
Le SAE devrait comporter des outils d’analyse statistique pour aider un administrateur à gérer les règles de conservation/destruction, notamment la possibilité de :
| O |
Plusieurs remarques :
|
9.2.30
| Le SAE doit produire un rapport détaillant les anomalies en cas de transfert, d’export, de destruction ou de suppression. Le rapport doit identifier les documents, groupes et métadonnées associées à transférer dont le traitement a provoqué une erreur, et toute entité dont le transfert, l’export, la destruction ou la suppression a échoué. | O |
Voir également 5.3.14. |
9.2.31
| Le SAE doit produire un rapport détaillant les anomalies en cas d’import. Le rapport doit identifier les documents, groupes et métadonnées associées à importer dont le traitement a provoqué une erreur, et toute entité dont l’import a échoué. | O |
Voir également 5.3.14. |
Modification, suppression et masquage des documents archivés
Incomplet
Voir également la 3.4.19, la 5.1.23, la 5.1.36 et la 5.3.6.
Dans les tableaux, lire :
| Exigence : Texte de l'exigence | Test : N (non testable)/P (partiellement testable) / O (testable) | Observations : Observations éventuelles |
|---|
9.3.1
| Le SAE doit proposer une option de configuration qui interdit qu’un document, une fois capturé, soit supprimé ou déplacé par un administrateur ou un utilisateur ; voir aussi 9.3.3. | O | Cette exigence ne doit pas affecter le transfert ou la destruction des documents en application des règles de conservation/destruction (voir section 5.3). Elle vise les cas où la suppression des documents archivés (voir ci-dessus) est inutile ou interdite. Une alternative est proposée en 9.3.2.
Voir également 9.3.5. |
9.3.3
Si l’option 9.3.1 est retenue, le SAE doit se comporter comme suit :
| O | Cela suppose que très peu d’administrateurs voire aucun n’aurait cette autorisation.
Voir également la 5.1.33. |
9.3.5
| Le SAE doit permettre aux administrateurs de supprimer des séries, dossiers, sous-dossiers, volumes et documents en dehors du processus de révision. | O | Ce point ne concerne que les cas exceptionnels cités dans cette section. A rapprocher de 9.3.1 et 9.3.2.
Attention : Les deux exigences de suppression explicitement listées (3.4.18 sur les séries et 3.3.15 sur les volumes) insistent sur le fait qu'une entité doit être vide pour être supprimée. Voir également la 3.4.19, la 9.3.3 et la 9.3.4. À l'instar d'actions telles que le gel ou la modification de mot-clé, la suppression d'entité aurait mérité un « motif_suppression_manuelle » comme métadonnée. |
9.3.6
| Le SAE doit permettre aux utilisateurs de proposer des séries, dossiers, sous-dossiers, volumes et documents à la suppression. | O | L’administrateur peut alors décider d’effectuer ou non la suppression.
|
9.3.7
En cas de suppression de ce type[1], le SAE doit :
| O | Ici l’expression « maintenir l’intégrité des métadonnées » signifie s’assurer qu’aucune métadonnée d’une entité (série, document, etc.) ne renvoie à une entité inexistante.
|
9.3.8
| Les administrateurs doivent pouvoir modifier une métadonnée saisie par un utilisateur. | O | Cette fonctionnalité doit permettre aux administrateurs de corriger les erreurs des utilisateurs (erreur de saisie, etc.) et de maintenir les accès des utilisateurs et des groupes. Les bonnes pratiques veulent que les utilisateurs corrigent eux-mêmes leurs erreurs ; cette exigence ne les en dispense pas.
|
9.3.9
| Toutes les modifications apportées aux métadonnées doivent être tracées dans l’historique. | O |
|
9.3.10
| Le SAE doit permettre aux administrateurs de créer un ou plusieurs extraits d’un document qu’il convient de masquer, tout en conservant l’original. | O | Il peut s’avérer nécessaire de fournir plusieurs extraits d’un document dont des passages différents ont dû être masqués.
|
9.3.11
| Le SAE doit permettre de retirer ou de cacher les informations sensibles dans un extrait pour tous les formats d’archivage préconisés. | O | Si le SAE n’offre pas cette fonction, il doit favoriser l’intégration d’un autre logiciel capable de le faire. On peut admettre que le SAE convertisse un document dans un format de fichier différent pour permettre le masquage d’une copie, si la conversion garantit une fidélité suffisante.
Il est essentiel, en cas de recours à l’une ou l’autre fonction de masquage, que les informations retirées ou cachées ne puissent en aucun cas être récupérées à partir de l’extrait, ni à l’écran ni à l’impression ni par rejeu, ni sous aucune forme, sans parler de l’utilisation des fonctions de rotation, de zoom ou de quelque manipulation que ce soit, y compris la restitution de l’extrait avec un autre logiciel. Vérifier qu'une exigence ne dit pas exactement l'inverse, c'est-à-dire qu'un extrait doit permettre de mettre à disposition des utilisateurs des parties non sensibles d'un document sensible. |
9.3.12
| Quand un extrait est créé, le SAE doit automatiquement enregistrer sa création dans les métadonnées de l’extrait et du document (date, heure, auteur, etc.). | O |
Si l'extrait, qui doit être considéré comme un document comme les autres, possède déjà ces métadonnées, et qu'un document doit systématiquement être lié aux extraits qui en sont fait, cette exigence est toujours remplie. |
9.3.13
| Quand un extrait est créé, le SAE doit demander à l’utilisateur concerné d’en saisir le motif et doit conserver cette donnée dans les métadonnées de l’extrait et du document. | O |
Voir également la 9.3.14. |
Notes
- ↑ On suppose qu'il s'agit de ce type-là.
