厳密な要求仕様記述を志すための形式手法

「こんなゲームを作りたい」だけでは企画の立案にならない。何のシーンが必要か、どういったシステムが必要(必要か否かの段階を含め)なのか、どのような素材が必要なのか。この要求をただしく定義し、特性を満たす仕様化を行うことが企画のリアライゼーションにつながる。(vice versa)

記述者：もやし（DTM課）

記事の手引き

今回記述する内容はIPAの実務家のための形式手法 厳密な仕様記述を志すための形式手法入門 厳密な仕様記述入門およびプロセスと環境トラック 要求工学を参考にさせていただいています。だいたいこのPDFおよび本にすべて書きたいことは載っています。この仕様記述(本記事では要求仕様の記述に絞ります)をゲーム開発(主にRiG++内での)に適用する際、たとえば企画リーダは何をすべきなのか、開発物(ゲーム)のスコープをどのように設定し、どのように要求を他人および開発メンバに共有・伝達すれば齟齬なく開発が可能かをこの記事では記載していきます。

よって、本記事は「RiG++内(あるいは他ゲーム開発サークル)で企画を立てたい、複数人での開発で作りたいゲームがあるが、自分の作りたいものをどのように公開しメンバ募集を行えばよいか分からない」「コーディング課にどうやって仕事を振ればよいか分からない」と悩んでいる企画リーダたちを最初の読者として想定しています。無論、リーダ以外の開発メンバも、ぜひ要求工学について知見を持っていただければと思います。

が、同時にある程度のコーディング知識を必要とする記事にもなります。要求仕様記述にまつわる要求工学とはすなわちソフトウェアエンジニアリングの一分野ですので、最低限Unityに触れたことがある方を読者として想定させていただきます(コーディング課の新人講習を受けていればGood)　とはいえ私もそうコーディング特にC#に明るいわけでもないため、そこまで深い知識を要求することはありません。

要求とは？要求仕様とは？

見出しのものについて触れる前に、まずソフトウェア工学の背景とソフトウェア開発のモデル全体像(の一例)について記述します。

ソフトウェア工学

1968年10月、NATO Science Committee主催のソフトウェア工学会議において、ソフトウェア危機(Software Crisis)の提案・認識がなされました。つまりは、高性能化するハードウェアは安くなる一方、複雑化するソフトウェア開発のコストは上昇する傾向が続くことにより、将来的にソフトウェアの供給が需要を満たせなくなるという警鐘です。このソフトウェア危機の根本には、正しく、可読性が高く、検証可能なコンピュータプログラムを書くことが困難であるという事情がありました。

この危機を打開するために、ソフトウェア工学が考えられました。ソフトウェア工学とは「高品質で高機能なソフトウェアを効率よく開発し、また利用するための手法・方法論の集大成」のことです。本記事にて触れる要求定義・要求仕様を扱う要求工学も、このソフトウェア工学の一分野ということになります。

1960年代、WWⅡを瞼裏に有したまま情報の時代へと世界が移り往く中で、OS(IBMのOS/360など)や列車の座席予約システム、弾道弾迎撃ミサイルなどの巨大システムが相次いで開発されましたが、特に軍用システムの多くはトラブルが多く、信頼性や性能の低さからいくつものプロジェクトが廃棄されました。このような背景からも、ソフトウェア危機およびソフトウェア工学の存在が提唱、認識されます。

ソフトウェア開発モデル(ウォーターフォールモデル)

こういったソフトウェア工学およびその前身となるシステム工学(詳細な記述は省きます)の成果の一つに、ソフトウェア開発のライフサイクルモデルの提案があります。つまり、ソフトウェアの開発や運用・保守の段階がどのように進んでいくかをモデル化したものです。

この記事ではその中のウォーターフォールモデルに触れます。このモデルは時代的に初期のものであり、他にもスパイラル型やプロトタイピング、アジャイルなどのモデルがありますが、今回はひとつだけ(学生のサークル活動として、半年くらいでゲームをつくるならウォーターフォール型で十分かも？)

