Proposal Phase 2
This section of the proposal will add more detail as well as Storyboard Sketches (You should revise the previous sections if needed and add storyboard sketches)
User Experience: Input/Output and Wireflow
You must create a wireflow diagram that shows all of your screens for your design. This is a combination of wireframe diagrams. This will include any user input/output that is needed to control your application including mouse and keyboard interaction.
Wireframe screens: These are the rough sketches of the key screens in your app. They’re usually shown as boxes with basic shapes like rectangles for buttons, lines for text, and dropdowns or checkboxes to represent interactions. If a screen changes its UI state you may duplicate it. Note the different states for those screens. Note: You must show all three versions of your design here. You can show this by using different colors for each part of your design (prototype, core and stretch) so you can see how it will function at each phase
Arrows: These connect the screens and show how users move from one to the next. Straight lines indicate simple navigation, while branching arrows can show decision branches or alternative paths. Note: You must show arrows from an exact point of a click to the destination screen. If your diagram becomes unweildy, you may reduce the number of arrows by labelling in and out points of arrows with a number instead such as (1, 2,3 etc)
Notes and annotations: Easily provide helpful context to explain things like button behavior, system feedback (like error messages), or any behind-the-scenes logic you want to capture. These are usually shown as callouts, sticky notes, or small text labels next to the wireframes.
- See examples of wireflows and a longer description here
Test Plan
Define how you are going to test that your code is working correctly, how you will test edge conditions or errors happening and so forth. Make sure to build time in your schedule to get this done. This should be very detailed on steps to follow to complete a test pass (you will be thankful you have this so you can run through these tests before each of the sprint demo’s on Friday’s). You should label your tests with the milestone needed to run that test (since you won’t have all the functionality to run all the tests until the work is completed)
An example for a testing strategy may be something like the following. Note: You will need to provide details steps for manual testing that describe which screens you will view, what you would click on and what the expected behavior is. For the Prototype testing, provide at least 5 questions for your peers to provide feedback to you for your specific application.
| Test Category | Details |
|---|---|
| Prorotype Testing | At prototype we will provide students X,Y,Z our application with a sheet to fill in answers to the following questions: - What can be improved? - What did each of the icons on the main screen mean to you? - etc |
| Manual Testing | Before each demo we will do the following manual tests: - Go to main screen and click X, and make sure Y comes up - etc many more |
| Automated testing | We will implement automated tests for the following classes/methods: - MainScreen.java (all of it) - CustomScreen.java:specialCalc - etc |
| Other testing | Any other type of testing you might be thinking of |
Approval
You must receive teacher approval to continue to Phase 3.