My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
reunion3ModifCahier  

CahierCharge
Updated Feb 9, 2008 by pascal...@gmail.com

Pour que ca soit plus simple à lire, je vais découper ca suivant qui a demandé les modifications. A chaque fois que je parle de client, c'est Dallet, sinon c'est BLS agacé.

Intro :

client : explicité un peu mieu ce que pourra faire un graphique, notamment le fait qu'on pourra faire des opérations entre les différentes données et les représenter ensuite.

bls : donner le contexte (expliquer l'environnement, ce qu'est un can, cna etc), l'architecture et la méthode utilisée.

Matériel utilisé :

bls : tout ce qui est langage de programmation est a mettre dans besoin non fonctionnel. Sinon il faut dire sur quel plateforme devra tourner le pc, s'il y a des logiciel indispensables, des contraintes pour l'utilisation ...

diagrammes de classe :

bls :Expliquer tous les choix qui sont fait (appartenance d'un compo a un utilisateur, but de la classe autre composant, pourquoi admin et utilisateur herite d'un acteur). Utilité du Nom composant dans la classe document ou erreur ? En gros, tt doit etre expliqué.

Cas d'utilisation :

bls :

-encore une fois, expliquer un peu tout, et développer les cas d'utilisations (gérer = consulter + supprimer + modifier + ...)

- poser les verrous : insister sur le faut qu'en protégé, le document et visible mais pas lisible.

- pour la création de compte : voir si on essaye de facilité les echanges entre admin et utilisateurs, ou si c'est laissé hors de l'application (avec évaluation des risques)

- trier composants : donner la nature des criteres, ou au moins les borner.

- demander création d'un nouveau type : référence au menu déroulement a mettre dans besoin non fonctionnel, pas ici.

- administrateur : création de compte laisser a l'utilisateur = possibilité pour un casse pied de flood les mails de l'admin. Risque a évaluer. Pour la destruction des comptes, changer le actif en activé.

Besoin non fonctionnel : (a inverser avec le modele conceptuel)

Client:

- Non linearité integral = reel (pas forcement positif)

- Non linearité differentielle = reel (pas forcement positif)

- THD = réel negatif

- materiaux initiaux a ajouter : AsGa, Ge

- séparer année et mois (et evaluation des risques, si pas de mois, pas de tri fiable par date)

- url de l'equipe, lien vers documents et mois sont facultatifs.

- insister sur le fait qu'on pourra récuperer un graphique.

bls :

- fin du paragraphe 4.1.1 (pour la suite, d'autres types blabla) rien a faire ici, c'est dans le chapitre extension possible.

- expliquer mieu la gestion et suppression des comptes (avec évaluation des risques)

- préciser les formats des réels (court, long, combien de décimale ?)

- Expliquer ce qu'est un type de technologie (qui apparait 4.2.2 dans la partie de l'admin).

- pour l'acces aux fichiers, préciser que l'admin peut avoir aussi acces aux fichiers privés.

- developper le systeme de panier, et la notion de graphique.

Besoin non fonctionnel :

bls : architecture ? serveur ? nombre d'intervenant ? gestion et partage des documents ? gestion des conflits ?

Sous ensembleS et priorités d'implémentation :

bls : derniere phrase du 1er paragraphe a supp. Le 2eme paragraphe c'est de la méthodologie (a mettre en intro donc)

Informations de maintenance :

bls:

- 7.1.1 : pas clair, a expliquer.

- 7.1.2 : idem, a eclaircir (les utilisateurs externes ne peuvent pas créer de compte, l'application est utilisable de l'exterieur par des utilisateurs internes.

Autre demande et recommandation de bls:

- possibilité d'avoir des interfaces ?

- Glossaire

- Analyse du risque

- echeancier.

- Tout ce qui est vu clairement avec le client, a mettre dans besoin fonctionnel, comme ca plus de problemes de savoir si c'est notre choix qui est mauvais ou pas -> c'est la faute du client !

- possibilité d'avoir une classe d'utilisateur anonyme, ce qui permettrait la suppression de compte, en faisant passer les composants sur cet utilisateur. Si oui, gestion des verrous avec cet utilisateur, comme se passe la transition utilisateur connu vers utilisateur anonyme.

- insister sur la notion de graphique et ce qu'on veut faire. c'est pas clair d'apres lui dans le cahier actuel.

Powered by Google Project Hosting