JP2017049697A - システム開発における要求定義決定支援システム - Google Patents

Abstract

【課題】鉄道の信号保安システム、或いはこれと同様の特徴を有するシステムの開発の際などに、システムに対する要求の検討漏れを大幅に減らすことのできる要求定義決定支援システムを提供する。【解決手段】複数の項目に関する複数の記録欄を有する要求分析テンプレートに従って外部から入力された内容を記憶装置へ記憶させる記録制御部と、要求分析テンプレートに従って記憶装置へ記憶された内容を外部から閲覧可能にする閲覧制御部とを備えた要求定義決定支援システムである。要求分析テンプレートには、分析結果項目、機能要求項目、非機能要求項目、および機能検証項目が含まれている。さらに、機能要求項目と非機能要求項目とには、これらの項目の要求内容が入力されるように設定された記録欄と、項目の内容について依頼者と設計者との間で行われた質疑内容が入力されるように設定された質疑記録欄とが設けられている。【選択図】図２０

Description

本発明は、システムの開発時などに、システムに対する依頼者の要求を分析する工程の支援を行う要求定義決定支援システムに関する。

以前より、システム開発の上流工程においてシステムに対する依頼者の要求を分析し、この要求の分析結果に従ってシステムの仕様を設計することが行われている。要求は、上位の要求である親要求と下位の要求である子要求とに階層化することができる。子要求とは親要求を実現するために親要求を詳細に展開した要求のことである。要求を分析する上流工程は、システムを実際に開発する下流工程に大きな影響を及ぼす。よって、システム開発を効率的に行う上で、要求分析の品質を向上することが不可欠である。なお、本明細書においてシステム開発と言ったときには、ハードウェアとソフトウェアとを含んだシステム全体の開発だけでなく、ハードウェア単体或いはソフトウェア単体の開発も含むものとする。

従来、システムへの要求が漏れなく仕様書に反映されるように、推奨すべき記述項目および記述指針が示されたＩＥＥＥ８３０−１９９８要求仕様書テンプレートが策定されている。
また、従来、システムの要求分析を支援する幾つかの技術が提案されている。例えば、特許文献１には、業務要件または仕様、機能等のオブジェクトを粒度が揃った状態でデータベースに登録できるようにしたシステム開発支援システムが提案されている。また、特許文献２には、入力すべき項目が開発対象のシステム間で異なる場合でも、システムごとに未記入項目を抽出して要求仕様書の抜けまたは漏れを指摘できるソフト要求仕様書作成支援システムが提案されている。

特許第４６０１９９８号公報 特許第４９４６１７０号公報

本発明者らは、鉄道の信号保安システムの分野において、システム開発に有効な要求分析の手法について検討した。検討の過程において、この分野のシステム開発には、他の分野のシステム開発と異なり、次のような特徴があることが分かった。例えば、システムへの要求として、安全性、信頼性、保守性などの非機能的な要求が多いという特徴、列車の動きなど外部のイベントの様々なパターンに対応することを考慮しなければならないという特徴、現行システムの仕様が結線図または制御図表により表わされることが多いという特徴、基本的な要求から不具合対策の要求など要求の抽象度が大きくばらつくという特徴などである。

そして、このような特徴を有するシステム開発に、上記従来の要求仕様書テンプレートまたは要求分析の手法を適用すると、システム開発の特徴に対応しきれずに、システムに対する要求の検討漏れが比較的に多く発生することが明らかになった。
例えば、上記のシステム開発では、上記の特徴により、要求が依頼者から暗黙に示されて設計者に伝わりにくい場合、様々な外部イベントを考慮したときに初めて要求に気が付く場合、現状のシステムの仕様に要求が表れているが依頼者も設計者もこの要求に気づき
にくい場合が多くある。このため、この分野の要求分析の工程では、依頼者と設計者とが情報を共有していく過程で、必要なシステムの要求を明らかにしていくことが必要である。

要求分析の過程で要求を明らかにしていく場合、要求の内容のみを記録し、その経緯を記録していないと、その後のシステムの仕様を設計する段階で、要求を正しく理解しにくくなるという課題が生じる。一方、無秩序に経緯の記録を多く残すと、多くの要求を整理して理解することが難しくなるという課題が生じる。そして、このような困難さがあると、システムに対する要求の検討漏れが多く発生すると考えられる。
このような要求分析時の課題は、鉄道の信号保安システムの分野にのみ該当するものではなく、同様の特徴を有すれば、他の分野のシステム開発の際にも同様に生じると考えられる。

本発明は、鉄道の信号保安システム、或いはこれと同様の特徴を有するシステムの開発の際などに、システムに対する要求の検討漏れを大幅に減らすことのできる要求定義決定支援システムを提供することを目的としている。

本発明は、上記目的を達成するため、システムに対する依頼者の要求を分析する工程の支援を行う要求定義決定支援システムであって、
複数の項目と前記複数の項目に対応する複数の記録欄とを有する要求分析テンプレートに従って外部から入力された内容を記憶装置へ記憶させる記録制御部と、
前記要求分析テンプレートに従って前記記憶装置へ記憶された内容を外部から閲覧可能にする閲覧制御部と、
を備え、
前記要求分析テンプレートには、
前記複数の項目および前記複数の記録欄のうち、互いに対応する項目および記録欄として、
前記システムにより代替される現行システムの分析結果に関する分析結果項目、および前記分析結果項目の内容が入力されるように設定された分析結果記録欄と、
前記システムの機能的な個々の要求である子要求に関する機能要求項目、前記機能要求項目の内容が入力されるように設定された機能要求記録欄、および前記機能要求項目の内容について前記依頼者と前記設計者との間で行われた質疑内容が入力されるように設定された機能要求質疑記録欄と、
前記システムに求められる品質または特性に関する非機能的な要求に関する非機能要求項目、前記非機能要求項目の内容が入力されるように設定された非機能要求記録欄、および前記非機能要求項目の内容について前記依頼者と前記設計者との間で行われた質疑内容が入力されるように設定された非機能要求質疑記録欄と、
どのような外部イベントに対して前記システムがどのように動作するかという検証内容と検証結果とに関する機能検証項目、および前記機能検証項目の内容が入力されるように設定された機能検証記録欄と、
が含まれ、
前記記録制御部は、互いに対応する前記項目と前記記録欄とを対応づけた入力画面データを生成し、前記入力画面データに基づき表示された入力画面を介して前記記録欄に入力された内容を前記項目に対応づけて前記記憶装置に記憶させ、
前記閲覧制御部は、前記記憶装置に記憶された前記内容と、前記内容に対応づけられた前記項目とを対応づけて表示する閲覧画面データを生成し、前記閲覧画面データに基づき表示された閲覧画面により前記要求分析テンプレートの内容を閲覧可能にすることを特徴としている。

この構成によれば、要求分析テンプレートに従って、分析結果記録欄、機能要求記録欄、機能要求質疑記録欄、非機能要求記録欄、非機能要求質疑記録欄、および機能検証記録欄に、必要事項が入力される。これにより、鉄道の信号保安システムの開発のような特徴を有するシステム開発の際、システムへの要求を明確にすることができる。具体的には、分析結果記録欄に現行システムの分析結果が設計者により入力される。これにより、結線図または制御図表により現行システムの仕様が表わされているような場合でも、設計者による現状の仕様の理解が深まり、依頼者と設計者とで現状の仕様の情報を共有することができる。よって、現行システムの仕様の中に暗黙的に示されていた要求を依頼者と設計者との間で明らかにすることができる。また、非機能要求記録欄に入力される要求項目と質疑記録欄に入力される質疑内容とによって、暗黙的な要求になりやすい非機能要求が明示化され、検証可能な要求であれば具体的に検証可能な内容を明らかにするなど、より明確化した非機能要求を追及することができる。さらに、機能検証記録欄に検証内容および検証結果が入力される。これにより、例えば列車の動きなどの様々な外部イベントについて、どのような発生パターンを考慮し、どのような発生パターンを考慮しなくてよいのか、或いは、考慮すべき希少な外部イベントのパターンが発見されるなど、システムの要求仕様に関連して考慮すべき外部イベントのパターンを依頼者と設計者との間で明らかにすることができる。これにより、システムへの新たな要求を明らかにすることができる。

