「シナリオを用いた要求定義」を聞いてきた

　ソフトウェアエンジニアリングシンポジウム2011のワークショップ４　要求工学の「シナリオを用いた要求定義」で聞いてきた話を報告してみる。

---

■概要

１．シナリオ概説
２．シナリオ言語SCEL
３．シナリオを用いた要求支援
　　－シナリオの視点変換
　　－シナリオの統合

---

■１．シナリオ概説

「要求工学」ソフトウエアテクノロジーシリーズ９　「３．シナリオ」

JISX0028.02.15（人工知能関係）

ここでは
ユーザーが目標を達成するために行う行動と
そこから得られるイベントを
時系列に沿って記述したものであり
ある状況に限定したシステムの具体的な利用例

良いところ
システムの使用法や手順をユーザーの始点に沿ってあらわすのに向いている
対話型のシステムの要求定義・設計に有用

シナリオの構成要素
・アクター
・アクターとその環境に関する背景情報
・アクターの目標（副目標）
・アクションとイベントの系列

シナリオの表現手段
・物語風の文章
・箇条書き
・絵
・ビデオのような動画像
・ストーリーボード
・フローチャート、シーケンス図、状態遷移図
・制限言語、形式言語

シナリオの分類観点
・表現方法
・形式化の度合い
・内容（中小度、文脈、議論、範囲）
・目的
・シナリオの使用法（どの開発時点で使用するか）

ユースケース
・ヤコブソンが提案したシナリオの一形態、システムの分析と仕様化のために用いられる
・外部との相互作用を用いてシステムを記述するというブラックボックスの視点を仮定
・自然言語によってアクタとシステムの相互作用を順番に記述

ユースケース記述

---

■２．シナリオ言語SCEL

制限言語を用いたシナリオ記述
・制限言語
　言語の表現範囲を制限して、機会での処理、解釈を容易にする目的で制限を課した言語

利点
・端的に、単一の形式で記述できる。単語や文章の意味をぶれを抑えることができる
・目的や動作の粒度をそろえることができる
　　→書くべきでない振りまいを書きにくくすることができる
・機械的に処理・解釈できる

シナリオ言語SCEL（せる）
・要求フレームモデルに基づく
　　格文法に基づいた
・種々の制御構造を記述できる
・アクタの視点ごとの分析ができる
・視点が異なるシナリオの統合やシナリオの視点変換、差分生成、ルールを用いた検証ができる

シナリオ記述言語SCELの要素
・タイトル
・ビューポイント（注目するアクターの視点）
　　→主語、目的語
・イベント文列（イベント文と時間的順序関係）
　　・イベント文
　　・時間的順序関係（順接、if-then-else,平行動機）
・事前条件
・事後条件

格文法と格構造
・イベント文を「述語（同士）＋名詞句」として記述
・文中の名詞句（型）との関係を構造（格構造）として定義
・顧客はシステムに著者名を入力する
　　入力する（表層）／データフロー（深層）
　　　この概念は「どこから」「どこに」「なにが」流れるのかという情報が必要
　　　顧客：どこから：源泉格「は」、「が」
　　　システム：どこに：目標「に」
　　　著者名：なにが：対象「を」

・動詞辞書と要求フレーム
　　動詞を中心とした格構造をドメインごとに決めておく
　　それぞれに格構造を定義する
　　　　源泉格
　　　　目標格
　　　　目的格
　　　　道具格
　　　　動作主格

・シナリオ言語の特徴
　　視点に依存しない内部表現に変換が可能
　　統合・視点変換・ルールによる検証が可能

・名詞辞書
　それぞれの格に入れられる名詞句の型が、格構造によって規定されている
　ドメインごとに利用されている名詞と型をあらかじめ対応付けておく

・SCELの有用性
　日本語の文法を制限する、語彙を絞り込む
　特定のアクタからの視点の振る舞いをシナリオの視点として明示できる

---

■３．シナリオを用いた要求支援

・シナリオ視点変換
　　→イベントの抜けや順序間違いを発見できる

・異なる視点のシナリオ群の統合

・シナリオの検証


・例外シナリオ作成支援
　正常シナリオと代替、例外シナリオ
　１つの正常シナリオに対して、複数の代替、例外シナリオ
　　例：正常シナリオ　カード払い
　　　　代替シナリオ　現金払い
　　　　例外シナリオ　カードが読めない
　代替、例外シナリオはわかりにくい
　　　→例外シナリオ作成支援

・差分分析

---

■演習のやり方

・正常シナリオを書く
・必要ない修飾語を落とす
・格文法を決める
・文法と語彙から逸脱しないように将来システムのシナリオを記述
・制限を緩和
・問題点と改善点
　　→表裏一体、否定表現＝問題点、肯定表現＝改善点

---

午前中の発表については、別のエントリで
　　

ＰＭＢＯＫのお勉強 その１０ － ２．１

今、

プロジェクトマネジメント　知識体系ガイド（PMBOKガイド）第４版
http://www.amazon.co.jp/dp/1933890681

のお勉強をしています。

前回までで１章が終わりです。
今回から、

「２章　プロジェクトライフサイクルと組織」

をやります。

---

■２．１　プロジェクトライフサイクルの概要

・プロジェクトライフサイクルとは、
　プロジェクト・フェーズの集合であり
　そのフェーズは一般に連続したものであるが、
　　　時には重複

