🍁 👈🏻 😻 機能しないソフトウェア要件。パート1 👩🏽‍🤝‍👩🏼 👨‍👧 🧓🏿

はじめに

新しい情報システムを開発するとき、または既存の情報システムを導入するとき、システムの非機能要件を決定する必要に迫られます。

この記事では、次のことについて説明します。

非機能要件は何ですか
非機能要件を決定する方法、
機能以外の要件の場合、数値はどこから来ますか。

非機能要件：それらは何ですか

まず、ソフトウェア製品または情報システムの要件を2つの大きなグループに分けることができます。これらは機能要件（製品またはシステムに実装する必要があるもの、ユーザーとの対話時に実行するアクションを含む）および非機能要件（システムまたはソフトウェア製品の動作方法、およびそのプロパティまたは特性を記述する）です。所有）。

原則として、非機能要件について話すとき、彼らはほとんどの場合、他のタイプの非機能要件に注意を払わずに、 品質属性 （すなわち、パフォーマンス、信頼性、スケーラビリティなどの開発中のソフトウェアまたはシステムの品質特性を決定する要件）について話します：

制約 -個々の要件またはそのセットを実装するための可能なソリューションの選択を制限する条件。製品またはシステムの外観と構造（アーキテクチャーを含む）を開発する際に、ツール、ツール、および戦略の選択を大幅に制限します。

制限の例：「開発はベンダーXのプラットフォームで実行する必要があります」、「ユーザーを認証するときは、生体認証方法を使用する必要があります。」

ビジネスルール - ビジネスの特定の側面を定義または制限するポリシー、ガイドライン、または規制。特定のビジネスプロセスの実装の構成とルールを決定するルール。ビジネスルールには、企業ポリシー、政府規制、業界標準、および製品またはシステムの開発時に使用されるか、開発に直接影響する計算アルゴリズムが含まれます。

ビジネスルールの例：「注文が発送されると、マネージャーは会計士に船荷証券と請求書を要求しなければなりません」、「請求書の支払いが15日以内に受領されなかった場合、注文はキャンセルされたとみなされます。」

外部インターフェース -他のシステムおよびオペレーティング環境との相互作用の側面の説明。これらには、製品またはシステムのAPIの要件、および統合が実行される他のシステムのAPIの要件が含まれます。

外部インターフェイスの例：「次のイベントがオペレーティングシステムログに記録されていることを確認します。XXサービスの開始と停止に関するメッセージ」。「プログラムモジュールのパラメーターがログに記録されていることを確認します。スキャナー、カーネル、ウイルス対策データベース（プログラムの起動時およびモジュールの更新時に情報を記録する必要があります）」

実装提案-特定の技術的および建築的ソリューションを使用する可能性を評価する提案。

開発中のソフトウェアのテスト提案は、特定の要件のテスト方法を示す要件の補足です。

法的要件 -ライセンス、特許の純度などの要件

これらの要件はすべて、システムまたは製品の実装を開始する前に定義および文書化する必要があります。

非機能要件：それらを定義する方法

さまざまなタイプの非機能要件に精通したので、次に何をする必要があるかを理解できてうれしいです。

最初に、非機能要件の主なタイプをリストする必要があるテンプレートを作成する必要があります。このテンプレートは、主に、指定されたタイプの要件を忘れないために必要です。このテンプレートをコンパイルするには、次のソースを使用できます。

Karl Wigersの本「ソフトウェア要件の開発」 -この本の「付録D」セクションの要件ドキュメントの例です。
GOST 34シリーズの資料

非機能要件：定義作業

機能要件の決定と非機能要件の決定の両方のために、ワーキンググループが使用され、そのメンバーが要件を決定、検証、承認します。分析者やユーザーだけでなく、製品やシステムの設計者や主要な開発者、テストグループを含む非機能要件を決定することは、グループにとって特に重要です。アーキテクトは、非機能要件をアプリケーションアーキテクチャの選択と設計への入力として認識し、テストチームは、非機能要件（主に品質属性）の充足を検証するために使用される負荷テストシナリオを計画します。

