IPAの非機能要求グレードを活用した非機能要件の定義の流れとポイント

要求分析

シェア
ツイート
ブックマーク

ユーザー目線でもわかりやすい機能要件に対して、非機能要件はユーザー目線では見えにくいものです。
しかし、非機能要件をないがしろにしてしまうと、開発中の大幅な手戻り、リリース後のトラブルなどが発生しかねません。本記事ではIPAの非機能要求グレードを活用しながら、非機能要件を定義する流れとポイントを解説します。

非機能要件の難しさと重要性

非機能要件は簡単にいうと「システムを安心して快適に使うためのもの」です。性能・拡張性や運用・保守性などの項目があり、システムを通常利用する場面では見えにくく、わかりにくいものです。

機能要件と比べてないがしろにされがちな非機能要件ですが、システムを支える重要な土台です。非機能要件に不備があるとそもそもシステムが利用できない、といったことが発生しかねません。
システム開発者でなければあまり馴染みがないこの非機能要件を、関係者をうまく巻き込みながら進められる人こそ、優秀なエンジニアと言えるでしょう。

非機能要件に抜け漏れがあるとどうなる？

Business and technology, digital software development concept. Double exposure, man programmer, software developer working on laptop computer and smart city with binary, html computer code, big data on screen on screen

非機能要件に不備があると具体的にどのようなことが起こるでしょうか。
非機能要件は大きく6つに分類されており、それぞれについて具体例を挙げていきます。

可用性

頻繁に停止したり、長時間停止したりして使いたいときに使えなくなってしまう

性能・拡張性

レスポンスが遅かったり、返ってこなかったりする。リソースの増強も困難となってしまう

運用・保守性

システム運用に多くの時間がかかってしまう

移行性

移行に失敗し、切り戻しにも多くの時間がかかってしまう

セキュリティ

システムがウイルスなどに感染して顧客情報が漏洩してしまう

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

法令違反となり課徴金の支払いとシステム改修が必要となってしまう

いずれも要件定義をきちんと行い、コストをかければ避けられるものです。ただし、過剰な要件としてしまうとコストが多くかかるうえに、弊害が起こることもあります。例えば、セキュリティのレベルだけを過剰に高めてしまうと、コストだけでなく使いやすさ、ユーザビリティの低下につながる場合があるので注意が必要です。

非機能要件を定義する流れとポイント

Developer programming and coding technology. Website design Safety of the social world Cyberspace concept.

非機能要件の定義は難しいうえに、経験がないと抜け漏れが多く出てしまいます。

情報処理推進機構（IPA）が作成した非機能要求グレードを活用すれば漏れなく（網羅的な項目一覧）、誤解なく（具体的な数値設定）、早期に（モデルシステムで大枠の確定）非機能要件を確認することができます。

非機能要件はインフラ機器の選定に影響するため、早期に確定できることは大きなメリットです。

非機能要求グレードは、非機能要件の定義に長年悩んできた国内SI事業社のエンジニアが集まって作成されたものなので、活用しない手はありません。著作権に伴う使用条件を守れば誰でもダウンロードして利用できます。

出典：システム構築の上流工程強化（非機能要求グレード）｜独立行政法人情報処理推進機構
https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html

非機能要求グレードの適用の流れは大きく、「1.モデルシステムの選定」、「2.重要項目のレベル決定」、「3.重要項目以外のレベル決定」の３段階からなります。あいまいになりがちな非機能要件を、順を追って詳細化していくことができます。

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

まずは、各詳細項目のレベル決定の基となるモデルシステムを選定します。ここで決めたモデルシステムを参考に、各項目の仮のレベルが決められ調整していきます。

モデルシステムには3つのレベルがあり、企業内の特定部門での利用などの「社会的影響がほとんど無いシステム」、企業活動の基盤となるシステムなどの「社会的影響が限定されるシステム」、社会基盤となるようなシステムの「社会的影響が極めて大きいシステム」に分けられます。稼働率や、性能目標、運用時間などの目安も記載されているので、最も近いものを選びましょう。

例えば「社会的影響が限定されるシステム」の場合、稼働率は99.99%（年間停止許容時間1時間未満）、被災時は1週間以内で復旧、というレベルが設定されています。

2. 重要項目のレベル決定

つづいて、約100個の重要項目のレベルを決定します。1.で決定したモデルシステムによって参考レベルが設定されているので、相違がある場合は変更を検討します。モデルシステム通りだと稼動率が99.99%と設定されているところに対して、そこまでのレベルが必要なければ変更したりします。どの項目もレベルが上がるほどコストがかかってしまいますので、ユーザーの予算感も把握したうえでレベル調整を行います。