CS I · Tue Nov 3 · 14.2 · Do Now

Requirements a Person Can Test

Open the discussion form on the right and answer Section 1 from your first reading.

Announcements

Specifications, Requirements and Tests

This section explains how a builder writes down what a tool must do, and how another person can check that the tool does it.

From a Purpose to a Specification

On Oct 26, the class described every tool by its input, processing and output, which explains how a tool works but not what one particular tool must do. A specification is a written description of what a tool must do, exact enough that someone can build from it and someone else can check the result. A specification usually begins with a purpose sentence, which says what the tool is for. The class's example tool, Code Coach, has this purpose sentence: "Code Coach helps a student understand a short piece of Java while reading it." A purpose sentence alone is not a specification, because it says what the tool is for and not what the tool must do. A builder could read it and still not know what Code Coach should do when someone gives it plain English instead of Java.

Requirements That Can Be Tested

A requirement is one statement of something the tool must do. A requirement can be tested when it names a result that a person can observe. NASA's checklist for writing good requirements asks whether a system can be tested, demonstrated, inspected or analyzed to show that it meets each requirement. The same checklist asks whether there is a way to measure the result. Code Coach has five requirements, shown below. R1 to R4 describe Code Coach's answers, and R5 describes the bench, the page around Code Coach, so R5 is built into the bench's code.

R1. Code Coach explains only the Java the student asked about.
R2. Every explanation names what the code prints or stores, if it prints or stores anything.
R3. Code Coach does not write new code for the student.
R4. When the input is not Java, Code Coach says so and asks for a Java snippet.
R5. When no line is picked, the bench shows "Paste or pick a line first." and sends no request.

The sentence "Code Coach should be smart" is a wish. It names no result that anyone can check, because nothing in it can be counted, seen or compared, so no test is possible. NASA's checklist names words such as "flexible," "sufficient" and "adequate" as words to avoid in a requirement for the same reason. A rule about speed becomes testable once it has a number, because the word "fast" alone cannot be checked, but a rule that Code Coach answers within 10 seconds can be timed with a clock.

Writing a Test for Each Requirement

A test is a check with three parts: an input, the output that is expected, and a comparison with what the tool actually does. NASA describes a test as using the finished product to collect data on whether each requirement is met. Reading a requirement a second time is not a test, because a test uses the tool. Figure 1 shows one test for each of Code Coach's requirements. These tests were written for this lesson, so the result column is still empty.

The test for R1 gives Code Coach a three-line snippet and picks line 2 only, so the expected output is an explanation of line 2 and of no other line. The test for R2 uses one of Code Coach's three test inputs, shown below with the output that real Java prints.

1int x = 7 / 2;
2System.out.println(x);
3

Because real Java prints 3, the test expects the explanation to say that x stores 3 and that 3 is printed. The test for R3 asks Code Coach to write a program that prints the student's name, and the expected output contains no new code. The test for R4 uses another test input, a request for help writing an essay about the Louisiana Purchase. That input is plain English, so the expected output says the input is not Java and asks for a Java snippet.

The test for R5 leaves the line choice on "Pick…" and presses Ask. The expected output is the message "Paste or pick a line first." with no request sent. A person can observe the second part, because the button never changes to "Asking…" and no answer appears. Each test writes down its input and expected output before it runs, so another person can run it again later and make the same comparison.

Rewriting a Wish as a Requirement

To rewrite a wish as a requirement, a builder first asks what a person would see if the wish came true, and then writes that result down. For example, "The bench should be clear about mistakes" is a wish. A student using the bench would see the words "Not yet" after a wrong answer, and the correct answer would stay hidden. The requirement could read, "When a check is wrong, the bench shows 'Not yet' and does not show the answer." A test for it enters one wrong answer and checks for both results.

Summary

A specification describes what a tool must do, and a purpose sentence is only where it starts. A requirement can be tested when it names a result a person can observe, and a wish such as "Code Coach should be smart" names none. A test gives an input, the expected output and a comparison with what the tool actually does.

Sources: NASA, Appendix C: How to Write a Good Requirement (n.d.); NASA, 5.3 Product Verification (n.d.); CS I, Code Coach README (2026); CS I, Code Coach panel source (2026); CS I, Build Spec v2.0 (2026); CS I, Input, Processing and Output (2026).

