Software-engineering-software-requirements

ソフトウェア要件

ソフトウェア要件は、ターゲットシステムの機能の説明です。 要件は、ソフトウェア製品に対するユーザーの期待を伝えます。 要件は、クライアントの観点から明らかまたは非表示、既知または未知、予想または予期しないものである可能性があります。

要件エンジニアリング

クライアントからソフトウェア要件を収集し、分析して文書化するプロセスは、要件エンジニアリングと呼ばれます。

要件エンジニアリングの目標は、洗練された記述的な「システム要件仕様」ドキュメントを開発して維持することです。

要件エンジニアリングプロセス

次の4つのステップから成るプロセスです–

• 実現可能性調査
• 要件の収集
• ソフトウェア要件仕様
• ソフトウェア要件の検証

プロセスを簡単に見てみましょう-

実現可能性調査

目的の製品を開発するためにクライアントが組織に近づくと、ソフトウェアが実行しなければならないすべての機能と、ソフトウェアに期待されるすべての機能について大まかなアイデアが思いつきます。

この情報を参照して、アナリストは、目的のシステムとその機能が開発可能かどうかについて詳細な調査を行います。

この実現可能性調査は、組織の目標に焦点を当てています。 この調査では、ソフトウェア製品が実装、プロジェクトの組織への貢献、コストの制約、および組織の価値と目的によって実際に実現できるかどうかを分析します。 使いやすさ、保守性、生産性、統合能力など、プロジェクトと製品の技術的側面を調査します。

このフェーズのアウトプットは、プロジェクトを実施すべきかどうかについての管理のための適切なコメントと推奨事項を含むべき実行可能性調査報告書であるべきです。

要件の収集

実行可能性レポートがプロジェクトの実施に肯定的である場合、次のフェーズはユーザーから要件を収集することから始まります。 アナリストとエンジニアは、クライアントとエンドユーザーと通信して、ソフトウェアが提供するものとソフトウェアに含める機能に関するアイデアを把握します。

ソフトウェア要件仕様

SRSは、さまざまな利害関係者から要件が収集された後、システムアナリストによって作成されたドキュメントです。

SRSは、目的のソフトウェアがハードウェア、外部インターフェイス、操作速度、システムの応答時間、さまざまなプラットフォームでのソフトウェアの移植性、保守性、クラッシュ後の回復速度、セキュリティ、品質、制限などと対話する方法を定義します。

クライアントから受け取った要件は、自然言語で書かれています。 システム開発者は、要件を技術用語で文書化して、ソフトウェア開発チームが理解し、役立つようにする必要があります。

SRSは次の機能を考え出す必要があります。

• ユーザー要件は自然言語で表されます。
• 技術要件は、組織内で使用される構造化言語で表現されます。
• デザインの説明は、擬似コードで記述する必要があります。
• フォームのフォーマットとGUI画面印刷。
• DFDなどの条件付きおよび数学表記

ソフトウェア要件の検証

要件仕様が作成された後、このドキュメントに記載されている要件が検証されます。 ユーザーが違法で非現実的な解決策を要求したり、専門家が要件を誤って解釈したりする場合があります。 これは、芽に挟まれていない場合、コストの大幅な増加につながります。 要件は、次の条件に対して確認できます-

• 実際に実装できる場合
• それらが有効であり、ソフトウェアの機能およびドメインに従って
• あいまいな点がある場合
• それらが完全な場合
• 実証できる場合

要件の引き出しプロセス

要件の抽出プロセスは、次の図を使用して説明できます。

要件抽出プロセス

• *要件の収集-*開発者はクライアントおよびエンドユーザーと話し合い、ソフトウェアに対する期待を把握します。
• *要件の整理-*開発者は、重要度、緊急度、および便利さの順に要件を優先順位付けおよび調整します。
• *交渉と議論-*要件があいまいな場合、またはさまざまな利害関係者の要件に何らかの矛盾がある場合は、利害関係者と交渉し、話し合います。 その後、要件が優先され、合理的に侵害される可能性があります。 +要件はさまざまな利害関係者からのものです。 あいまいさと矛盾を取り除くために、それらは明確さと正確さのために議論されています。 非現実的な要件は合理的に妥協されます。
• *ドキュメント-*すべての正式および非公式の機能的および非機能的要件はドキュメント化され、次のフェーズの処理に利用可能になります。

要件の引き出し手法

