Refined Requirements after discussion with PO

Below are the refined requirements for the project:

1. Authenticated users can use the platform.
2. Guess users can monitor recent events, what kind of services provided, basic offerings and what's goin on at society.
3. In order to be authenticated, users should follow a sign-up process.
4. Sign-up process requires providing valid e-mail address, user name, and short bio including name and surname, location for quick sign-up and login. "What do you know or good at?", "What would you like to learn or interested in?" and location are mandatory fields, which needs to be filled before using service.
5. Picture is optional field, maybe beneficial for attacking users for your services, or getting service.
6. System should be capable of giving service for millions of users. As prototype, capacity for fewer is ok.
7. Both Web or mobile access is ok. Mobile is preferred.
8. Platform users are equal and from an idealistic community , so services offered has no superiority against each other.
9. "New Comers" to systems are promoted by reminders.
10. There are "Badges" for level of users. "Mentor" badged users interact with community, help "new comers" to make new friends.
11. General morality rules are applied in system: no offensive arguments, no porn, no illegal service, no unethical behavior.
12. Whenever user doesn't follow any of these rules, they are flagged as inappropriate. If there are more flags, admins can remove user from system.
13. A group of moderators will be assigned as admin at first.
14. As 2nd version, delegation to some users is possible according to good-will.
15. At 1st version, admins take complaints from service providers and users, and solve conflicts.
16. Admins are superusers who can access things, modify them, remove offerings, reset and give penalties.
17. According to conflict resolution, users lose credits, or get bad reputation. A mechanism to report and admin is required.
18. Users can offer services to other signed community members by creating offerings in system.
19. Users can create recursive events for fixed times (i.e. for next 3 Sundays at 2:00 pm), each event should be seperate events.
20. Users can search and find services at platform.
21. Users should apply for services. They can apply multiple times, however their application is limited according to their credits.
22. When users apply, their credit is blocked for the amount required for offering.
23. There is an approval process for offering users. He/she checks applications and decide on user to get service.
24. If user is not selected for offering, his/her blocked credit is returned back to user.
25. User can offer limited service at the same time. This limit should be parametric with default value 10.
26. Users should have enough time credit to get a service.
27. When a user creates a service at platform, he/she should:
    • Describe service offered in details: content, topics
    • Duration for offering
    • Limitation if there are any (such as only on Sundays)
28. Platform offers services according to availability of time credits after user searches events in system.
29. User gets time credit as bonus for signing up to platform.
30. User's time credit decreases as the amount of the service taken.
31. User get time credits when he/she serves an offering.
32. Platform measures reputation of users based on their service.
33. Reputation scoring is based on whether service is taken/given. If a user doesn't follow a scheduled appointment, or cancel last minute, reputation score is decreased.
34. Users can create social events as a non-credit activity.
35. In order to dicipline participation for these non-credit activities, a deposit amount is deducted from your account when you apply the event, and it’s returned back after participation of event.
36. Organizer can decide on amount of this refundable credit.
37. Platform should have a timeline for users, so users can be updated on recent events, interested topics, and “New Comers” joining to system.
38. Users can create an offering as a group-event, however, user doesn't get total time credits of all participants.
39. Users have an upper limit for giving service. MAX_SERVICE is 10, limiting system. If user doesn’t get service that’s OK.
40. “Any unused time-credit expiring in time” should be considered at 2nd Version.
41. Appointments can be cancelled affecting reputation point.
42. After service occurs, users evaluate each other by rating and give comments on below affecting reputation points.
    • punctuality of participation: ontime / late / cancel
    • content
    • personal views
43. User can be only at one event at the same time (no double-booking)