Project design
Due: 5pm, Wednesday, April 23. Submit an ASCII file by e-mail to the instructor.
B Team | W Team | |
Coordinator: | Connor Bell | Mark Woodard |
Browser-Side Leader: | Megan Yociss | Angela Gloyna |
Interface Designer: | Bryan Urban | Connor Anderson |
Browser-Side Developer: | Buzurg Arjmandi Hunter Lewis |
Fina Sutarto |
Server-Side Leader: | Justin John | Andrei Ndindabahizi |
Database Administrator: | Rebecca Perez | Julie Britton |
Server-Side Developer: | Merlin Plumbley | Luke Lasley |
We start with our project by designing it. This is broken into three major pieces, leading to three major documents.
- AJAX specification (coordinator, browser-side leader, server-side leader)
- This should define each request that might be made by the front end. See Assignment 4 for an example of what this might include: the URL for the request, the request method (GET or POST), the parameters provided with the request, the conditions under which the request might legitimately fail, what is done in response to the request, and what is sent in the JSON response.
- Browser interface (interface designer, browser-side developer, browser-side leader)
- This should describe the primary interface to be presented to the user via HTML, with some indication of how a typical user will interact to access the major functionality of the Web app. It would be appropriate to build a preliminary prototype using HTML. This will not be complete; but it should describe the overall page layout, how the user can navigate between portions of the page, and the elements of any forms that the user might need to complete.
- Database design (database administrator, server-side developer, server-side leader)
- This should describe the tables that will appear in the database, including the table names, the list of columns, and the types and constraints associated with each column.
Above, I've vaguely associated team roles with each document, suggesting where primary responsibility for the document might lie. That said, the full team bears responsibility for each document.
Please submit your full design document, written as a single ASCII text file, in a single e-mail to the instructor. You may include additional documents (particularly for the front-end interface, where you may want to attach an HTML mockup).
Functional specifications
We will develop a repair assignments database intended for an organization that maintains a large number of buildings (such as Hendrix's Facilities Management department). The system should include the following elements:
Any user (with or without login) should be able to submit a “ticket” including a description of an issue, the facility affected (probably a building name), as well as a contact name and e-mail address. Upon submission, a number should be allocated to the ticket, which is shown to the submitter.
An employee (that is, somebody logged in) should be able to view any ticket and submit an “update” which may change the ticket's status, change the employee to whom the ticket is assigned, and/or add a comment. Note that previous information is not deleted: A complete log of changes is stored for each ticket, with the user ID and submission time for each update.
Possible statuses of a ticket:
- pending: submitted by anonymous user, but not yet validated by an employee
- accepted: validated as something that should be addressed, but not complete
- completed: all elements of ticket have been addressed
- declined: the ticket cannot be addressed right now
- deleted: the ticket is permanently hidden from future search results (this is meant for spam tickets, not legitimate requests)
Any user (with or without login) may enter a previously allocated number, and all information about the ticket should be displayed. This will include the initial description, as well as the history of the status and name of employee handling the ticket, as well as any comments logged.
Any user (with or without login) should be able to fill out a search form, and the system should list all non-deleted tickets related to the query. Please note that a convenient and robust search mechanism is a feature that can easily distinguish your database from competing products.
Typical queries that should be supported:
- List all pending tickets.
- List all accepted tickets.
- List all accepted tickets currently assigned to a particular employee.
- Full-text search of all non-deleted tickets.
Add a new employee or remove a current employee.