また、依頼者と設計者とで情報を共有する過程でシステムへの要求が明らかになる過程では、明らかになった要求の理解を深めるために、要求が明らかになる経緯を遡れるとよい。しかし、必要以上に経緯の記録が多いと、多数の要求を整理するのが難しくなる。そこで、本発明の構成によれば、機能要求記録欄と機能要求質疑記録欄とが別々に設けられている。さらに、非機能要求記録欄と非機能要求質疑記録欄とが別々に設けられている。そして、記録制御部および閲覧制御部によって、これらの記録欄の内容が項目に対応づけられて記憶されたり、項目に対応づけられて閲覧可能にされたりする。これにより、設計者は、例えばシステムの仕様を設計する際に、必要な経緯を遡ることができ、且つ、多数の要求を秩序正しく整理することができる。これらによって、システムに対する要求の検討漏れを大幅に減らすことができる。

好ましくは、前記要求分析テンプレートには、
互いに対応する前記項目および前記記録欄として、
前記システムの全体像に関する全体像項目、前記全体像項目の内容が入力されるように設定された全体像記録欄、および、前記全体像項目の内容について前記依頼者と前記設計者とで行われた質疑内容が入力されるように設定された全体像質疑記録欄と、
前記全体像に含まれる親要求、前記子要求、および前記非機能的な要求を含む各要求間の関連図を表わす項目である要求関連図項目、前記要求関連図項目の内容が入力されるように設定された要求関連図記録欄、ならびに前記要求関連図項目の内容について前記依頼者と前記設計者との間で行われた質疑内容が入力されるように設定された要求関連図質疑記録欄と、
が含まれるとよい。

この構成によれば、さらに、全体像記録欄に入力される全体像と、これに対応する全体像質疑記録欄に入力される質疑内容とによって、曖昧になりやすいシステムと周辺システムとの境界を明らかにでき、また、システムの根本的な要求を明確にできる。加えて、要求関連図記録欄において、要求間の関係が図示されることで、各要求の位置づけと各要求の導出根拠とが明確化される。よって、要求の抽象度にばらつきが多いシステム開発であっても、要求間の関係から、要求を誤解なく理解することができ、また、要求間の関係から要求の欠如がないか容易に認識することができる。これらによって、システムに対する要求の検討漏れを大幅に減らすことができる。

さらに好ましくは、前記依頼者と前記システムの仕様を設計する設計者とを識別可能な利用者識別情報を記憶する識別情報記憶部と、
前記利用者識別情報に基づいて各記録欄への入力の可否を管理するアクセス管理部とを、更に備え、
前記アクセス管理部は、
前記依頼者に対して前記機能要求記録欄と前記非機能要求記録欄との入力を許可し、前記設計者に対して前記分析結果記録欄と前記機能要求質疑記録欄と前記非機能要求質疑記録欄と前記機能検証記録欄との入力を許可する構成とするとよい。

依頼者と設計者とで情報を共有する過程でシステムへの要求が明らかになる過程では、依頼者と設計者との考えに差異が残っているのに、同一の考えに至っていると誤解する場合があり、このような誤解が下位の工程で大きな修正を要する事態を招くことがある。しかしながら、本発明の構成によれば、アクセス管理部が、上記のように依頼者による記録と設計者による記録とを分離する。よって、システムへの要求が明らかになる過程で、両者の考えが混同して入力されることが防止され、上記の誤解を避けることができる。よって、誤解の少ない要求分析が行われて、システムに対する要求の検討漏れを大幅に減らすことができる。

さらに好ましくは、前記依頼者と前記システムの仕様を設計する設計者とを識別可能な利用者識別情報を記憶する識別情報記憶部と、
前記利用者識別情報に基づいて各記録欄への入力の可否を管理するアクセス管理部とを、更に備え、
前記アクセス管理部は、
前記依頼者に対して前記全体像記録欄と前記機能要求記録欄と前記非機能要求記録欄と前記要求関連図記録欄との入力を許可し、前記設計者に対して前記全体像質疑記録欄と前記分析結果記録欄と前記機能要求質疑記録欄と前記非機能要求質疑記録欄と前記要求関連図質疑記録欄と前記機能検証記録欄との入力を許可する構成とするとよい。
この構成によれば、アクセス管理部が、全体像記録欄、全体像質疑記録欄、分析結果記録欄、機能要求記録欄、機能要求質疑記録欄、非機能要求記録欄、非機能要求質疑記録欄、要求関連図記録欄、要求関連図質疑記録欄、機能検証記録欄において、依頼者による記録と設計者による記録とを分離する。よって、システムへの要求が明らかになる過程で、両者の考えが混同して入力されることが防止され、上記の誤解を避けることができる。よって、誤解の少ない要求分析が行われて、システムに対する要求の検討漏れを大幅に減らすことができる。

さらに好ましくは、前記機能要求質疑記録欄および前記非機能要求質疑記録欄を含む複数の質疑記録欄には、前記設計者により作成される仕様書の中で要求内容を反映する反映箇所が入力可能に設定された参照項目が設けられているとよい。
この構成によれば、少なくとも機能要求質疑記録欄および非機能要求質疑記録欄に、要求内容が反映されている仕様書の箇所が入力可能なので、この仕様書の箇所の入力によりシステム仕様のトレーサビリティを向上することができる。

本発明の要求定義決定支援システムによれば、鉄道の信号保安システム、或いはこれと同様の特徴を有するシステムの開発の際などに、システムに対する要求の検討漏れを大幅に減らすことができる。

本発明の実施の形態の要求定義決定支援システムの構成を示すブロック図である。 要求分析テンプレートの上位の項目と入力手順の一例を示す図である。 目的の項目の記録欄の一例を示す図である。 アクター一覧表の記録欄の一例を示す図である。 アクター配置図の入力例を示す図である。 機器間接続図の入力例を示す図である。 接続機器一覧表の記録欄の一例を示す図である。 機器間接続のチェックポイント記録欄の一例を示す図である。 要求の全体像の項目の記録欄の一例を示す図である。 現行システム分析結果の項目の記録欄の一例を示す図である。 外部とのインタフェースの項目の記録欄の一例を示す図である。 外部とのインタフェースの項目の入力例を示す図である。 外部とのインタフェースのチェックポイント記録欄の一例を示す図である。 処理内容のチェックポイント記録欄の一例を示す図である。 システム全体の非機能的な要求に関する記録欄の一例を示す図である。 安全性のチェックポイント記録欄の一例を示す図である。 ユーザインタフェースの項目の記録欄の一例を示す図である。 要求関連図の入力例を示す図である。 機能検証結果の項目の記入欄を示す図である。 データベースサーバの機能構成を示すブロック図である。 データベースサーバの制御処理の手順の一例を示すフローチャートである。

以下、本発明の実施の形態について図面を参照して詳細に説明する。図面においてシステム設計の依頼者側をユーザと記し、システム設計の設計者側をメーカと記している。
図１は、本発明の実施の形態の要求定義決定支援システムの構成を示すブロック図である。
本実施の形態の要求定義決定支援システム１は、要求分析テンプレートに従って要求等の記録と閲覧とを可能にしたデータベースサーバ１０と、データベースサーバ１０と通信ネットワークＷを介して接続された複数のクライアントコンピュータ２０〜２３とから構成される。

データベースサーバ１０は、要求分析テンプレートの内容を記憶する記憶装置１１を備え、複数のクライアントコンピュータ２０〜２３と通信を行って要求分析テンプレートの内容の記録および閲覧の制御を行う。
複数のクライアントコンピュータ２０〜２３は、画像表示を行う表示装置３１と、文字データや図形データの入力が可能な入力装置３２と、通信ネットワークＷを介してデータベースサーバ１０と通信を行う通信装置（図示略）とを備えている。

複数のクライアントコンピュータ２０〜２３は、例えば、依頼者（例えばユーザ開発部門）、設計者（例えばメーカ）、その他の登録者（例えばユーザ保守部門またはユーザ仕様管理部門など）により操作される。各利用者は、クライアントコンピュータ２０〜２３を使用してデータベースサーバ１０にアクセスし、要求分析テンプレートの入力内容を閲覧することが可能である。依頼者と設計者とは、データベースサーバ１０の認証処理により、要求分析テンプレートの所定の記録欄へ内容を入力可能にされる。

＜要求分析テンプレート＞
先ず、要求分析テンプレートについて説明する。
図２は、要求分析テンプレートの上位の項目と入力手順の一例を示す図である。
要求分析テンプレートは、要求分析時に検討すべき各種の項目を含み、各項目に対する検討結果を依頼者、設計者の各々が書き込むことができる。要求分析テンプレートの目的
は、第一に、要求分析時の検討観点を明示することで仕様定義の漏れを防止すること、第二に、仕様とその導出の根拠である要求との関連を明確にすることにある。

