Open5
要件定義
punsuka- 塩ラーメン頼んだあとに味噌ラーメンに仕様変更されるイメージ
- キャベツとレタスの区別がつかない子供のイメージ
- 「レタス食べたい」と言われてレタスちぎってサラダ作ると「千切りのがいいって言った」みたいな状況
- プロの親なら「レタス食べたい」と言われた時点でキャベツの可能性を考えて「それって千切りのではなくて？」的なことが言える
- エンジニアも同じ漢字に対応できるはず
- キャベツとレタスの区別がつかない子供のイメージ
punsuka- アジャイルで重視していないのは包括的なドキュメントであって、ドキュメント自体を否定していない
- 最悪訴訟となったときも重要
- 要件定義の教科書的な書き方は共通認識の構成に役立つ
- 目的が処理速度の向上なのに、処理速度遅くなったらだめとか
- 非機能要件に記載なくても、ビジネス要求として記載されていれば効力がある
punsuka- 教科書的な要件定義の教科書を作った上でどこが過剰であるか、どの視点で見るべきかみたいなことをまとめると楽しそう
punsuka- 要件定義は要件を定義している
- 要件=満たすべき条件
- これを満たせば文句は言わない、言わせないの集合体
- 適度にファジーであるのが望ましい
- ユーザーが想定していない解決方法を提案する余白を残す
- 詳細設計までしたらフェーズ分ける意味がない
- 逆に邪魔になる
- 概念モデルとER図の違い的なことを理解していないと上手なファジーが実現できない