1. Does our program allow a user to setup new auctions?
Answer: Yes, if the site already knows about the user. For the prototype, you can assume the authorization has previously been completed and you don't need to check passwords (accept them cheerfully, and authorize anybody).
2. Does the user choose whether the auction ends on 10 min intervals or at a preset time?
Answer: Yes, effectively, this is the case. The auction ends either after "deadtime" (10 minutes right now), or when a preset time occurs.
3. What happens if someone bids within a 10 min interval immediately before the preset time ends (e.g. if the preset time is 2:00 pm and a bid comes in at 1:55 pm, does the auction end at 2:00 or 2:05)?
Answer: It ends at 2:00 per the preset time.
4. How many different user interfaces are needed for the bidding client?
Answer: One is probably enough. More if you think they are required.
5. Do we need to provide screens for the buyer and seller side of each of the two types of auctions (4 different screens total)?
Answer: You'll need a minimal screen to establish an auction, and a screen to bid. One bidder screen should be enough if cleverly designed (to handle auctions and reverse-auctions). The screen for a seller to watch the auction is not required for the prototype.
6. Can a user be involved in more than one auction at a time?
Answer: Sure. But only one per screen/client. The auction itself needs some kind of ID.
7. Do users need to be signed in to use the site?
Answer: Yes, but for the prototype you don't need an authorization module. Fake the password acceptance (everybody is OK). See question 1.
8. Do users need to be authorized to sign in?
Answer: Yes. See question 1.
9. Do users need to sign in once or for each auction?
Answer: Yes, and per session. We need to know who is bidding.
10. Can a user set up an account or must they already be known?
Answer: There needs to be an account setup procedure in the requirements, but the prototype can assume users have already completed this step. See question 1.
11. What information should be collected about the user when they initialize their account or will all necessary information about a client already be known?
Answer: I'm not sure what you mean by "account". To setup and auction, we need to know the user's name, email, address, and other typical financial information. When establishing an initial user, we'll know nothing until they tell us somehow (online, via email, via phone). The customer is not sure how this will work and will take suggestions.
12. Can the client set a bid start amount?
Answer: Yes, she must be able to do this.
13. Will there be a minimum bid increment and when will it be set?
Answer: The customer is not sure if there will be a minimum increment. If there were one, it would be set at auction setup time.
14. Do you have a preferred reaction to a tie in bid times and amounts?
Answer: This hasn't been analyzed enough yet, except there can't be a tie. The customer thinks this is resolved by not allowing ties in time, that is, no two bids occur at exactly the same time.
15. Does the bidder's history apply to a single auction or all time?
Answer: The requirements had a single auction in mind, but for all time sounds interesting.
16. In reserved auctions should users be aware of minimum price?
Answer: Yes.
17. How should active bidders be notified of the end of the auction?
Answer: Some kind of message on their screen. Flashing button, blinking screen, a text message. The customer is not sure what form the notification should take.
18. What information must the auctioneer inform the client about during the auction?
Answer: Good question. At a minimum, the client needs to know the current best bid (high or low) and whether it's theirs or not. It would be nice to know how much longer the bidding will go on. For a "deadtime" bid, this is a countdown, otherwise a set time. I guess either way, it's a countdown. The client needs to know when the auction starts and is over (maybe the clock/countdown does this). Other things, like the item description would be nice.
19. Should the preset times for auctions to end be set for each auction or for all auctions?
Answer: We're not sure what you mean. Each auction is independent and has it's own start/end time. We think the answer is "for each auction".
20. Are any due dates extended?
Answer: Not at this time.
21. What is meant by "The auctioneer must inform the client of what is going on during the auction"?
Answer: It means the auctioneer must keep the client's client program up-to-date on best bid, and who was the best bid, time left, and anything else that seems important.
22. Can an auctioneer cancel an auction?
Answer: Yes, there should be a way to technically cancel an auction although there may be legal ramifications that prevent the customer from using this capability.
23. Each bidder maintains their personal history, should the auctioneer be allowed to keep a history of every bid that occurs in their auction?
Answer: The auctioneer is an automaton -- a program. All it really needs to keep is records required to determine who has won, and who is next best bidder if a bidder leaves.
24. Should there be any way to prevent an auctioneer from bidding in his own auction in order to drive up the bid?
Answer: The auctioneer is a piece of code. The seller/buyer shouldn't bid. I suppose we could refuse to take bid information from the client that has the item up for bid. That makes sense.
25. Is there any time when the high(low) bidder is known to anyone besides the auctioneer and the person has the high bid?
Answer: After the auction is over, the identity can be revealed.
26. When a user sets up an account - you mentioned the need for: name, email, address are they required to enter in a phone number, credit card number? are there any other required entries?
Answer: Phone number makes sense, as does some way of paying, but credit card is probably not right. Since this is a commercial auction, it is likely the amounts will exceed amounts one would want to put on a credit card. The customer had a credit authorization process in mind as part of the initial sign-up so that we'd know a bidder could pay if they won. In fact, payment will often be on a Purchase Order, we suspect. Since payment is direct from winner to client, probably what we need to display is the bidder's credit rating. This raises the question of whether a client can reject a set of bidders based on the credit rating. We hadn't though about this before, so we'll have to get back to you.
27. Will bidders be allowed to set up an 'auto-bid' option that allows them to automatically bid if they don't hold the high bid?
Answer: This could be a feature of the client-side software but the auctioneer/auction site won't do this automatically.
28. At the end of an auction, the auctioneer notifies bidders of win/loss. Is the auctioneer notified of winning bidders account information? What are the requirements related to the payment/end transaction?
Answer: The auctioneer code is where the winner is determined. When the bidding is over, the winner and the client need to be notified, and we need to keep some records so the transaction can be completed. At this point, we can assume the winner will send a check to the client, and the goods transfer will be completed. The client will be billed by us for our auction services.
29. Regarding the distributed system - You mentioned that there needs to be a screen for the bidder and one for the auctioneer. If the window is closed does this imply a bidder leaves the auction? What if there computer crashes? Likewise for the auctioneer, must they maintain an open window monitoring their auction, or can they re-log in to check their current status?
Answer: No screen for the auctioneer is mentioned, and none is needed. The auctioneer is code. If the client code stops participating ("leaves", crashes, etc.) the auctioneer can assume the bidder has left unless that bidder is high bidder. The principle is you can't get out of the best bid by crashing your machine. The preferred method to leave would be a sign-off message, assuming it's not from the best bidder.
30. In a reverse auction, can the person who put the bid out cancel it or does he have to accept whatever the lowest bid is that comes in? For example if the guy wanted 1000 hammers and someone said they can get them to him for a 1000 bucks, can he just say no or does he have to give the guy the 1000 bucks.
Answer: Per the description, a selling client can optionally set the minimum acceptable price. Bids below this amount do have to be accepted. A buying client sets the highest acceptable price and doesn't have to accept bids that are above (too expensive). Otherwise, the process is binding. In your example, if the maximum price had been set above $1000, the client has to buy the hammers, otherwise the bid is not valid.
31. Can the auctioneer serve on more than one auction, or are the auctioneers auction specific?
Answer: Auctioneers are auction-specific. One per auction.
32. How do we deal with concurrent bids? Basically, what is the procedure when more than one bid arrives to the auctioneer at exactly the same time with the exact same bid value?
Answer: You'll need to devise a tie-breaker procedure. We don't have one in mind right now, although since is network communication, can this really happen?
33. Do we inform a bidder of how many other bidders are presently bidding on the auction?
Answer: Hmmm Good question. I don't see why not. Yes, that would be good.
34. How do we want to handle first time registration with the auction site? Do we want to keep a database with User IDs and passwords?
Answer: Yes, we need such a database. For now, assume the process is mostly manual and involves gathering credit information (see question 26). There will be a new bidder intake process of some sort.
35. What is to happen when a bidder wins an auction?
Answer: See question 26.
37. What happens if no one wins an auction? Examples: Reserve price not met, no bids posted on auction during specified start and ending times.
Answer: Good question. We think the auction just ends and the auctioneer declares (to the client) there is no winner. The bidders have to be told this also. This could happen if the reserves are not meet and the time runs out. This might, in fact, be a desired result. A client might request bids for an item at a ridiculously low price just to see if anyone will bite.
38. Can a bidder be connected to more than one auction at a time?
Answer: The bidder-person can, but not the bid-client code.
39. What happens if the user is the high bidder, he logs off the site, and he wins the auction?
Answer: Nothing in particular. He wins and is obligated to pay the price or deliver the goods. However, this does raise the question of looking at completed auctions to see who won. I suppose we could also send email to the winner.
40. In regards to Question 23 on the questions webpage, why do we need to keep track of the next best bid if the winning bidder is not allowed to leave the auction?
Answer: The only case where the next highest bidder might be used is if the auctioneer (through a person-manager) disqualifies the high bidder making the bidder leave the auction. Otherwise, the implication is correct: The high bid wins even if the client goes away.
41. How do we organize the list of auctions that are taking place on the auction site? Examples: By time started, time ending, time created, number of users.
Answer: Whatever seems appropriate. Probably either by start time (sooner near the top) or alphabetically by some name of the auction. Time created and number of users doesn't seem very useful.
42. What should happen if the person that starts the auction wishes to withdraw the auction while it is in progress? Basically, I think what we need is some clarification on question number 22 on the questions webpage.
Answer: Procedurally, I'm not sure about withdrawing the auction, but I can say that there has to be a provision to stop an auction. So, from a technical standpoint, there has to be a way to cancel the auction and inform all the clients this is so. Whether we allow, from a procedure viewpoint, an auction to be withdrawn needs to remain open for a while. So, to sum up: You have to be able to drop one or more auction clients from an ongoing auction, including stopping the whole auction.
43. Do we have to handle payment between buyers and sellers?
Answer: No. This is a separate issue. You do have to keep track of the completed auction, and whether it's reconciled or not, but the payment process is outside the system. "Reconciled" means have the parties settled up.
44. When creating an auction, should there be a save function available for the user to create a template for an auction they are not yet ready to submit, or engage in periodically, like every week or so?
Answer: This is a great idea and would be great addition and should be added if you can.
45. The requirements aren't to clear on the role of an auction's owner. There is code to facilitate sending messages to active bidders and to the site, but should the owner be allowed to monitor their own auction, and what information should be available to them?
Answer: Yes, the party that initiated the auction need a facility to watch the bidding process. He/she should be able to see who is bidding and what the bids are.
46. If a bidder is involved in multiple auctions, should there be one screen in which they can monitor all their auctions? Maybe the same window could be used to monitor auctions they own?
Answer: This would be another really great addition, but it's not required at this time. In an industrial setting I can see where someone might have lot of auctions in progress and keeping track of them from one status screen would be a very nice feature.
47. Should a bidder be allowed to see a representation of someone that is bidding against them? By this I mean something that maintains other bidders anonymity but allows the bidder to know how many people he is bidding against, and who is active?
Answer: A representation is fine as long as it does not reveal the bidders real identity. This can be a made-up handle or a system generated one.