Reviewing the Project Details from CMPE352 by the new members

[rburaksaritas]

Issue Description

New members must review the documentation and practice app prepared during the CMPE352.

• Buse
• Aziza
• Can

Deadline of the Issue

10.10.2023

Reviewer

Ramazan Burak Sarıtaş

[alper111]

I don't understand how this issue is related to me, but I have added Buse and Aziza to the team, if that is what you are asking from me.

[rburaksaritas]

I don't understand how this issue is related to me, but I have added Buse and Aziza to the team, if that is what you are asking from me.

Yes that was the intention, thanks.

[azizamankenova]

After reviewing the requirements, I have a few remarks and questions:
The glossary contains the following definitions:

Interaction rate: An activity sorting metric which measures how many times the activity has been viewed/shared/reacted to by other users.
Upvote: Registered users can upvote the action or event to affect its reliability scale. (in case if user wants to increase its reliability scare so the visibility)

However, there is no information on users being able to share, react, or upvote in the user requirements. I think the requirements should be revised accordingly.

1.1.3.2.4 Authenticated users shall verify their accounts by verifying their phone numbers or emails which are not entered.

I couldn't quite understand what "which are not entered" means.

1.1.2.1.1 Authenticated users shall be able to edit their profile info.
1.1.3.2.6 Authenticated users shall be able to edit their profiles.

Two duplicate requirements, one should be removed. Also, I suppose editing of some personal info(i.e. name, surname) might be restricted for safety purposes.

1.1.3.2.12 Users should be able to subscribe to a topic based on their filter and search

What was implied under "their filter and search"? Is it filter criteria and search requests?

[mehmetkuzu]

Good points.

After reviewing the requirements, I have a few remarks and questions: The glossary contains the following definitions:

Interaction rate: An activity sorting metric which measures how many times the activity has been viewed/shared/reacted to by other users.
Upvote: Registered users can upvote the action or event to affect its reliability scale. (in case if user wants to increase its reliability scare so the visibility)

However, there is no information on users being able to share, react, or upvote in the user requirements. I think the requirements should be revised accordingly.

Agree. (But dont know how to write)

1.1.3.2.4 Authenticated users shall verify their accounts by verifying their phone numbers or emails which are not entered.

I couldn't quite understand what "which are not entered" means.

How about:
"Authenticated users shall verify their accounts by verifying their phone numbers or emails unless already verified by system admins" (If that is)

1.1.2.1.1 Authenticated users shall be able to edit their profile info.
1.1.3.2.6 Authenticated users shall be able to edit their profiles.

Two duplicate requirements, one should be removed. Also, I suppose editing of some personal info(i.e. name, surname) might be restricted for safety purposes.

I think all of 1.1.2 can be moved under 1.1.3.2

1.1.3.2.12 Users should be able to subscribe to a topic based on their filter and search

What was implied under "their filter and search"? Is it filter criteria and search requests?

Agree. (But dont know how to write - Filter and search and subscribe to a topic should be written more clearly)

[mehmetkuzu]

But I guess these comments should be moved (or copied) under issue #264

[mervegrbz]

After reviewing the requirements, I have a few remarks and questions: The glossary contains the following definitions:

Interaction rate: An activity sorting metric which measures how many times the activity has been viewed/shared/reacted to by other users.
Upvote: Registered users can upvote the action or event to affect its reliability scale. (in case if user wants to increase its reliability scare so the visibility)

However, there is no information on users being able to share, react, or upvote in the user requirements. I think the requirements should be revised accordingly.

1.1.3.2.4 Authenticated users shall verify their accounts by verifying their phone numbers or emails which are not entered.

I couldn't quite understand what "which are not entered" means.

1.1.2.1.1 Authenticated users shall be able to edit their profile info.
1.1.3.2.6 Authenticated users shall be able to edit their profiles.

Two duplicate requirements, one should be removed. Also, I suppose editing of some personal info(i.e. name, surname) might be restricted for safety purposes.

1.1.3.2.12 Users should be able to subscribe to a topic based on their filter and search

What was implied under "their filter and search"? Is it filter criteria and search requests?

@mehmetkuzu can you make the necessary changes in the requirements? Thanks a lot

[mehmetkuzu]

Result of meeting: (Proposed)
The resource quantities will be given as total announced at start.
As the resource is used to supply a need, this quantity will be recorded as used.
(So the initial quantity and current quantity - computed- data will be present in the system)

[canbora]

Here are my comments and questions after considering what we discussed in the meeting and re-reviewing the documents:

• An optional "name" attribute for Locations should be added to the requirements and the class diagram for Location. For example, if a Resource of 10 blankets is currently in Aid Donation Center X, it may be beneficial to include the name of the center it is in.
• Similarly, an ability to choose a previously added location for a resource/event may be beneficial, though not necessary.
• The requirements include real-time location tracking of resources in Product Scope - 2, but the class diagram of Actions include no function getCurrentLocation() to get the current location of a resource in transit. There is a getStatus(), but that returns an Enum, which is not enough to store a location. Either such a function should be added or the product scope should be updated.
• Also, am I correct in that the application is not responsible for planning the specific route that the resources take during a transportation event or the provincial distribution centers that they may go through? These are things that were mentioned in the initial meeting documents from the first few weeks but left out in the requirements and later deliverables.
• Are people responsible of a place (village muhtars, aid center representatives etc.) considered credible users? Does this mean every such responsible person can create prioritized activities? Or are they considered role-based users? The first option makes more sense to me because credible users seem to have a region/location assigned to them.
• In the class diagram of role-based users, the proficiency of a role-based user is said to be a Location. I believe this is a minor error with an easy fix.