・ライフサイクルは一定の方法論にしたがって文書化される

・プロジェクトにはすべて明確な始まりと終わりが存在する
　その間に生じる要素成果物とアクティビティはプロジェクト
　によって大きく異なる

・ライフサイクルはプロジェクトをマネジメントする基本的な
　枠組みを提供する

---

■２．１．１　プロジェクト・ライフサイクルの特性

・すべてのプロジェクトのライフサイクルは
　以下のような項目にて表現することが出来る
　　　・プロジェクト開始
　　　・組織編制と準備
　　　・作業実施
　　　・プロジェクト終結

・一般的なライフサイクルの構成は、
　通常、以下のような特性を持つ

　　・コストや要因は
　　　　プロジェクト開始時には少ないが
　　　　作業を実行するにつれて頂点に達し
　　　　プロジェクトが終了に近づくと急激に落ち込む

　　・ステークホルダーの影響力、リスク、不確実性は
　　　　プロジェクトの開始時に最大であり
　　　　プロジェクトが進むにつれてじょじょに低下する

　　・コストに大きな影響を与えず、
　　　プロジェクトの成果物の最終的な特性に影響を及ぼす
　　　ことが出来る度合いは
　　　　　プロジェクトの開始時に最大であり
　　　　　プロジェクトが完了に向かうにつれて低下する

・さらに効果的なコントロールが必要なとき
　一層高い水準のコントロールを行うことが特に必要なとき
　　　→複数のフェーズに分割することで効果が得られる

---

■２．１．２　プロダクト・ライフサイクルと
　　　　　　　プロジェクト・ライフサイクルとの関係

・プロダクトライフサイクルは、
　一般に、連続する重複のないプロダクト・フェーズから構成される

・プロダクト・ライフサイクルの最終フェーズは、一般にプロダクトの撤収

・プロジェクトライフサイクルはプロダクト・ライフサイクルの
　フェーズの１つあるいは複数のフェーズにおいて生じる

・プロジェクトのアウトプットが製品にかかわるものである場合では、
　両者のライフサイクルに多くの関わり合いがある

・１つの製品には、それに多くのプロジェクトが関係することがあるので
　関係するすべてのプロジェクトをマネジメントすることで
　効率の良いマネジメントを行うことが出来る

---

■２．１．３　プロジェクトフェーズ

・プロジェクトフェーズは、
　それぞれの重要な要素成果物を効率的にマネジメントしてフェーズを完了するために
　一層のコントロールを必要とする
　プロジェクトの区分である。

・プロジェクトフェーズは、
　通常順を追って完了するが、
　プロジェクトの状況によっては重なり合うこともある

・プロジェクトを論理的な部分に分割することにより、
　フェーズの体系を作成する


○ライフサイクルにおけるプロジェクトのガバナンス
・プロジェクトのガバナンスは、
　プロジェクトを包括的かつ一貫した手法でコントロールし
　その成功を確実にするものである

・プロジェクトガバナンスへの取り組みは
　プロジェクトマネジメント計画書に記述しておくべきである

・フェーズの構成は、コントロールを行うために公式に
　定められた基盤である

・プロジェクトフェーズは、一般に要素成果物の完了と受け入れを
　判断するレビューをもって締めくくられ、公式に終結する

・レビューでは２つの目的を同時に達成しなければならない
　　　・現行のフェーズの終了
　　　・引き続くフェーズの開始

○フェーズ間の関係

・フェーズとフェーズとの関係は以下の３つの基本的なタイプがある
　　直列関係
　　重複関係
　　反復関係

初めてのＲｕｂｙを読む その９ ２．３

「初めてのRuby」を読むの続き
今回は、


２章　配列とハッシュ
２．３　Enumerableモジュール

---

■２．３　Enumerableモジュール

・配列とハッシュは同じEnumerableモジュールに属している
・モジュール＝共通のクラスを継承することなしに実装を共有する仕組み
・Enumerableはeachメソッドから導出可能なメソッドを集めたモジュール

---

■２．３　Enumerator
・each以外のイテレーターに基づいてEnumerableの機能を提供するクラス

---

つぎから３章

ソフトウエア開発や、UML、その他ダイアログは、ロジカルシンキングに還元できる

　ソフトウエア開発はロジカルシンキングであるといえる。

　基本的には、２つの考え方

１．三段論法（演繹法に属する）

　入力がある
　この関数(メソッド）は、この入力を、この出力に変換する
　よって、この出力が得られる

２．詳細化
　Aは、B,C,D・・・からできている

で構成されている（１が、振る舞い、２が構造になる）

---

　この２つの考え方を駆使して、詳細化を行い、論理的な「ピラミッド構造」を作る
　最終的には（最底辺は）、実行可能なプログラムとなり、

　　要求→実装までは、このピラミッドをトップダウンで作っていき、
　　テストでは、ボトムアップで確認する

　詳細化に展開していくときは、MECE（もれなく、でも重複しない）に作っていくことが重要になる。

---

　ソフトウエア開発で利用するダイアグラムは、
　したがって、ロジカルシンキングの考え方で構成されている
　（UMLも他のダイアグラムも）

　ただ、図によって、視点が異なる。
　その視点の違いが大事である。

　視点の違いによって記述されているもの、詳細化レベルが異なる。

---

ちなみに、ロジカルシンキングは、このサイトが詳しい。

ロジカルシンキング情報館
http://logical.tokusen-info.com/