The basic implementation of the project assumes the application runs on a
server and that various clients access it through a REST API.
I will not change the high-level requirements as a result of the requirements
clarification process. However, I will document the decisions made in the
Q&A document.
The main purpose of this project is to practice object-oriented analysis,
design and programming, not to teach you web development frameworks or
relational databases. As such, the use of a database is expressly prohibited
for the core project implementation.
There is a finer point to be made about the databases ban, namely that most
students would start with the design of a database schema, the way they learned
in a Databases class, instead of thinking about use cases, entity objects, etc.
In fact, the database should be a plug-in to your application, the same way
the delivery mechanism should be, whether command line, web, etc.
We can talk about extra credit iff (if and only if) your core project
implementation works impeccably. This point will not be debated.
If you complete your core project implementation on time and feel adventurous,
then you can get extra credit for implementing a web client for the customer.
5. Project Description
According to the Buy Nothing
Project "BuyNothing offers people a way to give and receive, share,
lend, and express gratitude through a worldwide gift economy network in which
the true wealth is the web of connections formed between people."
The rules of Buy Nothing are simple: "Buy Nothing Project rules are simple:
Post anything you’d like to give away, lend, or share amongst neighbors.
Ask for anything you’d like to receive for free or borrow. [...]
No buying or selling, no trades or bartering, we’re strictly a gift economy."
We intend to provide the RESTful services that support a Buy Nothing (BN)
application. The application will be developed by a different team; in fact
there may be multiple competing applications all using the services we build.
To become part of the BN community one must create and activate an account.
A user with an active account may create an "ask" for something,
a good or service.
A user may create a "give" which is a posting offering a good as
a gift, an offer to perform a service, share something with
another user(s), or lend something.
A "give" posting should indicate what the offer is for, i.e. gift,
service, share, lend, a description that provides additional detail, and an
indication of how it will be delivered, e.g. "will deliver",
"must pickup"
Lastly, a user may offer thanks to another user.
A user posting an "ask" or a "give" must limit the visibility based on
distance from her/his location, e.g. 1, 5, 10, 20 miles. If this is hard
to do, we can start by allowing the user to specify a list of
zip / postal codes where the ask/give can be visible in addition to the
user's zip code; the list defaults to the zip code of the account making
the ask/give.
Users can see all the active asks/gives that fall within the area of
visibility for the account. Let's say that you live in zip code 60616 and
there is one active ask and one active give from accounts in the same zip code;
then you'll be able to see the one ask and one give. However, if you live
in zip code 60608 -- which is just West of Halsted Street where 60616 ends --
then you won't be able to see the one ask and one give coming from the 60616
zip code accounts unless one of those users specified visibility in the
60608 zip code.
A user can respond with a note to an ask/give posting and the person who posted
can respond in turn. The notes can be used to clarify the ask/give, arrange
for delivery and pick up, etc.
A user can only see the notes they created and the responses to those notes.
The user that created an ask or a give can make the posting inactive so that
it doesn't appear in the list of active asks/gives for users that fall
within the area of visibility for the posting. This would be used after
a transaction is complete.
Users can search asks/gives using a keyword, and optionally filter the
results based on whether the posts are active or inactive.
This is not a for-profit business, we don't make any money in the process,
our only interest is to help people in need and create stronger communities.
That being said we know that the government bureaucrats will eventually ask us
for business data and/or information for all sorts of purposes, such as crime
prevention and investigations, taxes, etc. As such, certain users -- we call
them CSRs, short for Client Support Representatives -- will need to have
permission to generate some reports from BN, as follows:
-
Number of asks/gives posted between a start date and an end date, broken
down by zip code and current status.
-
A list of all asks/gives and related communications, between
a start date and an end date, for a givern user.