応用情報技術者 試験情報＆徹底解説

基本的には表2に記載されているユースケースを全て図中に描画することになります。ただし、表3「レビューでの指摘事項」にある「システム要求分析の範囲は，運用時間内の車両の運行に関する機能とすること」という記載があるので、範囲内かどうかに注意しなければなりません。

1つずつ考えていくために、図1の空白欄に番号を振った図を用いて解説します。
〔①について〕
ユースケース図に人型の図形（スティックマンと呼ばれます）として描画されているのが「アクタ」です。アクタは、システムの外部に存在し、システムと相互作用をする要素です。人ではない場合もあります。

表1を見てみるとアクタは、乗客、運転手、管理部門の3名です。乗客は既に図1に記載があるので、運転手または管理部門のいずれかであることがわかります。
問題文中に記載されている運転手のアクションは「運転手が運賃箱にその金額を運賃として設定する」こと、管理部門のアクションは「両替金の補充」です。「両替金の補充は，管理部門が運行時間外に行う」ため、運用時間内ではない管理部門のアクションはシステム要求分析の範囲外、すなわちユースケース図の記述対象外ということになります。したがって、①には「運転手」が当てはまります。

〔②について〕
ポイントは運転手、乗客の両者に関連するユースケースであることです。
問題文中で運転手が行うアクションとして説明されているのは、「整理券箱にICバスカードをかざさず，かつ，IC整理券を取り忘れた場合は、始発バス停からの運賃が適用され、運転手が運賃箱にその金額を運賃として設定する」ことだけです。このことから、②には運賃の設定に関することが入ることがわかります。
次に乗客のアクションを確認すると、「乗客がバスから降車する際，ICバスカードを利用していれば，ICバスカードを運転席横の運賃箱にかざすと運賃が確定する。IC整理券を利用していれば，IC整理券を運賃箱に投入すると運賃が確定する」と記載があるように、乗客がICバスカード、IC整理券を利用した場合は運賃箱により料金が確定します。

表2「ユースケース一覧」を見ると、項番3「運賃を確定させる」というユースケースがあるので、これが乗客と運転手に共通するユースケースであることがわかります。

〔③について〕
このユースケースはどのアクタとも関連を持ちません。どの要素とも何の関係を持たないユースケースは存在しないので、このユースケースは他のユースケースとの関係を持つと判断できます。

〔精算処理〕の説明には「精算とは，乗客が現金かICバスカードいずれか片方，又は両方の併用によって，運賃を支払うことである」とあるように、支払い方法には現金とICバスカードがあります。③と同じく、どのアクタとも関係を持たないユースケースとして「現金で支払う」がありますが、同列に扱うべき「ICバスカードで支払う」の記載がないので、③には項番5の「ICバスカードで支払う」が入るとわかります。

〔④について〕
表2中で残っているユースケースは、「チャージする」「現金を両替する」の2つです。
〔ICバスカード〕の説明には「乗客は，バス停や営業所にあるチャージ装置を使用してあらかじめ一定の金額をチャージする」と説明されています。この記述より、両替は、車両とは無関係の場所で発生するユースケースであり、今回のシステム要求分析の範囲外であることがわかります。
一方、問題文に「釣銭が必要な乗客は，運賃箱の両替機能で両替してから運賃を支払う」とあるように、両替は運行中の車両内で行われるアクションなのでユースケース図の記述対象です。図1中にはこの記載が不足しているので、④には項番7「現金を両替する」が当てはまります。

ここまでの内容を追記すると以下のようになります。次は「汎化（特化）」「包括」「拡張」の関連性を確認しましょう。

【汎化（特化）関係】
汎化とは様々な異なる対象に共通する性質や、共通して適用できる法則などを集めて抽象化した概念として表すことです。特化は汎化の対義語です。
飲み物を購入することを例にしましょう。
「水を買う」「お茶を買う」2つのユースケースについて、「飲み物を買う」というユースケースに共通化することができます。言い換えると、「飲み物を買う」を具体化したものが「水を買う」「お茶を買う」です。これらは以下のように表すことができます。

• 「水を買う」「お茶を買う」は「飲み物を買う」の特化である
• 「飲み物を買う」は「水を買う」「お茶を買う」の汎化である

図1より汎化（特化）可能なものを確認します。
表2「ユースケース一覧」の項番4に「抽象ユースケース。具体的な処理は項番5，6のユースケース」と説明されているように、「現金で支払う」「ICバスカードで支払う」は「運賃を支払う」を具体化したものです。よって、これらは以下のように表すことができます。

• 「現金で支払う」「ICバスカードで支払う」は「運賃を支払う」の特化である
• 「運賃を支払う」は「現金で支払う」「ICバスカードで支払う」の汎化である

この関係を記述すると以下のようになります。【包含関係】
包含は、あるユースケースが別のユースケースの一部であることを表します。
メース送信を例にしましょう。メール送信する際には「宛先の指定」「本文の記載」が必要です。言い換えると「メール送信」のユースケースには「宛先の指定」「本文の記載」を含んでいることになります。これらは以下のように表すことが出来ます。

• 「メール送信」は「宛先の指定」「本文の記載」を包括している

本問のユースケースには包含関係は存在していません。

【拡張関係】
拡張は、あるユースケースを使用する場合に、別のユースケースを利用する"可能性があるもの"を表します。
インターネットショッピングを例にしましょう。
注文を確定させる際、支払い方法がクレジットカードであれば、カード情報を登録する必要があります。しかし、支払いが銀行振込みであれば登録は不要です。これらは以下のように表すことができます。

