Understanding the Assignment Documents

Understanding the Assignment Documents

The Module Four repository contains several documents because each serves a different purpose in the development process.

Only one file is the graded assignment submission.

Artifact Map

Artifact	Purpose	Student edits?	Submitted?
Module Four Guidelines and Rubric	Official assignment requirements and grading criteria	No	No
Higher/Lower Game Sample Output	Official examples of expected behavior	No	No
analysis/hilow_game_srs.md	Organizes requirements for analysis	No	No
hilow_game_sdw.md	Optional working notes	Yes	No
design/hilow_game_sdd.md	Design guidance and traceability	No	No
design/hilow_game.drawio	Course-provided reference artifact	No	No
design/hilow_game.pseudo	Graded pseudocode design	Yes	Yes
src/hilow_game.py	Optional Python construction practice	Optional	No
tests/test_hilow_game.py	Optional course-provided practice tests	No	No

Guidelines and Rubric — The Authority

The current Module Four Assignment Guidelines and Rubric in D2L Brightspace is the official source for:

• assignment requirements;
• grading criteria;
• submission requirements; and
• AI-use expectations.

If repository or Wiki wording conflicts with it, follow the current Guidelines and Rubric and contact your instructor when needed.

Higher/Lower Game Sample Output — Behavior Evidence

The Sample Output shows examples of what a working game does.

Use it to ask:

• what input occurred;
• what output followed;
• what decision must have been made;
• what repeated; and
• what caused the game to continue or stop.

Sample output is not pseudocode. You should not copy console text and treat it as the algorithm.

SRS — What Must the Solution Do?

The Software Requirements Specification (SRS) reorganizes the assignment requirements into labeled groups.

Use it during Analyze to identify:

• functional requirements;
• design constraints;
• behavior verification cases; and
• features that are not required.

The SRS does not replace the official assignment.

SDW — Working Notes

The Software Development Worksheet (SDW) is optional student-editable working space.

It uses prompts to help you:

• describe the problem in your own words;
• identify inputs and outputs;
• separate validation from game decisions;
• identify repeated behavior;
• plan the algorithm; and
• trace requirements to the graded pseudocode.

The SDW is not submitted unless your instructor specifically requests it.

SDD — How to Review the Design

The Software Design Document (SDD) explains design concerns without supplying completed pseudocode.

It helps you review:

• the major solution components;
• validation;
• decision branching;
• loops and stopping conditions; and
• requirements traceability.

The SDD is course-provided reference material. Do not submit it.

Draw.io Reference

design/hilow_game.drawio is a course-provided reference artifact.

Module Four does not require a flowchart submission. Do not edit the Draw.io file or substitute it for the required pseudocode.

Pseudocode — The Graded Design

design/hilow_game.pseudo is the assignment deliverable.

The rubric evaluates whether it:

• logically outlines the required program;
• identifies required inputs and outputs; and
• uses decision branching and loops to control program flow.

This is where your graded design work belongs.

Optional Python and Tests

The optional Python starter lets you practice translating your design into code.

The optional test file lets you practice checking selected behaviors with controlled input.

Neither file changes the one-file Module Four submission requirement.

A Useful Artifact Chain

Think of the documents as a sequence:

Guidelines/Rubric + Sample Output → SRS → SDW notes → SDD guidance → your pseudocode → optional Python → optional tests

The goal is not to complete every file. The goal is to use the right artifact for the right development task.

Return to Home or continue to Pseudocode, Loops, and Program Flow.