今重要なのは非機能!?非機能を明確にするには!!#2

今重要なのは非機能!?非機能を明確にするには!!#2

今重要なのは非機能!?非機能を明確にするには!!#1」の続きです。業務プロセスから非機能要件を洗い出す場合、まずはあくまで「業務視点」「ユーザー視点」からまとめ、客観的、技術的数値に落とし込んでいく意識が重要です。

性能をどう数値化するか?

性能の数値化を行う際ユーザーの聞き取りだけを頼りに決定するのは危険です。ここは要件定義を行う開発者が「一般的に想定される性能」をきちんと把握した上で、数値化目標を決めていきます。間違っても先にユーザーに聞き取りをしてはいけません。ユーザーは、実際に操作するのが自分だったとしても、感覚的に物事を捉えているケースが多いものです。開発者が指針を出した上で、ユーザーとの合意に至る形が理想です。

例えば、コンシューマー向け Webシステムにおいて、何らかのボタンをリックして数秒間、何も動かないようでは話になりません。これは今日では一般常識です。

プロトタイプからの非機能要件抽出

後述するユーザビリティ要件を明確化するために、「UI· 機能要件の明確化」で作成したプロトタイプと画面遷移図を使用します。ここでの注意点は、設計レベルの議論に深入りしないことです。 あくまで非機能要件としてまとめるのだ、という意識を持つことです。

移行要件を甘く見ない移行要件は上記の「URPS +」の分類では、その他扱いになります。

非機能要件を整理する際に、移行要求をどのように要件化していくかも、きちんと検討します。 AsIs(現状のシステム像)から ToBe(理想のシステム像)を作り上げる過程でも検討していきます。ユーザーの要求としては当たり前であるにもかかわらず、埋もれてしまい、後々問題になることがあります。移行要件をきちんと明確化する必要があります。具体的にはまずデータ移行を考えます。

仕様継承の際の非機能要件とは?

現行仕様を継承する際の非機能要件の扱いは要注意です。エンタープライズ系システムにおいて、アークテクチャに何らかの変更が生じる場合でも、特にレスボンス (性能)が現行より劣化するようでは、ユーザーはなかなか受け入れてくれないでしょう。

コンシューマー向けシステムにおいては、より使いやすくならない限り、一般ユーザーは離れていくだけです。後述するアーキテクチャの選定を含め、熟考する必要があります。

「非機能要件の明確化」の手順

「非機能要件の明確化」の具体的な手態は以下のとおりです。

Step1「社会責任」になりうる非機能要件の明確化

社会的責任を最優先事項として、実現性を考慮しつつ、要件化していきます。

Step2業務プロセスの定義から非機能要件の明確化

業務プロー図に表現された「業務の流れ」、および個々の業務プロセスの定義から、各プロセス単位の非機能要件を抽出します。

Step3その他非機能要件の明確化

移行要件等、プロセスから抽出できない非機能要件を明確化します。移行要件は、ToBeとAsisの差異から洗い出します。基本はデータ移行の要件を中心に考えていきます。その際、漏れをチェックするため、類似のプロジェクトがあれば参考にします。

特に、古いデータを本当に移行する必要があるのか、熟考が求められます。具体的には、「5年間取引のない顧客及び取引データを移行対象とするか」等を検討し、決定していきます。

Step 4 トレードオフ関係にある非機能要件の整理

明確化された非機能要件のうち、トレードオフの関係があるものを抽出し、ある程度の両立が可能か、そうでない場合はどちらを優先するかを決定します。

Step 5 非機能要件定義書の作成

以上の非機能要件をプロセス単位と機能単位に一覧にし、最終的には目安で構わないので、システムで実現すべき目標を数値化して定めていきます。例えば、「応答時間○秒以内」とか、「同時登録可能な件数最大○件」などといった具合です。

この数値化は「ユーザー視点」「開発者(技術者)視点」で行います。それを一覧表にして非機能要件定義書としてまとめます。その際には、現時点で想定しうる実装方式の概要、方針までを記述しておきましょう。

テックカテゴリの最新記事