• 「カード情報登録」は「注文確定」を拡張する

本問のユースケースには拡張関係は存在していません。

したがって、汎化（特化）関係のみを書き込んだユースケース図が完成形となります。

〔aについて〕
代替シナリオ1は「1：乗客は、ICバスカードを整理券箱にかざす」「2：システムは、ICバスカードのチャージ金額を読み取る」までは基本シナリオと同様の内容です。基本シナリオはICバスカードを利用しているため、代替シナリオ1もICバスカードを利用することがわかります。では、どこでアクションが分岐するのでしょうか。

〔運賃の確定〕の説明に「乗客がバスに乗車する際，ICバスカードを持っていれば，ICバスカードを乗車口の整理券箱にかざす。チャージ金額が初乗り金額未満の場合は，警告するが乗車は可能である」と記載があるように、チャージ金額が初乗り金額を満たしているかどうかでその後の"システム"の動作が異なります。
基本シナリオには「3：システムは、チャージ金額が初乗り金額以上であることを確認する」とあるため、チャージ金額がチャージ金額が初乗り金額以上であるときのシナリオであることがわかります。したがって、代替シナリオ1はチャージ金額が初乗り金額未満のときのシナリオになります。

この場合にシステムが行うのは、「システムはチャージ金額が初乗り金額未満であることを確認して乗客に警告する」です。よって、正解は「キ」です。
なお、警告をするのは運転手ではなくシステムであるため、「エ」は誤りです。

∴a＝キ：システムは，チャージ金額が初乗り金額未満であることを確認して乗客に警告する。

〔bについて〕
〔運賃の確定〕の説明を見ると、バスに乗車する際は「ICバスカードを利用する」「IC整理券を利用する」「どちらも利用しない」の3パターンがあります。基本シナリオ、代替シナリオ1はICバスカード利用時のパターンでした。例外シナリオはどちらの利用もない場合です。
したがって、「b」にはIC整理券を利用するパターンが入ります。この場合、「乗客は，整理券箱が発券するIC整理券を取り出す」ことになります。よって、正解は「コ」です。

∴b＝コ：乗客は，整理券箱からIC整理券を取り出す。

〔cについて〕
〔精算処理〕の説明に、「精算とは，乗客が現金かICバスカードいずれか片方，又は両方の併用によって，運賃を支払うことである。システムは，運賃の残金があればその金額を表示する」とあるように、運賃の残金があることが支払うための前提条件となっています。要するに、運賃箱にICバスカードまたはIC整理券をかざすなどして「運賃の残金が確定した」後でなければ、精算はできないということです。よって、正解は「ア」です。
もしかすると「シ：乗車バス停は確定している」と迷うかもしれませんが、この条件だと運賃箱にICバスカードまたはIC整理券をかざす前でも精算ができることになってしまうので、適切ではありません。

∴c＝ア：運賃の残金は確定している。

〔dについて〕
現金で支払うの3つのシナリオでは、「1:乗客は，現金を運賃箱に入れる」が共通しています。また、代替シナリオでは「2:現金が運賃の残金よりも少ない」、例外シナリオでは「2:現金が運賃の残金よりも多い」ケースをカバーしています。
[e]の処理を終えた後に、「3:システムは，運賃の残金を0に更新する」とあります。現金での精算に釣銭を返すことはできませんから、基本シナリオは、残金と同額の現金が投入された際のシナリオであることがわかります。したがって、「システムは，現金が運賃の残金と等しいことを確認する」が当てはまります。よって、正解は「カ」です。

∴d＝カ：システムは，現金が運賃の残金と等しいことを確認する。

システムに求められる要件は機能要件と非機能要件に分類できます。機能要件はそれがないとシステムとして成立しないもの、非機能要件はそれ以外の要件と考えることができます。

機能要件

システムやソフトウェア開発に際して定義される要件のうち、業務要件を実現するための機能に関するもの。業務をシステム化する際に必ず満たすべき要件のことを指す。そのシステムが扱うデータの種類や構造、処理内容、ユーザーインタフェース、帳票などの出力の形式などが含まれる。

非機能要件

機能要件以外の要件のこと。性能や可用性、及び運用・保守性などの「品質要件」のほか、「技術要件」「セキュリティ」「運用・操作要件」「移行要件」「環境対策」などが非機能要件として定義される項目となる。

両替機を例に考えてみましょう。
例えば、1,000円札を入れた場合、両替といっても1円、5円、50円、100円と様々な硬貨があります。この場合「100円玉が10枚が出てくる」「ボタン1を押すと500円玉2枚、ボタン2を押すと100円玉10枚が出てくる」といったように、1,000円札も入れた際の動作を決定しないとシステム（両替機）として成り立ちません。このように、必ず要件を確定させる必要があるもの、言い換えると、決定していないとシステム構築が出来ない機能が機能要件です。
一方、非機能要件とはシステムの動作以外に関して求められるものです。両替機でいえば「1,000円札を入れた後、3秒以内にお金が出てくること」「100円玉は10,000枚まで格納出来ること」といったようなシステムの根幹動作とは関係ない要件です。

• 業務手順は機能要件です。
• 正しい。信頼性に対する要求なので非機能要件です。
• 正しい。効率性に対する要求なので非機能要件です。
• 業務で扱うデータの構造は機能要件です。
• 非機能要件ですが、チャージは運行している車両とは別の場所で行われるため、システム要求分析の範囲外です。
• 正しい。効率性に対する要求なので非機能要件です。
• 業務処理の内容や業務ロジックは機能要件です。

∴イ，ウ，カ