I Do questions
  1. notebook cue: specification

    Code Coach has a purpose sentence. What is still missing before someone could build it and check it?

    Check

    The requirements are missing, along with a test for each one. The purpose sentence says what Code Coach is for, but not what it must do, such as what to do when the input is not Java. See From a Purpose to a Specification.

  2. notebook cue: requirement

    Which one can be tested: "Code Coach is smart," or "When the input is not Java, Code Coach says so"? What makes the difference?

    Check

    "When the input is not Java, Code Coach says so" can be tested, because it names a result a person can observe in the answer. "Smart" names nothing that can be counted, seen or compared. See Requirements That Can Be Tested, paragraph 2.

  3. notebook cue: test

    R3 says Code Coach does not write new code for the student. Describe a test for it: the input, what you expect, and what you compare.

    Check

    The input asks Code Coach to write a program, such as one that prints your name. The expected output contains no new code, and the test compares that expectation with the answer Code Coach actually gives. See Writing a Test for Each Requirement and the R3 row of Figure 1.

Figure 1. Each of Code Coach's five requirements has a test input and a result a person should see, while the wish "Code Coach should be smart" has no test.
I Do questions
  1. notebook cue: specification

    Code Coach has a purpose sentence. What is still missing before someone could build it and check it?

    Check

    The requirements are missing, along with a test for each one. The purpose sentence says what Code Coach is for, but not what it must do, such as what to do when the input is not Java. See From a Purpose to a Specification.

  2. notebook cue: requirement

    Which one can be tested: "Code Coach is smart," or "When the input is not Java, Code Coach says so"? What makes the difference?

    Check

    "When the input is not Java, Code Coach says so" can be tested, because it names a result a person can observe in the answer. "Smart" names nothing that can be counted, seen or compared. See Requirements That Can Be Tested, paragraph 2.

  3. notebook cue: test

    R3 says Code Coach does not write new code for the student. Describe a test for it: the input, what you expect, and what you compare.

    Check

    The input asks Code Coach to write a program, such as one that prints your name. The expected output contains no new code, and the test compares that expectation with the answer Code Coach actually gives. See Writing a Test for Each Requirement and the R3 row of Figure 1.

Specifications, Requirements and Tests

This section explains how a builder writes down what a tool must do, and how another person can check that the tool does it.

From a Purpose to a Specification

On Oct 26, the class described every tool by its input, processing and output, which explains how a tool works but not what one particular tool must do. A specification is a written description of what a tool must do, exact enough that someone can build from it and someone else can check the result. A specification usually begins with a purpose sentence, which says what the tool is for. The class's example tool, Code Coach, has this purpose sentence: "Code Coach helps a student understand a short piece of Java while reading it." A purpose sentence alone is not a specification, because it says what the tool is for and not what the tool must do. A builder could read it and still not know what Code Coach should do when someone gives it plain English instead of Java.

Requirements That Can Be Tested

A requirement is one statement of something the tool must do. A requirement can be tested when it names a result that a person can observe. NASA's checklist for writing good requirements asks whether a system can be tested, demonstrated, inspected or analyzed to show that it meets each requirement. The same checklist asks whether there is a way to measure the result. Code Coach has five requirements, shown below. R1 to R4 describe Code Coach's answers, and R5 describes the bench, the page around Code Coach, so R5 is built into the bench's code.

R1. Code Coach explains only the Java the student asked about.
R2. Every explanation names what the code prints or stores, if it prints or stores anything.
R3. Code Coach does not write new code for the student.
R4. When the input is not Java, Code Coach says so and asks for a Java snippet.
R5. When no line is picked, the bench shows "Paste or pick a line first." and sends no request.

The sentence "Code Coach should be smart" is a wish. It names no result that anyone can check, because nothing in it can be counted, seen or compared, so no test is possible. NASA's checklist names words such as "flexible," "sufficient" and "adequate" as words to avoid in a requirement for the same reason. A rule about speed becomes testable once it has a number, because the word "fast" alone cannot be checked, but a rule that Code Coach answers within 10 seconds can be timed with a clock.

Writing a Test for Each Requirement

A test is a check with three parts: an input, the output that is expected, and a comparison with what the tool actually does. NASA describes a test as using the finished product to collect data on whether each requirement is met. Reading a requirement a second time is not a test, because a test uses the tool. Figure 1 shows one test for each of Code Coach's requirements. These tests were written for this lesson, so the result column is still empty.

The test for R1 gives Code Coach a three-line snippet and picks line 2 only, so the expected output is an explanation of line 2 and of no other line. The test for R2 uses one of Code Coach's three test inputs, shown below with the output that real Java prints.

1int x = 7 / 2;
2System.out.println(x);
3