要件の抽出とは、クライアント、エンドユーザー、システムユーザー、およびソフトウェアシステム開発に関与している他のユーザーと通信することにより、目的のソフトウェアシステムの要件を見つけるプロセスです。

要件を発見するにはさまざまな方法があります

インタビュー

インタビューは、要件を収集するための強力な手段です。 組織は、次のようないくつかのタイプのインタビューを実施できます。

• 収集するすべての情報が事前に決定されている構造化された（クローズド）インタビューは、パターンと議論の問題をしっかりと守ります。
• 収集する情報が事前に決定されておらず、より柔軟で偏りの少ない非構造化（オープン）インタビュー。
• 口頭インタビュー
• 書面によるインタビュー
• テーブルを渡って2人の間で行われる1対1のインタビュー。
• 参加者のグループ間で行われるグループインタビュー。 多数の人々が関与しているため、欠落している要件を明らかにするのに役立ちます。

調査

組織は、今後のシステムからの期待と要件について照会することにより、さまざまな利害関係者間で調査を実施できます。

アンケート

事前定義された客観的な質問とそれぞれのオプションのセットを含むドキュメントは、すべての利害関係者に渡されて回答され、収集およびコンパイルされます。

この手法の短所は、アンケートで問題のオプションが記載されていない場合、問題が放置される可能性があることです。

タスク分析

エンジニアと開発者のチームは、新しいシステムが必要な操作を分析できます。 クライアントが特定の操作を実行するためのソフトウェアをすでに持っている場合、それが調査され、提案されたシステムの要件が収集されます。

ドメイン分析

すべてのソフトウェアは、いくつかのドメインカテゴリに分類されます。 ドメインの専門家は、一般的および特定の要件を分析するのに非常に役立ちます。

ブレーンストーミング

さまざまな利害関係者の間で非公式の議論が行われ、さらなる要件分析のためにすべてのインプットが記録されます。

プロトタイピング

プロトタイプは、ユーザーが目的のソフトウェア製品の機能を解釈するための詳細機能を追加せずにユーザーインターフェイスを構築しています。 要件をよりよく理解するのに役立ちます。 開発者が参照するためにクライアント側にソフトウェアがインストールされておらず、クライアントが独自の要件を認識していない場合、開発者は最初に言及した要件に基づいてプロトタイプを作成します。 プロトタイプがクライアントに表示され、フィードバックが記録されます。 クライアントのフィードバックは、要件収集の入力として機能します。

観察

専門家チームがクライアントの組織または職場を訪問します。 既存のインストール済みシステムの実際の動作を観察します。 クライアント側のワークフローと、実行の問題の対処方法を観察します。 チーム自体が、ソフトウェアに期待される要件を形成するのに役立ついくつかの結論を導き出します。

ソフトウェア要件の特性

ソフトウェア要件の収集は、ソフトウェア開発プロジェクト全体の基盤です。 したがって、それらは明確で正しく、明確に定義されている必要があります。

完全なソフトウェア要件仕様は次のとおりである必要があります。

• クリア
• 正しい
• 一貫した
• コヒーレント
• わかりやすい
• 変更可能
• 検証可能
• 優先順位付け
• 明確な
• 追跡可能
• 信頼できるソース

ソフトウェア要件

要件抽出フェーズでどのような要件が発生する可能性があり、ソフトウェアシステムにどのような要件が予想されるのかを理解する必要があります。

ソフトウェア要件は、大きく分けて次の2つのカテゴリに分類する必要があります。

機能要件

ソフトウェアの機能面に関連する要件は、このカテゴリに分類されます。

それらは、ソフトウェアシステム内外の機能を定義します。

例 -

• さまざまな請求書から検索するためにユーザーに与えられた検索オプション。
• ユーザーは、レポートを管理者に郵送できる必要があります。
• ユーザーをグループに分割し、グループに個別の権限を付与できます。
• ビジネスルールと管理機能を遵守する必要があります。
• ソフトウェアは、下位互換性を損なわずに開発されています。

非機能要件

要件は、ソフトウェアの機能面とは関係ありませんが、このカテゴリに分類されます。 これらは、ユーザーが想定するソフトウェアの暗黙的または予想される特性です。

非機能要件には次が含まれます-

• セキュリティ
• ロギング
• ストレージ
• 設定
• パフォーマンス
• Cost
• 相互運用性
• 柔軟性
• 災害からの回復
• アクセシビリティ

要件は論理的に次のように分類されます