要求分析テンプレートは、依頼者から提示された「要求」に対して、どのような検討・協議を経て、どのような「仕様」とするに至ったか、その導出過程を記録するフォーマットを有している。また、依頼者が示す個別の要求は、より上位の要求から導出されるべきであり、要求分析テンプレートではその関係性、つまり各「要求」や各「仕様」に対する導出根拠を明確化する。
また、要求分析テンプレートは、依頼者の記録欄と設計者の記録欄とを分離している。これは、両者各々の考えを明示しやすくするためである。

要求分析テンプレートには、上位の項目として、「第１章＿目的」、「第２章＿全体像」、「第３章＿現行システムの分析結果」、「第４章＿機能要求」、「第５章＿非機能要求」、「第６章＿ユーザインタフェース」、「第７章＿要求関連図」、および「第８章＿機能検証結果」が設けられている。
要求分析テンプレートには、依頼者により内容を入力可能にされた記録欄と、設計者により内容を入力可能にされた記録欄とが、項目ごとに分離されて設けられている。要求分析テンプレートの各記録欄を示した各図においては、依頼者により入力可能な記録欄が「ユーザ記載」のラベル表示により示され、設計者により入力可能な記録欄が「メーカ記載」のラベル表示により示されている。
システムの仕様をまとめた仕様書は、要求分析テンプレートと別に作成される。

＜要求分析テンプレートの利用手順＞
要求分析テンプレートは、例えば、次のステップ１〜８の手順で内容が入力される。
１．初期要求の提示のため、依頼者が第１章の目的と第２章の全体像までを記載する。
２．要求の全体像に関して、依頼者と設計者とが協議を行い、設計者が合意内容を第２章まで記載する。この時点で、要求の全体像が確定したものとする（後からの変更は発生する可能性はある）。
３．次に、設計者は現行システムに関する分析を行い、その分析結果を３章に記す。依頼者はその分析結果を確認する。

４．依頼者は、確定した親要求を起点としてそれに関する子要求を洗い出し、４〜６章に記載する。
５．提示された要求に関して、依頼者と設計者とが協議を行い、不明点などを明らかにした上で、どのような仕様とするかを定めていく。その過程を４〜６章に記載する。
６．これらの検討を踏まえて、設計者は仕様書に仕様を記載し、依頼者はその内容を確認する。
７．定義した仕様が、様々な状況、様々な列車の動きに対しても妥当であることを検証し、その結果を要求分析テンプレートの第８章に記す。依頼者は、機能検証の範囲、および、検証結果に問題がないことを確認する。
８．依頼者は、非機能要求も含めたすべての要求に関する関連図を作成する

なお、典型的には、上記のステップ１〜８の手順で内容が入力される間、ステップ１〜８の手順の一部が繰り返されて、内容の追加或いは修正がなされることで、内容の検討が深められる。
なお、上述した要求分析テンプレートの上位の項目は、必ずしも全部が必要ということはない。開発するシステムの目的は、設計者および依頼者等の間で既に明らかになっている場合が多く、そのような場合には、テンプレートから第１章＿目的の項目が省かれてもよい。また、ユーザインタフェースが備わらないシステムでは、テンプレートから第６章＿ユーザインタフェースの項目が省かれてもよい。或いは、これらの項目をテンプレート
に残したまま、依頼者又は設計者による入力を省くようにしてもよい。

続いて、要求分析テンプレートの各項目の詳細について説明する。
＜第１章＿目的＞
図３は、目的の項目の記録欄の一例を示す図である。
目的の項目の目的は、システムを開発する根本的な目的を依頼者および設計者間で共有することにより、以降の要求分析を首尾一貫したものとすることにある。
目的の項目には、図３に示すように、依頼者により入力が可能な内容記録欄Ｃ１と、設計者により入力が可能な目的質疑記録欄Ｃ２とが設けられている。目的の項目の内容記録欄Ｃ１は目的記録欄と呼んでも良い。
内容記録欄Ｃ１は、システム開発の目的が入力されるように設定されている。例えば、現行システムをソフトウェアでリプレースするのであれば、リプレースする背景や理由が入力される。また、例えば、どのような問題を解決するために今回のシステムの開発に至ったのかが入力される。
目的質疑記録欄Ｃ２は、質疑項目、結論項目、参照項目を有し、目的の項目において、質疑の内容および結論があればそれらが入力されるように設定されている。参照項目には、設計者が作成した仕様書において、質疑内容が反映された箇所が入力される。
本明細書において、「入力されるように設定」とは、入力されるべき内容の説明が入力画面、本システムの説明書、或いは、本システムの説明用の別画面に記されることで、利用者が該当の記録欄に入力すべき内容を理解できるように構成されていることを示す。

＜第２章＿全体像＞
全体像の項目は、複数の下位の項目から構成される。下位の項目には、２．１節＿アクター、２．２節＿機器間接続、２．３節＿開発対象システムのハードウェア構成、２．４節＿要求の全体像、２．５節＿使用条件が含まれる。これらの節に含まれる内容記録欄が本発明に係る全体像記録欄の一例に相当する。続いて、各節の項目について説明する。

＜２．１節＿アクター＞
アクターの項目の目的は、システムと関連する要素を漏れなく洗い出すことで、開発対象システムに必要な機能やインタフェースの検討漏れを防ぐことである。また、関連する可能性のないものを明確にすることで、不必要な検討を避けることである。アクターとは、システムと関連する要素を意味する。
図４は、アクター一覧表の記録欄の一例を示す図である。
アクターの項目には、アクター一覧表の記録欄Ｃ３が設けられている。これは依頼者記録欄である。
アクター一覧表の記録欄Ｃ３は、アクターの候補がリストアップされ、且つ、各アクター候補について、開発対象システムとの想定される関わり方（”本システムとの関わり方”）（アクター候補として挙げた理由）が入力されるように設定されている。また、想定される関わり方に対して、開発対象システムでの対応方法（”本システムでの対応方法”）についても入力されるように設定されている。対応不要であるなら、その旨が明記され、それ以上の検討が不要であることが明らかにされる。候補としてリストアップしたものの、検討の結果、開発対象システムと関連しないことが判明したものについては、取り消し線で消去される。取り消し線で消去するのは、検討忘れではなく候補に挙がったことを明示しておくためである。

アクター一覧表の記録欄Ｃ３には、関連する可能性のあるアクター候補が幅広く列挙されるよう、複数のアクターの分類が示される。各分類のアクターとしては、例えば、次のような候補が入力される。
・人物．．．通行者、乗務員など
・装置．．．障害物検知装置、特殊信号発光器、定常監視装置、電源など
・列車・車両．．．通常列車、貨物列車、保守用車など
・車・バイク等．．．一般乗用車、大型車など
・自然現象．．．雨、風、雪、気温、電磁波など
・動物・虫．．．ネズミ、蟻など
・植物．．．雑草など

また、アクター一覧表の記録欄Ｃ３は、アクター種別が入力されるように設定されている。アクター種別の定義は、例えば、直接相互作用を行う１次のアクター、１次のアクターと相互作用を行う２次のアクター、２次のアクターと相互作用を行う３次のアクターなどである。
図５は、アクター配置図の入力例を示す図である。
アクター項目には、さらに、アクター配置図の記録欄Ｃ４が設けられている。これは依頼者記録欄である。
アクター配置図の記録欄Ｃ４には、アクターとシステムの位置関係、および、アクター同士の位置関係を明確にする図が入力されるように設定されている。アクター配置図が入力される際には、以下の留意点１〜３が示されるとよい。

留意点１．原則としてすべてのアクターを図に登場させる。ただし、アクターの数が多く、図が煩雑になる場合には、いくつかのアクターをグルーピングして表現する等の工夫をすること。
留意点２．アクターの位置関係を明確にするため、アクターでない補足的な要素も適宜登場させる。例えば、線路や踏切道など。
留意点３．配置図には以下のような情報を含めることができる。しかし、書き手が表現しようとした内容と、読み手がそこから読み取る内容に齟齬がある恐れがあるため、図から読み取るべき内容・読み取るべきでない内容について文として書き下しておくことが望ましい。例えば、距離、対象線路、アクターの配置順、場所、向き、大きさ、要素数など。

