Skip to content

Quiz: Technical Documentation and Requirements

Test your understanding of technical documentation, engineering specifications, functional and non-functional requirements, and debugging basics with these review questions.

1. What is the primary definition of technical documentation given in this chapter?

  1. Marketing materials and user guides written for external customers
  2. The collection of written materials that describe how a software system is designed, built, operated, and maintained
  3. Code comments written inline by developers to explain their logic
  4. The product roadmap and strategy documents shared with executive leadership
Show Answer

The correct answer is B. The chapter defines technical documentation as the collection of written materials that describe how a software system is designed, built, operated, and maintained. It encompasses everything from high-level architecture overviews to detailed API references, from product requirement documents to runbooks. Unlike marketing or user-facing content, technical documentation is written primarily for internal audiences such as engineers, QA teams, DevOps, and technical PMs.

Concept Tested: Technical Documentation

2. What is a software bug?

  1. A planned feature that has not yet been implemented by the development team
  2. A performance optimization that the engineering team has deprioritized
  3. An error, flaw, or unintended behavior in a software program that causes incorrect results, unexpected behavior, or crashes
  4. A security vulnerability that has been intentionally introduced for testing purposes
Show Answer

The correct answer is C. The chapter defines a software bug as an error, flaw, or unintended behavior in a software program that causes it to produce incorrect results, behave unexpectedly, or crash. Bugs arise from many sources including logic errors, off-by-one errors, race conditions, null references, integration failures, and unhandled edge cases. The chapter emphasizes that not all bugs are equal and provides a severity table from Critical (P0) to Low (P3) for triage.

Concept Tested: Software Bug

3. According to the chapter, what distinguishes functional requirements from non-functional requirements?

  1. Functional requirements are written by engineers while non-functional requirements are written by PMs
  2. Functional requirements describe what the system must do, while non-functional requirements describe how well the system must perform
  3. Functional requirements apply to the frontend only, while non-functional requirements apply to the backend only
  4. Functional requirements are optional enhancements, while non-functional requirements are mandatory constraints
Show Answer

The correct answer is B. The chapter clearly distinguishes these two types: functional requirements describe what the system must do (specific behaviors, features, and capabilities that users and other systems can observe), while non-functional requirements describe how well the system must perform its functions (quality attributes such as performance, security, scalability, usability, and reliability). The chapter illustrates this with the example of a search feature that returns correct results (functional) but takes 15 seconds (fails non-functional).

Concept Tested: Functional Requirements

4. Which six steps make up the debugging process described in this chapter?

  1. Report, assign, estimate, code, test, deploy
  2. Observe, hypothesize, experiment, conclude, publish, review
  3. Reproduce, isolate, diagnose, fix, verify, prevent
  4. Detect, log, alert, escalate, patch, document
Show Answer

The correct answer is C. The chapter outlines the typical debugging process in six steps: Reproduce (reliably make the bug happen), Isolate (narrow down which component causes the problem), Diagnose (read logs, inspect variables, trace execution to find root cause), Fix (modify the code to correct the underlying issue), Verify (confirm the fix resolves the bug without introducing new ones), and Prevent (add tests or monitoring to catch similar issues in the future).

Concept Tested: Debugging Basics

5. Why does the chapter describe non-functional requirements as "frequently overlooked" by product teams, and what risk does this create?

  1. They are overlooked because they are less important than functional requirements and rarely affect user experience
  2. They are overlooked because engineers handle them automatically, so PMs do not need to specify them
  3. They are overlooked because they are difficult to test, and this creates risk of delayed launches due to missing test coverage
  4. They are treated as afterthoughts, and discovering performance or scalability needs late may require a fundamentally different architecture
Show Answer

The correct answer is D. The chapter includes a specific warning called "The NFR Trap," explaining that non-functional requirements are frequently treated as afterthoughts. Engineers may ask "what are the performance requirements?" late in development, only to discover that meeting them requires a fundamentally different architecture. The chapter advises technical PMs to push for non-functional requirements to be defined alongside functional ones during the planning phase to avoid this costly risk.

