非機能要件の書き方｜性能や安全の決め方と漏れやすい項目

システムの要件定義で、画面や機能の一覧はすぐに書けたのに、「非機能要件はどう書けばいいのか」で手が止まる人は少なくありません。非機能要件とは、システムが何をするかではなく、どのくらいの速さで、どのくらい止まらずに、どのくらい安全に動くかを決める要件のことです。

この記事では、非機能要件と機能要件の違いを整理したうえで、情報処理推進機構（IPA）がまとめた非機能要求グレードの6つの大項目に沿って、決めることと書き方を順に説明します。数字で書くこつ、例文、漏れやすい項目の一覧、発注する側と開発する側で合意する進め方までを紹介します。要件定義の作業の担当と期限を共有する道具として、プロジェクト管理ツールのPinatecaにも触れます。

非機能要件とは

システムの要件は、大きく機能要件と非機能要件に分かれます。システム開発の会社の解説でも、次のように説明されています。

システム開発の要件定義は、主に「機能要件」と「非機能要件」に分かれます。要件定義未経験の人、携わった経験が乏しい人は「機能要件は分かるけど、非機能要件って具体的になに？」と疑問に思う人もいるのではないでしょうか。 出典: products.sint.co.jp

機能要件は、システムが「何をするか」を決める要件です。「商品を検索できる」「注文の確認メールを送る」「月末に売上の帳票を出す」といったものです。非機能要件は、その機能が「どのように動くか」を決める要件です。

比べる点	機能要件	非機能要件
決めること	システムが何をするか	どのくらいの速さ、安定さ、安全さで動くか
例	商品を検索できる	検索の結果が3秒以内に表示される
気づきやすさ	利用者が要望として出しやすい	利用者からは出にくく、漏れやすい
決めないと起きること	必要な機能がない	遅い、止まる、漏れる、直せない

利用者は「検索できるようにしてほしい」とは言いますが、「何秒以内に」「何人が同時に使っても」とはなかなか言いません。言われなかったからといって決めないままにすると、完成したあとで「遅すぎて使えない」「月末だけ止まる」といった問題が起き、作り直しにつながります。非機能要件を書く作業は、利用者が言葉にしていない期待を、測れる形にして合意する作業だと言えます。

非機能要件が漏れやすい理由

非機能要件が漏れやすいのには、いくつかの理由があります。

1つ目は、当たり前だと思われていることです。「普通に速く動く」「普通に止まらない」と、発注する側は考えています。しかし「普通」の中身は人によって違い、開発する側は、決められていない部分を自分たちの経験で補って作ります。

2つ目は、費用と直結していることです。止まらないシステムにするには、機器を二重にしたり、障害が起きたときに自動で切り替える仕組みを作ったりする必要があり、費用が大きく変わります。決めにくいので、後回しにされがちです。

3つ目は、関わる人が多いことです。性能は業務の担当、安全は情報システムの部門、運用は運用の担当というように、項目ごとに詳しい人が違います。1人で全部を書こうとすると、どうしても抜けが出ます。

4つ目は、見えにくいことです。画面の機能は試作品を見れば確かめられますが、非機能の性質は、大勢が使い始めたときや障害が起きたときに初めて表に出ます。

こうした理由から、非機能要件は「一覧を使って漏れなく確かめる」「数字で書いて合意する」という2つの工夫が欠かせません。

非機能要件の決め漏れは、あとから直すほど費用がかかります。設計の段階で「同時に200人が使う」と分かっていれば機器の構成で対応できますが、公開したあとに分かると、作り直しや機器の入れ替えが必要になることもあります。要件定義の段階で時間をかけて決めておくことが、結果として全体の費用と期間を抑えることにつながります。

IPAの非機能要求グレードとは

非機能要件を漏れなく確かめるための代表的な道具が、IPAがまとめた非機能要求グレードです。IPAの紹介ページでは、次のように説明されています。

「非機能要求グレード」は、「非機能要求」についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的とし、非機能要求項目を網羅的にリストアップして分類するとともに、それぞれの要求レベルを段階的に示したものです。 出典: ipa.go.jp

この取り組みは2009年度から2018年度に行われたもので、最新の版は「非機能要求グレード2018」です。紹介ページから、本体、利用ガイド、項目を階層で示した樹系図などを手に入れられます。

