要求工学における要求（要件）定義手法
放送大学の面接授業を受講してきました。
講義名：情報システム初めの一歩
http://forests.ouj.ac.jp/ouj-f292/dt-27456.html
講師：中谷 多哉子 教授
中谷 多哉子 - 研究者 - researchmap
最初は、軽い情報処理とか知らない方向けの授業だと思っていたのですが
実際、講義を受けてみると面白かったので
明日も授業がありますが興奮が冷めないうちに
備忘録として残しておきます。
※個人の独自解釈＆メモです。
概要
（結構な時間を割いてDisってくれた。自分が会社で思っている違和感を全部言葉にしてくれた。）
- アジャイルをうまく回せ
（なんで回せないの？ってくらい食い気味）
- せめてエクセルで要求（要件）定義書書くのはやめろ
（文章の羅列で成果物を想像するのはしんどい。せめてイメージ画像くらいつけろ）
要求工学とはなんぞ
テキストから抜粋
・現実世界の問題に対して解の開発活動を関連づける工学プロセスの1つ
・現状のシステムに起因する問題と（中略...）
将来のシステムが対応すべき事項を明らかにするための調整活動の集合
つまり要件定義でしっかり要求を実現できる様にしましょうねーって感じ
さらに言うと何千人、何万人集まってもプロジェクトがきれいに回る（燃えない）
ようにするにはどうしたらいいか？みたいなことを日々研究しているそうです。
要求定義工程における曖昧さ回避
- そもそも要求って？
AsIsとToBeの差分が要求
- ベストな要求定義
ISO/IEC/IEEE 29148を参照
良い感じのプレゼン資料がIPAにありました。
→https://www.ipa.go.jp/files/000027661.pdf
・妥当な要求の獲得
・非曖昧に定義する
・完全に定義する
強く言っていたのが非曖昧さの回避
一文に2つ以上の意味を含ませない
→一意な文にする。
例
・同時に100人以上アクセスできること
→作成者（要求者？）はアクセス数がせいぜい100人くらいだと思っている。
→開発者は30億人の同時アクセスでも満足させないといけないと解釈する。
例
・（Webアプリの）3秒以内のレスポンス
→ネットワーク等の環境に依存する条件
→3秒以上の要件を決めると良い
- 質問した
隣のプロジェクトが燃えている
どこが燃えているかもわからない規模だが
要件定義時点で防げたか？
また、完全な要件定義は実現可能か？
・A 炎上案件
ウォータフォールじゃなくてアジャイルで成果物と要求物の差分を少なくしろ。
・A 完全な要件定義
無理！
世の中の要求定義書の8割が自然言語で記述されている
（残りの2割は数理計画による数式によって定義されている）
自然言語自体があいまいなものだから非曖昧で完全な要件定義は不可能
システムの寿命
- プログラム進化の法則
いつかプログラムも限界がくる
研究論文タイトルに見る英語表現
・requirements gathering
→要求獲得：獲得ができない
→日本じゃまだ主流らしい
→古い考え方らしい
・requirements elicitation
→要求抽出：要求は抽出するものだ！
→お客様の発想を刺激して要求を抽出
要求定義時点から半年後の要求を想像させる。
アジャイル開発手法と合わせた話で技術の進歩スピードが速い
半年後には別のものが求められているかもしれない
なので使用者たるお客様に想像を促す。
そして完成時点でのお客様の要求と成果物との差分を少しでも少なくする。
雑感
まだ3分の1くらいの内容
途中で力尽きました。
まだ1日目の講義で明日も講義は続きますが
演習問題を使った実習見たいなので
とりあえず忘れないうちに書きました。
続きはそのうち追記します。
この前の面接授業の数理最適化の記事もまだなのに…