• Must Have ：それらなしではソフトウェアは動作可能とは言えません。
• Should have ：ソフトウェアの機能を強化します。
• Could have ：ソフトウェアは、これらの要件でも適切に機能します。
• ウィッシュリスト：これらの要件は、ソフトウェアのいかなる目的にも対応していません。

ソフトウェアの開発中は、「必要」を実装する必要があります。「必要」は、利害関係者との議論と否定の問題ですが、ソフトウェアの更新については「必要」と「希望リスト」を保持できます。

ユーザーインターフェイスの要件

UIは、ソフトウェア、ハードウェア、またはハイブリッドシステムの重要な部分です。 ソフトウェアは、広く受け入れられています-

• 操作が簡単
• 迅速な対応
• 操作エラーを効果的に処理する
• シンプルでありながら一貫したユーザーインターフェイスを提供する

ユーザーの受け入れは、ユーザーがソフトウェアを使用する方法に大きく依存します。 ユーザーがシステムを認識する唯一の方法はUIです。 優れたパフォーマンスのソフトウェアシステムには、魅力的で明確で一貫性のある応答性の高いユーザーインターフェイスも装備する必要があります。 そうしないと、ソフトウェアシステムの機能を便利な方法で使用できません。 システムは、それを効率的に使用する手段を提供するのであれば良いと言われます。 ユーザーインターフェイスの要件を以下に簡単に説明します-

• コンテンツのプレゼンテーション
• 簡単なナビゲーション
• シンプルなインターフェース
• レスポンシブ
• 一貫性のあるUI要素
• フィードバック機構
• デフォルトの設定
• 意図的なレイアウト
• 色とテクスチャの戦略的使用。
• ヘルプ情報を提供する
• ユーザー中心のアプローチ
• グループベースのビュー設定。

ソフトウェアシステムアナリスト

IT組織のシステムアナリストは、提案されたシステムの要件を分析し、要件が適切かつ正確に考案および文書化されていることを確認する人です。 アナリストの役割は、SDLCのソフトウェア分析フェーズで始まります。 開発したソフトウェアがクライアントの要件を満たしていることを確認するのはアナリストの責任です。

システムアナリストには次の責任があります。

• 対象ソフトウェアの要件の分析と理解
• プロジェクトが組織の目標にどのように貢献するかを理解する
• 要件のソースを特定する
• 要件の検証
• 要件管理計画を作成および実装する
• ビジネス、技術、プロセス、製品の要件の文書化
• 要件を優先し、曖昧さを排除するためのクライアントとの調整
• クライアントおよびその他の利害関係者との受け入れ基準の最終決定

ソフトウェアのメトリックと測定

ソフトウェア測定は、ソフトウェアのさまざまな属性と側面を定量化および記号化するプロセスとして理解できます。

ソフトウェアメトリックは、ソフトウェアプロセスおよびソフトウェア製品のさまざまな側面の指標を提供します。

ソフトウェア測定は、ソフトウェアエンジニアリングの基本的な要件です。 これらは、ソフトウェア開発プロセスの制御に役立つだけでなく、究極の製品の品質を優れたものにするのにも役立ちます。

（ソフトウェアエンジニア）Tom DeMarcoによると、「測定できないものを制御することはできません。」と彼は言っています。

いくつかのソフトウェアメトリックを見てみましょう。

• サイズメトリック- LOC（コード行）。ほとんどの場合、KLOCと表記される数千のソースコード行で計算されます。 + Function Point Countは、ソフトウェアによって提供される機能の測定値です。 機能ポイント数は、ソフトウェアの機能面のサイズを定義します。
• 複雑度メトリクス- McCabeの循環的複雑度は、プログラム内の独立したパスの数の上限を定量化します。これは、プログラムまたはそのモジュールの複雑度として認識されます。 制御フローグラフを使用して、グラフ理論の概念で表されます。
• *品質メトリクス-*欠陥、そのタイプと原因、結果、深刻度の強度、およびその意味が製品の品質を定義します。 +開発プロセスで見つかった欠陥の数と、製品がクライアント側でインストールまたは配信された後にクライアントによって報告された欠陥の数は、製品の品質を定義します。
• プロセスメトリック- SDLCのさまざまなフェーズで使用される方法とツール、会社の標準、および開発のパフォーマンスは、ソフトウェアプロセスメトリックです。
• *リソースメトリック-*努力、時間、および使用されるさまざまなリソースは、リソース測定のメトリックを表します。