要求の追跡可能性(2)

要求の追跡可能性が求められるシーン(ユースケース)は何か

要求追跡のユースケースに先立って、まずは要求の追跡可能性に登場するアクターの粒度についてもう少し考える。

ここで、一般的なシステム開発プロジェクトを想定してアクター群(管理者、開発者、、、、)を識別していく方法も考えられるが、基本的に、各個別のプロジェクトは明確に定義された目標と限定されたスコープを持つので、個別プロジェクトに参画するメンバーの主要な関心事は、ある程度の幅を持ちつつも比較的狭い方向性に収斂してしまうように思われる。

より幅広い視点を確保するためには、プログラム管理の文献やビジネス系の文献にあたるべきかもしれないが、(自身の素養の無さを隠すためにも)システムの要求に係る追跡可能性に範囲を限定してアーキテクティング系に範を求める。
例えば、[ROZ08]ではステークホルダのクラス及びその主要な関心事を以下のように整理している(一部を引用・抜粋)。

ステークホルダクラス	主要な関心事
取得者	戦略的目的との一致,投資収益率 等
評価者	テストの実施に集中し、正式の実証可能な遵守を重視する
コミュニケータ	アーキテクチャの背後にある論理的根拠と詳細を理解し、それに精通している人と素人の両方への説明
開発者	(省略)
保守管理者	開発ドキュメンテーションや機器の管理,デバッグ環境,製造変更管理,長期にわたる知識の維持
供給者	(省略)
支援スタッフ	ユーザと一緒に問題を解決する上で必要な情報を持っていること
システム管理責任者	システムの監視と管理,ビジネスの継続,障害回復,可用性,レジリエンス,スケーラビリティ等
テスタ	要求の確立と要求を満たしたかどうかを証明するテストの設計 等
ユーザ	スコープと機能性,パフォーマンスとセキュリティなどの運用面

最初のスタート地点としては、このステークホルダクラスに沿って、各ステークホルダクラスがシステムの要求追跡性を必要となるシーンを具体的に想定してみる。

取得者が要求追跡性を必要とするシーン

評価者が要求追跡性を必要とするシーン

コミュニケータが要求追跡性を必要とするシーン

開発者が要求追跡性を必要とするシーン

保守管理者が要求追跡性を必要とするシーン

供給者が要求追跡性を必要とするシーン

支援スタッフが要求追跡性を必要とするシーン

システム管理責任者が要求追跡性を必要とするシーン

テスタが要求追跡性を必要とするシーン

ユーザが要求追跡性を必要とするシーン

続きはまた。

参考文献

[ROZ08] Nick Rozanski,Eoin Woods システムアーキテクチャ構築の原理 ITアーキテクトが持つべき3つの思考 (IT Architects’Archive ソフトウェア開発の実践)

※当たり前だけど、全くもっての私見なのでこの文章に確からしさを期待しないでください。