custom closet use cases v1
DESCRIPTION
TRANSCRIPT
Custom Closet
Fashion Designer and E-Commerce Web Application
Date : 5th December 2011
Authors:
Version: 1
Status: Draft
document.docx Page 1 of 33
document.docx Page 2 of 33
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
Changes since last version
NA
Known Omissions
NA
Approvals
document.docx Page 3 of 33
Date Name Title Signature Version
document.docx Page 4 of 33
Reviewers Comments
No comments
document.docx Page 5 of 33
Table of Contents
1 INTRODUCTION......................................................................................................................5
1.1 PURPOSE OF THE DOCUMENT........................................................................................................5
1.2 INTENDED AUDIENCE...................................................................................................................5
1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS................................................................................5
2 USE CASES..............................................................................................................................6
2.1 LIST..........................................................................................................................................6
2.2 UC0001 – CUSTOMER REGISTRATION............................................................................................7
3 APPENDIX.............................................................................................................................10
3.1 NOTE......................................................................................................................................10
3.2 WHAT IS A USE-CASE?...............................................................................................................10
3.3 PROCEDURE FOR CREATING A USE-CASE.........................................................................................10
3.4 USE CASE STRUCTURE................................................................................................................13
document.docx Page 6 of 33
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 7 of 33
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 8 of 33
2 Use cases
2.1 List
document.docx Page 9 of 33
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 n 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.
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 10 of 33
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 11 of 33
2.2.3 Trigger Event
Clicking on the Sign Up Button.
2.2.4 Basic Flow
document.docx Page 12 of 33
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 13 of 33
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 14 of 33
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 15 of 33
2.3.3 Trigger Event
Clicking on the Join Us Button.
2.3.4 Basic Flow
document.docx Page 16 of 33
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 17 of 33
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 18 of 33
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 19 of 33
2.4.4 Trigger Event
Clicking on the Profile Button/Link.
2.4.5 Basic Flow
document.docx Page 20 of 33
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 21 of 33
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 22 of 33
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 23 of 33
2.5.4 Trigger Event
Clicking on the Profile Button/Link.
2.5.5 Basic Flow
document.docx Page 24 of 33
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 25 of 33
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 26 of 33
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 27 of 33
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 28 of 33
document.docx Page 29 of 33
3.4 Use case structure
Each use case has the following narrative structure:
document.docx Page 30 of 33
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 31 of 33
- 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 32 of 33
document.docx Page 33 of 33