Instructions

In your GitHub repository for the final project $($which you created from the Project Overview page$)$ you will create $/$ update three documents:

$1.$ README

This file should already exist in your repository. Add $2-3$ sentences to briefly describe the objective and overview of the application. Update your name at the top of the file.

$2.$ Planning Document

A general planning document that contains the following sections:

Requirements

Outline all requirements in detail. This includes any inputs, outputs, and algorithms. Requirements must start with the phrase "The program shall...". Does not need to contain detailed steps for algorithms.

Functions

Describe the main functions and algorithms you will need to develop $-$ the "sections" of your program. Give each piece of functionality a name, and explain any key steps or logic involved. Break the project down into manageable pieces that can be written and tested independently, as programs in themselves.

Challenges and Considerations

Take note of any potential challenges that came up as you were thinking through the problem or writing pseudocode. You don't have to have it all worked out at this point. This can also be a place to note "TODO" items, such as noting coding techniques or problem areas that you need to investigate further.

Organize the document so that it's clean and readable, with a clear title and sections broken out. Save $/$ print the file as a pdf named "planning.pdf$".$

$3.$ Pseudocode

Pseudocode for the program that was described in class and in the project overview video. A non$-$technical user should be able to read through it and understand the inputs, transformations, and outputs.

Steps for any algorithms in used the project should be shown in detail.

You do not have to use "pseudocode functions". It can be one long block of pseudocode. You may use functions if you wish.

Save the file as a text file named "pseudocode.txt$"$

There are many ways to write pseudocode. When choosing a style $/$ convention for your pseudocode, ask yourself $"$If I handed this off to a non$-$programmer would they be able to understand it$?"$ Given the two choices below, the former is more likely to be understood by our target audience: