機能スコープと設計スコープ
あるビジネスのシナリオを書く時、スコープを意識するのが重要なのだが、機能スコープと設計スコープを意識して使い分けるのが重要と改めて認識した。
「ユースケース実践ガイド―効果的なユースケースの書き方」で、機能スコープと設計スコープの話が出てくる。
機能スコープは、システムが提供するサービスを意味する。成果物は、アクタ・目的リストとユースケース概要の2つ。これらは、ペルソナ・シナリオ法を使えば、アクタごとのシナリオとして洗い出すことができる。
これらのユースケースは、受け入れテストで使える。
設計スコープは、ハードやソフトもこめて設計するシステムの集合を意味する。このイメージがなかなか湧かなかった。本の例を見ていると、イメージとしてはDFDやER図に似ていないか?
つまり、システムとして設計すべき機能なのか、設計外の機能なのか、を把握するには、企業・システム・サブシステムの視点からデータの受け渡しをイメージしないと書けない気がする。
とある勉強会でシナリオを書くタスクを背負ったが、メンバーのシナリオに対するイメージがバラバラで、どんなシナリオを書けば概念モデルや詳細モデルが書けるのか、プロセスすら分からなかった。
今になってようやく、下記の成果物は必須だと分かった。
1.各シナリオ・機能がスコープ内にあるかチェックするためのIn/Outリスト
→議論が発散しそうになったら、どんな要求がシステムに必要なのか、原点に立ち戻る時に使う。
2.アクタ別のシナリオを書いたユースケース概要
→ペルソナ・シナリオ法はオブジェクト図の位置づけに相当する。アクタ・目的リストはクラス図の位置づけに相当する。受け入れテストで使える。
3.色んな視点からシステムを眺めた時の設計スコープの図
→モデリングを行う時、どのシステムに着目して詳細化していくのか、を確認するのに使う。
ユースケースなんてモデリングで意味があるのか、と常々思っていたのだが、モデリングを行う前の仕込み段階であるシナリオを書きまくっていくうちに、ユースケースの威力が分かってきた。
モデリングへ辿りつくには、シナリオを具体化したユースケースが必要。そのシナリオはスコープに大きく依存している。
シナリオやユースケースを書いていると気づいたのは、IF文を極力排除していること。IF文を使う箇所はアクタ別のシナリオに分けられる時が多い。
ユースケースは奥が深い!
| 固定リンク
「日記・コラム・つぶやき」カテゴリの記事
- 考えながら書く人のためのScrivener入門の感想(2020.12.06)
- 課題は問題点をひっくり返す表現だけで良い場合もある(2020.09.28)
- ツールを使いこなせる事の重要性が増している(2020.05.28)
- ココログHTTPS化のメモ(2019.12.26)
- 「小水力発電が地域を救う」の感想(2018.04.06)
「モデリング」カテゴリの記事
- yWriterは映画の脚本を作るためのアプリだったのではないか(2021.01.05)
- 小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2(2020.12.31)
- 小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart1(2020.12.30)
- なぜユーザーストーリーによる要件定義にピンとこなかったのか(2020.12.29)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
「プロジェクトマネジメント」カテゴリの記事
- 文化は組織構造に従う(2021.01.19)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- カンバンはステータス名が大事(2021.01.02)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある(2020.12.11)
コメント