@@ -42,4 +42,44 @@ Si une commande est refusée, elle se retransforme en un panier d'achat.
- Chaque outil/service technique qui ne peut être modélisé, comme par exemple l'envoi d'emails, doit être abstrait et une fausse mise en oeuvre doit être fournie (`FakeXXX`).
- Plus tard, un module de vérification des paiements par carte de crédit vous sera fourni. Vous pourez générer une demande de paiement à l'aide de l'identifiant de l'utilisateur et ce dernier acceptera ou non la demande de paiement selon les critères vus plus haut. La difficulté et que la réponse pourra prendre plusieurs secondes ou minutes pour être vérifiée. Vous devrez pensez à accepter d'autres demande en attendant.
- Il s'agit d'une première version. Faites ce qui est demandé. Par exemple, il n'est pas demandé explicitement de supprimer un article d'un panier. Donc répondez aux exigeances avant d'apporter des fonctionnalités qui ne sont pas prioritaires.
- Votre enseignant est votre client. Un cahier des charges n'est jamais fidèle à la vision de ce dernier. En cas de doutes, interrogez-le.
\ No newline at end of file
- Votre enseignant est votre client. Un cahier des charges n'est jamais fidèle à la vision de ce dernier. En cas de doutes, interrogez-le.
- Environement de travail
- Utilisez la cartouche et les conventions décrites plus bas
## Environement de travail ( !! sanctions importantes si non respectée !! )
- Repo git
- Utilisez le compte d'un des membres
- Le repo **DOIT S'APPELER EXACTEMENT AINSI:**`shop-online-tp`
- Il doit **être privé**
- Rajoutez M. Malandin, Kevin Heirich et moi même avec au moins un rôle de `reporter`
- Un fichier `README.md` commence avec la cartouche décrite ci-dessous et comporte les sections suivantes:
-`how to`: permet de reproduire facilement votre travail
- éventuellement des sections optionnelles comme `bugs connus` ou `fonctionnalités manquantes`