＜２．２節＿機器間接続＞
図６は、機器間接続図の入力例を示す図である。図７は、接続機器一覧表の記録欄の一例を示す図である。
機器間接続の項目には、開発対象システムと接続される機器を示した機器間接続図の記録欄Ｃ５と、接続機器に関する情報をまとめた接続機器一覧表の記録欄Ｃ６とが設けられる。これらは依頼者記録欄である。
機器間接続の項目の目的は、開発対象システムと直接接続される機器を明確にすることで、開発対象システムに必要な機能やインタフェースの検討漏れを防ぐことである。
機器間接続図の記録欄Ｃ５と接続機器一覧表の記録欄Ｃ６は、前節のアクター項目で示されたアクターのうち装置に分類されるもの全てが入力されるように設定されている。また、機器の接続関係と、接続機器数がわかるよう入力されるように設定されている。接続機器一覧表の記録欄Ｃ６は、各機器について次の情報が併せて入力されるように設定されている。
・開発対象システムと接続される機器の接続数（最小〜最大）
・設置場所
・種類又は型名
・接続種別

各機器について実際には複数の機種・製品が存在するケースが想定される。このため、接続機器一覧表の記録欄Ｃ６は、把握された具体的な機器の機種を特定する種類又は型名が列挙され、且つ、それらと開発対象システムとの関わり方が入力されるように設定されている。接続種別には、関わり方として、次の番号が入力される。
１．今回の仕様での接続対象
２．今回の仕様での接続対象ではないが、将来接続対象となる可能性があるもの
３．今回の仕様での接続対象ではなく、将来接続対象となる可能性がないもの

図８は、機器間接続のチェックポイント記録欄の一例を示す図である。
機器間接続の項目には、さらに、チェックポイント記録欄Ｃ７と、全体像質疑記録欄（図示略）とが設けられる。
チェックポイント記録欄Ｃ７は、当該項目の検討においてチェックすべき留意点が示され、この留意点のステータスが入力されるように設定されている。ステータスとしては、次の何れかが選択される。
・既に明確になっている
・仕様書作成時に検討
・検討不要
全体像質疑記録欄は、図３の質疑記録欄Ｃ２と同様であり、質疑項目、結論項目、参照項目を有し、当該項目において質疑の内容および結論があればそれらが入力されるように設定されている。参照項目は、設計者が作成した仕様書において、質疑内容が反映された箇所が入力されるように設定されている。

＜２．３節＿開発対象システムのハードウェア構成＞
システムのハードウェア構成の項目の目的は、システムのソフトウェアへの要求を検討するにあたって、前提とすべきハードウェア構成を明らかにすることである。ここで示されるハードウェア構成を前提としてソフトウェアへの要求が成立する。したがって、ハードウェア構成に変更があれば、それに伴ってソフトウェアへの要求も変更となる可能性がある。
システムのハードウェア構成の項目には、図３の内容記録欄Ｃ１と質疑記録欄Ｃ２と同様に、依頼者により入力が可能な内容記録欄と、設計者により入力が可能な全体像質疑記録欄とが設けられている。

この項目の内容記録欄は、開発対象システムのハードウェア構成、或いは、想定しているハードウェア構成に関するイメージ又は概略が、ソフトウェアへの要求を検討できるだけの詳細度で入力されるように設定されている。言い換えれば、ここには、ソフトウェアに関連のない箇所について必要以上に詳細に入力される必要がない。
この項目の全体像質疑記録欄は、質疑項目、結論項目、参照項目を有し、システムのハードウェア構成の項目において、質疑の内容および結論があればそれらが入力されるように設定されている。参照項目は、設計者が作成した仕様書において、質疑内容が反映された箇所が入力されるように設定されている。

＜２．４節＿要求の全体像＞
図９は、要求の全体像の項目の記録欄の一例を示す図である。
要求の全体像の項目の目的は、第４章以降で展開される個別の要求（子要求）に対する上位の要求（親要求）を明確にし、ソフトウェアに対する要求の構造を明らかにすることである。
この実施の形態の要求分析テンプレートは、「親要求があり、それを実現するために子要求がある」という、要求の階層構造を示すことを主眼のひとつとしている。要求の全体像の項目で入力される親要求は、以降の要求分析の起点となる。
要求の全体像の項目には、図９に示すように、依頼者により入力が可能な内容記録欄Ｃ８と、設計者により入力が可能な全体像質疑記録欄Ｃ９とが設けられている。

内容記録欄Ｃ８は、親要求一覧の項目を含み、開発対象システムにおいて実現したい親要求が入力されるように設定されている。親要求は、システムに対する要求の全体構造を
示すものであるため、要求の数（もしくは粒度）は適切なものとする必要がある。１つの親要求では、第４章以降の展開が深くなりすぎる（多階層になりすぎる）恐れがあり、逆に多すぎる（10個以上）と全体の構造が見えづらくなる。そこで、人が一度に把握できる数と言われている７±２個程度にまとめるのが妥当だと思われる。よって、親要求の入力時に、７±２個程度にまとめるよう注意がなされるように構成するとよい。
内容記録欄Ｃ８で利用可能な記法としては、例えば、UML（Unified Modeling Language）ユースケース図、SysML（Systems Modeling Language）要求図、ゴールツリーなどを採用してもよい。

内容記録欄Ｃ８には、さらに、「信号保安装置に典型的或いは標準的な周辺機能として、監視（開発対象システムの機能不全の監視）、遠隔制御、動作記録、悪戯防止が想定され、これら必要な機能に漏れがないか確認すること」等の注意がなされてもよい。また、「将来見込まれる機能拡張のために、現時点で備えておく機能はないか確認すること」等の注意がなされてもよい。
全体像質疑記録欄Ｃ９は、質疑項目、結論項目、参照項目を有し、要求の全体像の項目において、質疑の内容および結論があればそれらが入力されるように設定されている。参照項目は、設計者が作成した仕様書において、質疑内容が反映された箇所が入力されるように設定されている。

＜２．５節＿使用条件＞
使用条件の項目の目的は、開発対象のシステムが満たすべき規格や、具体的な使用環境や条件を列挙することで、特に非機能面の妥当な仕様を導出する元情報とすることである。
使用条件の項目には、図３の内容記録欄Ｃ１と質疑記録欄Ｃ２と同様に、依頼者により入力が可能な内容記録欄と、設計者により入力が可能な全体像質疑記録欄とが設けられている。
この項目の内容記録欄は、法的に遵守が義務付けられている規格、鉄道分野における標準規格、その他の使用条件（耐用年数、使用環境、運用条件など）が入力されるように設定されている。なお、リレーでは実現できていた耐用年数も、ソフトウェア（正確にはソフトウェアが動作するための基盤である半導体装置）では達成できない可能性もある。ＯＳ（Operating System）など市販ソフトウェアのサポート期間も耐用年数に影響を及ぼす。よって、ソフトウェアの仕様定義においては、これらの要素に関する考慮が必要となる。
この項目の全体像質疑記録欄は、質疑項目、結論項目、参照項目を有し、使用条件の項目において、質疑の内容および結論があればそれらが入力されるように設定されている。参照項目は、設計者が作成した仕様書において、質疑内容が反映された箇所が入力されるように設定されている。

＜第３章＿現行システム分析結果＞
図１０は、現行システム分析結果の項目の記録欄の一例を示す図である。
現行システム分析結果の項目の目的は、現行システムにおいて実現されている機能、特に、現行システムに長年積み重ねられている不具合対策を、開発対象のシステムにおいても漏れなく検討できるようにすることである。また、現行システムをソフトウェア化することにより不要となる機能、および、追加すべき機能を特定することも目的としている。このような特定は、それまでリレーで実現されていた機能をソフトウェア化することに関する影響の分析に該当する。例えば、入力信号の微妙な振動（いわゆるチャタリング）に対して、リレーではその物理特性上、自ずと吸収される面もあったが、ソフトウェア化する際には別途対策が必要となる。

現行システムの分析結果の項目には、図１０に示すように、設計者により入力が可能な
内容記録欄Ｃ１１と、依頼者により補足的な情報が入力されるように設定された依頼者記録欄Ｃ１０と、が設けられている。内容記録欄Ｃ１１が本発明に係る分析結果記録欄の一例に相当する。現行システムの分析結果の項目は、主に設計者が入力するように設定されているが、分析に際して注意点等の補足的な情報があれば、依頼者が依頼者記録欄Ｃ１０に入力する。
内容記録欄Ｃ１１は、現行システムの分析結果が任意のフォーマットで入力されるように設定されている。分析結果には少なくとも次の内容が含まれるように画面上またはマニュアルにおいて注意が示されるとよい。
・現行システムの機能
・現行システムの主要な構成要素（構造）
・機能を実現する上での構成要素間の協調動作（振る舞い）
内容記録欄Ｃ１１で利用可能な記法としては、オブジェクト指向分析であれば、ユースケース図、クラス図、シーケンス図、状態遷移図などを採用することができる。構造化分析であれば、データフロー図、ＥＲ図（Entity Relationship Diagram）などを採用することができる。