このモデルでは、要求定義、設計、実装、テスト、運用・保守がこの順番で行われます。画像では要件定義とありますが、今回は要求定義と記述します(英語ではRequirementなのでどっちも変わらないです、実務での開発では要件、官報での物品の仕様では要求要件とよく使われます)。

各段階において、その成果物としてドキュメントが作成されて、それが次段階の入力となって開発が進んでいく形です。このうち、要求定義の成果物が要求仕様となります。他にも、設計段階の成果物は設計仕様(外部仕様/内部仕様)、コーディング段階の成果物はソースコード、というふうになります。
ウォーターフォールモデルが初期に出来たものと書きましたが、決して古いものではなく、たいていの場合は他モデルと組み合わせて用いられます。

要求定義・要求仕様

やっとこの話に入れる　要求定義とは、ソフトウェアライフサイクルのはじめに位置し、ソフトウェアのユーザ(になる人)の抱える問題やニーズを正確に定義する段階のことです。ゲーム開発においては、企画リーダ/立案者の作りたいゲーム像を正確に定義します。

一般に、ユーザの抱える問題やニーズは複雑です。あいまいであったり、矛盾している場合も少なくありません。たとえばこれが家族旅行の行き先でも意見がすべて自然に統一されることは無く、況や新規ソフトウェア開発をや、というわけです。ゲーム開発に置き換えれば、企画リーダが作りたいゲームを想像したとき、そのシステムモデルや内部設計、すべてのシーンやその遷移まで思い浮かべられる人間は現実的にいません。要求(特にソフトウェア要求)とはこのように、ユーザがソフトウェアに当然備わっているべきと考えた機能や性能のことであり、特にゲーム開発においては開発者側がユーザについて予測して、それを満たすような製品を開発するものを指します。(サークル活動でのゲーム開発においては、予測するユーザのニーズ=企画立案者のニーズでしょう)

そのため、問題/ゲーム像の本質を明らかにして、問題の解決策/ゲームのプレイ像を策定し、解決策/制作物を実現するためにソフトウェア/ゲームシステムがもつべき機能や性能を定める過程を要求定義と呼びます。
問題解決を根本としたソフトウェア開発では既存システムやモデルの事例の有無で要求のまとめやすさが異なりますが、(サークルでの)ゲーム開発では多くの場合「発想元」が存在し、ゲームシステムの前例を見つけやすいです。

そして、要求定義段階の目標は要求仕様を記述することです。ユーザ/企画リーダが本当に望んでいることを適切に引き出して文書化したものを要求記述と呼び、要求記述に対して誤りの検出・除去、実現できないものの修正を行って解析・精製することで、最終成果物として要求仕様がまとめられます。

ソフトウェア開発では、誰が何をどのようにどこまで要求仕様を書くかが分かっていなければ要求仕様をまとめることはできません。

結局要求仕様に何を書いたらいい？

要求仕様の構成は、例として次のようになります。

1. はじめに
2. 要求仕様の全体説明
3. 詳細な要求仕様
4. その他の情報

それぞれ(をゲーム開発に当てはめた場合)について、細かく紹介します。

「はじめに」

「はじめに」では以下の事項が明記される。

1. 要求仕様の目的
   • その要求仕様(ドキュメント)の目的
     例):「この要求仕様では、情報理工学部プロジェクト団体 RiG++ の通常企画の成果物であるゲーム (以下【企画タイトル】)における要求を策定することを目的とする。」
   • 要求仕様の読者をどのように想定しているか
     例):この要求仕様の読者は、【企画タイトル】の開発に関わるメンバを想定する。
2. 要求仕様の適用範囲(ゲーム開発においてはあんまり書くことないかも)
   • 開発するソフトウェア製品/ゲームの名称
   • ソフトウェア製品が何をするか(/何をしないか)
   • ソフトウェア製品の対象(利点、目的、目標を含む)
3. 要求仕様で用いられる用語の定義、略語の説明
   • 要求仕様を正しく解釈するのに必要となるすべての用語、略語、省略形等の定義が書かれる。これらの定義には他箇所や他文書の参照をさせてもOK
4. 要求仕様で用いた参考文献(これもゲーム開発ではあんまりないかも)
   • 要求仕様の中で参照した文献のリスト
   • 文献の参照元
