§6 도입부와 §9 가 같은 말을 두 번 한다.
"하나의 요구사항에는 하나의 주요 동작 또는 독립적으로 검증 가능한 목적을 작성한다."
한 문장에 두 결과를 넣으면 판정이 애매해진다
✗ "끼임 위험을 감지한 경우 닫힘을 정지하고 보호 위치까지 열어야 한다"
→ 정지는 됐는데 보호 동작이 안 되면? "부분 통과"라는 판정은 없다
✓ "… 진행 중인 닫힘 동작을 즉시 정지해야 한다"
✓ "… 정의된 보호 위치까지 열림 방향의 보호 동작을 수행해야 한다"
→ 두 개의 독립 시험 항목. 결함 위치가 정확히 특정된다
"감지는 되는데 정지가 늦다"와 "정지는 하는데 열림 보호를 안 한다"는 완전히 다른 결함이고, 분리된 요구사항만이 이 둘을 구분해 낸다.
우선순위를 사슬로 쓰는 이유
§6.2.1 은 "스위치 > HMI > 원격 > 자동환기"를 한 문장이 아니라 세 문장으로 쓴다. 그래야 "스위치 vs 원격"을 검증하는 근거 요구사항이 명확히 존재한다. §6.4.3 의 표시 우선순위 도 같은 방식이다.
중복이 아니라 검증 가능성을 위한 의도적 반복이다.
생성과 해제를 쌍으로 쓴다
이 문서는 상태를 만드는 요구사항 옆에 반드시 지우는 요구사항을 둔다. "상태를 만드는 코드는 누구나 쓰고 지우는 코드를 빼먹는다" — 요구사항 레벨에서 쌍을 강제하면 이 버그가 구조적으로 예방된다.