Overview

It's time to build our first "real" system with actual trust implications. You're going to build a requirements checker that takes a set of courses that a student has taken and determines whether those courses satisfy the requirements to complete a concentration.

For this first stage, you're just going to design/plan the tool and develop a testing strategy. Building the checker will occur over the next two assignments after this one.

You will develop this program in Typescript. We know many of you don't know Typescript, but that is part of the point. We're curious what challenges you do and do not run into when working in a language that you don't already know how to use.

Problem Description

When students declare a concentration at Brown, they list the set of courses that they plan to take in a form (the "declaration") on ASK. For many concentrations, ASK then checks whether the selected courses will satisfy the requirements of that concentration. Many students don't keep their declarations up to date. Fast forward to senior year, and now someone---the "Director of Undergrad Studies" (aka "DUS") for the concentration---has to figure out whether the student should graduate with the courses that they actually did take. This begs for automation with a program.

The program we want to build needs the following features:

• Students must be able to enter courses they plan to take and get feedback on whether their selections satisfy the requirements. When students enter courses, they should do so in a way that indicates which courses satisfy each piece of the requirements.
• The DUS must be able to provide a list of all courses a student has taken (e.g., extracted from the transcript) and get feedback on whether those courses can be used to meet the requirements.
• Students must be able to check variations on their original plan: given a set of courses that would meet the requirements and some changes (e.g., drop X and add Y), get feedback on whether they would still satisfy the requirements
• It will need to support multiple concentrations (though not during stage 1)
• The program design should anticipate that minor changes will occur to requirements over time: new courses get added, some courses get cancelled (ignore large overhauls -- those would be handled as entirely new concentrations).

Assignment Goals

This assignment tackles multiple features of good software: architecture (how the program is divided across files, which data structures are used, and how it is broken into functions/methods), usability by end-users, maintainability over time, and of course, trustworthiness. This is our first chance to work with the first three in under realistic constraints. Your final work on this project will be formally graded on testing.

Ultimately, we want you to end up with a program that is:

• Readable through its use of types, helper functions, and division of code across files
• Maintainable in that individual courses can be added or dropped from a concentration's requirements, while staying within the original structure (subsections) of requirements
• Extensible in that the system designer can easily add support for additional concentrations (with minimal code edits and without breaking existing concentrations)
• Usable in that someone who has to use this program can figure out how to use it while avoiding usage errors (we don't care about how pretty it is). You have to support both student and DUS users.
• Trustworthy in that it has been well-tested for behavioral requirements

We will, however, get there in stages. For this first stage, we just want you to develop the design for both single and multiple concentration versions and develop a high level testing strategy.

Warnings

You may be tempted to try your code on your own transcript. Remember that any data handed to Claude is shared with Claude and added to its training set. Make sure than any actual real data you want to play with has all identifying information removed.

Don't share your program with friends for their own course planning purposes. Kathi is actively developing the actual tool that we'll be deploying for this. The real-world tests for this are pretty gnarly and it is easy for your program to make errors!

Assignment Tasks

You are NOT writing code for this stage; just write design and testing strategy documents.

Task 1: As usual, start a reflection journal. Here's the repo to clone.

Task 2: Plan and design the architecture for a system to check CS concentration requirements as defined in the 2025-26 Brown Bulletin. The Bulletin refers to details in the CS concentration handbook. For this task, limit your design to a checker for this single concentration, but handle both the AB and ScB requirements. Put your work in a file named DESIGN-SINGLE.md.

You can work with Claude or do this manually, as you prefer. Just make a note in your DESIGN.md files indicating how you did it.

You can also tell Claude (or not) that you will eventually extend the simple version, but this first version should be designed around the idea of only one set of requirements. Make a note in your DESIGN.md file about what you did.

Task 3: Design a high-level testing strategy for the system. Don't write actual tests at this point, but rather plan out the categories of tests that you need and describe any specific situations that you will want to test. Put this work in a TESTING.md file

Task 4: Now produce a second design file (called DESIGN-MULT.md). This one should be for a system that handles multiple concentrations. You can pick any concentration you like as the second one that you will support (just have it be one where there are actual requirements laid out in the Bulletin, rather than a vague "meet with the advisor to make a plan"). You don't have to augment the TESTING.md file.

Grading

We will do group crits of the designs and testing plans in class on Tuesday. This will give you feedback that you can use to improve the design you eventually implement.

We will grade your testing plans after the next stage of the project (so you'll have a chance to revise them based on feedback), and the final set of tests when you turn in the last stage of the project.