5. 要求仕様の概要
   • 「はじめに」以降の内容
   • 要求仕様の構成

「全体説明」

全体説明では、ソフトウェア製品や要求に関する一般的な事項が書かれる。細かい事項は「詳細な要求仕様」に記述されるので、代わりに要求(および要求が仕様化された)背景が書かれるとより分かりやすくなる。

「全体説明」では以下の節で記述される。

1. ソフトウェア製品の全体像
   製品/ゲームが、他の関連製品を使用しながら運用されるのであればそれらとの関連やインタフェースを含めた全体像を、完全に単体で使用されるならばその旨を明記する。システムの主要な構成要素や内部の結合、 外部インタフェースを記述するにはブロック図がよい。
   具体的には(ゲーム開発に含みうるものに絞る)、
   • システムインタフェース
     ゲームシステムへのインタフェースのリストと、システム要求を実現するための機能
   • 利用者インタフェース
     ゲームと利用者とのインタフェースの論理的な特性(画面レイアウトやメニューの内容等)
     特定の利用者にとってのインタフェースの最適化(ショートカット、チュートリアルのスキップ等)
   • ソフトウェアインタフェース
     当該ゲーム以外に必要となるソフトウェア製品(データ管理システムやOS、ライブラリパッケージ等)、他アプリケーションとのインタフェース
   • 通信インタフェース
     通信に関するプロトコル等の要求
   • (メモリ制約)
     メイン・サブメモリに関する特性や制限の要求
   • (操作)
     一般的な操作以外に特殊な操作(開発者モード等)についての要求
   • (サイト適合要求)
     ゲームのインストールや初期設定のためのサイト等にまつわる要求
2. ソフトウェア製品の機能
   ゲーム製品が実行する主要な機能の要約。顧客(この場合は開発メンバや素材班)や最初にこの仕様を詠む人が理解できるような機能のリスト。
   種々の機能の関連を示すために文章や図を用いればよいが、ここでの図式は製品の設計を表すのではなくあくまで論理的な関連を示す。
3. 利用者の特性
   想定される利用者の特性(ゲーム経験、年齢、練度等)。特定の要求(例えば上記の「ソフトウェア製品の機能」における要求)というより、その要求を仕様化した理由が述べられる。(たとえば、「10代後半をプレイヤとして想定するため、細かい操作によるゲーム体験を提供すべくシューティングゲームとして○○の機能を実装する」等)
4. 制約事項
   開発者に対し制限する項目について記述される。具体的には、
   ・法的規制上の制約(ライブラリのライセンス等)
   ・ハードウェア/OS上の制約
   ・並列操作による制約
   ・セキュリティにおける制約(あんまない)
   等がある
5. 要求仕様で設けた仮定と依存事項
   要求に影響を与える要因を記述する。例えば、あるハードウェア上で、あるOSが利用できると想定した上で要求が記述されており、実際にそのOSが利用できないのであれば、要求を変更しなければならない。

詳細な要求仕様

すべてのソフトウェア要求について、設計者(コーディング班)がそれらを満たすようにシステムを設計するのに十分なレベルまで、要求は詳細化されなければならない。
すべてのソフトウェア要求について、テスタが、システムがその要求らを満たすかどうかテストするのに十分なレベルまで、要求は詳細化されなければならない。
最低限でも、システムへの全入出力、システムにて実行される全機能の記述が含まれる。ここが最も重要であり、一方で膨大な記述量になるため、以下の点に気を付けると良い。

• 要求特性を満たしているか
  今回ちょっと(書いてる側の)時間がないので細かい説明は省きますが、各要求に対し妥当性、非曖昧性、完全性、無矛盾性、重要度と安定性のランク付け、検証可能性、変更可能性、追跡可能積について検討すると良い。(それぞれ定義があるので調べておくとGood)
• 以前に作られた関連文書や企画書の案等と相互に参照できるかどうか
• すべての要求が個々に識別可能であるかどうか
• 読みやすい構成かどうか

構成の例：