IPAの資料によると、非機能要求グレードは、非機能要求を6つの大項目、35の中項目、118の小項目、238のメトリクス（項目を数字で表すための指標）に整理しています。それぞれのメトリクスには、レベル0からレベル5までの6段階が設定されていて、レベルが大きいほど実現が難しく、一般に開発の費用も増えるとされています。

さらに、システムが止まったときの社会への影響の度合いで、次の3つのモデルが用意されています。

モデル	想定するシステム
社会的影響がほとんど無いシステム	企業の特定の部門が比較的限られた範囲で使うシステム
社会的影響が限定されるシステム	企業活動の基盤となるシステムで、止まると取引先や顧客にも影響するもの
社会的影響が極めて大きいシステム	国民の生活や社会経済の基盤となるシステム

自分たちのシステムに近いモデルを1つ選ぶと、費用や品質への影響が大きい重要な項目について、目安のレベルが示されます。その目安を出発点にして、自分たちの事情に合わせてレベルを上げ下げしていく、という使い方をします。ゼロから考えるより、はるかに早く、漏れも少なく決められます。

6つの大項目ごとに決めること

非機能要求グレードの6つの大項目は、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーです。それぞれで決めることを、例を交えて説明します。

可用性

可用性とは、システムを止めずに使い続けられる度合いのことです。決めることの例は次のとおりです。

• 使う時間帯。平日の9時から18時だけか、24時間か
• 計画的に止めてよい時間。保守のために止める日時と長さ
• 障害が起きたとき、どのくらいの時間で復旧するか
• 大きな災害のとき、どのくらいの期間で業務を再開するか
• 止まらないようにするための仕組み（機器を二重にするなど）をどこまで用意するか

性能・拡張性

性能とは、システムの速さと、さばける量のことです。拡張性とは、利用者やデータが増えたときに対応できる度合いのことです。

• 1日あたり、1時間あたりの処理の件数
• 同時に使う人数
• 画面を開いてから表示されるまでの時間
• 夜間にまとめて行う処理を、何時までに終えるか
• 今後数年で、利用者やデータがどのくらい増える見込みか

運用・保守性

運用・保守性とは、システムを動かし続け、直していくための決まりと仕組みのことです。

• 運用する時間帯と、問い合わせを受ける時間
• データのバックアップをどの頻度で取り、どのくらいの期間残すか
• システムの状態を見張る仕組み（監視）と、異常を知らせる相手
• 障害が起きたときの連絡と対応の手順
• 開発した会社の保守の支援の範囲と時間

移行性

移行性とは、古いシステムや紙の業務から、新しいシステムへ切り替えるための決まりのことです。

• いつ、どの順番で切り替えるか
• 古いシステムから移すデータの種類と量
• 移すときに業務を止めてよい期間
• 移行のリハーサル（本番の前の練習）を何回行うか

セキュリティ

セキュリティとは、不正な利用や情報の漏れを防ぐための決まりと仕組みのことです。

• だれがどの情報を見られ、変えられるか（利用の制限）
• ログインの方法。パスワードだけか、確認コードなどを組み合わせるか
• 通信と保存するデータを暗号化するか
• 操作の記録を残す範囲と期間
• 弱点を調べる検査（セキュリティ診断）を行うか
• 不正なアクセスや情報の漏れが起きたときの対応の手順

個人情報を扱うシステムでは、個人情報保護法で求められる安全管理の措置も考える必要があります。個人情報保護委員会の個人情報保護法等のページで、法律やガイドラインを確かめられます。扱う情報の種類によって求められることが変わるため、具体的な対応は社内の担当や専門家と確かめてください。

システム環境・エコロジー

システム環境・エコロジーとは、機器の設置場所の条件や、環境への負荷に関する決まりのことです。

• 機器の設置場所の条件（地震への備え、温度、広さなど）
• 守る必要がある規格や法律
• 消費するエネルギーやCO2の排出の考え方

クラウドのサービスを使う場合は、機器の設置場所の条件はサービスを提供する会社に任せることになります。その場合でも、データを国内に保存する必要があるかどうかなど、自社で決めておくことは残ります。

非機能要件を書く手順

非機能要件は、次の手順で書くと進めやすくなります。

