TAKAが試したこと考えたこと

機能要求 機能要求は、意見はいろいろありますが私は「ユースケース」が良いと思っています。但し、機能仕様レベルを記述するには向いていないのでまずは目的レベルユースケース*1を記述するとよいと思っています。ユースケース記述をテンプレート化したフォーマットで記述します。 イベントフロー イベントフローは、以下のテンプレートで記述します。 アクター（実際のアクター名）はシステムに対して～する システムはアクター（実際のアクター名）に対して～する という組で記述します。システム内部で何が起こっているかはここでは問題にしません。 一般に「アクターがシステムに対して～する」というのは、入力を表しており、「システムはアクターに対して～する」というのは出力を表しています。 このような入出力イベントをフローとして記述するのがイベントフローです。 イベントフローと機能仕様 上記に記述したイベントフローの2つのテンプレートは組で機能を表しています。 そのため、この組を一つの機能仕様として捉えます。 入力→内部動作→出力といった形で記述します。 イベントフローにおいては、内部の動作を注目しませんでしたが機能仕様は内部の動作を意識します。要求において整理された業務ルールをこの内部動作にマッピングする形でトレーサビリティを保っておくとよいでしょう。 機能仕様における内部動作 内部動作は自然言語と図解によって記述されます。この動作は大きく分けて 入力のバリデーション 入力形式→内部構造の変換（形式的） 内部構造（形式的）から内部格納形式への変換およびシステム状態の変化（業務ロジック） 内部格納形式の永続化 出力する情報の検索 出力情報の構築 出力先の確定 に分かれます。 内部構造（形式的）とは、入力形式が特別な形式（ミドルウェアなどに依存）している場合に内部のオブジェクトなどにマッピングする作業です。 例えば、Webアプリケーションであれば入力情報はすべて文字列になっているので数値データは数値に変換するといったことです。 また、StrutsではActionFormという形式なため論理構造に変換するとわかりやすくなります。最近のDIコンテナを利用すればこの入力形式をPOJOに自動変換してくれるのでその必要はないかもしれません。 出力情報の構築とは、ViewHelperなどの出力情報を組み立てることを表しています。 非機能要件の記述 詳細はこれから勉強しますが、EvoのPlanguageに着目しています。 その意味で今日にでもこの本を買いたいと思っています。 初めてのアジャイル開発 ?スクラム、XP、UP、Evoで学ぶ反復型開発の進め方? 作者: クレーグ・ラーマン, ウルシステムズ株式会社, 児高慎治郎, 松田直樹, 越智典子 出版社/メーカー: 日経BP社 発売日: 2004/09/09 メディア: 単行本 購入: 2人 クリック: 11回 Amazon.co.jpで詳細を見る *1：ユーザの要求を満たす単位。通常、画面遷移を伴いいくつかのワークフローやチェックポイントがあったりします。アクターは何種類か登場することになるかもしれません。例えば、旅費清算をするというユースケースであれば、出張者が申請をして、承認者が承認して、清算担当者が手続きを取り、清算承認者が承認するといったことになります。

[続きを読む →]

このように抽出した情報を整理し、要求仕様としてまとめます。 要求仕様の網羅度チェック 要求仕様の網羅度をチェックするために重要なのが入力と出力の整合性チェックです。 ギャップがあった場合には 入力情報を加工すれば出力情報になる 入力情報が漏れている 出力情報が誤っている といったパターンが考えられます。 このうち1番目は加工するためのルールを業務ロジック*1として名前をつけておきます。 最後のパターンがこのチェックの主たる目的なので、入力すべき状況を洗い出し要求として追加します。 *1：情報系のルールとして決めておきます

[続きを読む →]

システムで何よりも難しいのが人間から情報を引き出すこと。 網羅性を持って、構造的に整理された情報を引き出すことはまずありません。 業務を実践している人にとって情報は取捨選択されていることが多く、当たり前の情報は表に出てきません。 その意味でいろいろな想起法を利用して、情報を引き出すことになります。 関連を利用して引き出すのが王道なので、業務フローやゴールモデルなどを用いた方法や芋づる的に引き出させるマインドマップなどを利用できます。

[続きを読む →]

ここでは要求仕様と要件は同じ意味で使っています。 要求と要求仕様は若干異なっています。 要求はステークホルダがだす要求を表しているもので要求仕様は要求を解決するために定義されたシステムの動作（ソリューションとしては概要的）を表しているものです。 要求仕様は踏み込みすぎると設計をしていることになってしまいますが、その境はあいまいです。 要求のMECE MECE（(Mutually Exclusive collectively Exhaustive))とは漏れなくダブりなく洗い出し整理された状態を表しています。もともとロジカルシンキングの考え方ですが整理手法として優れているので要求を整理するのに利用します。 MECEの出所からアイディアを借りて考えると、要求をロジックツリーのように整理します。Whyの問いかけをすることで階層構造となるわけです。 ステークホルダはいろいろな立場の人がいるとはいえ、根本にある共通目標は同じはずです。もし同じでないとすればまず同じになるように調整する必要があるはずです。 よくある表面的合意（あるいは総論賛成・各論反対）というのはプロジェクトを迷走させる原因になるので注意が必要でしょう。 共通目標から各ステークホルダの目標、共通目標のサブ目標といった形でブレイクダウンしながら要求を整理していきます。 そうするとそのツリーに偏りができたり階層の兄弟要素間で粒度が異なったりします。そのような時に「漏れ」があるということがわかったりします。このような整理をすることで漏れなくダブりなく整理することができるようになります。 この手法は、要求の整理の手法であって抽出の手法ではありません。抽出には抽出の技術ががあるので別途どこかで説明したいとは思います。 誤解しやすいのは、「要求の性質*1上MECEができないから無意味だ」という誤解です。完全なものを作ることができないという点は正しいのですが、できないからといってできるところまでやらない理由にはなりません。 ここでMECEを取り上げているのはできる限りその近くまで行くためにどうするかという話をしたいからであって、「MECEができる。」「だから変更を認めない」「仕様は凍結しなければならない」といったことではないのです。 補足しておくと、要求の追加・変更は変更管理プロセスによって制御されていればよく、要求の追加・変更を認めないわけではないのです。 *1：人間から抽出するので漏れる

[続きを読む →]

ANSI/SPARC3層スキーマ 外部スキーマ 外部スキーマはシステム外から見えるデータの見え方を表しています。 ユースケースで記述されるデータの入出力はこのスキーマに沿った記述といえます。 その意味では機能設計の入出力情報をまとめたものといえます。 論理スキーマ 論理スキーマはシステム内部で格納すべき情報です。スタートは外部スキーマにおいて永続化すべきものを選択し整理することでしょう。例えば、生年月日と年齢といった派生関係にあるものを両方持つべきか計算すべきかを検討し、整理することです。 次にER図を考え、正規化をしていきます。 物理スキーマ 論理スキーマを元に、テーブルの構造（ファイルシステム、ブロックサイズ）、インデックス設計などをおこないます。 間違えやすいのは外部スキーマの構造をそのまま論理スキーマにしてしまうことです。簡単でよいですが、正規化の問題やデータ構造の不整合を生み出してしまいます。 次に間違えやすいのは、論理スキーマ+DBMSのデフォルト設定による物理スキーマつくりです。厳密にするのは難しいかもしれませんが、各DBMSによってファイルシステムや、ブロックサイズなどの設定を検討し設計する必要があります。この設計にはDBMSの専門家である必要があるでしょう。

[続きを読む →]