高品質なシステム開発に欠かせない機能要件と非機能要件とは?
高品質
高品質なシステム開発に欠かせない機能要件と非機能要件とは?
アンドエンジニア編集部
2021.03.03
この記事でわかること
1.機能要件と非機能要件は要件定義の重要な項目
2.機能要件と非機能要件の違いや書き方について理解する
3.SEとしての真価が問われる要件定義の押さえどころ

要件定義について

image

機能要件の話に入る前に、機能要件と切っても切れない「要件定義」について確認しておきましょう。

要件定義とは

要件定義とは、システム開発においてユーザーやクライアントの要望をどのように実現するのかについて文章にまとめることです。要件定義フェーズは、ウォーターフォール開発において計画フェーズの次のフェーズです。要件定義を終えたら、基本設計・開発フェーズへと入ります。

要件定義はシステムの成否を左右する

要件定義では、いかにユーザーの要望を具体的に把握できるかが、システム開発の成否に大きく関わってきます。システム開発で失敗する最大の要因は、要件定義の甘さにあります。

逆に要件定義の精度が高いと、システムの完成度は高まり、出来上がったシステムに対するユーザー評価は好評価になります。システム開発において要件定義がいかに大切かということをご理解いただけると思います。

要件定義の成果物は要件定義書

要件定義フェーズの主な成果物は要件定義書です。要件定義では、ユーザー要求をヒアリングし、システムに必要な機能を洗い出していきます。またヒアリングを通じて、ユーザーの潜在的ニーズや、そのニーズの背景、理由なども探っていきます

その後要件定義に従ってシステム概要図や業務フローを作成して、ユーザーとの認識にズレがないかを確認します。

一通り要件が整理できたら、ユーザーの要求に対して、それらがシステムに実装可能か否かを判断します。このようにして搭載する機能を決めていきます。

要件定義書に記載すべき項目

要件定義書に記載する項目についてはユーザーとの合意に基づいて決めていきます。要件定義書のアウトプットについては、あらかじめ開発側から確認をとっておく必要がありますが、一般的には次のような項目が網羅されます。

「システムの目的」「システム概要」「新業務フロー」「機能要件」「非機能要件」「セキュリティ要件」「移行要件」「運用要件」などです。この中で、ユーザー要件を文言として記述する「機能要件」、「非機能要件」はシステム設計やシステム開発のバイブルとなる要件定義書の中枢であり、この出来栄えがシステムの成否を大きく左右します

機能要件と非機能要件

機能要件と非機能要件

機能要件、非機能要件が要件定義において非常に重要であることは分かっていただけかと思います。続いて、機能要件と非機能要件について深堀りしてまいりましょう。

機能要件とは

機能要件とは、ユーザーがシステムに対して求める機能のことです。システム化によって、具体的に何ができるのか、何が可能になるのかについて記述します。それはプロジェクトの目標になるもので、システム開発側にとってはプロジェクトのゴールが明確に分かってきます。

機能要件はユーザーのニーズを文書化したものですが、全てそのまま機能として実装できるわけではありません。予算、納期、組織などの制約もあります。実装の可否、優先順位なども明らかにし、ユーザーと相互に認識を合わせておく必要があります。

非機能要件とは

機能要件と同様に、非機能要件もユーザーが求める機能です。異なるのは、機能要件をユーザーの「表向きの要件」とすれば、非機能要件は「裏向きの要件」です。たとえば、「本社で全店の前日売上を翌日にPCの画面で確認できる」という機能要件があったとします。

非機能要件では、そのユーザー要求の裏にある潜在要求を引き出します。「翌日に確認できる」の翌日とは、午前6時以降なのか、午前9時なのか、より具体的な要求を明らかにします。これは性能要件にもつながりますが、システムを設計する上では重要なパラメーターです。

このように非機能要件ではシステム性能や効率、セキュリティ面、保守・運用面などについて記述していきます。これらは機能要件と同様にシステム構築におけるゴールと言えます。

非機能要件を引き出すのはSEの手腕です。システム設計に必要なパラメーターですから、パラメーターに不足があると、ユーザーが満足してくれるシステムの構築が困難になります。

よく、システムに問題があった時に、SEが「我々はユーザーの言われた通りに作った。」と責任転嫁する場合がありますが、それは非機能要件の洗い出しを怠ったSEに責任があります。

機能要件は手順に従ってしっかりヒアリングできれば、大きな漏れは起きませんが、非機能要件は洞察力、想像力、共感性などSEの資質に左右される要素があり、機能要件よりも難易度が高くなります。

プロジェクトの成否を左右する非機能要件の一覧について詳しく解説!

機能要件と非機能要件の書き方

image

ここまで、要件定義における機能要件、非機能要件の位置づけ、重要性について述べてまいりましたが、機能要件、非機能要件はどのように書けばよいのでしょうか?それぞれ、要件を記述する際に漏らしてはならない事項をあげながら、書き方について説明してまいりましょう。

機能要件に書く項目と書き方

機能要件はユーザーヒアリングを行いながら記述していきますが、次の手順や視点を外さないように気を付けてください。

1.     ユーザー要求の背景や目的は何か ユーザーの要求には必ず背景や目的があります。そこを理解しておかないと、認識のズレを生じる可能性があります。たとえば、「本社で全店の前日の売上が翌日に把握できるようにしたい」という要求があった場合、それは集計作業を軽減したいのか、売上を把握して具体的な販売促進につなげたいのかによって、実装する機能に違いが生じてきます。さらに、それは非機能要件にも影響を及ぼします。

2.     必要な機能は何か ユーザー要求の中には、単なる願望レベルのものから、切実な要求であるものまで、温度差があります。絶対に外してはならない機能は何か、実装が望まれる機能はなにか、システムに関わらない機能は何かを見極めることが重要です。

