Quiz — Chapter 33: Writing for Engineering

Target: 70%+ before moving on. Answers and explanations are hidden—try each before expanding.

Section 1 — Multiple Choice

1. What is the single defining property that separates an engineering requirement from a wish?

  • A) It is written in formal language
  • B) It uses the word "shall"
  • C) It is testable—there's a method that returns pass or fail
  • D) It appears in a numbered list
Answer**C.** Testability is the threshold of the chapter: a requirement is a commitment that will be verified, so if no method (Test/Inspection/Demonstration/Analysis) decides pass or fail, it commits no one to anything—it's a wish. Formal language (A) and numbering (D) are cosmetic. "Shall" (B) signals obligation *strength* but doesn't make an untestable statement testable—"the system shall be fast" is still a wish. (§33.2)

2. In RFC 2119, SHALL and MUST:

  • A) Mean opposite things
  • B) Mean the same thing (an absolute requirement)
  • C) SHALL is stronger than MUST
  • D) MUST is for hardware, SHALL is for software
Answer**B.** RFC 2119 defines SHALL and MUST as synonyms—both mean an absolute, mandatory requirement. There's no strength difference (C). The *convention* of which to prefer varies by field (software/internet specs often use MUST; systems/aerospace/defense prefer SHALL), but that's a style choice, not the reverse of what D claims, and it doesn't change their identical meaning. (§33.3)

3. Which keyword correctly expresses "a strong default you can deviate from only with a carefully considered, documented reason"?

  • A) SHALL
  • B) SHOULD
  • C) MAY
  • D) WILL
Answer**B.** That is exactly the definition of SHOULD (RECOMMENDED): do it unless you have a good, deliberate reason not to. SHALL (A) is mandatory with no escape hatch; MAY (C) is truly optional; WILL (D) is not an RFC 2119 keyword and is best reserved for statements of fact, not obligations. (§33.3)

4. A requirement reads: "The system shall log all access attempts and notify the administrator of failures." The primary defect is that it is:

  • A) Untestable
  • B) Compound (two requirements in one)
  • C) Using the wrong keyword
  • D) Informative, not normative
Answer**B.** It bundles two distinct obligations (log access attempts; notify the admin of failures) into one statement, so it can't be tracked or marked pass/fail as a unit—if logging works but notification doesn't, the requirement is neither pass nor fail. Split it at the "and." The keyword (SHALL) is fine, and each half *could* be made testable; the compounding is the first thing to fix. (§33.2)

5. "The system shall use a Redis cache" in a requirements document is problematic because:

  • A) Redis is not allowed in requirements
  • B) It specifies the how (a design decision) instead of the what (the outcome to verify)
  • C) It uses SHALL incorrectly
  • D) Caches can't be tested
Answer**B.** It bakes an implementation choice into a requirement, taking the decision away from the designers and possibly over-constraining the solution. The requirement should specify the outcome ("shall return results within 500 ms"); *how* to achieve it (a cache, and which one) belongs in the design document. There are rare exceptions (when a specific technology is genuinely required), but the default is specify the *what*, leave the *how* to design. (§33.4)

6. A test report records "PASS" for a 500 ms requirement but omits the measured value. The best reason this is a problem:

  • A) Reports must always be long
  • B) The verdict hides the margin (50 ms vs. 498 ms are both "PASS" but mean very different things for risk)
  • C) PASS is not a valid result
  • D) Requirements can't have numbers
Answer**B.** A bare "PASS" conceals decision-relevant information: huge headroom (50 ms) and a two-millisecond margin (498 ms) are both passes but tell opposite stories about robustness. Recording the actual number is the same discipline as [Chapter 13](../../part-03-academic-scientific-writing/chapter-13-lab-reports/index.md)'s Results section—report the observation, not just your conclusion about it—so the reader can judge the evidence. (§33.6)

7. The four standard verification methods for a requirement are:

  • A) Read, Review, Approve, Sign
  • B) Test, Inspection, Demonstration, Analysis
  • C) Unit, Integration, System, Acceptance
  • D) Draft, Review, Revise, Publish
Answer**B.** Test (exercise and measure), Inspection (examine directly), Demonstration (operate and observe without instrumented measurement), Analysis (model/calculate/simulate where testing is impractical). If you can't assign one of these to a requirement, the requirement isn't finished. (C) lists software *test levels*, not verification *methods*. (§33.2)

