ソフトウェア要件

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

要件エンジニアリング

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

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

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

これは4つのステップのプロセスであり、以下が含まれます–

フィージビリティスタディ
要件の収集
ソフトウェア要件仕様
ソフトウェア要件の検証

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

フィージビリティスタディ

クライアントが目的の製品を開発するために組織に近づくと、ソフトウェアが実行する必要のあるすべての機能と、ソフトウェアに期待されるすべての機能について大まかなアイデアが浮かび上がります。

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

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

このフェーズの出力は、プロジェクトを実施する必要があるかどうかについての管理者向けの適切なコメントと推奨事項を含む実現可能性調査レポートである必要があります。

要件の収集

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

ソフトウェア要件仕様

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

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

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

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

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

ソフトウェア要件の検証

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

それらが実際に実行できるかどうか
それらが有効であり、ソフトウェアの機能およびドメインに従っているかどうか
あいまいさがあれば
それらが完了している場合
それらが実証できれば

要件の引き出しプロセス

要件の引き出しプロセスは、次の図を使用して表すことができます。

Requirements gathering - 開発者はクライアントおよびエンドユーザーと話し合い、ソフトウェアに対する彼らの期待を知っています。
Organizing Requirements - 開発者は、重要性、緊急性、利便性の順に要件に優先順位を付けて配置します。
Negotiation & discussion - 要件があいまいな場合、またはさまざまな利害関係者の要件に矛盾がある場合は、それが交渉され、利害関係者と話し合われます。その後、要件に優先順位が付けられ、合理的に妥協される可能性があります。

要件はさまざまな利害関係者から来ています。あいまいさと矛盾を取り除くために、それらは明確さと正確さのために議論されます。非現実的な要件は合理的に妥協されます。
Documentation - すべての公式および非公式、機能および非機能要件が文書化され、次のフェーズの処理に利用できるようになります。

要件の引き出し手法

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

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

インタビュー

面接は、要件を収集するための強力な媒体です。組織は、次のようないくつかのタイプの面接を実施する場合があります。

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

調査

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

アンケート

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

この手法の欠点は、ある問題のオプションが質問票に記載されていない場合、その問題が放置される可能性があることです。

タスク分析

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

ドメイン分析

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

ブレーンストーミング

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

プロトタイピング

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

観察

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

ソフトウェア要件の特徴

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

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

Clear
Correct
Consistent
Coherent
Comprehensible
Modifiable
Verifiable
Prioritized
Unambiguous
Traceable
信頼できる情報源

ソフトウェア要件

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

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

機能要件

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

これらは、ソフトウェアシステム内およびソフトウェアシステムからの機能を定義します。

例-

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

非機能要件

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

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

Security
Logging
Storage
Configuration
Performance
Cost
Interoperability
Flexibility
災害からの回復
Accessibility

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

Must Have ：ソフトウェアは、それらなしでは動作可能とは言えません。
Should have ：ソフトウェアの機能を強化します。
Could have ：ソフトウェアは、これらの要件で引き続き適切に機能します。
Wish list ：これらの要件は、ソフトウェアの目的に対応していません。

ソフトウェアの開発中は、「必須」を実装する必要があります。「必須」は利害関係者との議論と否定の問題ですが、「必須」と「ウィッシュリスト」はソフトウェアの更新のために保持できます。

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

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

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

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

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

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

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

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

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

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

ソフトウェアメジャーは、ソフトウェアのさまざまな属性と側面を定量化およびシンボル化するプロセスとして理解できます。

ソフトウェアメトリクスは、ソフトウェアプロセスとソフトウェア製品のさまざまな側面の測定値を提供します。

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

（ソフトウェアエンジニア）のTom DeMarcoによると、「測定できないものを制御することはできません」。彼の言うことにより、ソフトウェア対策がいかに重要であるかは非常に明白です。

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

Size Metrics - LOC（Lines of Code）は、ほとんどがKLOCと呼ばれる、配信された何千ものソースコード行で計算されます。

ファンクションポイントカウントは、ソフトウェアによって提供される機能の尺度です。ファンクションポイントカウントは、ソフトウェアの機能面のサイズを定義します。
Complexity Metrics - マッケイブの循環的複雑度は、プログラムまたはそのモジュールの複雑さとして認識される、プログラム内の独立したパスの数の上限を定量化します。これは、制御フローグラフを使用してグラフ理論の概念で表されます。
Quality Metrics - 欠陥、その種類と原因、結果、重大度の強さ、およびそれらの影響によって、製品の品質が決まります。

開発プロセスで見つかった欠陥の数と、製品がクライアント側でインストールまたは配信された後にクライアントから報告された欠陥の数によって、製品の品質が決まります。
Process Metrics - SDLCのさまざまなフェーズで、使用される方法とツール、会社の標準、および開発のパフォーマンスは、ソフトウェアプロセスのメトリックです。
Resource Metrics - 労力、時間、および使用されるさまざまなリソースは、リソース測定のメトリックを表します。