Milestone 1 documentation 3.1 concept analysis

[AngelCIICMorales]

3 analytic part ═══════════════

3.1 concept analysis ────────────────────

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, …

Document: https://docs.google.com/document/d/1rSNv8yV2y-xq9DFhgR3jgsgReQAtk7w_BVA0NGwx7y4/edit Guidelines: https://online.upr.edu/mod/resource/view.php?id=3075527

Priority: 5 Complexity: 2

[AngelCIICMorales]

I have completed the 3.1 milestone 1 documentation.