Specification-by-Absence

Derived Failure Pattern của Implicit Rules và Unverifiable Expectations

Summary

Specification-by-Absence là Failure Pattern trong đó,
khi explicit specifications không tồn tại,
"điều không được viết" bản thân được coi như de facto specifications.

Điều mà Pattern này đề cập không phải là vấn đề không viết specifications đầy đủ.
Đó là một cấu trúc trong đó, giữa sự không chắc chắn và pressure cho change, ghi lại specifications bị hoãn lại,
và khoảng trống đó được lấp đầy bởi implicit expectations và conventions.

---

Context

Trong software đang vận hành,
định nghĩa tất cả specifications trước không thực tế.

Đặc biệt liên quan đến hành vi của các chức năng hiện có và các trường hợp ngoại lệ,
sự thật "nó đã hoạt động như thế này"
có xu hướng được coi như một thay thế cho các documented specifications.

Trong các tình huống như vậy,
ngay cả khi specifications không được làm rõ ràng,
chỉ expectations trở nên cố định.

Forces

Các động lực chính tạo ra Pattern này như sau:

• High cost of specification description
  Viết precise specifications yêu cầu thời gian và thỏa thuận,
  và trong các môi trường mà các thay đổi xảy ra thường xuyên, nó dễ dàng bị hoãn lại.

• Dependence on existing behavior
  Running code được tham chiếu như de facto specifications,
  và intent của behavior không được diễn đạt.

• Asymmetry of confirmation costs
  So với chi phí làm cho specifications rõ ràng,
  tiến hành dựa trên giả định của implicit expectations trông rẻ hơn trong ngắn hạn.

• Localization of changes
  Các thay đổi giới hạn phạm vi tác động tích lũy,
  và overall specification image không còn được chia sẻ.

Failure Mode

Bởi vì specifications không được làm rõ ràng,
các bất đồng giữa expectations và implementation không thể được xác minh sau thực tế.

Kết quả là, các dạng hỏng sau đây tiến hành đồng thời:

• Expectations xuất hiện sau code review
  Chỉ sau implementation, nó được chỉ ra như "khác với assumptions."

• Specification confirmation được thay thế bằng tham chiếu đến past behavior
  Cơ sở của correctness phụ thuộc vào history và memory.

• Changes được coi như cơ sở cho specifications
  Implementation xảy ra được nhập vào
  trở nên cố định như một điểm tham chiếu cho các specification decisions tiếp theo.

Consequences

• Sự phân biệt giữa specification changes và bug fixes trở nên mơ hồ
  (Part I: What Breaks — Responsibility / Data)

• Decision criteria không được chia sẻ, và các thảo luận trôi về impressions
  (Part II: Why It Breaks — Context Erosion)

• New members và AI không có lựa chọn nào khác ngoài đoán correctness
  Bởi vì assumptions và constraints không được làm rõ ràng,
  sử dụng như decision support bị giới hạn.
  (Part II: Why It Breaks — Context Erosion)

• Lòng tin vào specifications dần dần bị mất
  (Part I: What Breaks — Data / Responsibility)

Countermeasures

Sau đây không phải là danh sách các giải pháp,
mà là các counter-patterns để thay đổi động lực với can thiệp tối thiểu chống lại Failure Mode.

• Xử lý một cách rõ ràng điều chưa được quyết định
• Phân biệt và diễn đạt facts và expectations của behavior
• Không cố gắng viết mọi thứ,
  nhưng để lại minimal specifications cần thiết cho các quyết định

Resulting Context

Specifications vẫn không hoàn chỉnh,
và không phải mọi thứ được ghi lại.

Tuy nhiên, bằng cách làm hiển thị các phần không xác định,
các bất đồng giữa expectations và implementation có thể được giải quyết sớm.

Kết quả là, specifications hoạt động
không phải như các sản phẩm cố định,
mà là các điểm tham chiếu hỗ trợ các quyết định.

See also

• Context-Blind Change
  Foundational pattern trong đó absence of specifications trở nên cố định như một structure khi assumptions không được chia sẻ trong các thay đổi.

• ** Test-Passing Illusion**
  Một derived pattern trong đó, trong các môi trường mà explicit specifications không tồn tại, verification success có xu hướng được coi như một thay thế cho correctness.

---

Appendix: Conceptual References

• Requirements & Knowledge
  Background của các cấu trúc trong đó kiến thức tiên quyết cần thiết cho các quyết định không được coi như specifications.
• Information Hiding & Boundaries
  Background của failure structures trong đó các undefined assumptions rò rỉ vào implementation và behavior.
• Feedback, Measurement & Learning
  Background của các động lực trong đó verification results không dẫn đến learning mà không có specifications.

Appendix: References

• Pamela Zave, Michael Jackson, Four Dark Corners of Requirements Engineering, 1997.
• Barry W. Boehm, Software Engineering Economics, 1981.
• Gojko Adzic, Specification by Example: How Successful Teams Deliver the Right Software, 2011.