8. Normative text in a specification is:

  • A) Explanation, rationale, and background
  • B) The binding requirements (the SHALLs and SHOULDs)
  • C) The front matter and approvals
  • D) The figures and tables
Answer**B.** Normative text is the binding part—the actual requirements. *Informative* text (A) is the non-binding explanation/rationale/examples. Good specs keep them visibly separate so a reader knows instantly whether a sentence is a commitment or a comment; blurring them can turn an offhand explanation into an unintended requirement. (§33.3)

9. The most valuable—and most often omitted—section of a design document is usually:

  • A) The title page
  • B) The list of requirements
  • C) The "alternatives considered," with the reason each was rejected
  • D) The author's name
Answer**C.** Recording *why you rejected the alternatives* is what turns a design doc from "trust me" into checkable reasoning, and it's what a future maintainer most needs ("why did they do it this way?"). Authors most often skip it because the reasoning felt obvious at the time—but that's exactly the knowledge that evaporates. (§33.5)

10. Why is "approximately 100 mm" a defect in a manufacturing dimension requirement?

  • A) Round numbers aren't allowed
  • B) It hides the tolerance—a manufacturer can't tell whether a 101 mm part passes
  • C) Millimeters are the wrong unit
  • D) It should say "shall"
Answer**B.** In engineering, "approximately" without a tolerance is a missing specification, not modesty. A manufacturer builds to a value *and a tolerance*; without the tolerance ("100 mm ± 0.5 mm") they can't decide whether an out-of-round part passes or fails. The tolerance *is* the requirement. (§33.2)

11. A requirement with no entry in the Source column of the traceability matrix most likely indicates:

  • A) A typo
  • B) Gold-plating—a feature nobody actually asked for
  • C) A missing test
  • D) A formatting error
Answer**B.** If a requirement traces back to no stakeholder need or parent requirement, it may be something the team added that nobody asked for (gold-plating). (A blank *test* column would mean the requirement is unverified—a different failure.) The traceability matrix exists to make both kinds of blank visible. (§33.4)

12. The chapter argues engineering writing differs from other technical writing primarily because:

  • A) Engineers use more jargon
  • B) The document comes before the thing (you build to the spec), and it's read adversarially
  • C) It's always longer
  • D) It avoids the active voice
Answer**B.** Two structural differences: the document precedes the artifact (so a vague sentence gets the *wrong thing built*, not merely misread), and it's read adversarially (by testers, auditors, investigators), so precision functions as self-defense. Neither jargon (A), length (C), nor voice (D) is the defining difference. (§33.1)

Section 2 — True/False with Justification

State true or false and give the one-sentence reason.

T1. "To be safe, you should make every requirement a SHALL."

Answer**False.** An all-SHALL spec has prioritized nothing and ties the implementer's hands on requirements that should be tradeable—SHOULD exists precisely so you can mark a strong default you can deviate from with reason; reserve SHALL for the genuinely non-negotiable. (§33.3, §33.10)

T2. A requirement and a design statement say the same kind of thing in different words.

Answer**False.** A requirement states the *what* (the outcome to verify, e.g., "shall return results within 500 ms"); a design statement states the *how* and *why* (e.g., "uses a cache because…"). Keeping them separate leaves implementation decisions to the engineers and keeps requirements verifiable. (§33.4–33.5)

T3. A test case is, structurally, a kind of procedure.

Answer**True.** A test case has preconditions ("Before you begin"), numbered imperative steps, and an expected result—exactly [Chapter 22](../../part-04-professional-workplace-writing/chapter-22-instructions-procedures/index.md)'s procedure anatomy—plus a requirement ID it verifies and an unambiguous pass/fail criterion. (§33.6)

T4. An engineering notebook is more valuable if it's written up neatly after the project, once you know how things turned out.

Answer**False.** The notebook's value as memory and as legal/patent evidence depends on it being *contemporaneous*—a true record written as you work, including the dead ends—not a tidy reconstruction. "Tuned the controller. Works now." is worthless; the dated entry with values, observations, and the open question is the point. (§33.8)

T5. In safety documentation, it's acceptable to soften a known risk's wording to avoid alarming the reader.

Answer**False.** Safety documentation is where the buried/softened risk becomes lethal (the Challenger lesson): state the risk plainly, give it the prominence its severity warrants, and calibrate language to the evidence—softening "possible" into "unlikely" under pressure is exactly the failure to avoid. (§33.7)

T6. "The system shall be user-friendly" is a poor requirement mainly because "shall" is too strong.

