Requirements & Knowledge
Positioning
本サイトで扱う Failure Pattern の一部は、 仕様が未定義であることそのものではなく、 判断に必要な前提知識が明示されないまま 変更や実装が進むことによって生じている。
ここでいう Requirements や Knowledge は、 要求を網羅的に定義するための成果物ではない。 どの前提が共有され、どの前提が未確定であるかを 判断可能な形で扱うための 知識の配置と境界として位置づけられる。
Scope
本 Appendix では、 要求定義プロセスや 仕様記述手法の詳細は扱わない。
ユーザーストーリーや Specification by Example は、 前提知識を共有するための 一つの表現手段として参照されるにとどまる。
要求管理ツールや ドキュメント運用の具体論は、 本サイトでは扱わない。
Mapping
以下は、本サイトの構成要素と、 Requirements / Knowledge に関する考え方との対応関係を整理したものである。
| 本文の要素 | Requirements / Knowledge の系譜における位置づけ |
|---|---|
| Specification-by-Absence | 暗黙の前提が仕様として扱われない状態 |
| Context-Blind Change | 判断前提が共有されないまま変更が進む状態 |
| Countermeasures | 前提知識を明示し、判断単位を固定する介入 |
| Resulting Context | 不完全な知識のもとでも判断が成立する状態 |
Rationale
Requirements Engineering が本来扱ってきたのは、 「何を作るか」だけではなく、 どの知識が判断に必要かという問いである。
Design Rationale や Implicit Knowledge に関する議論は、 仕様として明文化されない前提が、 判断や変更にどのような影響を与えるかを 明らかにしてきた。
Specification-by-Absence は、 仕様が欠けている状態ではなく、 知識の所在と確定度が不明なまま 判断が行われる構造を示している。
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.