Bỏ qua đến nội dung chính

Requirements & Knowledge

Positioning

Một số Failure Patterns được đề cập trong trang web này
phát sinh không phải từ các specifications bản thân không được xác định,
mà từ các thay đổi và triển khai tiến hành
mà không làm rõ ràng kiến thức tiên quyết cần thiết cho các quyết định.

Requirements và Knowledge ở đây
không phải là các sản phẩm để xác định requirements một cách toàn diện.
Chúng được định vị như sự sắp xếp và boundaries của kiến thức
để xử lý dưới dạng có thể quyết định
những giả định nào được chia sẻ và những giả định nào vẫn chưa được xác định.

Scope

Appendix này không đề cập đến
chi tiết của các quy trình định nghĩa requirements hoặc
các phương pháp mô tả specification.

User stories và
Specification by Example
chỉ được tham chiếu như
một phương tiện biểu hiện để chia sẻ kiến thức tiên quyết.

Các chi tiết của các công cụ quản lý requirements hoặc
vận hành tài liệu
không được đề cập trong trang web này.

Mapping

Sau đây tổ chức sự tương ứng giữa
các yếu tố trong trang web này và
các khái niệm liên quan đến Requirements / Knowledge.

Element in Main TextVị Trí trong Requirements / Knowledge Lineage
Specification-by-AbsenceTrạng thái mà các giả định ngầm định không được coi như specifications
Context-Blind ChangeTrạng thái mà các thay đổi tiến hành mà không chia sẻ các giả định quyết định
CountermeasuresIntervention để làm cho kiến thức tiên quyết rõ ràng và cố định các đơn vị quyết định
Resulting ContextTrạng thái mà các quyết định thành lập ngay cả dưới kiến thức không đầy đủ

Rationale

Điều mà Requirements Engineering thực sự đã đề cập là
không chỉ "xây dựng cái gì,"
mà là câu hỏi về kiến thức nào là cần thiết cho các quyết định.

Các thảo luận về Design Rationale và
Implicit Knowledge đã
làm rõ cách các giả định không được ghi lại như specifications
ảnh hưởng đến các quyết định và thay đổi.

Specification-by-Absence
chỉ ra không phải một trạng thái mà specifications thiếu,
mà một cấu trúc trong đó các quyết định được thực hiện
trong khi vị trí và mức độ chắc chắn của kiến thức vẫn không rõ ràng.


References

  • Barry W. Boehm, Software Engineering Economics, 1981.
  • Pamela Zave, Michael Jackson, Four Dark Corners of Requirements Engineering, 1997.
  • Per Runeson, Martin Höst, Guidelines for Conducting and Reporting Case Study Research in Software Engineering, 2009.
  • Gojko Adzic, Specification by Example: How Successful Teams Deliver the Right Software, 2011.