1. システムの使われ方を整理する。だれが、いつ、どのくらいの人数で、どの業務に使うかを書き出す
2. 近いモデルを選ぶ。非機能要求グレードの3つのモデルから、自分たちのシステムに近いものを選ぶ
3. 重要な項目から目安のレベルを確かめる。選んだモデルの目安のレベルを出発点にする
4. 自分たちの事情に合わせてレベルを調整する。業務が止まったときの影響、予算、使う時間帯を考えて上げ下げする
5. レベルを具体的な数字にする。「レベル3」のままにせず、「障害時は〇時間以内に復旧」のような文にする
6. 発注する側と開発する側で合意する。数字の根拠と費用への影響を話し合い、合意した内容を文書に残す

IPAの資料でも、レベルで示す値は合意をつくる出発点であり、最終的には具体的な数字として合意することを想定している、と説明されています。レベルの番号だけを並べた要件は、読む人によって受け取り方が変わるので、必ず数字と条件の文にしておきます。

数字で書くこつ

非機能要件は、あとで「満たしているかどうか」を確かめられる形で書くことが大切です。そのためには、数字と条件をそろえて書きます。

あいまいな書き方	確かめられる書き方
画面の表示が速いこと	通常の時間帯に、検索の結果の画面が3秒以内に表示されること（同時に使う人が100人の場合）
なるべく止まらないこと	平日の9時から18時の間の稼働率を99.5%以上とすること
すぐに復旧できること	障害が起きてから4時間以内に業務を再開できること
データを失わないこと	障害が起きた時点から、最大で1日前の状態までデータを戻せること
安全であること	管理の画面へのログインには、パスワードと確認コードの両方を求めること

確かめられる書き方には、次の3つがそろっています。

• 対象。何についての要件か（検索の結果の画面、管理の画面など）
• 数字。時間、件数、割合などの基準
• 条件。どんな状況で満たせばよいか（通常の時間帯に、同時に使う人が100人の場合に、など）

条件を書かないと、「月末の一番混む時間に遅かった」「いや、通常の時間帯なら3秒以内だ」という食い違いが起きます。特に性能の要件は、どの時間帯、どの人数、どのデータの量を前提にするのかまで書いておきます。

稼働率と復旧の目標の考え方

可用性の要件でよく使われるのが、稼働率と、復旧の目標です。

稼働率

稼働率とは、システムを使う予定の時間のうち、実際に使えた時間の割合のことです。割合だけだと実感がわきにくいので、止まってよい時間に直して考えると分かりやすくなります。たとえば1年中24時間動かすシステムで稼働率を99.9%とすると、1年は8,760時間なので、止まってよい時間は1年でおよそ8.76時間になります。99.99%なら、およそ53分です。

稼働率を1けた上げるごとに、止まってよい時間は10分の1になり、そのための仕組みの費用は大きく上がります。本当にその水準が必要なのかを、業務が止まったときの影響と比べて決めます。

復旧の目標

障害が起きたときの目標は、2つに分けて考えます。

• どのくらいの時間で業務を再開するか（目標の復旧の時間）
• どの時点の状態までデータを戻せればよいか（目標の復旧の時点）

たとえば「4時間以内に再開し、前の日の夜の時点までのデータを戻せればよい」と決めれば、バックアップは1日1回で足ります。「1時間以内に再開し、データは1件も失えない」とするなら、データを常に別の場所に写しておく仕組みが必要になり、費用が上がります。

この2つの目標は、業務の担当が「どのくらいの時間止まると、どのくらい困るか」を考えて決めます。情報システムの部門や開発の会社だけで決めると、業務の実態とずれた数字になりがちです。

非機能要件の書き方の例文

要件定義書に書く非機能要件の例文を、大項目ごとに示します。数字は例です。

可用性の例

• 本システムの利用時間は、平日の8時から20時とする
• 計画的な停止は、毎月第3土曜日の22時から翌6時までの間に行う
• 利用時間内の稼働率は99.5%以上とする
• 障害が起きた場合、4時間以内に業務を再開できること

性能・拡張性の例

• 同時に利用する人数は最大200人を想定する
• 通常の画面の表示は、同時に利用する人数が200人の場合に3秒以内とする
• 夜間のまとめての処理は、毎日22時に始め、翌朝6時までに終えること
• 今後5年間で利用者が2倍になっても、機器の追加で対応できる構成とすること

運用・保守性の例

• データのバックアップは毎日1回取得し、30日分を保存する
• システムの状態を常に監視し、異常を検知した場合は運用の担当へ自動で通知する
• 保守の問い合わせは、平日の9時から18時に受け付ける

セキュリティの例

