Understanding the Assignment Documents

Understanding the Assignment Documents

The Module Three repository contains several documents and starter files. They serve different purposes and do not all become assignment submissions.

Document Priority

When information conflicts, use this order:

1. Module Three Assignment Guidelines and Rubric in D2L Brightspace
2. Current instructions from your instructor
3. Repository README files
4. Supplemental Wiki pages

The repository SRS, SDD, and SDW help organize your work. They do not add graded requirements beyond the official assignment.

Artifact Map

Artifact	Purpose	Who creates/edits it?	Submit?
Guidelines and Rubric	Official problem, directions, grading, and submission rules	Course	No
analysis/paycheck_calculator_srs.md	Reorganizes official requirements	Course	No
paycheck_calculator_sdw.md	Optional guided working notes	Student	No
design/paycheck_calculator_sdd.md	Design guidance without a completed solution	Course	No
design/paycheck_calculator.drawio	Graded visual design	Student	Yes
design/paycheck_calculator.pseudo	Graded textual design	Student	Yes
src/paycheck_calculator.py	Optional design-to-code practice	Student, optional	No
tests/test_paycheck_calculator.py	Optional automated test tool	Course	No
README files	Step-by-step workflow and phase instructions	Course	No

Guidelines and Rubric

The Guidelines and Rubric in D2L Brightspace is the authoritative assignment source.

It defines:

• the paycheck problem;
• the regular and overtime pay rules;
• the required flowchart elements;
• the pseudocode expectations;
• the optional code-practice step;
• what files to submit; and
• how the two graded artifacts are evaluated.

Always review the current D2L version before relying on repository summaries.

SRS — Software Requirements Specification

The SRS answers:

What must the planned program do?

The repository SRS gives stable requirement identifiers such as FR-1 and DR-1. Those identifiers make it easier to trace requirements into the designs.

The SRS also distinguishes:

• required behavior;
• design/file constraints;
• verification cases; and
• behaviors that are not required unless the course adds them.

Why include an SRS in CS1?

You are not expected to become a requirements engineer in Module Three. The SRS is a learning scaffold that helps you practice reading requirements before designing or coding.

SDW — Software Development Worksheet

The SDW is your optional working-notes file.

It asks you to:

• summarize the purpose in your own words;
• identify input, processing, and output;
• interpret selected requirements;
• reason about the 40-hour boundary;
• plan flowchart and pseudocode structure;
• connect SRS requirements to both designs; and
• trace a case through the completed design.

The SDW is intentionally question-driven. It should not contain a prewritten solution for you to copy into the graded artifacts.

SDD — Software Design Document

The SDD answers a different question:

What should a good design make clear?

Because you create the graded design in Module Three, the SDD cannot contain a completed paycheck algorithm. Instead it explains:

• input/decision/process/output as design categories;
• the boundary the design must represent;
• flowchart and pseudocode design constraints;
• consistency checks; and
• requirements traceability.

Flowchart Starter

design/paycheck_calculator.drawio is one of the two graded files.

The file contains multiple tabs so the reference material stays with the template:

• Paycheck Calculator — your graded chart
• README — template instructions
• Symbols — reference shapes
• Snippets — generic constructs
• References — source/attribution information

Only the Paycheck Calculator tab contains your graded solution, but the entire .drawio file is submitted.

Pseudocode Starter

design/paycheck_calculator.pseudo is the second graded file.

The starter provides an outer BEGIN / END structure and TODO prompts. You replace the TODOs with your own logically ordered and indented pseudocode.

The starter may provide structural scaffolding such as IF / ELSE, but it does not provide the paycheck condition or processing calculations.

Optional Python Starter

src/paycheck_calculator.py exists to practice the next SDLC phase.

It provides:

• a documentation structure;
• constants from the assignment;
• a main() function scaffold;
• a main guard; and
• TODO comments for the implementation.

You are not expected to have mastered functions yet. The structure is provided so you can focus on translating your design with Module Three concepts.

Optional Test File

tests/test_paycheck_calculator.py runs the optional Python program against numeric verification cases.

You do not need to understand all of the test code, and you should not edit the test just to make a failure disappear.

The test file is a tool, not a graded artifact.

README Files

README files tell you how to work through each phase.

A useful reading order is:

1. repository README.md
2. analysis/README.md
3. design/README.md
4. submit the assignment
5. optional src/README.md
6. optional tests/README.md

Keep "Provided" and "Student Work" Separate

A simple rule:

Read the provided documents; edit the student work files.

The repository README lists exactly which files you may edit.

Return to Home or continue to Flowcharts and Pseudocode.