Team Project Phase 1: Requirements

Description

Before Spring Break we discussed the Black Jack application. We have also looked at a requirements document for the Black Jack application. It is now your turn to come up with an application that your team will be designing and developing this semester. Feel free to be creative! This project is supposed to be educational and enjoyable. To ensure that the project is appropriate for the class, it must meet the following criteria:

• The project must use a Graphical User Interface (GUI) using Java SWING API.
• The project must allow the user to select from at least two options.
• If your project is a game, it may have several configuration options
• If your project is a game against the computer, the options may be the "difficulty level"
• For example, in the Black Jack application, we could have added an option to set the bet amount
• Some application state can be saved when the application exits and re-loaded when application starts up.
• For example, high scores can be saved and re-loaded
• Another example, for the Black Jack application, we could have saved and re-loaded the amount of money the player has remaining.

Work with your team to create a requirements document using this template (following the example of the Black Jack requirements document we discussed in class). Review your requirements document after it is completed and ensure that:

• The overview is clear and concise. You may want to ask somebody else to read the overview and get feedback on whether it makes sense.
• Each functional requirement is focused on a specific aspect of the application. Ask yourself a question: can this functional requirement be split into two separate requirements? If the answer is "yes", then you should split the requirement into two or more.
• The functional requirements are complete. Ask yourself (and each other) the question: is there any piece of information about this application that is assumed and not clearly stated? If the answer is "yes", you should add explicit requirement(s) for any unstated assumptions.
• The prototype is aesthetically pleasing and provides sufficient details.
• User interface requirements refer to the prototype and explain how user needs will be accomodated by the prorotype. User interface requirements should refer to the functional requirements and the prototype, while explaning expected user interactions with the application.

Submitting your solution

Submit your prototype code to the requirements directory of your team git repo.

Submit the pdf of your requirements document to the requirements directory of your team git repo.

Each team member must email me a filled out copy of the Peer Evaluation Form. Title your email: CSCI 2300 Team __ Phase 1 Evaluation. (Fill in the blank with your team number).

Grading

I will use the list of questions below to grade your submissions. Each question can score you from 0 to 2 points: No - 0, Somewhat - 1, Yes - 2. The sum of these points will be your grade for this phase of the team project.

1. Does your requirements document have an 'Overview' section?
2. Is the 'Overview' clear and concise?
3. Does your requirements document have a 'Functional Requirements' section?
4. Are your functional requirements orgianized in a logical manner?
5. Are your functional requirements complete?
6. Is each functional requirement focused on a specific aspect of the application?
7. Does the prototype contain sufficient details?
8. Is the prototype aesthetically pleasing?
9. Does the prototype compile?
10. Do the user interface requirements specify how the user will interact with the prototype?
11. Do the user interface requirements refer to which functional requirements will be activated by various user actions?