非機能要件を決定するためにワーキンググループのメンバーが果たす役割を以下に説明します。

ユーザー -非機能要件を決定するために使用されるパラメーター値の推定値を提供します。パラメータは通常、スクリプトに関連付けられています。特定のアクションを特定の制限付きで特定の時間実行する必要があるユーザースクリプトです。
システムアナリスト -非機能要件を収集、分析、文書化し、体系化します。
システム設計者、主要開発者 -非機能要件の定義と分析に参加し、実行可能性を確認します。
テストグループ -非機能要件の定義と分析に参加し、テスト機能を使用して非機能要件を検証します。

サイトのユーザーに電子メールで通知を送信するシステムモジュールのパフォーマンス要件を決定するために使用されるスクリプトの例：

1.システムは、通知の配信を開始するイベントに関する通知を受け取ります。

2.システムは、Yテンプレートを使用してメーリングリストXのアドレスにアラートを送信し、Zサービスはメッセージの送信に使用されます。

3.配布を完了することができない場合、システムは別の送信を試みます。

通知の送信を開始するイベントの通知時間の要件：システムは、イベントの発生後XX秒以内にアラートを受信する必要があります。

通知時間の要件：すべての通知は、イベント通知を受信してからYY分以内に送信する必要があります

失敗した試行後にメールを再送信するための要件：再試行の回数は10回で、失敗した送信の試行ごとに10分間隔である必要があります。

お客様にどのような質問をする必要がありますか？実際、イベントが発生してからどれだけの時間が経過すると、サイトのすべてのユーザーが通知を受け取ることを保証する必要があります。

機能以外の品質要件の基準

機能要件と非機能要件の両方が要件品質基準の対象となります。品質要件によって満たされる必要がある品質の説明。

品質要件の主な特徴は次のとおりです。

（別個の要件と要件システムの）完全性 -要件には、その実装に必要なすべての情報が含まれている必要があります。これには、説明の時点でわかっている、説明されているパラメーターに関するすべての情報が含まれています。要件システムには、未検出および未定義の要件が含まれていてはなりません。説明が不完全な理由は、明示的に宣言する必要があります。
明確性 -要件は内部的に一貫している必要があり、それを扱うすべての人が同じように理解する必要があります。要件は、よく知られた用語を使用して、簡単、簡潔、正確に表現する必要があります。通常、ソフトウェアの仕様要件に関する読者の基本的な知識はさまざまです。したがって、要件を決定する際に使用されるアプリケーション領域の概念の定義を含むセクションを構成に含める必要があります。あいまいな要件の例。「画面の更新間隔は少なくとも20秒である必要があります。」
個々の要件の正確さと、要件システムの一貫性（一貫性） -要件に不正確で不正確な情報が含まれてはならず、要件システム内の個々の要件が互いに矛盾してはなりません。
必要性 -要件は、ユーザーに本当に必要な、または他の要件から生じるソフトウェアの可能性または特性を反映する必要があります。
実現可能性 -仕様に含まれる要件は、動作環境の制約を考慮して実現可能でなければなりません。要件の実現可能性は、開発者による実現可能性分析のプロセスで検証されます。特に、非機能要件については、既存の制限の下で示された数値を達成する可能性がチェックされます。
検証可能性 —要件の検証可能性とは、ソフトウェアがこの要件を満たしていることを手動または機械で確認するための有限で合理的なプロセスがあることを意味します。各要件（特に機能しない）には、その実装を明確に検証するのに十分な情報を含める必要があります。それ以外の場合、実装の事実は分析に基づくのではなく意見に基づいており、完成したソフトウェアを提供する際に問題が発生します。品質属性（思い出すように、さまざまな非機能要件）については、製品またはシステムの品質特性の数値の存在をテスト基準と見なすことができます

非機能要件の品質は、開発された製品またはシステムの品質を直接決定し、開発に関与するグループ全体の調整作業中に非機能要件を決定および分析する反復プロセスによって達成されます。

品質属性

このセクションでは、製品またはシステムの品質特性に焦点を当てます。