• 利用者の権限は、一般、管理者、閲覧のみの3種類とする
• 管理者のログインには、パスワードに加えて確認コードによる認証を求める
• 通信はすべて暗号化する
• 操作の記録は1年間保存する
• 公開の前に、第三者によるセキュリティ診断を行う

例文の数字は、自分たちの業務に合わせて決め直してください。大切なのは、すべての文が「満たしているかどうかを確かめられる形」になっていることです。

要件定義書の中での書き方の形

非機能要件を要件定義書のどこに、どんな形で書くかも決めておくと、読む人が探しやすくなります。よく使われるのは、機能要件の章のあとに非機能要件の章を設け、大項目ごとに節を分ける形です。

節	書く内容
前提	利用者の人数、利用の時間帯、データの量の見込み、モデルの選択
可用性	利用時間、計画的な停止、稼働率、復旧の目標
性能・拡張性	処理の件数、同時に使う人数、表示の時間、将来の増え方
運用・保守性	運用の時間、バックアップ、監視、保守の範囲
移行性	切り替えの時期と方法、移すデータ、リハーサル
セキュリティ	権限、認証、暗号化、操作の記録、検査
システム環境	設置の条件、守る規格や法律
確かめ方	各要件のテストの方法と合格の基準

各要件には番号を付けておくと便利です。「可用性の3番」「性能の5番」のように番号で呼べると、話し合いやテストの記録で、どの要件の話をしているのかが食い違いません。

要件ごとに、その数字を決めた理由も1行で添えておきます。「同時に使う人数を200人とする。理由は、全社員300人のうち、月末に同時に使うのは最大で約3分の2と見込んだため」のように書いておけば、あとで前提が変わったときに、どの数字を見直せばよいかがすぐに分かります。

書き終えたあとの見直しの観点

非機能要件を書き終えたら、関係者で読み合わせて見直します。見直すときは、次の観点で1つずつ確かめます。

1. 測れるか。すべての要件に、対象と数字と条件がそろっているか
2. 食い違いがないか。たとえば稼働率と計画的な停止の時間、バックアップの頻度と復旧の目標が、互いに矛盾していないか
3. 業務に合っているか。業務の担当が読んで、実際の使われ方と合っていると言えるか
4. 実現できるか。開発する側が読んで、予算と期間の中で実現できると言えるか
5. 確かめられるか。テストの方法と合格の基準が決まっているか
6. 漏れがないか。前の節の一覧や、非機能要求グレードの項目と照らし合わせて、決め忘れがないか

特に2の食い違いは、別々の人が別々の節を書いたときに起きやすい問題です。「障害時は1時間以内に復旧」と書いた一方で、バックアップは週に1回、と書いてあれば、データを戻すのに時間がかかり、1時間では復旧できないかもしれません。節をまたいで読み、つじつまが合っているかを確かめます。

漏れやすい項目の一覧

非機能要件の中でも、特に決め忘れやすい項目を一覧にしました。要件定義書を書き終えたら、この一覧で確かめてください。

項目	確かめること
混む時期の性能	月末、年度末、セールの時期など、利用が集中する時期の人数と処理の量を決めたか
データの増え方	数年後のデータの量を見込み、性能と保存の容量を決めたか
計画的な停止	保守のために止める日時と、利用者への知らせ方を決めたか
バックアップの保存期間	何日分、何か月分残すかを決めたか
操作の記録	何を、どのくらいの期間残すかを決めたか
退職者の扱い	利用者が辞めたときに、アカウントを止める手順を決めたか
利用する端末とブラウザ	対応するパソコン、スマートフォン、ブラウザの種類を決めたか
外部のサービスとの連携	連携先が止まったときの動きを決めたか
移行のリハーサル	本番の切り替えの前に何回練習するかを決めたか
保守の範囲	公開後の不具合の修正、問い合わせの対応の範囲と期間を決めたか
法律や規程	守る必要がある法律、業界の規格、社内の規程を洗い出したか

一覧のうち、自分たちのシステムに関係しない項目は「対象外」と書いて残しておきます。空欄のままだと、決めなくてよいのか、決め忘れたのかが分からないからです。

特に見落とされやすいのが、利用する端末とブラウザです。「スマートフォンでも使えると思っていた」「古いブラウザでは画面が崩れる」という食い違いは、公開の直前になって表に出ることが多い問題です。

発注する側と開発する側で合意する進め方

非機能要件は、発注する側と開発する側の話し合いで決めるものです。どちらか一方だけで決めると、実現できない数字になったり、業務に合わない数字になったりします。