＜第４章＿機能要求＞
機能要求の項目は、２．４節＿要求の全体像の項目で入力された複数の親要求の各々に１セットずつ設けられ、各セットが１節として表わされる。つまり、複数の親要求と同数の節が設けられる。各節に含まれる内容記録欄が本発明に係る機能要求記録欄の一例に相当する。以下、１番目の親要求を「親要求１」と記し、親要求１についての項目について説明する。
＜４．１節＿親要求１＞
機能要求の各節の項目は、複数の下位の項目から構成される。下位の項目には、４．１.１＿考慮すべき特殊事情、４．１．２＿外部とのインタフェース、４．１．３＿処理内容、４．１．４＿派生ポイントが含まれる。続いて、これらの各項目について説明する。

＜４．１．１＿考慮すべき特殊事情＞
考慮すべき特殊事情の項目の目的は、検討漏れとなる恐れのある特殊な事象や状況を依頼者側から設計者側へ予めインプットすることにより、検討漏れを防ぐことにある。
考慮すべき特殊事情の項目には、図３の内容記録欄Ｃ１と質疑記録欄Ｃ２と同様に、依頼者により入力が可能な内容記録欄と、設計者により入力が可能な機能要求質疑記録欄とが設けられている。
この項目の内容記録欄は、親要求１に関する仕様を定義していく上で、特に配慮が必要な任意の項目、典型的には、特殊な線形の駅や関連する過去の不具合事例などが入力されるように設定されている。ここで入力された特殊な事象や状況は、後述する第８章＿機能検証の項目において、入力のひとつとして利用できる。つまり、ここに示された状況に対して、定義した仕様に問題がないことを第８章＿機能検証にて明らかにする
この項目の機能要求質疑記録欄は、質疑項目、結論項目、参照項目を有し、考慮すべき特殊事情の項目において、質疑の内容および結論があればそれらが入力されるように設定されている。参照項目は、設計者が作成した仕様書において、質疑内容が反映された箇所が入力されるように設定されている。

＜４．１．２＿外部とのインタフェース＞
図１１は、外部とのインタフェースの項目の記録欄の一例を示す図である。
外部とのインタフェースの項目の目的は、親要求１に関して、外部とのインタフェースの観点から子要求を漏れなく洗い出すことにある。
外部とのインタフェースの項目には、図１１に示すように、依頼者により入力が可能な内容記録欄Ｃ１２と、設計者により入力が可能な機能要求質疑記録欄Ｃ１３とが設けられている。子要求は、親要求１から複数に且つ階層的に派生して得られる。このため、内容
記録欄Ｃ１２には、複数の子要求の各々に１つずつ記録欄が設けられ、さらに、階層構造を表わす階層構造表示Ｌ１と階層表示Ｌ２とが付加されている。機能要求質疑記録欄Ｃ１３についても、１つの子要求ごとに１つの記録欄が設けられている。

内容記録欄Ｃ１２は、親要求１に関して、外部とのインタフェースに関する子要求が入力されるように設定されている。外部とのインタフェースとしては、例えば、ハードウェアとの入出力、他のソフトウェアとの入出力、通信上のインタフェース、およびユーザインタフェースなどがある。一つの具体例として、信号保安システムであれば、内容記録欄Ｃ１２において、入出力信号の定義、入出力信号の揺れやチャタリングの扱いについて、或いは、入出力のタイミングまたは処理サイクルについての子要求が入力される。
なお、ユーザインタフェースに関しては、第６章に別途項目があるので、そこでまとめて検討するようにしてもよい。また、システム全体としてまとめてユーザインタフェースに関する要求がある場合は第６章の項目で入力し、親要求から派生するユーザインタフェースに関する要求がある場合は本節の項目で入力するようにしてもよい。

機能要求質疑記録欄Ｃ１３は、質疑項目、結論項目、参照項目を有し、外部とのインタフェースの項目の各子要求ついて、質疑の内容および結論があればそれらが入力されるように設定されている。参照項目は、設計者が作成した仕様書における反映箇所が入力されるように設定されている。別のシステム開発の例であるが、図１２に、外部とのインタフェースの項目の入力例を示す。ここでは、駅のエレベータシステムの開発に関する入力例を示している。
外部とのインタフェースの項目には、さらに、チェックポイント記録欄が設けられる。図１３は、外部とのインタフェースのチェックポイント記録欄の一例を示す図である。
チェックポイント記録欄は、当該項目の検討においてチェックすべき留意点が示され、この留意点のステータスが入力されるように設定されている。ステータスとしては、次の何れかが選択される。
・既に明確になっている
・仕様書作成時に検討
・検討不要

＜４．１．３＿処理内容＞
処理内容の項目の目的は、親要求１に関して、処理内容の観点から子要求を漏れなく洗い出すことにある。
処理内容の項目には、図１１の内容記録欄Ｃ１２と機能要求質疑記録欄Ｃ１３と同様に、依頼者により入力が可能な内容記録欄と、設計者により入力が可能な機能要求質疑記録欄とが設けられている。内容記録欄には、複数の子要求の各々に１つずつ記録欄が設けられ、さらに、階層構造を表わす階層構造表示Ｌ１と階層表示Ｌ２とが付加されている。機能要求質疑記録欄にも、１つの子要求ごとに１つの記録欄が設けられている。

この項目の内容記録欄は、親要求１に関して、処理内容に関する子要求が入力されるように設定されている。
この項目の機能要求質疑記録欄は、処理内容に関する各子要求について、質疑の内容および結論と設計者が作成した仕様書における反映箇所とが入力されるように設定されている。
図１４は、処理内容のチェックポイント記録欄の一例を示す図である。
さらに、処理内容の項目には、チェックポイント記録欄Ｃ１４が設けられている。
チェックポイント記録欄Ｃ１４は、当該項目の検討において、機能の動作条件と機能の範囲とのチェックすべき留意点が示され、この留意点について、既に明確になっているか、仕様書作成時に検討するか、或いは検討不要かを表わすステータスが入力されるように設定されている。

＜４．１．４＿派生ポイント＞
派生ポイントの項目の目的は、将来、拡張や派生が見込まれる項目を事前に提示することで、それに備えた設計を行い、将来の開発を効率的に進められるようにすることにある。また、今回開発するシステムの範囲内で、カスタマイズが必須な項目があれば本節で明示し、開発の後戻りを防止することも目的としている。開発の後段になって、カスタマイズに大きな設計変更工数を要するという事態を避けるためである。
よって、派生ポイントの項目は、“開発対象のシステムにおいてカスタマイズ可能としておく項目”と、“将来発生し得る変更項目”とに細分化される。

”開発対象のシステムにおいてカスタマイズ可能としておく項目”には、図１１の内容記録欄Ｃ１２と機能要求質疑記録欄Ｃ１３と同様に、依頼者により入力が可能な内容記録欄と、設計者により入力が可能な機能要求質疑記録欄とが設けられている。内容記録欄には、複数の子要求の各々に１つずつ記録欄が設けられ、さらに、階層構造を表わす階層構造表示Ｌ１と階層表示Ｌ２とが付加されている。機能要求質疑記録欄についても、１つの子要求ごとに１つの記録欄が設けられている。
この項目の内容記録欄は、親要求１に関して、カスタマイズ可能としておく内容についての子要求が入力されるように設定されている。例えば、設置される駅毎に調整が必要となるパラメータに関する子要求などが入力される。ここで入力される内容は、明確な子要求であり、仕様化される内容である。

この項目の機能要求質疑記録欄は、各子要求について、質疑の内容および結論と設計者が作成した仕様書における反映箇所とが入力されるように設定されている。
“将来発生し得る変更項目”には、図３の内容記録欄Ｃ１と質疑記録欄Ｃ２と同様に、依頼者により入力が可能な内容記録欄と、設計者により入力が可能な機能要求質疑記録欄とが設けられている。
この項目の内容記録欄は、親要求１に関して将来発生し得る変更内容が入力されるように設定されている。ここで示される内容は、あくまで見込みであって確定した情報である必要はない。可能であれば、提示された変更内容の予定について、発生確率に基づき優先度付けがなされると良い。これらの情報は、設計時の判断材料として利用することができる。ここで入力される内容は、システムの設計に有益な参考情報となるが、基本的には仕様化されない。なお、仕様化に含めるよう場合には、それを明記するよう要求分析テンプレート中に注意が示されていてもよい。

