要件定義
平成21年度 秋期 システムアーキテクト試験 午後Ⅱ 問題 問1「要件定義について」である。
問題文
システムアーキテクトは,要件定義において,ユーザ要求をヒアリングし,その要求を正しく理解した上で,システムの要件としてドキュメントにまとめ,ユーザに確認する。
しかし,ユーザから提示された要求に漏れがあったり,ユーザ要求の意味を取り違えたりすると,システムから出力された情報が想定したものと異なったり,必要な情報の提供タイミングが遅くなったりするなど,本来,ユーザが求めているシステムにはならないことがある。したがって,システムアーキテクトは,次のような点に留意して,ユーザ要求をヒアリングし,その要求を正しく理解することが大切である。
- ユーザから提示された個々の要求に矛盾がないか。
- ユーザ要求として提示されるべき業務手順や法的な制約などが,ユーザ部門内では自明のこととして,省略されていないか。
その上で,要件としてまとめるために,対象業務をモデル化したり,ユーザ要求を可視化したりする。その際,ユーザとの認識の相違をなくすために,次のような工夫を行うことが重要である。
- モデルを分かりやすく表記するために,UML を用いたり,言葉の定義を統一するために用語辞書を作成したりする。
- 現行業務とシステム構築後の業務の変更点を明確にするために,両者の対比表を作成する。
- システムによって実現する機能と運用によって行う作業を明確にするために,業務の流れ,処理のタイミングを記述した業務フロー図を作成する。
あなたの経験と考えに基づいて,設問ア~ウに従って論述せよ。
設問ア
あなたが要件定義に携わったシステムについて,対象業務の概要とシステムの開発目的を,800 字以内で述べよ。
設問イ
設問アで述べたシステムについて,ユーザ要求を正しく理解するために,あなたはどのような点に留意してユーザ要求をヒアリングし,どのように要件としてまとめたか。800 字以上 1,600 字以内で具体的に述べよ。
設問ウ
設問イで述べた要件をまとめる際,ユーザとの認識の相違をなくすために,重要と考え工夫した点について,600 字以上 1,200 字以内で具体的に述べよ。
合格論文を書く手順
Step 1 「章立て」を作る
- 第1章 対象業務の概要とシステム開発の目的
- 1.1 対象業務の概要
- 1.2 システム開発の目的
- 第2章 ユーザ要求のヒアリングと要件のまとめ方
- 2.1 ユーザ要求のヒアリングで留意した点
- 2.2 要件やまとめ方
- 第3章 ユーザとの認識の相違をなくすために重要と考え工夫した点
論文案
第1章 対象業務の概要とシステム開発の目的
1.1 対象業務の概要
私は送配電会社の設備部門で,業務システムの企画・開発に携わっている。今回,送変電設備の保全業務である日常巡視,定期点検に関するシステム開発の要件定義を行ったことについて述べる。
日常巡視は,送電・変電それぞれで決められた頻度で,送電設備や変電所にある変電設備の異常有無を確認する。設備毎に巡視項目が決まっており,その項目に基づき,巡視を行う。
定期点検は,設備毎に定められた頻度で,点検を行う。設備の点検を行う際は,設備を停止して実施する。点検においても,設備毎に点検項目が決まっており,その項目に基づき,点検を行う。点検では,測定値の記録も行う。
巡視で取得する巡視記録,点検で取得する点検記録は,設備の修繕や更新計画の策定に活用される。
1.2 システム開発の目的
従来,日常巡視,定期点検の結果は紙媒体に記録していた。日常巡視,定期点検の記録を用いたデータ分析を行う際,人手によるデジタルデータ化が必要であり,大変な負担であった。そのため,巡視記録,点検記録の分析が進んでいなかった。
2021年10月,電力広域的運営推進機関は,送変電設備更新のための設備管理の高度化を目指し,『高経年化設備更新ガイドライン』を定めた。今後,このガイドラインに基づき,高経年化設備更新の計画を策定する必要がある。それには,巡視記録や点検記録の分析は不可欠である。そのため,巡視点検システムを開発し,スマートデバイスで巡視や点検の結果を記録し,設備保全システムで設備情報と一元的に管理できるようにする。
第2章 ユーザ要求のヒアリングと要求のまとめ方
2.1 ユーザ要求のヒアリングで留意した点
(1)巡視点検システム開発の目的を共有
ユーザ要求をヒアリングする前に,巡視点検システムを開発する目的を共有した。ヒアリングするユーザに対して,以下のシステム開発の背景・目的・コンセプトを説明した。
- 背景:送変電設備は高経年化していること
- 目的:送配電会社の限られたリソースで高経年化した送変電設備を維持するためには,巡視・点検の記録を分析し,最適な設備修繕計画を策定する必要があること
- コンセプト:送電と変電の巡視・点検業務の共通化を行い,システム開発費用を抑えること
上記のことを説明することで,背景・目的・コンセプトに合致したユーザ要求をヒアリングできると考えた。
(2)送電・変電それぞれのユーザ要求をヒアリング
送電・変電のユーザ要求をまとめてヒアリングした場合,それぞれのユーザ要求の主張が激化して収集がつかなくなることが想定された。そこで,最初は送電・変電それぞれのユーザ要求をヒアリングすることにした。
(3)共通したユーザ要求は全体ミーティングでヒアリング
送電・変電それぞれでユーザ要求をヒアリングした結果,共通化できそうなユーザ要求がいくつかあった。共通化できるユーザ要求は,送電・変電が参加する全体ミーティングであらためてヒアリングし,齟齬がないようにした。
2.2 要件のまとめ方
(1)DFD作成
本システム開発の目的である巡視記録・点検記録が,設備情報と一元的に管理できることを可視化するため,DFDを作成した。開発する巡視点検システムで巡視・点検業務を行うことで,巡視記録・点検記録が一元的なデータベースへ保存できることをユーザに確認してもらった。
(2)ユーザ要求を可視化
送電・変電・共通のユーザ要求があるため,ユーザ要求を可視化することにした。具体的には,送電独自のユーザ要求,変電独自のユーザ要求,共通化したユーザ要求に整理し,一覧表を作成した。これにより,送電と変電のユーザ要求のバランスが適正であるか確認,さらに共通化できるユーザ要求がないかを深掘りした上で,要件をまとめた。
第3章 要件定義をまとめる際の工夫点
(1)業務フロー図作成
巡視点検システム構築後の業務をユーザが理解しやすくするため,業務フロー図を作成した。具体的には巡視・点検の準備,巡視・点検の実施,巡視・点検結果の報告までのフローである。作成した業務フローを,実際に巡視・点検を行うユーザに確認してもらい,システム構築後の巡視・点検業務が成り立つことを確認した。
(2)対比表作成
現行の業務とシステム構築後の業務の対比表を作成した。現行業務は送電・変電に分類して作成するが,システム構築後の業務は送電・変電の分類に加えて,共通の分類を追加した。これにより,システム開発のコンセプトである送電・変電の巡視・点検業務の共通化がどれだけ実現出来ているか,確認しやすくなる。
(3)機能一覧作成
巡視点検システムの開発に必要な機能一覧を作成した。一覧には,機能の名称,機能の概要,各機能の開発工数を記載する。ユーザは,各機能を実現することで得られる効率化効果を想定する。そして,各機能の開発工数と効率化効果をもとに,機能の優先順位付けを行う。これにより,限られた開発予算で,効果を最大化できる機能を選択することができる。
(4)全体説明会
要件をまとめる最終段階には,ユーザ要求をヒアリングした送電・変電のユーザに加えて,送変電設備部門の長(プロジェクトオーナー)にも参加してもらった。全体説明会でプロジェクトオーナーの承認を得た上で,開発工程へと進めることができた。
“要件定義” に対して1件のコメントがあります。