進め方の例は次のとおりです。

1. 発注する側が、業務の使われ方と、止まったときの影響を説明する
2. 開発する側が、非機能要求グレードなどの一覧を使って、決めるべき項目を示す
3. 両者で、重要な項目から目安のレベルを確かめる
4. 開発する側が、レベルごとの費用と期間への影響を示す
5. 発注する側が、費用とつり合う水準を選ぶ
6. 決まった内容を、数字と条件の文にして要件定義書に書き、両者で確認する

話し合いでは、「高い水準ほどよい」と考えないことが大切です。どの項目も最高の水準にすれば費用がふくらみ、予算に収まらなくなります。業務にとって本当に大事な項目に費用を集め、それ以外は標準的な水準にする、というめりはりを付けます。

開発を外部に任せる場合は、合意した非機能要件を契約の資料に含めておくと、あとで「どこまでが約束だったのか」で揉めることを防げます。

クラウドやSaaSを使う場合の書き方

自社でシステムを作らず、クラウドのサービスや、インターネット経由で使うソフト（SaaS）を使う場合も、非機能要件の考え方は役に立ちます。ただし、書き方が少し変わります。

クラウドやSaaSでは、可用性や性能の多くはサービスを提供する会社が決めています。そのため、自分たちで数字を決めるのではなく、提供する会社が示している水準が、自分たちの要件を満たしているかを確かめる形になります。

確かめることの例は次のとおりです。

• サービスの水準の約束（SLA）。稼働率の目標や、下回ったときの扱いが示されているか
• 計画的な停止の時間と、知らせ方
• データの保存場所とバックアップの方法
• 障害が起きたときの知らせ方
• 操作の記録を取り出せるか
• データを書き出せるか（やめるときに移せるか）

こうした情報は、提供する会社の公式の資料や利用規約に書かれていることが多いので、契約の前に必ず読んでおきます。書かれていない項目は、問い合わせて文書で回答をもらっておくと安心です。

提供する会社の水準が自分たちの要件に届かない場合は、別のサービスを探すか、要件そのものを見直すか、足りない部分を自分たちの運用で補う方法を考えます。

テストで満たしているかを確かめる

非機能要件は、書いただけでは意味がありません。完成したシステムが満たしているかを、テストで確かめます。

• 性能のテスト。想定した人数で同時に使った状態を作り、画面の表示の時間や処理の時間を測る
• 負荷のテスト。想定より多い人数や処理の量をかけ、どこで遅くなるか、止まるかを確かめる
• 障害のテスト。機器やサービスを意図的に止め、切り替えや復旧の手順が動くかを確かめる
• バックアップから戻すテスト。実際にバックアップからデータを戻し、決めた時間内に戻せるかを確かめる
• セキュリティの検査。権限の設定どおりに見られる範囲が分かれているか、弱点がないかを確かめる

テストの方法と合格の基準は、要件を書く段階で一緒に決めておくと、あとで「どう測るのか」で揉めずに済みます。たとえば「画面の表示は3秒以内」と書いたなら、「どの画面を、何人で、何回測り、何割が3秒以内なら合格とするか」まで決めておきます。

よくある失敗と防ぎ方

非機能要件でよく見られる失敗を挙げます。

「既存と同等」とだけ書く

古いシステムの置き換えで、「性能は既存のシステムと同等とする」とだけ書く失敗です。既存のシステムの性能を測った数字がなければ、同等かどうかを確かめられません。置き換えの前に、今のシステムの性能を測っておき、その数字を要件に書きます。

すべてを最高の水準にする

止まらない、速い、安全、を全部最高にすると、費用が予算を大きく超えます。業務にとっての重要度で優先順位を付けます。

運用の担当が話し合いにいない

開発の担当と業務の担当だけで決め、公開後に運用する人が加わっていないと、監視やバックアップ、障害の対応の手順が現実と合わなくなります。運用の担当を最初から話し合いに入れます。

専門用語のまま書く

開発する側の言葉で要件を書くと、発注する側の業務の担当が読んでも意味が分からず、合意したつもりで中身を確かめていない、ということが起きます。「冗長化」「フェールオーバー」のような言葉を使うときは、「機器を二重にして、片方が壊れても動き続けるようにする」のように、業務の担当にも分かる言葉を添えます。読む人が分からない要件は、合意されていないのと同じです。

前提の数字の出所が分からない

