Feedback Meeting Notes #1

Meeting Information

Date: 28.03.2024
Time: 17.15
Online/Offline: Offline
Location: BM #35
Duration: 1.15 hour
Note Taker: Mutti, Emin

Attendees

• Suzan Uskudarli
• Mustafa Atak
• Mehmet Emin İpekdal
• Yiğit Kağan Poyrazoğlu
• Taha Topaloğlu

Agenda

Getting feedback from SUuzan Teacher about our general Wiki page and deliverables.

Main Page Feedbacks:

• Collect the first milestone deliverables (elicitation, mockup, scenarious etc.) under the Requirements heading and add them to the bar

• Since meeting notes will take up a lot of space at the main page in the future, you should keep them in the bar.

• Note names should be determined accordingly if there is a very specific situation (Feedback Meeting notes, Customer Meerting notes).

Requirement Feedbacks

• In a functional requirement, it is wrong to say that this type of user does everything that this type of user can do; there is nothing that describes the function. As this covers this, an item does not specify a function.

• When switching between guest requirements to member requirements, instead of stating that it is included, you will say guest can register to the system. After it is done, you can specify that the registered user is able to that.

• Our main corcern should be what can be done with this system, not what cannot be done in this system. For example, guest can make a search and we can specify this as requirements, but it is wrong to write a requirements that says guest cannot create a route. Of course, this should not be confused with what should be done in the face of negative situations. So we should be able to report a person and this is a negative situation, but it is not something that cannot be done in the system.

• When organizing the sub-headings, it would be much healthier to group them according to functions, because when implementing them, we will implement the functions piece by piece, not, for example, the user type. Accordingly, regrouping needs to be done.

• Contributor is a nice addition, of course we don't want the newly registered person to be able to add directly due to bot spam situations. However, this can be added under the title of real life scenario, but for now it can be removed from the requirement to ease the burden on the requirement a little. If there is such a title, it would be much more logical to describe it in Glossary. For example, what is the criterion for switching from registered user to contributer? Is it the registration period, the score received, etc. These rules should be stated in the glossary.

• It might be better to explain some concepts further in the glossary. For example 1.1.2.1.1. We are talking about a blocked user, but it is not clear what exactly it is, for instance, what is the matter with the blocked user? We cannot see his posts or comments. Is it visible in those who like it? These need to be explained clearly.

• Discuss the requirements and understand that it is a comprehensive job. All the work done without understanding will explode in your hands. Then they say you should have told me.

Scenario Feedbacks:

• Scenarios should focus more on the persona of the person. This first gives us a more serious view. The latter may be something that should be specifically mentioned for people in that specific situation. It helps with this. The third one may be easier to remember and verify details in the scenario. Asking what should be done if the following happens in a scenario where the character Suheyla lives is easier and more understandable than asking what should be done in the following situations in requirement 1.1.2.1.

• There is no need to specify which requirement corresponds to the situations in the scenario.

• There is a problem in using Wikidata. Only the description and image are included, then you can go to Wikipedia and get information. We need better usage of Wikidata. Wikidata has structural information within itself. Answers to questions such as who was the Architect of the work, when was it built, what is its surface area, etc. can also be given.

• It would be much better to show the Wikidata API more in designs.

Glossary Feedbacks:

• The term Reroute in Glossary is a troublesome choice. Yes, its name is defined, but it is a word with an established meaning in general English, so it is not so easy or logical to use it in a different meaning. It may be necessary to think and develop this term or its meaning.

• Concepts such as guest, basic user, blocking can be explained.

Elicitation Feedback:

• It would be better to add answers to some tricky elicitation questions, but there is no need to write the answers to every question.

About Design:

• We must create at least one sequence diagram for each use case. The goal is to call certain methods in a certain order and show that we have solved a certain use case.

• These diagrams are very important so that we can see how things will go before instead of the code and fix system.

Issue Feedback:

• It makes sense to assign a reviewer on the issues so that everyone in the group is fully aware of what they are doing and can learn from each other and build on each other.

Other :

• A properly understood RAM needs to be created until the next milestone. Do not make this mistake that many people make unconsciously without looking at the definition.

Action Items

Item	Responsible Person	Due Date	Relevant Issue
Inform the rest of the team about meeting	Mutti, Yigit, Taha, Emin	31/03/2024, 23:59	#110 Notes #10
Prepare the note about feedback meeting	Mustafa (Mutti)	31/03/2024, 23:59	#109