Requirements & Knowledge
Positioning
Some of the Failure Patterns addressed in this site arise not from specifications themselves being undefined, but from changes and implementations proceeding without making explicit the prerequisite knowledge needed for decisions.
Requirements and Knowledge here are not deliverables for comprehensively defining requirements. They are positioned as the arrangement and boundaries of knowledge for handling in a decidable form which assumptions are shared and which assumptions remain undetermined.
Scope
This Appendix does not address details of requirements definition processes or specification description methodologies.
User stories and Specification by Example are referenced only as one means of expression for sharing prerequisite knowledge.
Specifics of requirements management tools or document operations are not addressed in this site.
Mapping
The following organizes the correspondence between elements in this site and concepts related to Requirements / Knowledge.
| Element in Main Text | Position in Requirements / Knowledge Lineage |
|---|---|
| Specification-by-Absence | State where implicit assumptions are not treated as specifications |
| Context-Blind Change | State where changes proceed without sharing decision assumptions |
| Countermeasures | Intervention to make prerequisite knowledge explicit and fix decision units |
| Resulting Context | State where decisions hold even under incomplete knowledge |
Rationale
What Requirements Engineering has originally addressed is not only "what to build," but the question of what knowledge is necessary for decisions.
Discussions on Design Rationale and Implicit Knowledge have clarified how assumptions not documented as specifications influence decisions and changes.
Specification-by-Absence indicates not a state where specifications are lacking, but a structure in which decisions are made while the location and degree of certainty of knowledge remain unclear.
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.