同時に使う人数や処理の件数などの前提の数字が、だれがどう見積もったのか分からないまま書かれていると、あとで実際の利用がその数字を大きく超えたときに、責任の所在があいまいになります。前提の数字には、出所（業務の担当の見込み、今のシステムの実績など）と、見積もった日付を書き添えます。

決めたあとに見直さない

開発の途中で利用者の数の見込みが変わったのに、非機能要件を直さないまま進める失敗です。前提が変わったら、要件も見直します。

要件定義の作業をチームで共有する

非機能要件を決める作業は、確かめる項目が多く、業務、情報システム、運用、開発の会社など、関わる人も多い作業です。「性能の数字は業務の担当が確かめる」「セキュリティの項目は情報システムの部門が確かめる」というように分担すると早く進みますが、だれがどこまで確かめたのかが見えなくなりがちです。

数人の作業なら、表計算ソフトに「項目・担当・期限・状態・決まった内容」の列を作り、週に1回見直すだけでも十分に回ります。関わる人が増え、担当と期限と進み具合を全員で共有したくなったら、プロジェクト管理ツールを使う方法があります。

その選択肢の1つが、国産のプロジェクト管理ツールのPinateca（ピナテカ）です。公式サイトによると、カンバン、ガントチャート、カレンダー、リストなど8種類のボードとチャットが、無料プランから使えます。確かめる項目を1つずつカードにして担当と期限を付ければ、進み具合を全員が同じ画面で確かめられます。カードには見積もりの工数や優先度などの項目を自由に追加でき、カードごとのコメントで、決まった数字の根拠を残しておけると案内されています。料金は5人までとボード10個までが無料で、それを超えるとスタンダードプランが1人あたり月額500円（税抜）です。

Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

要件定義の力を生かせる仕事

非機能要件まで含めて要件を整理できる力は、システム開発の仕事で高く評価されます。在宅や業務委託でも、要件定義の支援や、開発の現場に加わる仕事があります。開発の仕事はアプリケーション開発のお仕事で、セキュリティに関わる仕事を含む分野はAI・マーケティング・セキュリティのお仕事で紹介しています。使いやすさの面から画面の設計に関わる人は、デザイナーの年収・単価相場で相場を確かめられます。

在宅ワークの仲介を2004年から続けてきた運営の立場から見ると、開発の仕事で長く頼りにされる人は、作る力に加えて、受ける前に「何人が使うのか」「止まったらどのくらい困るのか」を自分から確かめ、合意した内容を文書で残す人が多い傾向があります。中間の手数料がかからない直接のやり取りでは、こうした確かめの丁寧さがそのまま信頼になり、継続の依頼へとつながっていきます。

非機能要件は、利用者が言葉にしていない期待を、測れる形にして合意する作業です。IPAの非機能要求グレードの一覧で漏れを防ぎ、すべての要件を対象と数字と条件のそろった文にして、テストで確かめられる状態にしてください。

よくある質問

Q. 非機能要件と機能要件の違いは何ですか？

機能要件は、システムが「何をするか」を決める要件で、商品を検索できる、メールを送る、といったものです。非機能要件は、その機能が「どのように動くか」を決める要件で、何秒以内に表示されるか、どのくらい止まらずに動くか、どう守るかといったものです。非機能要件は利用者から出にくく、漏れやすいのが特徴です。

Q. 非機能要求グレードはどこで手に入りますか？

情報処理推進機構（IPA）の非機能要求グレードの紹介ページで、本体や利用ガイド、項目を階層で示した樹系図などを手に入れられます。取り組みは2009年度から2018年度に行われたもので、最新の版は「非機能要求グレード2018」です。使う前に、ページに書かれた使用の条件を確かめてください。

Q. 小さなシステムでも非機能要件は必要ですか？

小さなシステムでも、使う時間帯、表示の速さ、バックアップ、だれが見られるか、といった基本の項目は決めておくべきです。非機能要求グレードには、社会的影響がほとんど無いシステムのモデルもあり、目安のレベルを出発点にできます。決めないままにすると、完成後に作り直しが必要になることがあります。

Q. 稼働率は何％にすればよいですか？

業務が止まったときの影響と、費用のつり合いで決めます。1年中24時間動かすシステムで稼働率を99.9%にすると、止まってよい時間は1年でおよそ8.76時間、99.99%ならおよそ53分になります。1けた上げるごとに仕組みの費用は大きく上がるため、業務の担当と一緒に、本当に必要な水準を考えます。