＜第５章＿非機能要求＞
非機能的な観点からの要求は、暗黙的なものになりやすい。非機能要求の項目の目的は、暗黙的な要求を避けて、品質および特性に関する要求を明確にするものである。
非機能要求の項目は、システムに求められる品質または特性に関する複数の観点に応じて複数節の項目から構成される。複数の観点には、安全性、可用性、信頼性、保守性、移植性、効率性、使用性（Usability）、およびその他の非機能要求が含まれる。従って、非機能要求の項目には、下位の項目として、第１節＿安全性、第２節＿可用性、第３節＿信頼性、第４節＿保守性、第５節＿移植性、第６節＿効率性、第７節＿使用性（Usability）、および第８節＿その他が設けられる。その他には、例えば、互換性、セキュリティ、柔軟性、完全性、相互接続性、再利用性、堅牢性、試験性、保全性、機能性、パフォーマンス、支援可能性（Supportability）などが含まれる。各節に含まれる内容記録欄が本発明に係る非機能要求記録欄の一例に相当する。複数節の各項目に設けられた記録欄は互いに略同様であるので、１つの節の項目に設けられた記録欄について説明する。
各節の項目には、依頼者により入力が可能な内容記録欄と、設計者により入力が可能な非機能要求質疑記録欄とが設けられている。

各節の内容記録欄は、１つの観点ごとに、システムが満たすべき要求事項が入力されるように設定されている。要求事項を仕様に含める場合には、極力検証可能な内容が入力されるように依頼人に注意が記されるとよい。なお、使用性についての要求事項は、主にユーザインタフェースが満たすべき性質を表わすことになるが、機能的な要求とも関連する。例えば、汎用コンピュータにおけるＧＵＩ（Graphical User Interface）を想定すると、ある処理の実行中でもキャンセルできること、処理の進捗度合が表示されることなどは、使用性の要求に含まれる。
非機能要求を満たすためには、ハードウェアとソフトウェアの協調を検討しなくてはならない場面も多い。そのため、要求分析テンプレートに入力できない内容もあり得るが、その場合、要求分析テンプレートにはリンク情報を記載しておき、その非機能要求に対するトレーサビリティが確保できるようにしておくとよい。

このような入力により、ハードウェアとソフトウェアとの協調によって非機能要求が実現される場合、設計者はシステムの仕様の設計時、ソフトウェアの仕様がハードウェア仕様と併せて仕様検討がなされているか注意することができる。すなわち、ソフトウェアの仕様がハードウェア仕様を踏まえた仕様になっているか、特に性能などの非機能要求に対してハードウェアの処理時間を加味してソフトウェアの仕様が設計されているか、設計者が検討することができる。
非機能要求は、多くの場合、２．４節＿全体の要求で挙げられた個々の親要求に対して導出されるものではなく、開発対象のシステム全体に対して導出される。このため、非機能要求の項目には、システム全体の非機能的な要求に関する記憶部と、個々の親要求についての非機能的な要求に関する記録部とが、分離して設けられている。
図１５は、システム全体の非機能的な要求に関する記録部の一例を示す図である。
システム全体の非機能的な要求に関する記憶部には、依頼者により入力が可能な内容記録欄Ｃ１６と、設計者により入力が可能な非機能要求質疑記録欄Ｃ１７とが設けられている。

システム全体の非機能的な要求は、１つの要求から複数に且つ階層的に派生することがある。このため、図１５に示すように、内容記録欄Ｃ１６には、派生元と派生先とを合わせた複数の要求の各々に１つずつ記録欄が設けられ、さらに階層構造を表わす階層構造表示Ｌ１と階層表示Ｌ２とが付加されている。非機能要求質疑記録欄Ｃ１７についても、個々の要求ごとに１つの記録欄が設けられている。
個々の親要求についての非機能的な要求に関する記録部は、図１１の内容記録欄Ｃ１２と機能要求質疑記録欄Ｃ１３と同様の記録欄を有している。
上述したように非機能要求の項目には、下位の項目として、第１節＿安全性、第２節＿可用性、第３節＿信頼性、第４節＿保守性、第５節＿移植性、第６節＿効率性、第７節＿使用性（Usability）、および第８節＿その他の節が設けられている。そして、各節に対応して、上述したシステム全体の非機能的な要求に関する記録部と、個々の親要求についての非機能的な要求に関する記録部とが別途設けられている。

図１６は、非機能要求の安全性の項目のチェックポイント記録欄の一例を示す図である。
第５章＿非機能要求の第１節＿安全性の項目には、上述した各記録欄に加えて、さらに、チェックポイントの記録欄Ｃ１８が設けられている。チェックポイント記録欄Ｃ１８は、当該項目についてのチェックすべき留意点が示され、この留意点について、既に明確になっているか、仕様書作成時に検討するか、或いは検討不要かを表わすステータスが入力されるように設定されている。

＜第６章＿ユーザインタフェース＞
図１７には、ユーザインタフェースの項目の記録欄の一例を示す図である。
ユーザインタフェースの項目の目的は、ユーザインタフェースに関する要求を漏れなく抽出することである。
ユーザインタフェースの項目には、図１７に示すように、依頼者により入力が可能な内容記録欄Ｃ１９と、設計者により入力が可能なユーザインタフェース質疑記録欄Ｃ２０とが設けられている。内容記録欄Ｃ１９とユーザインタフェース質疑記録欄Ｃ２０には、イメージ又は概略の入力を推奨する旨の表示が行われている。ユーザインタフェースの項目の内容記録欄Ｃ１９はユーザインタフェース記録欄と呼んでもよい。

内容記録欄Ｃ１９は、開発対象システムが持つ、操作盤等のユーザインタフェースに対する要求が入力されるように設定されている。特に、システムの動作状況を示すユーザインタフェースに関しては、荒天などの状況を考慮した要求、例えば視覚（光）、聴覚（音）、および触覚（手触り）に関する要求が入力される。ユーザインタフェースに関する要求や仕様は、開発期間中にも変更が生じやすい要素である。変更に関して、依頼者と設計者との間での齟齬を防ぐために、依頼者は、変更が容易であると期待する項目（例えば、ボタンの色、配置の変更又は追加など）を入力しておくとよい。また、設計者は、ユーザインタフェース質疑記録欄Ｃ２０に、変更が困難であることを依頼者に認識しておいてほしい項目を入力しておくとよい。

なお、ユーザインタフェースの項目は、入力者が項目を細分して複数の節を追加できるように構成してもよい。例えば、６．１節＿踏切制御装置本体、６．２節＿モニタソフトウェアなどの追加を可能としてもよい。また、ユーザインタフェースに関しては、第４章＿機能要求の項目において入力することも可能である。親要求の単位でユーザインタフェースに対する要求を示したほうが理解しやすい場合は第４章＿機能要求の項目に入力し、全体としてまとめた方が理解しやすい場合は、ユーザインタフェースの項目に入力するようにしてもよい。

＜第７章＿要求関連図＞
図１８は、要求関連図の入力例を示す図である。
要求関連図の項目の目的は、すべての要求に関する関連を俯瞰することである。特に親要求と子要求以外の関係性は、前章までに表現されていないため、本章にて明確にする。
要求関連図の項目には、図１８に示すように、依頼者により入力が可能な内容記録欄Ｃ２１と、設計者により入力が可能な要求関連図質疑記録欄Ｃ２２とが設けられている。内容記録欄Ｃ２１が本発明に係る要求関連図記録欄の一例に相当する。
内容記録欄Ｃ２１は、非機能要求も含めた、全ての要求に関するゴールツリーが入力されるように設定されている。ここで入力される図は、２．４節で示された要求の全体構造に、第４章＿機能要求以降の各証で展開した子要求を追加したものとなる。要求関連図は、ゴールツリーの代わりにSysML要求図を用いて、親要求と子要求とのの構造を表現しても良い。また、親要求と子要求との関係にないが要求間に何らかの関連がある場合、ゴールツリー上に追加の線を記し、仕様変更時の調査に活用できるようにしておくとよい。
要求関連図質疑記録欄Ｃ２２は、質疑項目、結論項目、参照項目を有し、要求関連図の項目において、質疑の内容および結論があればそれらが入力されるように設定されている。参照項目は、設計者が作成した仕様書において、質疑内容が反映された箇所が入力されるように設定されている。