[mehmetkuzu]

After reviewing the requirements, I have a few remarks and questions: The glossary contains the following definitions:

Interaction rate: An activity sorting metric which measures how many times the activity has been viewed/shared/reacted to by other users.
Upvote: Registered users can upvote the action or event to affect its reliability scale. (in case if user wants to increase its reliability scare so the visibility)

However, there is no information on users being able to share, react, or upvote in the user requirements. I think the requirements should be revised accordingly.

1.1.3.2.4 Authenticated users shall verify their accounts by verifying their phone numbers or emails which are not entered.

I couldn't quite understand what "which are not entered" means.

1.1.2.1.1 Authenticated users shall be able to edit their profile info.
1.1.3.2.6 Authenticated users shall be able to edit their profiles.

Two duplicate requirements, one should be removed. Also, I suppose editing of some personal info(i.e. name, surname) might be restricted for safety purposes.

1.1.3.2.12 Users should be able to subscribe to a topic based on their filter and search

What was implied under "their filter and search"? Is it filter criteria and search requests?

@mehmetkuzu can you make the necessary changes in the requirements? Thanks a lot

Done

[bgmrsln]

• An optional "name" attribute for Locations should be added to the requirements and the class diagram for Location. For example, if a Resource of 10 blankets is currently in Aid Donation Center X, it may be beneficial to include the name of the center it is in.

I agree with this one. It should be added.

[bgmrsln]

• In the class diagram of role-based users, the proficiency of a role-based user is said to be a Location. I believe this is a minor error with an easy fix.

I have changed it to string.

[bgmrsln]

• Also, am I correct in that the application is not responsible for planning the specific route that the resources take during a transportation event or the provincial distribution centers that they may go through? These are things that were mentioned in the initial meeting documents from the first few weeks but left out in the requirements and later deliverables.

We decided that it was not our task in our first customer(Alper and Suzan hoca) meeting

[bgmrsln]

• The requirements include real-time location tracking of resources in Product Scope - 2, but the class diagram of Actions include no function getCurrentLocation() to get the current location of a resource in transit. There is a getStatus(), but that returns an Enum, which is not enough to store a location. Either such a function should be added or the product scope should be updated.

I think we can update product scope for this one.

[egecans]

• The requirements include real-time location tracking of resources in Product Scope - 2, but the class diagram of Actions include no function getCurrentLocation() to get the current location of a resource in transit. There is a getStatus(), but that returns an Enum, which is not enough to store a location. Either such a function should be added or the product scope should be updated.

I think we can update product scope for this one.

You are right, we should update it as real-time quantity tracking instead of location tracking.

[egecans]

• Are people responsible of a place (village muhtars, aid center representatives etc.) considered credible users? Does this mean every such responsible person can create prioritized activities? Or are they considered role-based users? The first option makes more sense to me because credible users seem to have a region/location assigned to them.

Yes, the first option is the correct one as you can see.

[egecans]

• An optional "name" attribute for Locations should be added to the requirements and the class diagram for Location. For example, if a Resource of 10 blankets is currently in Aid Donation Center X, it may be beneficial to include the name of the center it is in.

I agree with this one. It should be added.

I added that on class diagrams

[egecans]

• Similarly, an ability to choose a previously added location for a resource/event may be beneficial, though not necessary.

It's added to requirements under 1.2.3.5, thanks for your contributions!

[azizamankenova]

After reviewing the class diagram, I have the following remarks:

• I have added the subtype field of human, food, and clothes classes as stated in the req. 1.2.3.1.2.2.
• There is no info about the age of medication and clothes in req., maybe should just leave it as an additional description, since age is usually within some range?
• I couldn't see an operation for sharing and reacting. Is reacting considered the same as upvoting and downvoting?
• I couldn't find the fields for reliability scale and interaction rate of subtypes of activity class as stated in req.
• I believe there are no functions for filtering and sorting in the diagram.

[egecans]

Thanks for your feedbacks!

• I couldn't see an operation for sharing and reacting. Is reacting considered the same as upvoting and downvoting?

We created a Feedback class for this, but forgot to add function on User about his/her reacting, so I added
reactActivity(username: string, vote: boolean) function on users

• I couldn't find the fields for reliability scale and interaction rate of subtypes of activity class as stated in req.

You are right! I added

• getReliabilityScale()
• getInteractionRate()
  under Activity class.

• I believe there are no functions for filtering and sorting in the diagram.

You are right, I think we tried to mean that with searchActions(topic: Topic): List
 function, but it unintentionally was written as action instead of activity I guess. So, I added

• searchEvents(topic: Topic): List
• searchNeeds(topic: Topic): List
• searchResources(topic: Topic): List
  functions also.

[egecans]

I think we progressed well, feedback from some eyes outside the project became very effective for us, thanks for your contributions again!