Custom Closet
Fashion Designer and E-Commerce Web Application
Date : 8th December 2011
Authors:
Version: 4
Status: Draft
document.docx Page 1 of 61
document.docx Page 2 of 61
Document Control
Contributors
Name/Position Organization Contact Details
Fabrizio Valerio Covone DIT [email protected]
Cara Murphy DIT [email protected]
Christopher Conlan DIT [email protected]
Stephen Carberry DIT [email protected]
Shane Ellis DIT [email protected]
Version History
Date Version Status Comments
05/12/2011 1 Draft Use Cases of the first 4 Functional Modules added.
06/12/2011 2 Draft Document Recycled for Admin Profile new FM
07/12/11 3 Draft 4 New Use Cases added.
08/12/11 4 Release Candidate Added last 3 Use Cases.
Changes since last version
NA
document.docx Page 3 of 61
Known Omissions
NA
Approvals
Date Name Title Signature Version
document.docx Page 4 of 61
Reviewers Comments
No comments
document.docx Page 5 of 61
Table of Contents
DOCUMENT CONTROL ............................................................................................................................... 2
REVIEWERS COMMENTS ............................................................................................................................ 3
TABLE OF CONTENTS ................................................................................................................................. 4
1 INTRODUCTION ................................................................................................................................... 7
1.1 PURPOSE OF THE DOCUMENT..................................................................................................................7
1.2 INTENDED AUDIENCE.............................................................................................................................7
1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS...........................................................................................7
2 USE CASES ........................................................................................................................................... 8
2.1 LIST...................................................................................................................................................8
2.2 UC0001 – CUSTOMER REGISTRATION......................................................................................................9
2.2.1 ACTORS...................................................................................................................................................9
2.2.2 BRIEF DESCRIPTION....................................................................................................................................9
2.2.3 TRIGGER EVENT......................................................................................................................................10
2.2.4 BASIC FLOW...........................................................................................................................................10
2.2.5 CONSTRAINTS.........................................................................................................................................11
2.2.6 DATA MODEL AND METADATA REQUIREMENTS..............................................................................................11
2.3 UC0002 – FASHION DESIGNER REGISTRATION..........................................................................................12
2.3.1 ACTORS.................................................................................................................................................12
2.3.2 BRIEF DESCRIPTION..................................................................................................................................12
2.3.3 TRIGGER EVENT......................................................................................................................................13
2.3.4 BASIC FLOW...........................................................................................................................................13
document.docx Page 6 of 61
2.3.5 CONSTRAINTS.........................................................................................................................................14
2.3.6 DATA MODEL AND METADATA REQUIREMENTS..............................................................................................14
2.4 UC0003 – REGISTERED CUSTOMER PROFILE............................................................................................15
2.4.1 ACTORS.................................................................................................................................................15
2.4.2 BRIEF DESCRIPTION..................................................................................................................................15
2.4.3 PRE-CONDITIONS.....................................................................................................................................15
2.4.4 TRIGGER EVENT......................................................................................................................................16
2.4.5 BASIC FLOW...........................................................................................................................................16
2.4.6 CONSTRAINTS.........................................................................................................................................17
2.4.7 DATA MODEL AND METADATA REQUIREMENTS..............................................................................................17
2.5 UC0004 – FASHION DESIGNER PROFILE..................................................................................................18
2.5.1 ACTORS.................................................................................................................................................18
2.5.2 BRIEF DESCRIPTION..................................................................................................................................18
2.5.3 PRE-CONDITIONS.....................................................................................................................................18
2.5.4 TRIGGER EVENT......................................................................................................................................19
2.5.5 BASIC FLOW...........................................................................................................................................19
2.5.6 CONSTRAINTS.........................................................................................................................................20
2.5.7 DATA MODEL AND METADATA REQUIREMENTS..............................................................................................20
2.6 UC0005 – WEB ADMINISTRATOR PROFILE..............................................................................................21
2.6.1 ACTORS.................................................................................................................................................21
2.6.2 BRIEF DESCRIPTION..................................................................................................................................21
2.6.3 PRE-CONDITIONS.....................................................................................................................................21
2.6.4 TRIGGER EVENT......................................................................................................................................22
2.6.5 BASIC FLOW...........................................................................................................................................22
2.6.6 CONSTRAINTS.........................................................................................................................................23
document.docx Page 7 of 61
2.6.7 DATA MODEL AND METADATA REQUIREMENTS..............................................................................................23
2.7 UC0006 – USER LOGIN.......................................................................................................................24
2.7.1 ACTORS.................................................................................................................................................24
2.7.2 BRIEF DESCRIPTION..................................................................................................................................24
2.7.3 PRE-CONDITIONS.....................................................................................................................................24
2.7.4 TRIGGER EVENT......................................................................................................................................25
2.7.5 BASIC FLOW...........................................................................................................................................25
2.7.6 CONSTRAINTS.........................................................................................................................................26
2.7.7 DATA MODEL AND METADATA REQUIREMENTS..............................................................................................26
2.8 UC0007 – PRODUCTS GALLERY.............................................................................................................27
2.8.1 ACTORS.................................................................................................................................................27
2.8.2 BRIEF DESCRIPTION..................................................................................................................................27
2.8.3 PRE-CONDITIONS.....................................................................................................................................27
2.8.4 TRIGGER EVENT......................................................................................................................................28
2.8.5 BASIC FLOW...........................................................................................................................................28
2.8.6 DATA MODEL AND METADATA REQUIREMENTS..............................................................................................29
2.9 UC0008 – FASHION DESIGNER ENGAGEMENT..........................................................................................30
2.9.1 ACTORS.................................................................................................................................................30
2.9.2 BRIEF DESCRIPTION..................................................................................................................................30
2.9.3 PRE-CONDITIONS.....................................................................................................................................30
2.9.4 TRIGGER EVENT......................................................................................................................................31
2.9.5 BASIC FLOW...........................................................................................................................................31
2.9.6 CONSTRAINTS.........................................................................................................................................32
2.9.7 DATA MODEL AND METADATA REQUIREMENTS..............................................................................................32
2.10 UC0009 – CUSTOM PRODUCT REQUEST...............................................................................................33
document.docx Page 8 of 61
2.10.1 ACTORS...............................................................................................................................................33
2.10.2 BRIEF DESCRIPTION...............................................................................................................................33
2.10.3 PRE-CONDITIONS...................................................................................................................................33
2.10.4 TRIGGER EVENT....................................................................................................................................34
2.10.5 BASIC FLOW.........................................................................................................................................34
2.10.6 CONSTRAINTS.......................................................................................................................................35
2.11 UC0010 – SHOPPING CART...............................................................................................................36
2.11.1 ACTORS...............................................................................................................................................36
2.11.2 BRIEF DESCRIPTION...............................................................................................................................36
2.11.3 PRE-CONDITIONS...................................................................................................................................36
2.11.4 TRIGGER EVENT....................................................................................................................................37
2.11.5 BASIC FLOW.........................................................................................................................................37
2.11.6 CONSTRAINTS.......................................................................................................................................38
2.12 UC0011 – PURCHASE PROCESS..........................................................................................................39
2.12.1 ACTORS...............................................................................................................................................39
2.12.2 BRIEF DESCRIPTION...............................................................................................................................39
2.12.3 PRE-CONDITIONS...................................................................................................................................39
2.12.4 TRIGGER EVENT....................................................................................................................................40
2.12.5 BASIC FLOW.........................................................................................................................................40
2.12.6 DATA MODEL AND METADATA REQUIREMENTS............................................................................................41
2.13 UC0012 – REFUND PROCESS.............................................................................................................42
2.13.1 ACTORS...............................................................................................................................................42
2.13.2 BRIEF DESCRIPTION...............................................................................................................................42
2.13.3 PRE-CONDITIONS...................................................................................................................................42
2.13.4 TRIGGER EVENT....................................................................................................................................43
document.docx Page 9 of 61
2.13.5 BASIC FLOW.........................................................................................................................................43
2.13.6 CONSTRAINTS.......................................................................................................................................44
3 APPENDIX ......................................................................................................................................... 45
3.1 NOTE...............................................................................................................................................45
3.2 WHAT IS A USE-CASE?.........................................................................................................................45
3.3 PROCEDURE FOR CREATING A USE-CASE...................................................................................................45
3.4 USE CASE STRUCTURE..........................................................................................................................48
document.docx Page 10 of 61
1 Introduction
1.1 Purpose of the Document
This document addresses the use cases associated with the following functional modules:
Ref Name
FM-0001 Customer Registration
FM-0002 FD Registration
FM-0003 RC Profile
FM-0004 FD Profile
FM-0005 Admin Profile
FM-0006 User Log In
FM-0007 Products Gallery
FM-0008 FD Engagement
FM-0009 Custom Product Request
FM-0010 Shopping Cart
FM-0011 Purchase Process
FM-0012 Refund Process
1.2 Intended Audience
This document is a business level document intended for all project members, the project stakeholders and potential users of the system.
document.docx Page 11 of 61
1.3 Definitions, Acronyms and Abbreviations
UCD: User Centred Design
Requirements Specification: A document that describes the high level functional requirements of the system to be developed.
RC: Registered Customer.
FD: Fashion Designer.
Admin: Custom Closet’s Administrator.
document.docx Page 12 of 61
2 Use cases
2.1 List
document.docx Page 13 of 61
Ref Description
UC-0001
This is the registration process of any user who wants to buy FD’s shown products and/or engage a FD for a customized product.
UC-0002
This is the registration process that a Fashion Designer has to fulfil in order to set up his/her Personal Profile. During this process FDs have to apply to the monthly subscription.
UC-0003
This functional module is the RCs’ personal profile where FDs can manage their purchased products and rate FDs.
UC-0004
This functional module is the FDs’ personal showroom where FDs can exhibit their work and be contacted by RC.
UC-0005
This functional module is the Admin’s personal console where he/she can approve refunds and ban RCs and FDs.
UC-0006
This is the module where RCs and FDs log in in order to access their relative features.
UC-0007
In this module all FD’s products are shown and can be purchased by RCs.
UC-0008
This functionality module provides RCs to contact and engage FDs to order tailored attire.
UC-0009
RCs can customize their purchase by choosing different products by many FDs and see how they will look like on a stylized Avatar.
UC-0010
RCs can add to the shopping cart the products that they want to purchase.
UC-0011
During this process RCs will pay the products they want to purchase. After they have received their purchased products, RCs and FDs have to rate each other.
UC-0012
During this process RCs can ask for a refund, but only a Admin will decide to proceed further or to reject it.
document.docx Page 14 of 61
2.2 UC0001 – Customer Registration
Use case reference UC0001
Use case title Customer Registration
Author Fabrizio Valerio Covone
Creation Date 05/12/2011
Version 1
Last Modified by Fabrizio Valerio Covone
Date Modified 05/12/2011
2.2.1 Actors
Customer type user Web Application
2.2.2 Brief Description
This is the registration process of any user who wants to buy FD’s shown products and/or engage a FD for a customized product.
document.docx Page 15 of 61
2.2.3 Trigger Event
Clicking on the Sign Up Button.
2.2.4 Basic Flow
document.docx Page 16 of 61
2.2.5 Constraints
Ref Description
0001 Terms & Conditions: A refund is granted to the client only in case of wrong size and damaged product delivery.
0002 Terms & Conditions: Registered users whether they are Fashion Designer or Customers have to behave properly.
0003 Terms & Conditions: If a registered user (RC and/or FD) is caught behaving in an inappropriate way (e.g.: usage of bad words in rating system, spamming, etc.) by and Admin. He/she will be banned for a period of time related to the gravity of his/her actions.
2.2.6 Data model and metadata requirements
document.docx Page 17 of 61
Name Type Mandatory
Restrictions Description
Name Text Field Y Customer’s Name
Surname Text Field Y Customer’s Surname
Gender Radio Button N Customer’s Gender
Date of Birth Date Field Y DD/mm/YYYY format
Customer’s Date of Birth
Address Text Field Y Customer’s Address
Country Drop Down list Y Customer’s Country
State Drop Down list N Customer’s State (for US Residents)
Phone Number Text Field Y Customer’s Main Phone Number
Secondary Phone No.
Text Field N Customer’s Secondary Phone Number
Email Text Field Y Customer’s Email
Password Password Field Y Customer’s Password
Credit Card Type Radio Button Y Customer’s Credit Card Type
Card Number Text Field Y Customer’s Credit Card Number
Expiration Date Date Field Y Customer’s Credit Card Expiration Date
CCV Text Field Y Maximum of 4 digits
Customer’s Credit Card Verification Number
document.docx Page 18 of 61
2.3 UC0002 – Fashion Designer Registration
Use case reference UC0002
Use case title FD Registration
Author Fabrizio Valerio Covone
Creation Date 06/12/2011
Version 1
Last Modified by Fabrizio Valerio Covone
Date Modified 06/12/2011
2.3.1 Actors
FD type user Web Application
2.3.2 Brief Description
This is the registration process that a Fashion Designer has to fulfill in order to set up his/her Personal Profile. During this process FDs have to apply to the monthly subscription.
document.docx Page 19 of 61
2.3.3 Trigger Event
Clicking on the Join Us Button.
2.3.4 Basic Flow
document.docx Page 20 of 61
2.3.5 Constraints
Ref Description
0001 Terms & Conditions: A refund is granted to the client only in case of wrong size and damaged product delivery.
0002 Terms & Conditions: Registered users whether they are Fashion Designer or Customers have to behave properly.
0003 Terms & Conditions: If a registered user (RC and/or FD) is caught behaving in an inappropriate way (e.g.: usage of bad words in rating system, spamming, etc.) by and Admin. He/she will be banned for a period of time related to the gravity of his/her actions.
0004 Terms & Conditions: Custom Closet will keep a small percentage of the revenues of each purchase.
2.3.6 Data model and metadata requirements
document.docx Page 21 of 61
Name Type Mandatory
Restrictions Description
Name Text Field Y FD’s Name
Surname Text Field Y FD’s Surname
Gender Radio Button N FD’s Gender
Date of Birth Date Field Y DD/mm/YYYY format
FD’s Date of Birth
Address Text Field Y FD’s Address
Country Drop Down list Y FD’s Country
State Drop Down list N FD’s State (for US Residents)
Phone Number Text Field Y FD’s Main Phone Number
Secondary Phone No.
Text Field N FD’s Secondary Phone Number
Email Text Field Y FD’s Email
Password Password Field Y FD’s Password
Credit Card Type Radio Button Y FD’s Credit Card Type
Card Number Text Field Y FD’s Credit Card Number
Expiration Date Date Field Y FD’s Credit Card Expiration Date
CCV Text Field Y Maximum of 4 digits
FD’s Credit Card Verification Number
Subscription Type Radio Button Y FD’s Subscription Type
document.docx Page 22 of 61
2.4 UC0003 – Registered Customer Profile
Use case reference UC0003
Use case title Registered Customer Profile
Author Fabrizio Valerio Covone
Creation Date 06/12/2011
Version 1
Last Modified by Fabrizio Valerio Covone
Date Modified 06/12/2011
2.4.1 Actors
RC user Web Application
2.4.2 Brief Description
This functional module is the RCs’ personal profile where FDs can manage their purchased products and rate FDs.
2.4.3 Pre-conditions
A Registered Customer can access to this feature only after the registration process.
document.docx Page 23 of 61
2.4.4 Trigger Event
Clicking on the Profile Button/Link or redirected from Login page.
2.4.5 Basic Flow
document.docx Page 24 of 61
2.4.6 Constraints
Ref Description
0001 Terms & Conditions: A refund is granted to the client only in case of wrong size and damaged product delivery.
0002 Terms & Conditions: Registered users whether they are Fashion Designer or Customers have to behave properly.
0003 Terms & Conditions: If a registered user (RC and/or FD) is caught behaving in an inappropriate way (e.g.: usage of bad words in rating system, spamming, etc.) by and Admin. He/she will be banned for a period of time related to the gravity of his/her actions.
2.4.7 Data model and metadata requirements
document.docx Page 25 of 61
Name Type Mandatory
Restrictions Description
Name Text Field Y Customer’s Name
Surname Text Field Y Customer’s Surname
Gender Radio Button N Customer’s Gender
Date of Birth Date Field Y DD/mm/YYYY format
Customer’s Date of Birth
Address Text Field Y Customer’s Address
Country Drop Down list Y Customer’s Country
State Drop Down list N Customer’s State (for US Residents)
Phone Number Text Field Y Customer’s Main Phone Number
Secondary Phone No.
Text Field N Customer’s Secondary Phone Number
Email Text Field Y Customer’s Email
Password Password Field Y Customer’s Password
Credit Card Type Radio Button Y Customer’s Credit Card Type
Card Number Text Field Y Customer’s Credit Card Number
Expiration Date Date Field Y Customer’s Credit Card Expiration Date
CCV Text Field Y Maximum of 4 digits
Customer’s Credit Card Verification Number
document.docx Page 26 of 61
2.5 UC0004 – Fashion Designer Profile
Use case reference UC0004
Use case title Fashion Designer Profile
Author Fabrizio Valerio Covone
Creation Date 06/12/2011
Version 1
Last Modified by Fabrizio Valerio Covone
Date Modified 06/12/2011
2.5.1 Actors
FD user Web Application
2.5.2 Brief Description
This functional module is the FDs’ personal showroom where FDs can exhibit their work and be contacted by RC.
2.5.3 Pre-conditions
A Fashion Designer can access to this feature only after the registration process.
document.docx Page 27 of 61
2.5.4 Trigger Event
Clicking on the Profile Button/Link or redirected from Login page.
2.5.5 Basic Flow
document.docx Page 28 of 61
2.5.6 Constraints
Ref Description
0001 Terms & Conditions: A refund is granted to the client only in case of wrong size and damaged product delivery.
0002 Terms & Conditions: Registered users whether they are Fashion Designer or Customers have to behave properly.
0003 Terms & Conditions: If a registered user (RC and/or FD) is caught behaving in an inappropriate way (e.g.: usage of bad words in rating system, spamming, etc.) by and Admin. He/she will be banned for a period of time related to the gravity of his/her actions.
0004 Terms & Conditions: Custom Closet will keep a small percentage of the revenues of each purchase.
2.5.7 Data model and metadata requirements
document.docx Page 29 of 61
Name Type Mandatory
Restrictions Description
Name Text Field Y FD’s Name
Surname Text Field Y FD’s Surname
Gender Radio Button N FD’s Gender
Date of Birth Date Field Y DD/mm/YYYY format
FD’s Date of Birth
Address Text Field Y FD’s Address
Country Drop Down list Y FD’s Country
State Drop Down list N FD’s State (for US Residents)
Phone Number Text Field Y FD’s Main Phone Number
Secondary Phone No.
Text Field N FD’s Secondary Phone Number
Email Text Field Y FD’s Email
Password Password Field Y FD’s Password
Credit Card Type Radio Button Y FD’s Credit Card Type
Card Number Text Field Y FD’s Credit Card Number
Expiration Date Date Field Y FD’s Credit Card Expiration Date
CCV Text Field Y Maximum of 4 digits
FD’s Credit Card Verification Number
Subscription Type Radio Button Y FD’s Subscription Type
document.docx Page 30 of 61
2.6 UC0005 – Web Administrator Profile
Use case reference UC0005
Use case title Web Administrator Profile
Author Fabrizio Valerio Covone
Creation Date 06/12/2011
Version 1
Last Modified by Fabrizio Valerio Covone
Date Modified 06/12/2011
2.6.1 Actors
Admin user Web Application
2.6.2 Brief Description
This functional module is the Admin’s personal console where he/she can approve refunds and ban RCs and FDs.
2.6.3 Pre-conditions
Only a registered employee of Custom Closet can access to this feature.
document.docx Page 31 of 61
2.6.4 Trigger Event
Clicking on the Profile Button/Link or redirected from Login page.
2.6.5 Basic Flow
document.docx Page 32 of 61
2.6.6 Constraints
Ref Description
0001 Terms & Conditions: A refund is granted to the client only in case of wrong size and damaged product delivery.
0002 Terms & Conditions: Registered users whether they are Fashion Designer or Customers have to behave properly.
0003 Terms & Conditions: If a registered user (RC and/or FD) is caught behaving in an inappropriate way (e.g.: usage of bad words in rating system, spamming, etc.) by and Admin. He/she will be banned for a period of time related to the gravity of his/her actions.
2.6.7 Data model and metadata requirements
Name Type Mandatory
Restrictions Description
Name Text Field Y Admin’s Name
Surname Text Field Y Admin’s Surname
Gender Radio Button N Admin’s Gender
Date of Birth Date Field Y DD/mm/YYYY format
Admin’s Date of Birth
Password Password Field Y Admin’s Password
document.docx Page 33 of 61
2.7 UC0006 – User Login
Use case reference UC0006
Use case title User Login
Author Fabrizio Valerio Covone
Creation Date 07/12/2011
Version 1
Last Modified by Fabrizio Valerio Covone
Date Modified 07/12/2011
2.7.1 Actors
Customer type user Fashion Designer user type Web Administrator user type Web Application
2.7.2 Brief Description
This is the module where RCs, FDs and Admins log in in order to access their relative features and profiles.
2.7.3 Pre-conditions
In order to complete the Log In process properly, a user has to be registered to Custom Closet.
document.docx Page 34 of 61
2.7.4 Trigger Event
Clicking on the Log In Button.
2.7.5 Basic Flow
document.docx Page 35 of 61
2.7.6 Constraints
Ref Description
0001 Terms & Conditions: A refund is granted to the client only in case of wrong size and damaged product delivery.
0002 Terms & Conditions: Registered users whether they are Fashion Designer or Customers have to behave properly.
0003 Terms & Conditions: If a registered user (RC and/or FD) is caught behaving in an inappropriate way (e.g.: usage of bad words in rating system, spamming, etc.) by and Admin. He/she will be banned for a period of time related to the gravity of his/her actions.
2.7.7 Data model and metadata requirements
Name Type Mandatory
Restrictions Description
Email Text Field Y User’s Email
Password Password Field Y User’s Password
document.docx Page 36 of 61
2.8 UC0007 – Products Gallery
Use case reference UC0007
Use case title Products Gallery
Author Fabrizio Valerio Covone
Creation Date 07/12/2011
Version 1
Last Modified by Fabrizio Valerio Covone
Date Modified 07/12/2011
2.8.1 Actors
Guest user type Registered Customer user type Fashion Designer user type Web Application
2.8.2 Brief Description
In this module all FD’s products are shown and can be purchased by RCs.
2.8.3 Pre-conditions
In order to access to the features “Add to The Shopping Cart” and “Fit it on your Avatar” features a customer has to be registered.
document.docx Page 37 of 61
2.8.4 Trigger Event
Clicking on the Gallery Button.
2.8.5 Basic Flow
document.docx Page 38 of 61
2.8.6 Data model and metadata requirements
Name Type Mandatory
Restrictions Description
Name Text Field N Product’s Name
FD Name Text Field N Product’s Fashion Designer Name
Colour Drop Down List
N Product’s Colour
Price Range Radio Button N Product’s Price Range
Type Drop Down List
N Product’s Type of Clothing
Fashion Season Drop Down List
N Product’s Fashion Season
document.docx Page 39 of 61
2.9 UC0008 – Fashion Designer Engagement
Use case reference UC0008
Use case title Fashion Designer Engagement
Author Fabrizio Valerio Covone
Creation Date 07/12/2011
Version 1
Last Modified by Fabrizio Valerio Covone
Date Modified 07/12/2011
2.9.1 Actors
Registered Customer user type Fashion Designer user type Web Application
2.9.2 Brief Description
This functionality module provides RCs to contact and engage FDs to order tailored attire.
2.9.3 Pre-conditions
In order to access to this feature a Customer has to be Registered, while a FD has to be Registered and Active.
document.docx Page 40 of 61
2.9.4 Trigger Event
RC point of view:
Clicking on the Ask for an Engagement in RC’s Profile.
FD Point of view:
Clicking on Manage Engagement in FD’s Profile.
2.9.5 Basic Flow
document.docx Page 41 of 61
2.9.6 Constraints
Ref Description
0001 Terms & Conditions: A refund is granted to the client only in case of wrong size and damaged product delivery.
0002 Terms & Conditions: Registered users whether they are Fashion Designer or Customers have to behave properly.
0003 Terms & Conditions: If a registered user (RC and/or FD) is caught behaving in an inappropriate way (e.g.: usage of bad words in rating system, spamming, etc.) by and Admin. He/she will be banned for a period of time related to the gravity of his/her actions.
0004 Terms & Conditions: Custom Closet will keep a small percentage of the revenues of each purchase.
2.9.7 Data model and metadata requirements
See Chapters 2.4.7 and 2.5.7.
document.docx Page 42 of 61
2.10 UC0009 – Custom Product Request
Use case reference UC0009
Use case title Custom Product Request
Author Fabrizio Valerio Covone
Creation Date 07/12/2011
Version 1
Last Modified by Fabrizio Valerio Covone
Date Modified 07/12/2011
2.10.1 Actors
Registered Customer user type Web Application
2.10.2 Brief Description
RCs can customize their purchase by choosing different products by many FDs and see how they will look like on a stylized Avatar.
2.10.3 Pre-conditions
In order to access to this feature a Customer has to be Registered.
document.docx Page 43 of 61
2.10.4 Trigger Event
Clicking on the Fit on Avatar.
2.10.5 Basic Flow
document.docx Page 44 of 61
2.10.6 Constraints
Ref Description
0001 Terms & Conditions: A refund is granted to the client only in case of wrong size and damaged product delivery.
0002 Terms & Conditions: Registered users whether they are Fashion Designer or Customers have to behave properly.
0003 Terms & Conditions: If a registered user (RC and/or FD) is caught behaving in an inappropriate way (e.g.: usage of bad words in rating system, spamming, etc.) by and Admin. He/she will be banned for a period of time related to the gravity of his/her actions.
0004 Terms & Conditions: Custom Closet will keep a small percentage of the revenues of each purchase.
document.docx Page 45 of 61
2.11 UC0010 – Shopping Cart
Use case reference UC0010
Use case title Shopping Cart
Author Fabrizio Valerio Covone
Creation Date 08/12/2011
Version 1
Last Modified by Fabrizio Valerio Covone
Date Modified 08/12/2011
2.11.1 Actors
Registered Customer type user Web Application
2.11.2 Brief Description
RCs can add to the shopping cart the products that they want to purchase.
2.11.3 Pre-conditions
In order to access this feature a user has to be registered to Custom Closet.
document.docx Page 46 of 61
2.11.4 Trigger Event
Clicking on the Shopping Cart button.
2.11.5 Basic Flow
document.docx Page 47 of 61
2.11.6 Constraints
Ref Description
0001 Terms & Conditions: A refund is granted to the client only in case of wrong size and damaged product delivery.
0002 Terms & Conditions: Registered users whether they are Fashion Designer or Customers have to behave properly.
0003 Terms & Conditions: If a registered user (RC and/or FD) is caught behaving in an inappropriate way (e.g.: usage of bad words in rating system, spamming, etc.) by and Admin. He/she will be banned for a period of time related to the gravity of his/her actions.
document.docx Page 48 of 61
2.12 UC0011 – Purchase Process
Use case reference UC0011
Use case title Purchase Process
Author Fabrizio Valerio Covone
Creation Date 08/12/2011
Version 1
Last Modified by Fabrizio Valerio Covone
Date Modified 08/12/2011
2.12.1 Actors
Registered Customer user type Fashion Designer user type Web Application
2.12.2 Brief Description
During this process RCs will pay the products they want to purchase. After they have received their purchased products, RCs and FDs have to rate each other.
2.12.3 Pre-conditions
In order to access to this feature a Customer has to be registered and there should be at least one product in his/her Shopping cart.
document.docx Page 49 of 61
2.12.4 Trigger Event
Clicking on the Buy Now Button.
2.12.5 Basic Flow
document.docx Page 50 of 61
2.12.6 Data model and metadata requirements
Name Type Mandatory
Restrictions Description
Name Text Field Y Customer’s Name
Surname Text Field Y Customer’s Surname
Gender Radio Button N Customer’s Gender
Date of Birth Date Field Y DD/mm/YYYY format
Customer’s Date of Birth
Address Text Field Y Customer’s Address
Country Drop Down list Y Customer’s Country
State Drop Down list N Customer’s State (for US Residents)
Phone Number Text Field Y Customer’s Main Phone Number
Secondary Phone No.
Text Field N Customer’s Secondary Phone Number
Email Text Field Y Customer’s Email
Password Password Field Y Customer’s Password
Credit Card Type Radio Button Y Customer’s Credit Card Type
Card Number Text Field Y Customer’s Credit Card Number
Expiration Date Date Field Y Customer’s Credit Card Expiration Date
CCV Text Field Y Maximum of 4 digits
Customer’s Credit Card Verification Number
document.docx Page 51 of 61
2.13 UC0012 – Refund Process
Use case reference UC0012
Use case title Refund Process
Author Fabrizio Valerio Covone
Creation Date 08/12/2011
Version 1
Last Modified by Fabrizio Valerio Covone
Date Modified 08/12/2011
2.13.1 Actors
Registered Customer user type Fashion Designer user type Web Application
2.13.2 Brief Description
During this process RCs can ask for a refund, but only a Admin will decide to proceed further or to reject it.
2.13.3 Pre-conditions
In order to access to this feature a Customer has to have purchased at least one product.
document.docx Page 52 of 61
2.13.4 Trigger Event
Clicking on the Ask for a Refund.
2.13.5 Basic Flow
document.docx Page 53 of 61
2.13.6 Constraints
Ref Description
0001 Terms & Conditions: A refund is granted to the client only in case of wrong size and damaged product delivery.
0002 Terms & Conditions: Registered users whether they are Fashion Designer or Customers have to behave properly.
0003 Terms & Conditions: If a registered user (RC and/or FD) is caught behaving in an inappropriate way (e.g.: usage of bad words in rating system, spamming, etc.) by and Admin. He/she will be banned for a period of time related to the gravity of his/her actions.
0004 Terms & Conditions: Custom Closet will keep a small percentage of the revenues of each purchase.
document.docx Page 54 of 61
3 Appendix
3.1 Note
This appendix would not be in every use case. An appendix in a use case contains additional information and artifact examples that might be use full in describing or understanding the usage scenario.
3.2 What is a use-case?
Use-cases are an unfolding story that describes the functions in a system and the usage paths through them. They are essentially narrative descriptions with diagrams and example screens. Their purpose is to describe in the simplest possible terms how the proposed system would be used.
Use-cases document the accomplishment of a single task by the user.
The use cases illustrate the functionality of the system in terms of the business processes the system is being built to support. Use cases describe how it is envisioned users of the system (actors) would perform tasks such as login, change settings, and enter a particular type of data.
3.3 Procedure for creating a use-case
The diagram below illustrates the process by which each use case is created. Basically it is an iterative process where the business function required is considered from a number of different perspectives which can be summarized as : CRUD-SPARP.
For example in a use case area like add a moodle site to the site list the analyst asks themselves how will I :
Create a Site (Create)
Review site details e.g. URL, Username – are there different views (Review)
Correct site details (Update)
Delete or Retire a site from use (Delete)
document.docx Page 55 of 61
Search for a site on the site list (Search)
Print a sites details, a list of sites – are there different print styles (Print)
Archive or backup the site list e.g. send to dropbox (Archive)
Generate a report on all sites e.g. how frequently are they accessed (Report)
Publish \ Export \ Import e.g. send the list to twitter, facebook or a website (Publish)
All of the above are self contained functionality within a module. But what are the reporting requirements of this module in relation to other modules in the system – are there lookup to other modules, what cross system reports are executed within this module or involve this module (Report across system)
document.docx Page 56 of 61
document.docx Page 57 of 61
3.4 Use case structure
Each use case has the following narrative structure:
document.docx Page 58 of 61
Ref Heading Description
Actors Who performs the process described in the use case
Brief Description A description of the use case being specified with an overview diagram of the process.
What is the goal of this use case, what is the objective of the user.
User Interface A wire frame diagram of the main screens and dialogs presented to the user as they execute the use case. This is only used where appropriate. Its purpose is to provide a visual aid to the reader as to the functionality available.
The user interface in this case is used to help explain the proposed functionality. As user experience designers get involved the UI may change and even use cases may disappear.
Including a mock up user interface can however drive out issues as to what data needs to be displayed and if data is to be entered how it is validated. This information then helps the design of the data model.
User Interface description A description of the user interface components and their functions
Trigger Event What event or action triggers this use case
Flow of Events
- Basic Flow A description of the main process where each step is referenced by a number. A flow, state or sequence diagram may also be added to explain the process.
- Alternative Flow The basic flow describes how the process would be executed in 90% of the cases i.e. where no error has occurred or where no business rule exceptions occur.
The alternate flows concern the business logic applied to a basic flow. For instance the basic flow could be for to enter a URL, username and password. Access to the moodle site is checked and the site is added.
Alternative flows may describe situations where there is an error in the input data, the site cannot be reached etc.
Non-functional Requirements
This section only contains content if it is specific to that particular use case not the system as a whole.
- Usability A particular usability requirement. For instance command line functionality required, quick key, must be able to select all and deselect a list, or deselect all and select a list etc.
- Reliability A particular reliability requirement. For instance no site should be stored unless connection to the site has been established at least once.
document.docx Page 59 of 61
- Performance Minimum performance requirements. For instance the system should respond report an issue with uploading within 10 seconds and ask if the user wants to continue or wait until they have a WiFi connection.
- Supportability What support/debug features need to be provided for this process.
Artefacts What is created, updated or deleted as a result of this business process
Pre-conditions This section outlines the Pre-conditions prior to the execution of the basic flow. For instance there must be at least one valid site in the site list before the main functionality of the moodle app can be accessed.
Assumptions may also be expressed here
Ref Heading Description
Post-Conditions How must the system or user interface be left after the execution of the basic flow.
Authorization and Audit Requirements
What roles are allowed access this functionality. Are there any confidentiality, auditor logging requirements.
Business Rules Business rules referenced within the basic or alternative flows. For instance theire may be rules as to what constitutes a valid password e.g. One capital letter, One number, one non-number\alpha character where the password has not been used before in the last 6 months..
Issues Any potential issues identified which may cause problems in the deployment of this use case functionality.
Assumptions What assumptions have been made e.g. a wifi network connection is available as opposed to an Edge or 3G connection
Constraints Are there scheduling constraints, legal constraints, accessibility constraints, environment constraints
Data model and metadata requirements
Description of any data required or stored in relation to this use case.
For a photo graph, audio recording or video there maybe metadata such as the time taken\recorded, location of the recording\photo\video.
The focus is a business description of the data rather than a technical description of the data. For instance a use case may require a drop known list of participant types – administrator, teacher, student, reviewer they would be mentioned here
If there was a particular XML format for publishing the site list to twitter or facebook then the specification or definition would be mentioned here.
document.docx Page 60 of 61
document.docx Page 61 of 61