Concept Tested: Non-Functional Requirements

6. What strategy does the chapter recommend for learning technical jargon effectively?

  1. Memorize a comprehensive engineering glossary before starting in the role
  2. Avoid using technical terms altogether and ask engineers to translate into business language
  3. Learn terms organically in context by paying attention during meetings, asking questions, and building a personal glossary
  4. Enroll in a computer science degree program to gain formal technical vocabulary training
Show Answer

The correct answer is C. The chapter explicitly states that the most effective approach to learning technical jargon is not memorizing a glossary. Instead, it recommends paying attention to terms as they come up in meetings, asking engineers to explain them in context, and building vocabulary organically. The chapter also suggests creating a personal glossary in a note-taking app, adding terms with the context where you encountered them, and reviewing weekly. It notes that engineers respect curiosity far more than false confidence.

Concept Tested: Technical Jargon

7. According to the engineering specification structure in the chapter, what should a PM look for in the "Goals and Non-Goals" section?

  1. Whether the engineering team has estimated the correct number of sprints
  2. Whether the non-goals are acceptable trade-offs for the current release
  3. Whether the technical design uses the most modern frameworks available
  4. Whether the testing plan covers all edge cases identified in the requirements
Show Answer

The correct answer is B. The chapter's engineering specification table maps each section to what PMs should look for. For the "Goals and Non-Goals" section, PMs should evaluate whether the non-goals are acceptable trade-offs. This section scopes what is and is not included in the implementation. Understanding what the team has explicitly decided not to build is critical for ensuring that deferred items will not leave noticeable gaps for users.

Concept Tested: Engineering Specifications

8. In the bug severity table, which severity level describes a scenario where a workaround exists for a partially broken feature?

  1. Critical (P0)
  2. High (P1)
  3. Medium (P2)
  4. Low (P3)
Show Answer

The correct answer is C. The chapter's bug severity table classifies Medium (P2) bugs as "Feature partially broken, workaround exists," with the example of an export to PDF feature that generates blurry images. The expected response time is "Next sprint." This contrasts with Critical (P0) which demands immediate action, High (P1) which requires resolution within 24 hours, and Low (P3) which goes to the backlog.

Concept Tested: Software Bug

9. A PM is drafting a technical specification for a new search feature. Based on the anatomy of an effective tech spec described in this chapter, which of the following would belong in the "Out of Scope" section?

  1. The search service must return results within 200 milliseconds
  2. The API will accept GET requests with query parameters for search terms and filters
  3. This specification does not cover voice-based search or image search capabilities
  4. Success will be measured by a 25% increase in search engagement within 30 days
Show Answer

The correct answer is C. The chapter lists ten components of an effective technical specification, including an "Out of scope" section that explicitly states what the specification does not cover. Declaring that voice-based and image search are out of scope sets clear boundaries and prevents scope creep. Option A is a non-functional requirement, option B belongs in API contracts, and option D belongs in success metrics, all of which are separate sections of the tech spec.

Concept Tested: Technical Specifications

10. Analyzing the relationship between business requirements and technical requirements as described in this chapter, which statement best characterizes how they differ?

  1. Business requirements and technical requirements are interchangeable terms for the same type of document
  2. Business requirements specify what the product must achieve based on user needs, while technical requirements specify what the system must do to fulfill those business requirements with precise, implementable detail
  3. Technical requirements are written first and business requirements are derived from them afterward
  4. Business requirements focus on the engineering implementation while technical requirements focus on the market opportunity
Show Answer

The correct answer is B. The chapter explains that the relationship between business and technical requirements flows in one direction: business requirements state what the product must achieve (driven by user needs and strategy), then technical requirements state what the system must do to fulfill those business requirements (driven by engineering constraints and best practices). The chapter illustrates this with the example of a business requirement ("Users should be able to search for products") being translated into a technical requirement with precise specifications (200ms response time, 10 million items, full-text search with typo tolerance).

Concept Tested: Technical Requirements