要求仕様の記述方法

機能要求

機能要求は、意見はいろいろありますが私は「ユースケース」が良いと思っています。但し、機能仕様レベルを記述するには向いていないのでまずは目的レベルユースケース*1を記述するとよいと思っています。ユースケース記述をテンプレート化したフォーマットで記述します。

イベントフロー

イベントフローは、以下のテンプレートで記述します。

1. アクター（実際のアクター名）はシステムに対して〜する
2. システムはアクター（実際のアクター名）に対して〜する

という組で記述します。システム内部で何が起こっているかはここでは問題にしません。
一般に「アクターがシステムに対して〜する」というのは、入力を表しており、「システムはアクターに対して〜する」というのは出力を表しています。
このような入出力イベントをフローとして記述するのがイベントフローです。

イベントフローと機能仕様

上記に記述したイベントフローの2つのテンプレートは組で機能を表しています。
そのため、この組を一つの機能仕様として捉えます。
入力→内部動作→出力といった形で記述します。
イベントフローにおいては、内部の動作を注目しませんでしたが機能仕様は内部の動作を意識します。要求において整理された業務ルールをこの内部動作にマッピングする形でトレーサビリティを保っておくとよいでしょう。

機能仕様における内部動作

内部動作は自然言語と図解によって記述されます。この動作は大きく分けて

1. 入力のバリデーション
2. 入力形式→内部構造の変換（形式的）
3. 内部構造（形式的）から内部格納形式への変換およびシステム状態の変化（業務ロジック）
4. 内部格納形式の永続化
5. 出力する情報の検索
6. 出力情報の構築
7. 出力先の確定

に分かれます。
内部構造（形式的）とは、入力形式が特別な形式（ミドルウェアなどに依存）している場合に内部のオブジェクトなどにマッピングする作業です。
例えば、Webアプリケーションであれば入力情報はすべて文字列になっているので数値データは数値に変換するといったことです。
また、StrutsではActionFormという形式なため論理構造に変換するとわかりやすくなります。最近のDIコンテナを利用すればこの入力形式をPOJOに自動変換してくれるのでその必要はないかもしれません。
出力情報の構築とは、ViewHelperなどの出力情報を組み立てることを表しています。

非機能要件の記述

詳細はこれから勉強しますが、EvoのPlanguageに着目しています。
その意味で今日にでもこの本を買いたいと思っています。

初めてのアジャイル開発　?スクラム、XP、UP、Evoで学ぶ反復型開発の進め方?

*1:ユーザの要求を満たす単位。通常、画面遷移を伴いいくつかのワークフローやチェックポイントがあったりします。アクターは何種類か登場することになるかもしれません。例えば、旅費清算をするというユースケースであれば、出張者が申請をして、承認者が承認して、清算担当者が手続きを取り、清算承認者が承認するといったことになります。