Download - Custom Closet Use Cases v2

Custom Closet

Fashion Designer and E-Commerce Web Application

Date : 6th December 2011

Authors:

Version: 2

Status: Draft

document.docx of 38

document.docx of 38

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

Changes since last version

NA

Known Omissions

NAdocument.docx of 38

mailto:[email protected]





Approvals

Date Name Title Signature Version

document.docx of 38

Reviewers Comments

No comments

document.docx of 38

Table of Contents

DOCUMENT CONTROL ............................................................................................................................... 2

REVIEWERS COMMENTS ............................................................................................................................ 3

TABLE OF CONTENTS ................................................................................................................................. 4

1 INTRODUCTION ................................................................................................................................... 6

1.1 PURPOSE OF THE DOCUMENT..................................................................................................................6

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

1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS...........................................................................................6

2 USE CASES ........................................................................................................................................... 7

2.1 LIST...................................................................................................................................................7

2.2 UC0001 – CUSTOMER REGISTRATION......................................................................................................8

2.2.1 ACTORS...................................................................................................................................................8

2.2.2 BRIEF DESCRIPTION....................................................................................................................................8

2.2.3 TRIGGER EVENT........................................................................................................................................9

2.2.4 BASIC FLOW.............................................................................................................................................9

2.2.5 CONSTRAINTS.........................................................................................................................................10

2.2.6 DATA MODEL AND METADATA REQUIREMENTS..............................................................................................10

2.3 UC0002 – FASHION DESIGNER REGISTRATION..........................................................................................11

2.3.1 ACTORS.................................................................................................................................................11

2.3.2 BRIEF DESCRIPTION..................................................................................................................................11

2.3.3 TRIGGER EVENT......................................................................................................................................12

2.3.4 BASIC FLOW...........................................................................................................................................12

document.docx of 38

2.3.5 CONSTRAINTS.........................................................................................................................................13


2.4 UC0003 – REGISTERED CUSTOMER PROFILE............................................................................................14

2.4.1 ACTORS.................................................................................................................................................14


2.4.3 PRE-CONDITIONS.....................................................................................................................................14

2.4.4 TRIGGER EVENT......................................................................................................................................15

2.4.5 BASIC FLOW...........................................................................................................................................15

2.4.6 CONSTRAINTS.........................................................................................................................................16


2.5 UC0004 – FASHION DESIGNER PROFILE..................................................................................................17

2.5.1 ACTORS.................................................................................................................................................17


2.5.3 PRE-CONDITIONS.....................................................................................................................................17

2.5.4 TRIGGER EVENT......................................................................................................................................18

2.5.5 BASIC FLOW...........................................................................................................................................18

2.5.6 CONSTRAINTS.........................................................................................................................................19


2.6 UC0005 – WEB ADMINISTRATOR PROFILE..............................................................................................20

2.6.1 ACTORS.................................................................................................................................................20


2.6.3 PRE-CONDITIONS.....................................................................................................................................20

2.6.4 TRIGGER EVENT......................................................................................................................................21

2.6.5 BASIC FLOW...........................................................................................................................................21

2.6.6 CONSTRAINTS.........................................................................................................................................22

document.docx of 38


3 APPENDIX ......................................................................................................................................... 23

3.1 NOTE...............................................................................................................................................23

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

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

3.4 USE CASE STRUCTURE..........................................................................................................................26

document.docx of 38

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 of 38

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 of 38

2 Use cases

2.1 List

document.docx of 38

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 of 38

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 of 38

2.2.3 Trigger Event

Clicking on the Sign Up Button.

2.2.4 Basic Flow

document.docx of 38

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 of 38

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 of 38

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.

document.docx of 38

2.3.3 Trigger Event

Clicking on the Join Us Button.

2.3.4 Basic Flow

document.docx of 38

2.3.5 Constraints

Ref Description




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


document.docx of 38

Name Type Mandatory


Name Text Field Y FD’s Name

Surname Text Field Y FD’s Surname

Gender Radio Button N FD’s Gender


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


FD’s Credit Card Verification Number

Subscription Type Radio Button Y FD’s Subscription Type

document.docx of 38

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.

document.docx of 38

2.4.4 Trigger Event

Clicking on the Profile Button/Link or redirected from Login page.

2.4.5 Basic Flow

document.docx of 38

2.4.6 Constraints

Ref Description





document.docx of 38

Name Type Mandatory


Name Text Field Y Customer’s Name

Surname Text Field Y Customer’s Surname

Gender Radio Button N Customer’s Gender


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


Customer’s Credit Card Verification Number

document.docx of 38

2.5 UC0004 – Fashion Designer Profile


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.


A Fashion Designer can access to this feature only after the registration process.

document.docx of 38

2.5.4 Trigger Event


2.5.5 Basic Flow

document.docx of 38

2.5.6 Constraints

Ref Description




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


document.docx of 38

Name Type Mandatory


Name Text Field Y FD’s Name

Surname Text Field Y FD’s Surname

Gender Radio Button N FD’s Gender


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


FD’s Credit Card Verification Number

Subscription Type Radio Button Y FD’s Subscription Type

document.docx of 38

2.6 UC0005 – Web Administrator Profile


Use case title Web Administrator Profile



Version 1



2.6.1 Actors

Admin user Web Application


This functional module is the Admin’s personal console where he/she can approve refunds and ban RCs and FDs.


Only a registered employee of Custom Closet can access to this feature.

document.docx of 38

2.6.4 Trigger Event


2.6.5 Basic Flow

document.docx of 38

2.6.6 Constraints

Ref Description





Name Type Mandatory


Name Text Field Y Admin’s Name

Surname Text Field Y Admin’s Surname

Gender Radio Button N Admin’s Gender


Admin’s Date of Birth

Password Password Field Y Admin’s Password

document.docx of 38

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 of 38

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 of 38

document.docx of 38

3.4 Use case structure

Each use case has the following narrative structure:

document.docx of 38

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 of 38

- 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 of 38

document.docx of 38