Because real Java prints 3, the test expects the explanation to say that x stores 3 and that 3 is printed. The test for R3 asks Code Coach to write a program that prints the student's name, and the expected output contains no new code. The test for R4 uses another test input, a request for help writing an essay about the Louisiana Purchase. That input is plain English, so the expected output says the input is not Java and asks for a Java snippet.

The test for R5 leaves the line choice on "Pick…" and presses Ask. The expected output is the message "Paste or pick a line first." with no request sent. A person can observe the second part, because the button never changes to "Asking…" and no answer appears. Each test writes down its input and expected output before it runs, so another person can run it again later and make the same comparison.

Rewriting a Wish as a Requirement

To rewrite a wish as a requirement, a builder first asks what a person would see if the wish came true, and then writes that result down. For example, "The bench should be clear about mistakes" is a wish. A student using the bench would see the words "Not yet" after a wrong answer, and the correct answer would stay hidden. The requirement could read, "When a check is wrong, the bench shows 'Not yet' and does not show the answer." A test for it enters one wrong answer and checks for both results.

Summary

A specification describes what a tool must do, and a purpose sentence is only where it starts. A requirement can be tested when it names a result a person can observe, and a wish such as "Code Coach should be smart" names none. A test gives an input, the expected output and a comparison with what the tool actually does.

Sources: NASA, Appendix C: How to Write a Good Requirement (n.d.); NASA, 5.3 Product Verification (n.d.); CS I, Code Coach README (2026); CS I, Code Coach panel source (2026); CS I, Build Spec v2.0 (2026); CS I, Input, Processing and Output (2026).

Table Talk
Someone tells the builder of Code Coach, "Make it smart." Could a person check whether that was done? Answer yes or no, then rewrite it as one sentence a person could check.

Each table decides yes or no, then rewrites "Make it smart" as one sentence a person could check, and says how they would check it.

Chromebooks stay closed while your table talks. Sections 1 and 2 of the discussion form are already done. After you talk, finish Section 3 right here under My View. Submit before the exit ticket.

Open the discussion form

This form has three sections. Section 1: answer today's Board Question. Section 2: after the reading. Section 3 opens later in class. Today's Board Question: Someone tells the builder of Code Coach, "Make it smart." Could a person check whether that was done? Answer yes or no, then rewrite it as one sentence a person could check.

CR 1. Board Question: Someone tells the builder of Code Coach, "Make it smart." Could a person check whether that was done? Answer yes or no, then rewrite it as one sentence a person could check. Give your answer and one reason.

Write your answer in your lab notebook, labeled CR 1.

MC 1. Think about your answer to the board question. Someone tells the builder of Code Coach, "Make it smart." Could a person check whether that was done? Answer yes or no, then rewrite it as one sentence a person could check. Which position is closest to yours now?

  • Yes. A person can use it and decide whether it seems smart.
  • No. "Smart" does not name a result that anyone can check.
  • Only if everyone first agrees on what "smart" means.

MC 2. (Reading claim 1) A requirement that cannot be tested is still useful to a builder.

  • Agree
  • Disagree

MC 3. (Reading claim 2) A good test can be run again by another person.

  • Agree
  • Disagree

MC 4. (Reading claim 3) A purpose sentence is enough to build a tool from.

  • Agree
  • Disagree

MC 5. (Reading claim 4) A test needs an input, an expected output and a comparison with what the tool actually does.

  • Agree
  • Disagree

MC 6. (Reading claim 5) In Figure 1, the test for R5 sends a request to Code Coach and waits for its answer.

  • Agree
  • Disagree

MC 7. (Reading claim 6) In Reading 2, the comment lines at the top of the program run before main does.

  • Agree
  • Disagree

MC 8. (Reading claim 7) A rule about speed can be tested once it gives a number, such as an answer within 10 seconds.

  • Agree
  • Disagree

MC 9. (Reading claim 8) In Reading 2's program, the last line to run is line 11, which prints Exit ticket.

  • Agree
  • Disagree

CR 2. (A different view) Write the view at your table that was most different from yours. If everyone agreed, write the strongest argument against your table's answer.

Write your answer in your lab notebook, labeled CR 2.

CR 3. Think about the Board Question again: Someone tells the builder of Code Coach, "Make it smart." Could a person check whether that was done? Answer yes or no, then rewrite it as one sentence a person could check. Do you have the same opinion as when you first answered the board question? If it is the same, what from the reading or table talk reaffirmed your opinion? If it is different, what from the reading or table talk changed your opinion?

Write your answer in your lab notebook, labeled CR 3.