1. 外部とのインタフェース
   ゲームシステムへの全入力とゲームシステムからの全出力についての詳細な記述。全体像のときの記述の繰り返しになってはいけないので、それを補足するものとして記述するとよい。
   以下のフォーマットが例となる。
   • 入出力項目名
   • 入出力の目的(なぜこのキーを押させるのか？等)
   • 入力元と出力先
   • 入力データの有効な範囲、精度や許容できる誤差
   • タイミングの情報
   • 他の入出力との関連
   • 画面のフォーマットと構成
   • (複数ウィンドウであれば)ウィンドウの構成
   • 入出力されるデータのフォーマット
2. 機能要求
   入力の受理や処理時、出力の処理や生成時にソフトウェア内部で生起する基本的な動作を定義する。一般に、「○○しなければならない」という表現をとる。
   機能要求には次の項目が含まれる。(無論これだけでなくてもよい)
   • 入力の妥当性チェック
   • 操作の厳密な順序
   • エラー処理や回復等の異常な状況での応答
   • パラメータの有効性
   • 入出力関係(入力から出力への変換式)
3. 性能要求
   非機能要求の代表的なものだが、定量的に表される方が好ましい。
   例)
   ステージ選択後のステージ初期化処理が終了するまで、プレイヤが待たされるようなことがあってはならない。
   ↓
   各ステージ初期化処理は、1秒以内に処理されなければならない
4. 論理DB要求(あれば)
   データベースに格納される情報の論理的な要求が記述される。
   例としては次のような項目が記述される。
   • 各機能によって利用される情報の型
   • DBの利用頻度
   • 実体と、実体間の関連(ER)
   • 完全性制約(要求仕様特性の完全性とは異なることに注意する)
   • データ保持に関する要求
5. (設計制約)
   標準規約やハードによる制限によってもたらされる設計制約が記述される。あんまりないかも。
6. (システムの属性)
   信頼性、可用性、保守性、移植性といったソフトウェアシステムの属性が記述される。これにより、各属性が達成されているか確かめることが出来る
7. その他の要求
   上記に該当しない要求が存在する場合、記述される。(素材班に対するRSが長くなりすぎないものであればここに記述する等)
8. コメント

その他の情報

目次・索引・付録が付加される。
特に目次と索引は重要であり、一般的な構成に従って作られる必要がある。一方付録はその通りではなく、入出力のサンプルや要求仕様を読むのに役立つ情報があると良い。

要求仕様の構成についての例

ゲーム開発は一般にオブジェクト指向ソフトウェア開発で行われる。この時、要求仕様もオブジェクトを中心として構成する場合の例を示す。

1. はじめに
2. 全体説明
3. 詳細な要求仕様
   1. 外部インタフェース要求
      1. ユーザインタフェース
      2. 通信インタフェース
      3. …
   2. クラス/オブジェクト
      1. クラス/オブジェクト1.○○
         1. 属性
            1. 属性1
            2. …
            3. 属性n
         2. 機能(メソッド)
            1. 機能要求1.1
            2. …
            3. 機能要求1.m
      2. クラス/オブジェクト2.○○
      3. …
      4. クラス/オブジェクトp.○○
   3. 性能要求
   4. 設計制約
   5. ソフトウェアシステムの属性
   6. その他の要求

おわりに

以上が要求仕様についての記事となります。結構急ぎで作っちゃったので抜けや表現の揺らぎ等あると思いますので、アドカレ記事として投稿後もちょくちょく修正していくと思います。また、ここに書いたことがすべてではないので気になったら自分でも調べてみてください。

ソフトウェア工学の第一地点としての要求工学にまつわるもののうち、要求仕様は、ソフトウェアとして、あるいはシステムとして、あるいはゲームとして何を作りたいかを開発メンバに明確に伝えるためのものです。RiG++での活動の視点で見れば、企画書および企画発表の次段階、「これ(企画段階で提案されたもの)を作るために、この機能や性能が無くてはならない」を、企画実現に向けて出来るだけ厳密に文書化したもの(創造性を伝える場でもありません)。これの如何によって設計の段階的詳細化やモジュール分割のレベルも異なります(要求仕様においてなされた記述の分割方法がそのまま設計でも分割されるわけではないですが)。

これからの企画作成もといプロジェクトのマネジメントに役立ったなら幸いです。