Answer**False.** The keyword is fine; the defect is that "user-friendly" is *untestable*—no Test/Inspection/Demonstration/Analysis returns pass/fail on it, and two reviewers would disagree. Replace it with the specific, verifiable behaviors you actually mean. (§33.2)

Section 3 — Short Answer

S1. Write the test-the-requirement question you should ask of every requirement you write, in one sentence.

Model answer + rubric*"What test (Test/Inspection/Demonstration/Analysis) returns pass or fail on this, and would two engineers run the same test and get the same answer?"* **Rubric:** must capture both *a verification method exists* and *the result is unambiguous across people*. (§33.2)

S2. Turn "the system should be fast" into a testable SHALL requirement, then name its verification method.

Model answer + rubric*"REQ-PERF-001. The system SHALL return search results within 500 ms at the 95th percentile, measured at the API boundary, under a sustained load of 1,000 concurrent users. **Verification:** Test—run a 10-minute load test at 1,000 users and measure the p95 response time."* **Rubric:** must include (1) SHALL, (2) a measurable value, (3) the condition, (4) a named verification method. Exact numbers may vary. (§33.2–33.3)

S3. In one or two sentences, explain why a standardized keyword like SHALL communicates more reliably than the ordinary sentence "the system needs to encrypt passwords."

Model answer + rubricSHALL has one published, agreed meaning, so it removes the reader's need to *infer* obligation strength from tone—and inference is where disagreements hide. "Needs to" could be read as mandatory, recommended, or descriptive; a defined keyword collapses that interpretive space the way a legal term of art or an SI unit does. **Rubric:** must name the removal of *inference/interpretation* as the mechanism. (§33.3)

S4. Name the three properties of a well-formed requirement and give a one-word failure example of each.

Model answer + rubric**Atomic** (failure: a compound "log and notify"), **Unambiguous** (failure: "fast"), **Testable** (failure: "user-friendly," which has no verification method). **Rubric:** all three named with a plausible failure each. (§33.2)

S5. Why must a test report record the actual measured value, not just "PASS"?

Model answer + rubricBecause the verdict hides the margin, and the margin is decision-relevant: a pass at 50 ms (robust) and a pass at 498 ms against a 500 ms requirement (fragile) tell opposite stories about risk, and a reader making a ship decision needs to know which. **Rubric:** must connect the *number* to *margin/risk/decision*. (§33.6)

Section 4 — Applied Scenario

AS1. You receive this requirement from a stakeholder for a new feature: "The export function should work well with large files and not crash or take forever." Rewrite it as a small set of proper requirements (expect to find at least three hiding in it). Then write a one-line verification method for each. Grade yourself with the rubric below.

RubricA strong answer splits the statement into roughly: (1) a *functional* requirement (the export SHALL produce a valid file of the specified format), (2) a *performance* requirement with a value and condition (SHALL export a file of N records within T seconds), and (3) a *reliability/error* requirement (SHALL NOT crash on a file up to the supported maximum; SHALL return a specific error above it). Each has an ID, a correct RFC 2119 keyword, a measurable criterion, and a named verification method. Full marks: no weak words survive ("work well," "forever," "large" all replaced with values and conditions), and the "doesn't crash" wish became a bounded, testable statement (max supported size + defined behavior beyond it).

AS2. A junior engineer's design doc says only: "We chose microservices for the new platform." Write the two or three sentences that should accompany that decision (the why, the forcing constraint, and at least one alternative considered with the reason it was rejected). Grade against the rubric.

RubricFull marks: states the *forcing constraint* (e.g., independent team deployment cadence, fault isolation, or scaling a hotspot independently—something concrete), names the chosen approach, and gives at least one **alternative considered with a specific rejection reason** (e.g., "a modular monolith—rejected because the deploy coupling between teams was the actual bottleneck, not module boundaries"). Partial marks if it states a benefit but no rejected alternative; that's the section's whole point.

Scoring & Next Steps

Score What it means Do this
< 50% The core distinction (requirement vs. wish; SHALL/SHOULD/MAY) hasn't landed Re-read §33.2–33.3, then redo Section 1
50–70% You get the ideas but miss them in practice Redo Exercises Part B (the rewrites)—especially B7
70–85% Solid. You can write and audit requirements Proceed to Chapter 34; try Exercises Part D
> 85% Strong command Try Exercises Part E (audit a real spec) and the Deep Dive case study

The whole chapter compresses to one habit: write the test in your head as you write the requirement. If you can't picture the test, you haven't finished the requirement.