• Course: IT 140 - Introduction to Scripting
• Activity: Module Four Assignment
• Program: Higher/Lower Game
• Status: Provided requirements reference; do not edit

The Higher/Lower Game allows a player to choose a lower and upper bound and then guess a randomly selected number between those bounds. The program provides feedback after valid guesses and continues until the player guesses the selected number correctly.

This SRS reorganizes requirements from the Module Four Assignment Guidelines and Rubric and the Higher/Lower Game Sample Output. It does not replace or expand those course materials. If this file and the current course materials differ, follow the current course materials.

The planned program shall:

• FR-1 — Obtain bounds. Prompt the player to enter a lower bound and an upper bound.
• FR-2 — Validate bounds. Ensure the lower bound is less than the upper bound.
• FR-3 — Repeat invalid-bound input. Obtain bounds again when the entered bounds do not satisfy the required relationship.
• FR-4 — Generate the target number. Generate a random number between the valid lower and upper bounds.
• FR-5 — Obtain a guess. Prompt the player to enter a guess between the selected bounds.
• FR-6 — Validate guesses. Ensure the player proceeds only with guesses between the selected bounds.
• FR-7 — Repeat invalid-guess input. Obtain another guess when the entered guess is outside the selected bounds.
• FR-8 — Compare a valid guess. Use decision branching to distinguish a valid guess that is lower than, higher than, or equal to the target number.
• FR-9 — Output guess feedback. Output appropriate feedback for too-low, too-high, and correct guesses.
• FR-10 — Continue the game. Continue prompting for guesses until the target number is guessed correctly.
• FR-11 — End after success. Stop the guessing process after a correct guess.

The graded assignment has one design deliverable.

Create design/hilow_game.pseudo that:

• logically outlines each step needed to satisfy the required game functionality;
• identifies the required user inputs and program outputs;
• represents validation of the lower and upper bounds;
• represents validation of guesses;
• uses decision branching for too-low, too-high, and correct guesses;
• uses loops for required repeated behavior;
• makes the stopping condition for the guessing process clear; and
• uses indentation and pseudocode keywords so the program flow is understandable.

The official rubric evaluates the pseudocode using three criteria:

• Logical Steps — 35%
• Input/Output — 30%
• Program Flow — 35%

A complete design should satisfy all three criteria without adding unrelated functionality.

• TC-1: The graded deliverable shall remain a pseudocode text file (.pseudo).
• TC-2: The assignment does not require a flowchart submission.
• TC-3: Python construction and testing are optional practice and are not graded Module Four deliverables.

A design is ready for final review when a reader can trace each required behavior through the pseudocode.

The scenarios below restate or derive from the required behaviors. They are repository learning checks, not additional graded requirements and not prescribed output wording.

Use the official Higher/Lower Game Sample Output for concrete examples of these behaviors.

The assignment requires the random number and valid guesses to be between the lower and upper bounds. The rubric does not separately define endpoint terminology.

When you complete the optional Python practice, use the provided starter operation and current course guidance for the intended Python behavior. Do not turn an implementation detail into a new graded pseudocode requirement.

A guess must first satisfy the selected range before the game compares it with the target number.

Keep these ideas distinct when reviewing the design:

1. Validation: Is the guess within the selected bounds?
2. Game decision: Is the valid guess too low, too high, or correct?

Each repeated section should have a clear condition that can eventually allow the program to continue or stop. A design that repeats without a path toward new input can describe an infinite loop instead of the required game behavior.

The Module Four Assignment Guidelines and Rubric does not explicitly require:

• handling nonnumeric text entered where a number is expected;
• a fixed number of guesses;
• a score or guess counter;
• multiple rounds after the correct number is guessed;
• exact wording for every output message; or
• a flowchart submission.

Do not add these as graded requirements unless your instructor or current course materials direct you to do so.