Add concept analysis to the documentation

[AnthonyMed13]

For this task one needs to add the concept analysis to the documentation

One needs to follow the criteria and guidelines for milestone 1:

You always want to start with a rough sketch whether you want to document your domain, your requirements, or whatever else. Documenting the rough sketch allows you to check the steps taken to get to your concepts, abstractions, decisions, etc. Only when you document the initial starting point can you later retrace your steps and check whether you would still take them the same way.

In the concept formation and analysis of your rough sketch you find and introduce concepts that you think arise from the rough sketch. You document your decision to e.g. take the "Toyota Corolla" mentioned by Paul and the "Suzuki Hayabusa" mentioned by Iris and to introduce a concept "Vehicle" and you identify how these are similar for the purpose of your project.

Also in that section you identify potential clashes: maybe someone is using a term in one way and someone else uses the same term in the (slightly?) different way. Are these compatible? Can a common base be found?

• When you want to do domain concept analysis you need to take the domain rough sketch (obtained from interviews, common knowledge, literature review, …) and analyze what the common concepts are.

• For example, you hold one beach-goer's statement "I come to the beach daily to do 15 minutes of butterfly" and another beach-goer's statement "when I visit the beach I like to swim for half an hour" side-by-side. Outcomes of analysis: both are talking about swimming, butterfly is a style of swimming, (some) activities are measured by the duration for which they are performed, swimming is an activity that can be done on (some) beaches, … The outcomes can then be used to formulate the narrative. You want to start with the rough sketch so that your analysis, how you got from the initial findings to your concepts, can be retraced whenever needed.

• As another example, you have interviewed prospective users. User A says "I have trouble keeping track of all the tasks I need to do", user B says "I like to mark assignments that I get from STEM classes with a special tag". When you put them side-by-side you can come up with several abstractions. Here "task" and "assignment" are likely synonyms for the same concept. Also, (some) tasks have origins e.g. STEM classes. When you have the abstractions you then use these and the specifics to formulate the (polished) narrative.

• So, base your concept analysis on some rough sketch where you use the rough sketch and hold parts of it side-by-side to justify some decision you are taking.

• "User" is not normally a domain concept.

• When analyzing the domain rough sketch remember to stay within the domain (no system-to-be). When analyzing requirements rough sketches (e.g. as user stories) you may find terms that belong to e.g. the application functions or the implementation and not to the domain.

• Rough sketches are meant for collecting ideas in brainstorming, meeting recordings, Q&A, clippings from the literature, …

Tentative Points:

Urgency: 8 Difficulty: 2-3

[warm007]

Concept Analysis for PhotoFit

1. Domain Analysis Fashion Organization and Personal Wardrobe Management: These are the core domains of PhotoFit, focusing on the user's interaction with their clothing items. Key concepts here include "Outfit", "Clothing Item", "Wardrobe", and "Fashion Style". Each clothing item (such as shirts, pants, accessories...) can be categorized and managed within the app, facilitating personal wardrobe management.

Management Application Features: This encompasses functionalities like categorization, filtering, and searching of clothing items, as well as suggestions for outfits. These features aim to optimize the user's wardrobe collection experience, suggesting a close relationship between user experience (UX) design and software functionality.

2. Requirements and Architecture User Needs and Preferences: A critical aspect of the project, understanding user needs involves identifying how users manage their wardrobes, their challenges, and their expectations from the app. This will inform the "User Requirement" concept, which is paramount for the app's success.

Scalable Software Design: The architecture must support the dynamic nature of wardrobe management, including the storage of user data (clothing items) and the processing required for the automatic identification of clothing attributes. Key concepts here include "Scalable Architecture", "React Native" (for front-end development), and "Database Management".

3. Functional Objectives Automatic Identification of Clothing Items: The app's functionality to photograph clothing items and identify their color, type, and category introduces concepts such as "Image Processing", "Item Recognition", and "Inventory Organization". This technological aspect requires a solid understanding of machine learning algorithms or image recognition technologies.

User Interface and Experience: The UI/UX design is crucial for ensuring user engagement and satisfaction. Concepts like "User-Friendly Interface", "Intuitive Navigation", and "Visual Aesthetics" will be central to the design and implementation phases.

4. Project Management and Collaboration Milestone Planning and Progress Tracking: The project's timeline, divided into milestones like domain investigation, interface design, backend development, and project documentation, introduces "Project Milestone", "Progress Report", and "Team Collaboration" as key management concepts.

Technology and Tools: Utilizing React Native, Expo, and potential backend technologies, alongside collaboration tools like WhatsApp and GitHub, underscores the importance of "Technology Selection" and "Collaborative Tools" in the project's success.

5. Analysis of Clashes and Common Ground Terminology Consistency: Ensuring that terms like "Outfit", "Clothing Item", and "Wardrobe" are used consistently across the project to avoid confusion. Where discrepancies arise (e.g., between technical and fashion terminology), a common definition should be established.

User Requirements vs. Technical Limitations: Balancing user expectations with what is technically feasible, especially regarding automatic clothing item identification. A common base must be found to satisfy user needs while staying within technological constraints.

[JoseLQV]

Some examples:

• Jonathan enters his entire wardrobe from his pants, polos shirts, blazers and ever gym clothes. He can Randomize the items to find an Outfit to wear but a conflict may occur where the algorithm must verify the categorization of Items. To prevent having an outfit be unwearable together for example a blazer with a swimsuit.

• Sophia has lots of T-shirts and a variety of Different color pants. She is very picky when it comes to her fashion style and likes that her outfits have the same colors all the way through. This is another observation that we could improve upon by sorting the item by colors to be able to comply with our Client’s feedback.

• Steve is a construction worker and would like to have the Item sorted not only Available but also by Status (New/Used/Old) from Oldest for him to not worry to mess up his brand-new White Pollo T-shirt.

With the different examples provided we can see a pattern of occurring issues or pain point that we will have when implementing our algorithms. Meaning we have to be very observant of the sorting algorithms and classification of the items for them to be a very useful and convenient feature for the clients to enjoy.