In AP Computer Science Principles, program requirements describe how a program functions and may include the user interactions it must provide. They come from investigation (surveys, interviews, user testing, observation) during the design phase of the development process (Topic 1.3).
Program requirements are the list of things a program has to do before anyone would call it finished. They describe how the program functions, and they often spell out the user interactions the program must support, like "the user can search for a song" or "the app must let users transfer money between accounts." Think of them as the contract between the developer and the people who will actually use the program.
Here's the part the CED really cares about (EK CRD-2.F.1): you don't just make requirements up. The design of a program incorporates investigation to determine its requirements. That means collecting data through surveys, running user testing, doing interviews, and making direct observations. Investigation also surfaces the program's constraints and the concerns of its users. So requirements aren't a brainstorm, they're the output of research. Once you have them, they guide every later phase: design, prototyping, and testing all get measured against the requirements.
Program requirements live in Topic 1.3 (Program Design and Development) in Unit 1: Creative Development, supporting learning objective AP Comp Sci P 1.3.B (design a program and its user interface). They're the bridge between investigating and building. Without requirements, you can't design a sensible user interface, you don't know what to prototype, and functional testing has nothing to check against. Unit 1 sets up the development process that the entire course (and your Create Performance Task) leans on, and requirements are the first concrete artifact that process produces. If you understand where requirements come from and what they're for, the whole iterative development story in EK CRD-2.E clicks into place.
Keep studying AP Computer Science Principles Unit 1
Iterative Development Process (Unit 1)
Requirements aren't frozen. An iterative process (EK CRD-2.E.3) means feedback and testing can send you back to earlier phases, so if user testing reveals a missing feature, you update the requirements and revisit your design. Requirements are a living document, not a one-time checklist.
User Interface (UI) (Unit 1)
Requirements often describe user interactions the program must provide, and the UI is where those interactions actually happen. You can't design a good interface until you know what users need to do with it, which is exactly why LO 1.3.B pairs designing a program with designing its UI.
Functional Testing (Unit 1)
Testing only makes sense if there's a target. Functional testing checks whether the program actually does what the requirements say it should, so requirements written during design become the pass/fail criteria used later in the process.
Program Documentation (Unit 1)
Requirements describe what the program should do before it's built; documentation (EK CRD-2.G.1) describes what code does and how it was developed. Both are written records that keep a team on the same page, especially in collaborative environments.
This is multiple-choice territory. Expect scenario questions like a developer building a mobile banking app where you pick what belongs in program requirements documentation, or a team that discovers mid-investigation that users need a feature missing from the original requirements (correct move: revise the requirements, because the process is iterative). Another common stem asks which interview question would yield the most valuable information for establishing requirements. The pattern across all of these is the same skill: know that requirements come from investigation of real users, describe program function and user interactions, and can be revised as the development process loops back on itself. You won't write requirements on the exam, but you'll constantly judge whether a team is handling them correctly.
Requirements say what the program SHOULD do; documentation explains what the code DOES do and how it was developed. Requirements come first, produced by investigating user needs during design. Documentation (including comments) is written throughout development to describe code segments, procedures, and the program itself. A requirement might say "users must be able to log in," while documentation explains how the login procedure you wrote actually works.
Program requirements describe how a program functions and may include the user interactions the program must provide.
Requirements come from investigation, not guesswork, using surveys, user testing, interviews, and direct observations.
Investigation also identifies program constraints and the concerns and interests of the people who will use the program.
Because development is iterative, requirements can be revised when feedback or testing reveals new user needs.
Requirements drive the rest of the process, since UI design, prototyping, and functional testing are all measured against them.
Program requirements describe how a program functions and may include the user interactions it must provide. In the CED (EK CRD-2.F.1), they're determined through investigation during the design phase of development.
No. Requirements describe what a program should do before it's built, while documentation describes what the code actually does and how it was developed. Documentation includes comments; requirements come from investigating user needs.
Through investigation. The CED lists four methods: collecting data through surveys, user testing, interviews, and direct observations. These reveal user needs, concerns, and program constraints.
Yes. An iterative development process requires refinement based on feedback, testing, or reflection, which can mean revisiting earlier phases. If users need a feature that wasn't in the original requirements, the right move is to update the requirements, not ignore the discovery.
You won't submit a formal requirements document, but the Create task expects a program with a clear purpose and function. Knowing your program's requirements up front makes describing its purpose and testing it far easier.