品質機能とソフトウェア品質モデル

品質属性の定義は、製品に選択された品質モデルに密接に関連しています。品質モデルの開発は、品質保証グループ（テスターを含み、もちろんテスターに限定されない）によって実行されます。

ソフトウェア業界には、標準として受け入れられているいくつかの品質モデルがあります。これらのモデルは、前世紀の70年代から80年代に開発され、改良が続けられています。

その中には次のものがあります。

ISO 9126
GOST 34
マッコールの品質モデル
ベームの品質モデル

また、品質モデルを決定するためのソースとして使用できる標準をさらに2つ指定できます。

1061-1998ソフトウェア品質メトリクスの方法論に関するIEEE規格
ISO 8402：1994品質管理と品質保証

システムアーキテクチャへの影響に関する品質特性

システムアーキテクチャの観点から見ると、すべての品質属性は2つの大きなグループに分けることができます。最初のグループ（実行時）-これらはアプリケーションまたはシステムの動作時間に関連する属性です。 2番目のグループ（設計時）は、アプリケーションまたはシステムの設計の重要な側面を定義します。これらの属性の多くは相互に依存しています。

これらの各グループをさらに詳しく検討してみましょう。

ランタイムグループ

次の品質属性がこのグループに属します。

可用性は、アプリケーションまたはシステムの稼働時間を決定する品質の属性です。このパラメータを決定するには、通常、最大許容ダウンタイムが示されます。
信頼性 -緊急事態におけるアプリケーションまたはシステムの動作を説明する要件（例：自動再起動、作業の復元、データの保存、重要なデータの複製、バックアップロジック）
データ保存時間の要件 （たとえば、データベースを永続的なデータストアとして使用する、データ保存期間）
スケーラビリティ -アプリケーションまたはシステムの水平および/または垂直スケーリングの要件。垂直スケーラビリティといえば、システムまたはアプリケーションの垂直アーキテクチャの要件を定義します。垂直スケーラビリティ要件には、たとえば、アプリケーションをより強力なSMPシステムに転送する機能、および大量のメモリとファイルのサポートが含まれる場合があります。水平スケーラビリティといえば、システムまたはアプリケーションの水平アーキテクチャの要件を定義します。水平方向のスケーラビリティ要件には、たとえば、クラスタリングテクノロジを使用する機能が含まれる場合があります。通常、垂直スケーリングはシステムパフォーマンスの向上を目的としています。パフォーマンスに加えて、水平スケーリングにより、システムの復元力が向上します。たとえば、垂直および水平スケーリングの詳細については、こちらをご覧ください。
システム/アプリケーションのユーザビリティ要件（ユーザーの観点から）およびユーザビリティ要件（ユーザビリティ）
セキュリティ要件には、原則として、アクセス制御に関連する要件、プライベートデータの操作に関連する要件、および外部攻撃からのリスクを減らすことを目的とした要件という3つの広範なカテゴリが含まれます。
アプリケーションの構成可能性 、相互作用、およびコンポーネントの場所の要件は 、4つのレベルに分けることができます。

1.事前定義されたセットからパラメーター値を変更することによって必要なレベルの変更が達成される場合、事前定義されたパラメーターのセットに基づく構成可能性（事前定義された構成可能性）。

2.事前定義された一連のプロセス、エンティティ、およびサービス手順を再配置することによって必要なレベルの変更が達成される場合、事前定義された基本オブジェクトのセットに基づく構成可能性（フレームワーク制約付き構成可能性）;

3.プロセスおよびエンティティのセットの拡張が提供される場合、新しい基本オブジェクトの実装による構成可能性（基底再実装）。

4.システムを最初からインストールして構成する必要がある場合の、新しいシステムの再実装による構成可能性。
同時ユーザー数、サービストランザクション、反応時間、計算時間、通信チャネルの速度とスループットの観点から定義されたソリューションパフォーマンス要件
利用可能なメモリの量、プロセッサ時間、ディスク容量、ネットワーク帯域幅に課される制限。アプリケーションは、割り当てられたタスクを効果的に実行する必要があります。

設計時グループ