3.     機能要件の確定 必要な機能を洗い出しましたが、全てを網羅すると予算がオーバーするという問題に直面することがあります。そこで、生かす機能、削る機能を選別するのですが、削る場合はユーザーに代替案を示さなければなりません。当面の予算範囲で実現する機能、予算を確保してから取り組む機能、あるいはシステムに頼らず業務の見直しなどによって解決するものなど、ユーザーが納得できる方策を詰めていきます。

非機能要件に書く項目と書き方

非機能要件については、独立行政法人の情報処理推進機構(IPA)がとりまとめた「非機能要件グレード」を参考に以下まとめてみました。

以下の項目は非機能要件のマスト項目として必ず網羅してください。

1.可用性 システムの継続利用という視点から、障害や災害発生時における稼働目標を記述します。

2.性能・拡張性 システム性能や将来の拡張性などの視点から、例としてオンラインのレスポンスやデータ量増加への対応などを記述します。

3.運用・保守性 運用と保守サービスの視点から、システム稼働時間、データバックアップ、システム監視、システムの計画停止、サポート体制などについて記述します。

4.移行性 現行システムからの移行という視点から、移行スケジュール、移行方法、データ移行などについて記述します。

5.セキュリティ セキュリティ確保の視点から、認証機能(ログインなど)、ユーザー権限コントロール、データやファイルの暗号化などについて記述します。

6環境・エコロジー 設置環境や規格などの視点や、耐震や温度、湿度、騒音対策、さらには災害対策やBCP(事業継続プログラム)の視点で記述します。

参考:システム構築の上流工程強化(非機能要求グレード)

【保守・運用】仕事内容や将来性、必要なスキルについて徹底解説!

失敗しない要件定義

失敗しない

システム開発において、要件定義は要になる部分です。ここを失敗すると、どんなに頑張ってもユーザーに満足や評価をしてもらえるようなシステムは作れません。

逆に、要件定義、とりわけ機能要件・非機能要件の完成度が高ければ、システムの完成度が高まります。この要件定義を成功させるために押さえておくべきポイントがいくつかありますので、これから述べてまいります。

要件定義で押さえておきたい4つのこと

要件定義の内容についてはSEやプログラマーの皆さんはご承知と思いますが、特に押さえておきたいことについてこれから述べます。

1.ユーザーは必要な機能を分かっていないという前提に立つ そもそもユーザーとは誰にあたるのでしょうか?ITベンダーから見た場合は、相手企業のシステム部門ということになりますが、厳密に言えばシステム部門はユーザーではありません。実際にシステムを利用する部門の方々、現場の方々です。システム部門にヒアリングしても必要な機能の半分しか出てきません。必ず、実際にシステムを利用する方にヒアリングをし、機能要件・非機能要件について確認をとることです。

2.技術的裏付けが必要 機能要件・非機能要件が確定する前に、技術的裏付けを取っておくことが必要です。SEが全て掌握できていれば良いのですが、スーパーSEでもない限り、SEがすべてを判断するのは難しいでしょう。要件定義には技術SEやプログラマーの参画を求めた方が良いでしょう。

或いは持ち帰って、専門家を集めて実現手段について徹底的に議論することです。安請け合いは禁物です。

3.判断はYESかNO以外はない ユーザーへのリップサービスのつもりなのか、開発側が「とりあえずやってみましょう」と約束してしまうケースがあります。また、機能要件や非機能要件にあいまいな表現があっても、それを黙認してしまうケースもあります。こうしたあいまいさが後で大きな問題に繋がります。機能要件や非機能要件ではあいまい表現、努力目標などはあってはなりません。デジタル思考で、YESorNOをはっきりさせましょう。

4.理想論や精神論に走らない 何事も夢を持つことは必要ですが、ユーザー要件は聴けば聴くほど膨らみます。そのうち、単なる願望レベルのものが要求として上がります。

例えば、ユーザーから「ENTERキーを押したら瞬時に結果が出るようにしてほしい」と言った要件が出るとしましょう。しかし、こうした要求は与えられた予算、ハードウェア環境、ネットワーク環境などからシミュレーションして、きちんと実現可能な機能要件・非機能要件として定義しておかないと、最悪の場合、検収印を貰えないといった事態になる場合もあります。現実を直視し、実現性の観点からシビアに見据えていきましょう。

 

SEは要件定義で評価が決まる

評価

要件定義はSEの能力、スキルを判断するバロメーターです。要件定義の精度が高いと、システムの完成度は上がり、ユーザーから評価されます。また要件定義がきちんと出来ていると、プログラマーやエンジニアのモチベーションにも大きく影響し、後工程の基本設計、詳細設計、開発、テスト、本番移行が非常にスムーズに進みます。要件定義はSEの腕の見せ所です。

ユーザーやクライアントの立場に立って、ユーザーと開発側双方の信頼を得られるよう、能力を最大限発揮して素晴らしい要件定義を完成させてください。

Twitterをフォローしよう!
この記事をシェア
Twitter
Facebook
LINE
Hatena
アンドエンジニアの公式LINEができました! ピッタリの記事や役立つ情報が届きます!

編集部オススメコンテンツ

eyecatch_visual_coder
Adobe製品を使わない"デザイナー"?「ビジュアルコーダー」が考える、自己満足で終わらないWebデザインとは
三角
2020.06.16

アンドエンジニアへの取材依頼、情報提供などはこちらから

お問い合わせ・情報提供
この記事をシェア
Twitter
Facebook
LINE
Hatena
アンドエンジニアの公式LINEができました! ピッタリの記事や役立つ情報が届きます!

編集部おすすめコンテンツ

アンドエンジニアへの取材依頼、情報提供などはこちらから