This document is a requirements specification for Bad Coffee by BeanTree Development. It outlines our group's vision for the project, the basic features we hope to implement, and the possible ways the project could be extended. It contains our process model, team organization, detailed vision of scheduling, management reporting and lists people involved as well as the hardware, software and system requirements. This document also includes a Rational Rose use case diagram with use case and user descriptions, and our Gantt chart.

Although it's been around for a few years now, wireless Internet access is still a maturing technology. Many establishments are trying to gain some form of customer loyalty by providing free Internet access with Wi-Fi access points. Microsoft Windows and Mac OS X provide some excellent tools for easily connecting to these access points. Once connected, a user can access the Internet to check stocks, grades, e-mail, or anything else possible with an Internet connection. Given the growing popularity of this technology, it would be beneficial to have some form of system to track and rate these access points. When Bad Coffee's first release is completed, the system will allow anyone running our program on a Palm OS 5-based device to look up information such as the transmission rate, encryption keys, or past user experiences, for any registered access point. If an access point is not registered, the system will also allow a user to rate the specific access point on a number of criteria and enter some identifying information about it. The system can later be extended to include builds for Wi-Fi enabled cellular phones or laptops, access through a web browser, and the ability to leave "sticky notes" - messages targeted at another user, set to appear when he or she enters a certain access point.

1. The project will follow the prototyping development model. Initial prototypes will demonstrate the ability to make a connection to the Internet, send a query to our database, and receive an XML file as a response. Subsequent prototypes will add functionality in order of priority. (see Use case, Feature list)
2. Each team member will specialize in one of four areas: front-end design, documentation, back-end/database design, and user interface.
   1. Front-end design: This person will be responsible for the majority of the initial code involved in the front-end application.
   2. Documentation: This person will be responsible for the majority of the documentation writing. A reasonable first draft can be expected for most major documents.
   3. Back-end/Database design: This person will be responsible for the majority of the back-end database work and will also be responsible for the code needed to run the database.
   4. User Interface design: This person will be responsible for the layout design used on the Palm interface and the website front end (if the website front end becomes a reality).

1. Gantt chart (HTML, Excel): Our Gantt chart outlines our rough schedule. With the exception of the major events, such as due dates, this schedule is not necessarily concrete. Given the nature of the project, some areas of development and design may take longer or shorter than initially thought. Adjustments will be made as needed.
2. Meetings: Meetings with the customer will happen whenever the customer wants, when the design team has a matter of uncertainty, or when the design team wants a specific opinion from the customer. Team meetings will occur every Wednesday at 3:30 and last until the agenda for the day has been completed or assigned to different days. Team meeting agendas and minutes will be recorded and submitted to the customer weekly.

1. Team members
   • Bob Zeilstra
   • Eric Knibbe
   • John Van Enk
   • Tom Mellema
2. Other stakeholders
   • Keith Vander Linden - our customer and evaluator.
   • Users of Wi-Fi-enabled Palm devices.
   • Owners of establishments providing Wi-Fi access.
   • Companies interested in statistics culled from our data.
   • Advertisers wishing to embrace a wide market.
3. Hardware/Software required for development
   • A workstation with J2ME development software.
   • A wireless-enabled hand held device capable of running J2ME.
   • A server for our back-end database and web page.

1. Team Miscommunication: Inadequate communication may result in some of us redoing work already done by another team member.

   Response: We will have weekly meetings with a set agenda of items we must cover every week to make sure we are up to task. Items on the agenda should include:

   • back-end design
   • J2ME Palm application development
   • documentation process
   • other matters
2. Customer Miscommunication: What we build may not be what the customer was expecting to see as a final product.
   

   Response: We will design semi-functional prototypes to display our concept of the product to make sure it matches what the customer is hoping for. We will also carefully document customer meetings and inform the customer of any necessary changes to the project.

3. Poor System Design: Our project can be made to work in any number of ways. We may inadvertently use a lot of bad "hacks" instead of proper code to make it work.

   Response: We must be sure to explicitly document our planned system design, and bring it before other group members to make sure our work will mesh without a problem.

4. Time Constraints: The entire project development time is unfortunately short. If we do not stay on top of the given tasks, there is a good chance that we will be unable to complete on time.

   Response: We must parcel out work among group members in portions they can handle and effectively complete. We also must prioritize the features and parts which are most vital to the project's success.

5. Lack of Equipment: Because of the type of equipment involved in the project, availability of cheap hardware could be hard to come across.

   Response: Our group should be able to acquire the hardware, if only for a short time, so that we can test the system.

6. Database Centralization: Since a single database drives the whole system, the loss of that database would bring the entire system down.

   Response: We will find a reliable place to host and store the database, and will have backup plans in place.

7. Privacy Concerns: Given the nature of the system, it is possible that people could abuse the information provided to do such things as track users, spread viruses, and many other non-desirable actions.

   Response: We need to limit the type of data the system keeps track of and also inform users of what that information is. We also need to provide a way for users to use the system anonymously.

8. Message Board Abuse: In the event a message board is added to our system, our message system could fall victim to comment spam or used as a covert communications system.

   Response: Programs have been made available to block comment spam rather well. Covert use of the system can be avoided by making sure there are no private boards.

1. User - someone with a Wi-Fi-enabled device, who will be able to:
   • Detect an in-range access point
   • View data for that access point
   • Add a new access point to the database
   • Search for access points within the database
   • Update data for an existing access point (i.e. add data, ratings, message board posts etc.)
   • View personal stats (i.e. number of access points seen and discovered; etc.)
2. Server - our back-end database server, which will:
   • Serve requests for data
   • Parse incoming data and update the database
   • Authenticate users
3. Administrator - person responsible for our database, who will:
   • Maintain the server and database
   • Serve special requests
   • Moderate message boards
4. Access Point Moderator - any owner of an access point listed in our database, who will be able to:
   • View data for their access point
   • Update data for their access point
   • Request moderation for their access point's message board
   • Make a special request
5. Researcher - anyone interested in in-depth statistics we'll collect about the system and its users, who will:
   • View extended stats

• View access point statistics, location info, technical data, and ratings.
• Add new, unregistered access points to online database.
• Search online access point database for existing access points.

• Update access point information.
• Post comments and ratings about specific access points.

• User-to-user message system.
• Web interface with all the same functionality as the handheld interface.
• Gather aggregate statistics and information.