Requirements and Specification
Rev 1.0 2019-10-05 - initial version
WearHouse is organized and easily understandable database system of clothing which allows users to keep track of what they own, what they have worn, what their likes/dislikes are. It will free users from the burden of choosing an appropriate outfit on a daily basis. It also gives useful information when user is shopping. Using WearHouse, user can figure out whether they have some clothing at home to match with the new one to buy, or similar clothing so that they don’t have to buy one. Unlike pre existing personal clothing database services where users strictly follow predefined and fixed category, WearHouse automatically detect basic category for each clothing and allow user to generate user-defined tags for further identification. Due to tag based system saving and searching is easy and simple. Additionally, WearHouse asks users’ satisfaction on each outfit and using that satisfaction index and weather information, recommends users outfit afterwards. WearHouse will make users feel his/her emotion and history concerning outfit is being taken care of.
In general, people who want to record their outfit history with tags for each item. They can check how frequently they wear specific clothing or outfits. Specifically, we expect people who want to know when they wear specific clothing, what combination of clothing they frequently use and in which weather they wear their favorite clothing and outfits to use our service. They can also record their satisfaction score for that day and remind it later. Competitive Landscape
-
Your Closet
- Categories for outfit and item(specific clothing) are separated
- When user save outfit, they cannot newly add one but should combine items which have already been saved.
- First page of service is just list of categories.
- It supports browsing through 'Calendar tab' but users can hardly identify each item due to tiny size of cell for each day.
-
Smart Closet
- User should separate outfit and item(specific clothing).
- On each save user should manually designate the outfit to a specific predefined fixed category
- These categories are overly specific and too verbose
- User cannot search for a certain clothing/outfit, only browsing list is available.
- User can follow other users’ look-book but cannot express '좋아요' or make any comments. No communication is allowed
-
내옷장 - 내일 뭐 입지?
- Can generate numerous closets for grouping several clothings on specific purpose.
- Hard to manage integrated closet.
- Can publically share certain closet to other users.
- Can get recommendation about style coordination from others on ‘Coordi community tab’.
-
High degree of freedom
- Rather than following predefined and fixed category tag, user can generate any tag, more appropriate for identifying each clothing.
- User can search clothing based on tags. (Competitive services do not support even search feature. Should access each item only by selecting category and specific classifications in series.)
-
Simplicity - lower user workload
- Do not separate outfit and clothing
- Only one outfit closet exists.
- On saving, simple and basic categories are automatically imported by ML.
-
Intuitive UI
- First page of service is outfit feed composed of photos in chronological order, from the most recent to oldest.
- (Optional) Support Calendar tab for browsing outfit - satisfaction history.
- User can access specific outfit data worn on that day by clicking emoji.
- Single data type(outfit), Single page for saving, Single page for browsing outfit
-
User customized recommendation
- WearHouse get satisfaction index from users on each outfit data.
- Based on satisfaction index and weather information, WearHouse recommend certain user’s outfit.
- Aim user feel his/her emotion and history concerning outfit is being taken care of.
- Pre-existing services automatically recommend external clothing from shopping malls (aiming ad effect) or
- other users’ recommend based on others’ taste. Taste of user is not reflected.
- Outfit: A full look (OOTD), or a photo of a full look. Standard unit of database entry
- Clothing/Item: Individual parts that make up an outfit. Can be classified into categories. Is denoted by a specific tag/category combination
- Tags: Denotes specific information about clothing. There are 3 basic tag slots for each item: category, color, and user-defined.
- Categories: Special type of tag that denotes type of clothing (e.g. Top, Bottom, Outerwear, Shoes, etc.)
Feature: Log in
Actor: Those who want to use the ‘WearHouse’ service
Precondition: User has signed up before, but has not logged in yet & is in the Login/Sign up screen.
Scenario:
- When user enters website, system displays log-in screen.
- User inputs id and password
- System checks inputs for validation.
- If either id or password is wrong, error message pops up and user returns to log-in page.
- If id and password are both correct, the user is redirected to the main page.
Feature: Sign up
Actor: Those who want to use the ‘WearHouse’ service
Precondition: User does not have an account yet & is in the Login/Sign up screen
Scenario:
- User clicks the ‘sign in’ button on the bottom of log-in page.
- User is redirected to the sign in page.
- User can click on social login (facebook / google) to use social media accounts or ‘create account’ to create a new account
- If the user clicks on ‘create account’ they are redirected to a sign-in form page and asked to fill in a form with necessary login credentials
- When they have provided satisfactory login credentials, user may click on the ‘create account’ button
- User is redirected to the login page, and a new account is created
Exceptions:
- The provided social login credentials are already linked to another account
- User exits without finishing the process
Acceptance Test:
- Given that the user has provided satisfactory login credentials (i.e. proper id and password / owns social media account in case of social login)
- When the user clicks on create account/social login button
- Then the system should create a new user entry in the database associated with the login credentials provided
(All features/stories from this point onward require the user to be logged in as a precondition)
Feature : Upload outfit information
Actor : Those who want to upload a new outfit entry
Precondition : User owns a photo that they want to upload
Trigger: User clicks on the ‘upload’ button
Scenario:
- System shows a ‘choose photo’ pop-up, user chooses and uploads a photo from file system.
- When the user is satisfied with the choice, they click the ‘confirm’ button to move to the next screen
- System runs the photo through an ML API(Mirror That Look API) to detect and generate appropriate categories for each clothing item
- When the user is not satisfied with how each clothing items have been categorized by the API (ex. Trouser has been categorized as top), the user can add to or edit the categories.
- User clicks on each item to display the tag input bar
- User types in desired tagging information (user may add up to 3 tags (color / style / user-defined) to each individual item)
- System provides a list of autocomplete options based on tag combinations (items) that are previously uploaded to the database. User may choose one from the list(existing item), or create a new combination(new item).
- When satisfied with the upload information, user clicks on the ‘publish’ button to upload the outfit to the database.
- User is redirected to the ‘browse’ page where they can see the reflected changes
Exceptions:
- User does not finish uploading the photo / outfit categories / item tags
Acceptance Test:
- Given that the user has successfully uploaded a photo of an outfit
- Then the API will successfully detect and generate the appropriate category (top/bottom/shoes) for each clothing item.
- When the user is not satisfied with the categorization results, the user can edit the category as seen fit.
- Then the user can input tags for each categorized clothing item.
- When the user clicks on the ‘Publish’ button, the outfit data is uploaded to the database
- Then the user may view the uploaded data from the ‘browse’ or ‘search’ features
Feature : Delete an outfit entry
Actor : Those who want to delete certain outfit entry from WearHouse database
Precondition : User has uploaded one or more outfit entries in the database, user is on the detail page of the to-be deleted item
Trigger : User clicks the ‘delete’ button
Scenario :
- User clicks the ‘delete’ button
- A system pop-up confirming delete appears, informs the user that deletion is final
- If the user confirms the delete, the entry is removed from the database and the user is redirected to the ‘browse’ page
Exception :
- User does not finish deletion/cancels out of deletion
Acceptance Test:
- Given that the user is on the detail page of an outfit to be deleted
- When the user clicks on the delete button
- Then the outfit entry is deleted from the database, and cannot be further queried or viewed from other screens
Feature: Save satisfaction data
Actor: Those who reflect their activity with specific outfit
Precondition : User has uploaded the outfit data composed of photo and user-defined / system-defined tags, and has not logged the satisfaction data yet
Scenario:
- System prompt (pop-up) appears and asks the user how satisfied they were with their outfit today
- User selects their level of satisfaction from a given list of options (5-point Likert scale, ‘Not at all’ to ‘Extremely satisfactory’)
- System logs the satisfaction data to the day’s outfit Exceptions:
- User closes the popup without answering Acceptance Test
- Given that the user has selected an option for satisfaction on an outfit
- Then save their satisfaction score for that specific outfit of the day
- Then the user may view the satisfaction score in the ‘browse’ tab
Feature: Browse my outfit history/feed
Actor: Those who want an overview of their previous outfit history
Precondition: User has already uploaded some outfit data to the system
Scenario:
- Screen displays a grid of all the uploaded and saved outfit photos in chronological order, from the most recent to oldest, as well as a search bar.
- User may click on an outfit photo to view details or click on the search bar to search items Acceptance Test:
- Given that the user has previously uploaded one or more outfits to the system
- Then the browse tab must show all of the uploaded outfits in the database
Feature: Search my outfit history by tag
Actor: Those who wants to search for a particular outfit
Precondition : User needs to have had previously uploaded outfit data to the database
Trigger: Enter search page
Scenario:
- Screen displays a search bar (text input) and search button
- User types in a search query (tag)
- System provides a list of autocomplete options according to the pre-existing tags in the database
- User selects a tag from the autocomplete list
- Repeat 2~4 as necessary
- User clicks on the ‘search’ button / presses ‘Enter/Return’ key
Acceptance Test:
- Given that the user has typed in one or more search query to the search bar
- When the user clicks on the ‘search’ button / presses ‘Enter/Return’ key
- Then the user should see the search results (Items in the database that contain the queried tags)
Feature: Edit tag information for individual/multiple outfits
Actor: Those who are unsatisfied with current tags of a certain outfit.
Precondition: User is in the detail page of the to-be edited outfit
Scenario:
- User clicks on the ‘edit’ button
- System switches to edit mode and displays an ‘edit’ button next to each item as well as a global ‘save’ button.
- When the user clicks on each item, the system displays an input bar
- User types in desired new tagging information / removes pre-existing tags.
- If the pre-edited tag combination was associated with multiple outfits, a system pop-up asking if the user wants to edit all entries of the tag combination (editing for multiple outfits) or just this entry (editing single outfit). User chooses accordingly
- Repeat 3-5 as necessary.
- When satisfied with the results, user clicks on the save button
- After saving the modified data, save button disappears and user is redirected to the edited detail page. Exception:
- User cancels or exits the website mid-edit
- User does not edit anything Acceptance Test:
- Given that the user has edited one or more items in the outfit
- When the user clicks the ‘save’ button
- Then user should see the edited information, and the system should update the database to reflect the edited information
Feature: Log out
Actor: Those who have finished using service, and want to log out for security
Trigger: User clicks on the ‘Log out’ button
Scenario:
- User clicks on the ‘Log out’ button that is visible from every page
- If there is unsaved content or progress, a system pop-up informing the user of that the unsaved progress will be lost appears.
- User clicks ‘confirm’ to confirm logout
- User is logged out of the system and is redirected to the login/signup page Exceptions:
- User cancels logout to preserve unsaved progress Acceptance Test:
- Given that the user has clicked on the Logout button
- When the user confirms that they want to log out (despite unsaved progress)
- Then they should return to the login page, and be unable to access other features of the system until they are logged in again.
Interface overview (built with Adobe XD) : link
