Custom Closet Use Cases v1

Custom Closet
Fashion Designer and E-Commerce
Web Application

Date : 5thDecember 2011

Authors:

Version: 1

Status: Draft

usecasenamecustomclosetv1-111211101203-phpapp01.docx
Page 1 of 32

Document Control

Contributors

Name/Position Organization Contact Details

Fabrizio Valerio Covone DIT Fabrizio.covone@mydit.ie

Cara Murphy DIT Cara.murphy@mydit.ie

Christopher Conlan DIT Christopher.conlan@mydit.ie

Stephen Carberry DIT Stephen.carberry@mydit.ie

Shane Ellis DIT Shane.ellis@mydit.ie

Version History

Date Version Status Comments

05/12/2011 1 Draft

Changes since last version

NA

Known Omissions

NA

Approvals

Page 2 of 32

Date Name Title Signature Version

Page 3 of 32

Reviewers Comments
No comments

Page 4 of 32

Table of Contents
1 INTRODUCTION ................................................................................................................................ 6
1.1 PURPOSE OF THE DOCUMENT ......................................................................................................................6

1.2 INTENDED AUDIENCE ..................................................................................................................................6

1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS ..............................................................................................7

2 USE CASES ........................................................................................................................................ 8
2.1 LIST .........................................................................................................................................................8

2.2 UC0001 – CUSTOMER REGISTRATION ....................................................................................................... 10

3 APPENDIX....................................................................................................................................... 25
3.1 NOTE .................................................................................................................................................... 26

3.2 WHAT IS A USE-CASE? ............................................................................................................................. 26

3.3 PROCEDURE FOR CREATING A USE-CASE ...................................................................................................... 26

3.4 USE CASE STRUCTURE .............................................................................................................................. 29

Page 5 of 32

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.

Page 6 of 32

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.

Page 7 of 32

2 Use cases
2.1 List

Page 8 of 32

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.

Page 9 of 32

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.

Page 10 of 32

2.2.3 Trigger Event

Clicking on the Sign Up Button.

2.2.4 Basic Flow

Page 11 of 32

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

Page 12 of 32

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

Page 13 of 32

2.3 UC0002 – Fashion Designer Registration


Use case title FD Registration



Version 1



2.3.1 Actors

FD type user
Web Application


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.

Page 14 of 32

2.3.3 Trigger Event

Clicking on the Join Us Button.

2.3.4 Basic Flow

Page 15 of 32

2.3.5 Constraints

Ref Description




0004 Terms & Conditions: Custom Closet will keep a small percentage of the revenues of each purchase.


Page 16 of 32


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

Page 17 of 32

2.4 UC0003 – Registered Customer Profile


Use case title Registered Customer Profile



Version 1



2.4.1 Actors

RC user
Web Application


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.

Page 18 of 32

2.4.4 Trigger Event

Clicking on the Profile Button/Link.

2.4.5 Basic Flow

Page 19 of 32

2.4.6 Constraints

Ref Description





Page 20 of 32


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

Page 21 of 32

2.5 UC0004 – Fashion DesignerProfile


Use case title Fashion Designer Profile



Version 1



2.5.1 Actors

FD user
Web Application


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.

Page 22 of 32

2.5.4 Trigger Event

Clicking on the Profile Button/Link.

2.5.5 Basic Flow

Page 23 of 32

2.5.6 Constraints

Ref Description




0004 Terms & Conditions: Custom Closet will keep a small percentage of the revenues of each purchase.


Page 24 of 32


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

Page 25 of 32

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)

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)
Page 26 of 32

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)

Page 27 of 32

usecasenamecustomclosetv1-111211101203-phpapp01.docx Page 28 of 32

3.4 Use case structure
Each use case has the following narrative structure:

Page 29 of 32

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.

- 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

Page 30 of 32

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 What roles are allowed access this functionality. Are there any confidentiality,
Requirements 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-numberalpha 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 Description of any data required or stored in relation to this usecase.
requirements
For a photo graph, audio recording or video there maybe metadata such as the
time takenrecorded, location of the recordingphotovideo.

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.

Page 31 of 32

Page 32 of 32

Custom Closet Use Cases v1

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Custom Closet Use Cases v1

Ähnlich wie Custom Closet Use Cases v1 (20)

Mehr von Fabrizio Valerio Covone

Mehr von Fabrizio Valerio Covone (19)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Custom Closet Use Cases v1