Permalink
Browse files

Organize requirements into groups for easy reading

Did not change or alter any requirements, moved them into categories
with check boxes so they are easier to identify.

Moved some items to the tips.md that were not requirements.
  • Loading branch information...
MicFin committed Aug 28, 2017
1 parent d639d53 commit acb8340c2e7fa262571e5ec0e39470e0c0d1ea9b
Showing with 63 additions and 67 deletions.
  1. +55 −67 requirements.md
  2. +8 −0 tips.md
@@ -1,71 +1,59 @@
# Requirements

In order to get a satisfactory score, by the time you present your project, you
**must**:

- Present **working browser game, built by you**, hosted on GitHub Pages.
- Practice using version control by:

- Sharing your work through a **git repository hosted on Github**.
- Making **frequent, cohesive commits** dating back to the very beginning
of the project with **good commit messages**.

- Produce **documentation** in the form of a **README**, which must:

- **Link to your hosted game** in the **URL section** of your Github
repo.
- **List technologies used**.
- **Document your planning** and tell a story about your **development
process** and problem-solving strategy.
- **List unsolved problems** which would be fixed in future iterations.
- Link to **wireframes and user stories**.

Your app **must**:

- Be a **single-page** application.
- Use a custom game engine **written by you**.
- **Be deployed online**, where the rest of the world can access it.
- **Render a game board in the browser**.
- **Switch turns** between X and O (or whichever markers you select).
- **Visually display which side won** if a player gets three in a row or show
a draw/"cat’s game" if neither wins.
- Support playing **multiple games**, one at a time.
- Use **jQuery** for **DOM manipulation** and **event handling**.
- Use **AJAX** for interacting with a provided API. Specifically, your app
must:

- **Visually display** the results of retrieving game statistics, such as
total games won by a user. (READ)
- **Create** new games on the server. (CREATE)
- **Update** a game by storing new moves. (UPDATE)

- Have **login**, **logout**, and **change password** functionality.

**must** meet the following requirements:

### Deployment
Be deployed online, where the rest of the world can access it.
1. [ ] Present a working browser game, built by you, hosted and deployed on GitHub Pages.

### Version Control
Demonstrate using version control by:
1. [ ] Sharing your work through a git repository hosted on Github.
1. [ ] Making frequent, cohesive commits dating back to the **first day**
of the project week.

### Documentation
Produce documentation in the form of a **README**, which must:
1. [ ] Link to your hosted game in the URL section of your Github repo.
1. [ ] List technologies used
1. [ ] Document your planning and tell a story about your development process and problem-solving strategy.
1. [ ] List unsolved problems which would be fixed in future iterations.
1. [ ] Link to wireframes and user stories.

### Technical Specifications
1. [ ] Use a custom game engine written by you.
1. [ ] Be a single-page application, no browser refresh.
1. [ ] Render a game board in the browser.
1. [ ] Switch turns between X and O (or whichever markers you select). Tip: Assume player X is the first player to start the game.
1. [ ] Visually display which side won if a player gets three in a row or show a draw if neither wins.
1. [ ] Support playing multiple games, one at a time.
1. [ ] Use jQuery for DOM manipulation and event handling.
1. [ ] Use AJAX for interacting with a provided API.

### API Specifications
1. [ ] Create new games on the server. (CREATE)
1. [ ] Update a game by storing new moves. (UPDATE)
1. [ ] Visually display the results of retrieving game statistics, such as total games won by a user. (READ)
1. [ ] Give feedback to the user after each action.

### Auth Specifications
1. [ ] Signup with email, password, and password confirmation.
1. [ ] Login with email and password.
1. [ ] Logout when logged in.
1. [ ] Change password with current and new password.
1. [ ] Give feedback to the user after each action's success or failure.

### DO NOT!!
Your app **must not**:

- Rely on **refreshing the page** for **any** functionality.
- Display **non-functional** buttons, nor buttons that **do not successfully
complete** a task.
- Have **any** user-facing **bugs**.
- Be playable **after finishing a game**.
- Allow players to move in the same square **more than once**.
- Change players when an **invalid move** is made.

Additionally, you **should**:

- Use **semantic** HTML.
- Practice separation of concerns by:

- Using the [js-template](https://github.com/ga-wdi-boston/js-template) to
store HTML, CSS, and JavaScript in the appropriate places.
- Storing DOM manipulation code and network code in separate files.

- **KISS (Keep It Stupidly Simple)**.
- **DRY (Don't Repeat Yourself)**.
- **Assume player X is the first player to start the game**.

Finally, you **should not**:

- **Use alerts** for anything.
- **Display errors** or warnings in the console.
- **Display debugging** messages in the console.
1. [ ] Delete your repository at any time or start over.
1. [ ] Rely on refreshing the page for any functionality.
1. [ ] Have any user-facing bugs.
- [ ] Display non-functional buttons, nor buttons that do not successfully complete a task.
- [ ] Show actions at inappropriate times (example: sign out button when not signed in).
1. [ ] Allow the same game to be played after a player has won or tied.
1. [ ] Allow players to move in the same square more than once.
1. [ ] Change players when an invalid move is made.
1. [ ] Use alerts for anything.
1. [ ] Display errors or warnings in the console.
1. [ ] Display debugging messages in the console.
@@ -1,5 +1,13 @@
# Tips

You **should**:
- Use **semantic** HTML.
- Practice separation of concerns by:
- Using the [browser-template](https://git.generalassemb.ly/ga-wdi-boston/browser-template) to
store HTML, CSS, and JavaScript in the appropriate places.
- Storing DOM manipulation code and network code in separate files.
- **KISS (Keep It Stupidly Simple)**.
- **DRY (Don't Repeat Yourself)**.
- **Break the project down into different components** (data, presentation,
style, DOM manipulation) and brainstorm each component individually. Use
whiteboards!

0 comments on commit acb8340

Please sign in to comment.