Skip to content

Understanding the Assignment Documents

Jump to bottom
mike-snhu edited this page Aug 15, 2026 · 1 revision

Understanding the Assignment Documents

The Module Two Assignment repository contains several kinds of software-development files.

You do not need to edit or submit every file you see.

Follow the repository README files for the current instructions. If an instruction does not tell you to edit a provided file, leave that file unchanged.

Top-level assignment README:

https://github.com/GC-STEM/it140-m2-assignment

Files You Work In

For this assignment, student work is limited to three files:

  • Part-A/name_age_sdw.md — Software Development Worksheet working notes
  • Part-A/src/name_age.py — Part A Python program
  • Part-B/ide_features.md — Part B IDE Features Reflection

Only name_age.py and ide_features.md are assignment deliverables.

The SDW is a working file that helps you complete Part A. Do not submit it unless your current D2L Brightspace instructions explicitly say otherwise.

Software Development Worksheet (SDW)

File:

Part-A/name_age_sdw.md

The Software Development Worksheet (SDW) is where you record short notes during the Analyze and Design phases.

It helps you:

  • Summarize the program's purpose
  • Identify Input → Processing → Output
  • Put selected requirements into your own words
  • Identify constraints and edge cases
  • Connect requirements to the provided design
  • Follow a test case through the planned solution
  • Record questions or unclear information

The SDW is meant to support your thinking. It does not need to read like a polished report.

Open the SDW:

https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/name_age_sdw.md

Software Requirements Specification (SRS)

File:

Part-A/analysis/name_age_srs.md

The Software Requirements Specification (SRS) defines what the name_age program must do.

Use it during Analyze and return to it whenever you need to verify required behavior.

The SRS includes information such as:

  • General program description
  • Functional requirements
  • Nonfunctional requirements
  • Technology constraints
  • Quality constraints
  • Sample input and output
  • Acceptance test cases

For this assignment, treat the SRS as the primary Part A source for what the program must do.

Open the SRS:

https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/analysis/name_age_srs.md

Software Design Document (SDD)

File:

Part-A/design/name_age_sdd.md

The Software Design Document (SDD) describes the planned solution.

The SRS describes what is required. The SDD helps describe how the planned program will meet those requirements.

Use the SDD with the flowchart and pseudocode during the Design phase.

Open the SDD:

https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/design/name_age_sdd.md

Flowchart

File:

Part-A/design/name_age.drawio

A flowchart represents a sequence visually.

In this assignment, follow the diagram from Start to End and identify where the planned program:

  • Receives or obtains input
  • Processes data
  • Produces output

The course IDE includes Draw.io support so you can view the provided .drawio file in VS Code.

Open the flowchart from your cloned repository in VS Code rather than editing the original course repository online.

Pseudocode

File:

Part-A/design/name_age.pseudo

Pseudocode describes the algorithm as ordered steps without requiring valid Python syntax.

It is intended to help you understand the logic before you write code.

During Construct, use the pseudocode as the primary step-by-step coding guide. Translate its ideas into Python using the concepts identified in the Construct instructions.

Pseudocode is not Python code. Do not expect it to run in the Python interpreter.

Open the pseudocode:

https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/design/name_age.pseudo

Source Code

File:

Part-A/src/name_age.py

This is the Python source file you complete during Construct and test during the Test phase.

The file contains provided structure plus specific TODO: lines for you to complete.

Follow the Construct README carefully:

https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/src/README.md

The starter file deliberately contains some Python structures you have not studied yet. You are not expected to rewrite those structures.

Your task is to complete only the work identified by the current instructions.

Test Cases

A test case describes a set of conditions used to check a program.

For this assignment, the SRS contains the shared acceptance test cases.

An acceptance test checks whether software behaves according to a stated requirement or expected result.

When reviewing an acceptance test, look for:

  • Input values
  • Expected output or behavior
  • The requirement being checked
  • Whether the case represents typical or unusual input

You use one acceptance case by hand during Design and use the cases again during Test.

Automated Test File

File:

Part-A/tests/test_name_age.py

This provided file can run the shared acceptance cases automatically.

It is an example of test code: code that runs other code and checks its behavior.

You have not studied Python testing yet, so:

  • You are not expected to understand every line.
  • You are not expected to modify it.
  • Running it locally is optional.
  • A failing test should normally lead you back to name_age.py, not to editing the test.

Use the Test README for the current instructions:

https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-A/tests/README.md

IDE Features Reflection

File:

Part-B/ide_features.md

This is the Part B deliverable.

You use it to describe three IDE features that you used or observed while completing Part A and explain how those features can make programming easier or more effective.

The reflection is about your own experience. The Part B README tells you when and how to use outside documentation to confirm feature names.

Part B instructions:

https://github.com/GC-STEM/it140-m2-assignment/blob/main/Part-B/README.md

How the Documents Connect

The Part A artifacts form a chain:

SRS
 │
 │ What must the program do?
 ▼
SDD + Flowchart + Pseudocode
 │
 │ How is the solution planned?
 ▼
name_age.py
 │
 │ How is the plan implemented in Python?
 ▼
Acceptance Tests
   Does the result behave as required?

The SDW sits alongside this chain as your working notes.

A useful habit is to ask which document should answer your question:

If your question is... Start with...
What must the program do? SRS
What input, output, or constraint is required? SRS
How is the solution planned? SDD, flowchart, or pseudocode
What step comes next while coding? Pseudocode and Construct README
What Python file do I edit? name_age.py and Construct README
What result should a test produce? SRS acceptance test cases
What should I submit? D2L Guidelines and Rubric and repository README

Working Files, Reference Files, and Deliverables

These terms help explain why the repository contains more files than you submit.

Working File

A working file supports your process.

For Module Two:

  • name_age_sdw.md

You edit it, but it is not a grading deliverable.

Reference File

A reference file provides information or a tool you use without changing it.

Examples include:

  • SRS
  • SDD
  • Flowchart
  • Pseudocode
  • Test file
  • README files

Deliverable

A deliverable is a file you complete for submission.

For Module Two, the repository identifies:

  • Part-A/src/name_age.py
  • Part-B/ide_features.md

Always confirm the current submission requirements in the Module Two Assignment Guidelines and Rubric in D2L Brightspace before submitting.

Where to Go Next

IT 140 Module Two Assignment

Assignment Links

Help and Course Resources

Clone this wiki locally