＜第８章＿機能検証結果＞
図１９は、機能検証結果の項目の記入欄を示す図である。
信号保安システムの仕様は、様々な状況、様々な列車の動きに対しても要求を満たすことを検証する必要がある。機能検証結果の項目の目的は、様々な状況、様々な列車の動きとは具体的に何であるかを示し、検証すべき範囲を依頼者と設計者とで共有することである。さらに、検証すべき範囲内において、具体的に検証した結果を両社で確認することを
目的としている。
機能検証結果の項目には、図１９に示すように、依頼者により内容が入力可能であり、補足的な情報が入力されるように設定された依頼者記録欄Ｃ２３と、設計者により入力が可能な内容記録欄Ｃ２４とが設けられている。内容記録欄Ｃ２４が本発明に係る機能検証記録欄の一例に相当する。機能検証結果の項目は、主に設計者が入力するように設定されているが、検証結果に対するコメントなどの補足的な情報があれば、依頼者が依頼者記録欄Ｃ２３に入力する。

内容記録欄Ｃ２４は、検証すべき範囲と、検証対象とした具体的な状況と、検証結果とが入力されるように設定されている。検証すべき範囲としては、具体的な状況を列挙するのではなく、どのような要素の組み合わせによって、様々な状況が網羅されるのかが入力される。例えば、列車長と列車速度と列車台数の組み合わせによって作り出される状況を、様々な状況の全てとするなどである。この検証すべき範囲の中から、検証対象とした具体的な状況が選択される。そして、検証結果により、検証すべき範囲のいくつかの具体的な状況に対して、仕様に問題がないことが示される。
また、検証結果の記録欄は、４．ｎ．１節（ｎは親要求の番号）に示された、特に配慮が必要な特殊状況に対する検証結果も併せて入力されるように設定されている。
なお、例えば検証結果の記法には、図１９の検証結果の欄に示される拡張タイミングチャートを採用してもよい。拡張タイミングチャートは、複数の列車の動きを位置−時刻のグラフ上に帯として描き、各要素の状態を時間軸に沿って記したチャートである。

＜データベースサーバの詳細＞
続いて、データベースサーバの詳細を説明する。
図２０は、データベースサーバの機能構成を示すブロック図である。
データベースサーバ１０は、要求分析テンプレートの入力内容を記憶する記憶装置１１に加え、通信装置１２、アクセス管理部１３、テンプレート管理部１５、記録制御部１６、および閲覧制御部１７を備えている。
これらの各ブロックは、ＣＰＵ（中央演算処理ユニット）が制御プログラムを実行して機能するソフトウェア、或いは、ソフトウェアとハードウェアとが協働して機能する構成として実現される。

記憶装置１１には、要求分析テンプレートの各項目に入力された内容が記憶されるデータベース１１Ａ〜１１Ｈが設けられている。各データベース１１Ａ〜１１Ｈには、要求分析テンプレートのより細分化された項目に応じて、さらに細分化されたデータベースが構成されていてもよい。
通信装置１２は、通信ネットワークＷを介してクライアントコンピュータ２０〜２３とデータ通信を行う。
アクセス管理部１３は、クラインアントコンピュータ２０〜２３の接続に対して認証処理を行って、クライアントコンピュータ２０〜２３からデータベース１１Ａ〜１１Ｈへの読み書きの可否を管理する。アクセス管理部１３は、利用者を識別するための利用者ＩＤ（識別情報）と読み書きの許可情報とが記録されたアクセスＩＤ記憶部１４を有しており、認証処理で認証された利用者ＩＤに応じて各データベース１１Ａ〜１１Ｈの各記録欄への入力の可否を管理する。なお、データベースサーバ１０が複数のプロジェクトの要求分析テンプレートの記録および管理を行う場合には、アクセス管理部１３は、個々のプロジェクトごとに利用者ＩＤと読み書きの許可情報とを記録し、個々のプロジェクトごとに独立して利用者ＩＤと読み書きの許可情報を扱うようにするとよい。これにより、個々のプロジェクトごとに独立して、読み書きできる者の設定を行うことができる。

テンプレート管理部１５は、データベース１１Ａ〜１１Ｈへの入力完了の割合を計数しアクセス管理部１３へ通知する。この割合の情報は、通信装置１２と通信ネットワークＷ
とを介して各クライアントコンピュータ２０〜２３が受信し、要求分析テンプレートの閲覧画面に含ませるようにしてもよい。
記録制御部１６と閲覧制御部１７とは、各データベース１１Ａ〜１１Ｈに記憶された各記録欄の内容を、対応する項目と対応づけて表示するページデータを作成する。閲覧制御部１７が作成したページデータが本発明に係る閲覧画面データの一例に相当する。クライアントコンピュータ２０〜２３は、このページデータを受信することで、表示装置３１の画面に要求分析テンプレートを表示することができる。ここで、項目と記録欄とを対応づけるとは、例えば、１つの項目に含まれる複数の記録欄の先頭に項目名の表示を行ったり、１つの項目に含まれる複数の記録欄の少なくとも一部が表示されているときに画面の一部に項目名の表示を行ったり、或いは、クライアントコンピュータの操作者が項目名の確認操作を行ったときに現在表示されている記録欄に対応する項目名の表示を行ったりするなど、利用者が何れの項目の記録欄なのか認識できるように対応付けられていることを意味する。１つの項目中に、複数の記録欄が階層的に関連している場合には、階層的な関連も表わされたページデータが作成される。

記録制御部１６は、さらに、アクセス管理部１３の管理に従って、書込み許可のある記録欄については内容の入力および修正を可能とし、読出しのみ許可された記録欄については入力および修正を不可としたページデータを作成する。具体的には、依頼者のＩＤであれば、要求分析テンプレートに「ユーザ記載」と記された依頼者記録欄への入力および修正を可能とする。また、設計者のＩＤであれば、要求分析テンプレートに「メーカ記載」と記された設計者記録欄への入力および修正を可能とする。記録制御部１６が作成したページデータが本発明に係る入力画面データの一例に相当する。
記録制御部１６は、さらに、新たな入力または修正があった場合に、入力または修正のあった記録欄の内容を要求分析テンプレートの項目に対応づけて記憶装置１１に記憶させる。項目に対応づけて記憶させるとは、例えば、データベース１１Ａ〜１１Ｈのように、該当する項目に割り当てられた記憶領域へ内容を記憶させたり、或いは、項目を識別するための項目ＩＤと記録欄の内容とを対応づけて記憶装置１１に記憶させたりするなど、入力された内容が何れの項目の何れの記録欄に入力されたものであるのかコンピュータが識別可能な対応付けを行って記憶することを意味する。１つの項目中に、複数の記録欄が階層的に関連している場合には、複数の記録欄の階層構造を表わす階層構造データも付加されて記憶装置に記憶される。

図２１は、データベースサーバの制御処理の手順の一例を示すフローチャートである。
データベースサーバ１０は、クライアントコンピュータ２０〜２３からアクセスがあった場合に、図２１に示した手順で処理を実行する。
ステップＳ１では、先ず、アクセス管理部１３がプロジェクトＩＤの認証を行う。プロジェクトＩＤとは、データベースサーバ１０が複数のプロジェクトの要求分析テンプレートのデータ管理を行っている場合に、何れのプロジェクトであるか識別するための情報である。
ステップＳ２では、アクセス管理部１３は、プロジェクトＩＤに応じたアクセス許可情報をアクセスＩＤ記憶部１４から読み出す。アクセス許可情報とは、認証されたプロジェクトに対して登録された利用者を識別するための利用者ＩＤ（識別情報）と読み書きの許可情報とが含まれる情報である。
ステップＳ３では、アクセス管理部１３がアクセスした利用者の認証処理を行う。認証処理は、利用者ＩＤの入力を要求し、入力された利用者ＩＤとステップＳ２で読み出したアクセス許可情報とを照合して行われる。
ステップＳ４では、記録制御部１６または閲覧制御部１７が、記憶装置１１のデータベース１１Ａ〜１１Ｈに記憶されている内容と、各項目とを対応づけて要求分析テンプレートデータを作成する。ここで、記憶装置１１から読み出されるデータはプロジェクトＩＤに紐づけられたデータとする。
ステップＳ５では、ステップＳ３の認証処理で認証した利用者ＩＤに応じた分岐処理を行う。そして、利用者ＩＤが依頼者ＩＤであれば処理を一連のステップＳ６、Ｓ９〜Ｓ１１へ移行し、設計者ＩＤであれば処理を一連のステップＳ７、Ｓ９〜Ｓ１１へ移行し、その他の登録ＩＤであれば処理を一連のステップＳ８、Ｓ１２へ移行する。
ステップＳ６では、記録制御部１６が、ステップＳ４の要求分析テンプレートデータから、依頼者記録欄を入力可能とし、設計者記録欄を入力不可としたページデータを作成する。
ステップＳ７では、記録制御部１６が、ステップＳ４の要求分析テンプレートデータから、設計者記録欄を入力可能とし、依頼者記録欄を入力不可としたページデータを作成する。

