+1

2012/05/17

慶應SDM公開講座 受発注者間での要求/要件の合意形成

慶應SDM公開講座 現代ソフトウェアエンジニアリングの俯瞰図 2012.05.17資料はこちら。
http://sec.ipa.go.jp/events/2012/sdm.html

今日のテーマは【受発注者間での要求/要件の合意形成】

◆第1部:非機能要求グレード 〜システム基盤における非機能要求の合意を目指して〜

・要件定義が不具合に繋がる(日経コンピュータ調べ)
・ソフトにおける非機能要求とは
→機能要求(プロセス、データ、I/F)以外の全て(品質、運用、移行等の要求)。例えば、将来の拡張性に対する要求や、担当者へのコンタクトを取れるようにして欲しい、など。これらシステムそのもの以外の要求を以下に体系化し、取りこぼしをなくすか、という話かな。
・非機能要求グレードの大項目6個
●可用性:運用スケジュール、障害発生時の対応など
●性能・拡張性
●運用・保守性
●移行性
●セキュリティ
●システム環境・エコロジー:CO2排出量、騒音など
この下に中項目、小項目(ここまでで200項目強)、メトリクス(指標)がつく。メトリクスには定量的なレベルが定められている。
…衛星開発における、衛星そのものに対する要求の他の、環境試験要求(システム環境に対する要求)のようなものか?
・非機能要求グレードのメリット
●受注者が非機能要求を提示しやすく、発注者が確認しやすい
●非機能要求に対して開発の優先順位をつけられる
●社会的影響力を基準にした、モデルケースを参照することで、テンプレ的に非機能要求レベルを設定できる
●社内システムにも適用できる
●機能をアプリケーションとすると、非機能はOSやハードウェアに該当する。非機能要求を明確化することで、ユーザには非機能項目も選択の余地が与えられる
・まだ広まってない。この先ベンダー・ユーザーを介して広がると良い。

◆第2部:機能要件の合意形成ガイド:機能要件に関する発注者と開発者の合意形成を目指して

・要件定義から設計内容までに、受発注者間で勘違いすることがままある(てへっ)
・V字モデルに従ってると、要求がずれてることが運用テストまでわかんないこともある(おそっ)
・本ガイドは、この合意形成プロセスのコツを一般化したガイドである
・大項目はGUIから帳票まで。設計時に要求漏れのないような、ケースごとのUML図の模範例など。

【雑感】
・プレゼン資料の右上に、緑文字でSECて書いてあるのを見て、赤文字でRECって書けば良いのにって思った。
・非機能要求、取りこぼしのチェックにはよさそう。無批判に使おうとすると、テーラリング面倒臭そう。
・各自が場当たり的に対応している事柄を、なるべく抽象化して皆が使えるようにする取り組みはどんどんするべき。特に汎用的な考え方とコツを知ってるけどガツガツ心のないおじーちゃんたちに向いているのでは。
・同時にこれって文書のレベルを上げるだけじゃなくって、契約したあとにぐちぐち要求を追加するような、ビジネス文化を改めないと。一度決めた契約書には定量的に従おう。

0 件のコメント:

コメントを投稿

copyright

当ホームページ掲載の記事、写真、イラスト等の無断掲載を禁止します。
(c)2008- Yuta. ALL Rights Reserved.