For the Error Report, you’ll compose a formal analytical report that examines an error that has occurred during the development of your project, contextualizes the error, and then provides possible solutions.

Because of the nature of this class, the error doesn’t actually have to have happened, but I want you to decide on an error, define it, and treat it like you would a real problem. For example, if you’re working on an app, a possible problem could be frequent crashes of the first build. If you’re writing a book, you might have written yourself into a corner or be unhappy with how a particular element is working out. Like your proposal, the content of your Error Report should be ACTIONABLE.

Remember: This Error Report should deal with one error of sufficient complexity that it supports a document of this length and could have multiple solutions, not multiple errors with one solution each.

I want to see the depth and breadth of your research here. Successful Error Reports will be the same length or longer than a successful Proposal. This report should follow the PES and be written in sections.

Components:

Your Error Report should be about four or five double-spaced pages (not including your works cited page) and can include visual aids. The goal is to introduce and analyze an error, then suggest solutions while being as concise as you can. If your error report ends up being less than three double-spaced pages or more than eight, you either have too little detail or too much and will need to revise before turning your project in.