ステップＳ８では、閲覧制御部１７が、ステップＳ４の要求分析テンプレートデータから、全ての記録欄を入力不可としたページデータを作成する。
ステップＳ９では、記録制御部１６が作成したページデータをアクセス元のクライアントコンピュータ２０又は２３へ送信する。
ステップＳ１０では、記録制御部１６が、アクセス元のクライアントコンピュータ２０又は２３から入力された記録欄のデータを受信する。記録欄のデータは、例えば、クライアントコンピュータ２０又は２３で編集終了の操作により送信させるように構成してもよい。
ステップＳ１１では、記録制御部１６が記録欄の入力内容と項目とを対応づけて記憶装置１１へ記憶させる。ここで、記録制御部１６は、プロジェクトＩＤに紐づけてデータを記憶装置１１へ記憶させる。そして、この制御処理が終了となる。
ステップＳ１２では、閲覧制御部１７が作成したページデータをアクセス元のクライアントコンピュータ２０又は２３へ送信する。そして、この制御処理が終了となる。

このような制御処理によって、システム設計の依頼者と設計者とは、システムに対する要求の検討および要求分析テンプレートへの入力を重ね、要求分析テンプレートの内容を充実していく。これにより、鉄道の信号保安システム、或いはこれと同様の特徴を有するシステムの開発の際に、システムに対する要求の検討漏れを大幅に減らすことができる。
また、ユーザ保守部門またはユーザ仕様管理部門は、作成途中の要求分析テンプレートを閲覧して、要求の内容について依頼者（ユーザ開発部門）へ意見を行うことができる。また、依頼者、設計者、ユーザ保守部門またはユーザ仕様管理部門は、作成が完了した要求分析テンプレートの内容を後から閲覧して、要求の定義を確認することもできる。
以上、本発明の実施の形態について説明した。しかしながら、本発明は実施の形態で説明した細部に制限されることなく、発明の趣旨を逸脱しない範囲で適宜変更可能である。例えば、上記実施の形態では、複数のクライアントコンピュータがデータベースサーバ１０と通信を行って要求分析テンプレートの内容を入力および閲覧する構成を示したが、１台のコンピュータが要求分析テンプレートの内容の入力、閲覧および記録を行うシステムとしてもよい。また、要求定義決定支援システム専用の構成はデータベースサーバのみとし、クライアントコンピュータはシステム専用外の任意のコンピュータにより構成してもよい。また、データベースサーバは、１つのコンピュータから構成してもよいし、複数のコンピュータを連携させて構成してもよい。

１ 要求定義決定支援システム
１０ データベースサーバ
１１ 記憶装置
１１Ａ〜１１Ｈ データベース
１２ 通信装置
１３ アクセス管理部
１４ アクセスＩＤ記憶部
１５ テンプレート管理部
１６ 記録制御部
１７ 閲覧制御部
２０〜２３ クライアントコンピュータ
３１ 表示装置
３２ 入力装置
Ｗ 通信ネットワーク

Claims (5)

1. システムに対する依頼者の要求を分析する工程の支援を行う要求定義決定支援システムであって、
   複数の項目と前記複数の項目に対応する複数の記録欄とを有する要求分析テンプレートに従って外部から入力された内容を記憶装置へ記憶させる記録制御部と、
   前記要求分析テンプレートに従って前記記憶装置へ記憶された内容を外部から閲覧可能にする閲覧制御部と、
   を備え、
   前記要求分析テンプレートには、
   前記複数の項目および前記複数の記録欄のうち、互いに対応する項目および記録欄として、
   前記システムにより代替される現行システムの分析結果に関する分析結果項目、および前記分析結果項目の内容が入力されるように設定された分析結果記録欄と、
   前記システムの機能的な個々の要求である子要求に関する機能要求項目、前記機能要求項目の内容が入力されるように設定された機能要求記録欄、および前記機能要求項目の内容について前記依頼者と前記設計者との間で行われた質疑内容が入力されるように設定された機能要求質疑記録欄と、
   前記システムに求められる品質または特性に関する非機能的な要求に関する非機能要求項目、前記非機能要求項目の内容が入力されるように設定された非機能要求記録欄、および前記非機能要求項目の内容について前記依頼者と前記設計者との間で行われた質疑内容が入力されるように設定された非機能要求質疑記録欄と、
   どのような外部イベントに対して前記システムがどのように動作するかという検証内容と検証結果とに関する機能検証項目、および前記機能検証項目の内容が入力されるように設定された機能検証記録欄と、
   が含まれ、
   前記記録制御部は、互いに対応する前記項目と前記記録欄とを対応づけた入力画面データを生成し、前記入力画面データに基づき表示された入力画面を介して前記記録欄に入力された内容を前記項目に対応づけて前記記憶装置に記憶させ、
   前記閲覧制御部は、前記記憶装置に記憶された前記内容と、前記内容に対応づけられた前記項目とを対応づけて表示する閲覧画面データを生成し、前記閲覧画面データに基づき表示された閲覧画面により前記要求分析テンプレートの内容を閲覧可能にすることを特徴とするシステム開発における要求定義決定支援システム。
2. 前記要求分析テンプレートには、
   互いに対応する前記項目および前記記録欄として、
   前記システムの全体像に関する全体像項目、前記全体像項目の内容が入力されるように設定された全体像記録欄、および、前記全体像項目の内容について前記依頼者と前記設計者とで行われた質疑内容が入力されるように設定された全体像質疑記録欄と、
   前記全体像に含まれる親要求、前記子要求、および前記非機能的な要求を含む各要求間の関連図を表わす項目である要求関連図項目、前記要求関連図項目の内容が入力されるように設定された要求関連図記録欄、ならびに前記要求関連図項目の内容について前記依頼者と前記設計者との間で行われた質疑内容が入力されるように設定された要求関連図質疑記録欄と、
   が含まれることを特徴とする請求項１記載のシステム開発における要求定義決定支援システム。
3. 前記依頼者と前記システムの仕様を設計する設計者とを識別可能な利用者識別情報を記憶する識別情報記憶部と、
   前記利用者識別情報に基づいて各記録欄への入力の可否を管理するアクセス管理部とを
   、更に備え、
   前記アクセス管理部は、
   前記依頼者に対して前記機能要求記録欄と前記非機能要求記録欄との入力を許可し、前記設計者に対して前記分析結果記録欄と前記機能要求質疑記録欄と前記非機能要求質疑記録欄と前記機能検証記録欄との入力を許可することを特徴とする請求項１記載のシステム開発における要求定義決定支援システム。
4. 前記依頼者と前記システムの仕様を設計する設計者とを識別可能な利用者識別情報を記憶する識別情報記憶部と、
   前記利用者識別情報に基づいて各記録欄への入力の可否を管理するアクセス管理部とを、更に備え、
   前記アクセス管理部は、
   前記依頼者に対して前記全体像記録欄と前記機能要求記録欄と前記非機能要求記録欄と前記要求関連図記録欄との入力を許可し、前記設計者に対して前記全体像質疑記録欄と前記分析結果記録欄と前記機能要求質疑記録欄と前記非機能要求質疑記録欄と前記要求関連図質疑記録欄と前記機能検証記録欄との入力を許可することを特徴とする請求項２記載のシステム開発における要求定義決定支援システム。
5. 前記機能要求質疑記録欄および前記非機能要求質疑記録欄を含む複数の質疑記録欄には、前記設計者により作成される仕様書の中で要求内容を反映する反映箇所が入力可能に設定された参照項目が設けられていることを特徴とする請求項１〜請求項４の何れか一項に記載のシステム開発における要求定義決定支援システム。