Module
Module 3 of 5Lesson 2 of 2~16 min

Edge cases and non-functional requirements

Production incidents often come from a case no one wrote down or a performance requirement that stayed implicit. This lesson helps you find the situations at the edges of a feature methodically and express its non-functional requirements in a testable way, so neither the team nor a coding agent has to guess them.

Take this lesson: your first course is freeSee the full syllabus

Lesson objective

By the end of this lesson, you will be able to find a feature's edge cases methodically with a grid of questions, and write its non-functional requirements (performance, reliability, security, accessibility, personal data) in a quantified, testable form.

Topics covered

  • edge cases
  • non-functional requirements
  • NFR
  • accessibility requirements
  • performance and reliability

Where it fits

Criteria, edge cases and requirements

How do you write criteria you can verify, and not forget what happens when things do not go as planned?

Lessons in this module

  1. Write verifiable Given / When / Then criteria
  2. Edge cases and non-functional requirements (this lesson)

What you will learn in the course

This lesson is part of the course Write specs that developers and AI agents understand

  • Choose the level of spec suited to the decision at hand (PRD, feature spec, ticket) and know what each must contain.
  • State the intent of a feature (problem, target outcome, constraints, non-goals) separately from the solution, to leave the right room to the team and the agent.
  • Write verifiable, declarative and unambiguous Given/When/Then acceptance criteria, including as tables of examples.
  • Identify edge cases and non-functional requirements (performance, security, accessibility, personal data) and make them testable.
  • Write a spec and an intent file that a coding agent can use (context, constraints, files involved, out of scope, verifiable definition of done).
  • Review a coding agent's plan against the spec, spot gaps before it writes code, then check the evidence of what was delivered.
  • Keep a spec alive (versions, decisions, updates when the code reveals a case) and spot the anti-patterns that make it useless.

Related courses