Zenn
😽

非機能要件の進め方

2024/06/11に公開
要件定義
非機能要件
非機能
tech

はじめに

今回の記事では、非機能要件を決める際の流れや各項目の選定方法、要求のレベルを決める際の
意思決定材料になるような情報をまとめることを目的としている。
非機能要件の項目・要求レベル選定においては、IPAが提供している非機能要求グレードを利用する方針で記載をしている。

大まかな流れ

  1. 実現したいシステムの規模感を確認する
  2. 項目1をもとに非機能要求グレード表にあるモデルシステムを選定
  3. 非機能要求シートをもとに案件内容から検討すべき項目を選定
  4. 項目2で選定した項目の要求レベルを選定
  5. 顧客に提出。フィードックをもとに内容を修正。
    ※各項目ごとに詳細は下記

前提

はじめに で記載した通り、下記の非機能要求グレードを用いる前提で記載を進めている。
下記ページの非機能要求グレード本体（日本語版）、利用ガイド［活用編］一括ダウンロード
からダウンロードが可能。非機能要求2018と古い年数がついているが、これが最新版である。
https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html

1.システムの規模感確認

対象システムがどういったものなのかは非機能要件の決める重要なファクターとなる。
例えば、基幹システムのように企業の業務遂行に重要なシステムであれば、高い可用性が求められる。あるいは、金融・インフラ関係のように国民生活や社会にあたえる影響が大きいものであれば非常に高い可用性が求められるし、企業の特定部門のみしか使わないような比較的限られた範囲で利用されるシステムであれば、ある程度性能や可用性は落とせる といったように非機能要件を判断する材料となる。このように、まずは実現したいシステムの規模間を確認する。
https://products.sint.co.jp/ober/blog/nonfunctionalrequirements

※基幹システム：「販売管理」「在庫管理」「会計」など企業がビジネスを遂行するために必須である業務を効率化ためのシステム

2.モデルシステムの選定

続いて、項目１で確認した自分のシステム規模感が非機能要求グレードでIPAが定めたモデルシステムと呼ばれるシステムの規模感ごとのグループ分けのうち、どこに該当するのかを確認する。
下記は01_利用ガイド解説編.pdfから抜粋したIPAが定めたモデルシステムの一覧と説明である。

例えば基幹システムの開発であれば、この表で見ると企業活動の基盤となるシステムなので項番２
の「社会的影響が限定されるシステム」となり、金融・インフラ関係であれば項番３「社会的影響が極めて大きいシステム」となり、企業内の特定部門だけ利用されるものであれば項番１「社会的影響が殆ど無いシステム 」となる。

この表だけで選定が難しいシステムであればよりモデルシステムごとに詳しい特徴が乗った
グレード表と呼ばれるものが03_グレード表というファイルで同梱されているはずなので
こちらを参考に選定を進める。

3.検討すべき非機能要求項目の選定

続いて、検討すべき非機能要求項目の選定を行う。
非機能要求項目に関しては、同梱されている06_活用シート.xlsを参照するとよい。

中を見ると、「非機能要求グレード活用シート」に非機能要求項目が分類ごとに列挙されている。
IPAとしては、非機能要件の項目を網羅的に埋めるためのツールとしてこのシートを提供しているため膨大な項目数があるが、全て考えるのは難しい。
なのでまずは項目の中から「重要項目」の印がついているものを対象とする。

さらに「重要項目」外のものでもシステムによっては考えるべき項目や
シートに存在しないが考えるべき項目当あれば独自に追加等して
検討すべき日機能要求項目の選定を進める。

クラウド？オンプレミス？

非機能要求グレードをもとに非機能要求を選定する際、
対象システムがクラウド環境下(AWS?)の場合に必要のない要求項目も混ざっている。
その分類分けを下記の方がわかりやすくまとめてくださっている。
https://github.com/yamazoon0207/aws-hikinou-grade

4.項目の要求レベルをモデルシステムから選定

続いて、項目3で選定した各非機能要求項目を「具体的な要求内容」を決めていく。
各項目の要求内容も、３と同じく06_活用シート.xlsに記載されている。
下記は「運用スケジュール」に関するレベル別要求一覧になる。

上記画像の赤枠内を見ると、運用スケジュールの要求として
下記要求がレベル別に定義されているのがわかる。

  • レベル０「規定なし」
  • レベル１「定時内（9時～17時）」
  • レベル２「夜間のみ停止（9時～21時）」
  • レベル３「1時間程度の停止有り（9時～翌朝8時）」
  • レベル４「若干の停止有り（9時～翌朝8時55分）」
  • レベル５「24時間無停止」

これが、IPAが運用スケジュールに対する要求内容一覧として例示しているものとなり
基本的にはこの中の要求内容からプロジェクトでの要求を選定することになる。
どの要求を選定するかは、項番２で決めたモデルシステムが役に立つ。

06_活用シート.xlsに乗っているレベル別要求内容のさらに右に、
下記のようにモデルシステム別の推奨要求レベル、つまり選定すべき要求レベルが乗っている。

この画像を見ると、各モデルシステム別の推奨運用スケジュールは下記だとわかる。

  • 社会的影響が殆ど無いシステム：レベル２「夜間のみ停止（9時～21時）」
  • 社会的影響が限定されるシステム：レベル４「若干の停止有り（9時～翌朝8時55分）」
  • 社会的影響が極めて大きいシステム：レベル５「24時間無停止」

このように、各要求内容ごとにモデルシステム別の推奨要求レベルが乗っているので
そこから対象要求のレベルを選定していく。

ただし、プロジェクトの内容によってはモデルシステム別推奨レベルでは過不足がある
といったことは当然発生するため、そこは臨機応変にレベルを変更する必要はある。

5. 顧客に提出。フィードックをもとに内容を修正。

項番１～４の内容を資料にまとめ顧客と認識の共有。
各項目に対するフィードバックをもらいその内容をもとに非機能要件定義資料を修正。

以上が、非機能要件を決める大きな流れとなる。
以降の記載は個人的に非機能要件を策定する上で気になった内容のメモ。

個人的なメモ

要求レベルを決める上でのポイント

ログの考え方

各項目のレベル選定材料

バックアップデータの保存

電子帳簿保存法の存在

電子帳簿保存法（以下、電帳法）とは、各税法で保存が義務付けられている帳簿・書類を電子データで保存するためのルール等を定めた法律です。法律自体は1998年から施行され、何度か改正されています。
https://mirasapo-plus.go.jp/hint/17457/

Q>電子帳簿保存法で要件となっているのか？
A>要件にはなっていないが、バックアップの取得は推奨している。
https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/07denshi/02.htm#a015

セキュリティ遵守

ISO27000系

情報セキュリティマネジメントシステムに関する規格群のことで、中核を成すISO27001を始めとしたISMSに関する第三者認証 規格のことです。
ISO27000シリーズは、情報セキュリティの管理・リスク低減に関するフレームワークとして国際的に活用されています。
https://activation-service.jp/iso/column/2216

Discussion