ソフトウェア要件

ソフトウェア要件とはターゲットシステムの特徴と機能性の記述のことである。 要件は、ユーザーがソフトウェア製品に期待することを伝えるものです。

要件エンジニアリング

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

要件エンジニアリングの目標は、高度で説明的な「システム要件仕様」文書を開発し維持することです。

要件定義プロセス

これは 4 つのステップからなるプロセスです。

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

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

Feasibility study

クライアントが希望の製品を開発してもらうために組織にアプローチするときです。 そのソフトウェアに期待される機能は何か、どのような機能なのか、おおよその見当はついているはずです。

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

この実現可能性の研究は、組織の目標に焦点を当てたものです。 この研究では、ソフトウェア製品が、実装、組織へのプロジェクトの貢献、コストの制約、および組織の価値や目的に従って、実際に実現できるかどうかを分析します。

この段階の出力は、フィージビリティ スタディのレポートであるべきで、プロジェクトが実施されるべきかどうかについて、経営陣への適切なコメントと推奨が含まれていなければなりません。

フィージビリティ レポートがプロジェクトの実施に前向きであれば、次の段階ではユーザーから要件を集めることから始めます。 アナリストやエンジニアは、クライアントやエンドユーザーと連絡を取り、ソフトウェアが提供すべきものや、ソフトウェアに含ませたい機能について、彼らの考えを把握します。

ソフトウェア要件仕様

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

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

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

SRSは以下の機能を備えている必要があります。

• ユーザー要件は自然言語で表現される
• 技術要件は組織内で使用される構造化言語で表現される
• 設計記述は疑似コードで記述されるべきである
• ユーザー要件は自然言語で表現される。
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following conditions –

• If they can be practically implemented
• If they are valid and as per functionality and domain of software
• If there are any ambiguities
• If they are complete
• If they can be demonstrated

Requirement Elicitation Process

Requirement elicitation process can be depicted using the folloiwng diagram:



• 要件の収集 – 開発者はクライアントおよびエンド ユーザーと話し合い、ソフトウェアに対する彼らの期待値を把握します。
• 要件の整理 – 開発者は、重要性、緊急性、および利便性の順に要件に優先順位を付けて整理します。
• 交渉 & 議論 -要件があいまいである場合、またはさまざまな利害関係者の要件にいくつかの矛盾がある場合、それは、次に交渉して利害関係者と議論されます。 要件はその後、優先順位を付けられ、合理的に妥協されるかもしれません。

  要件はさまざまな利害関係者から出されます。 曖昧さおよび対立を取除くために、それらは明確さおよび正確さのために論議される。

• ドキュメント化 – すべての正式な & 非公式な、機能的および非機能的な要件がドキュメント化され、次の段階の処理に利用できるようにされます。

要件抽出の手法

要件抽出とは、クライアント、エンド ユーザー、システム ユーザー、およびソフトウェア システムの開発に関係する他の人とコミュニケーションをとることにより、意図するソフトウェア システムの要件を見つけ出すプロセスです。

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

インタビュー

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

• 構造化（クローズド）インタビュー：収集する情報のすべてが事前に決定されており、議論のパターンと内容にしっかりと従います。
• 非構造化（オープン）インタビュー：収集する情報が事前に決定されておらず、より柔軟で偏りの少ないインタビューです。
• オーラルインタビュー
• ライティングインタビュー
• テーブルを挟んで二人で行う一対一のインタビュー
• 参加者のグループ間で行うグループインタビュー

。

アンケート

組織は、次期システムに対する期待や要件について問い合わせることにより、さまざまな利害関係者にアンケートを実施することができます。

アンケート

あらかじめ定義された目的の質問とそれぞれの選択肢を含む文書がすべての関係者に渡され、回答が収集・集計されます。

この手法の短所は、ある問題に対する選択肢がアンケートに記載されていない場合、その問題が放置されることがあることです。

タスク解析

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

ドメイン分析

すべてのソフトウェアは、何らかのドメイン カテゴリに分類されます。 その分野の専門家は、一般的な要件と特定の要件を分析するための大きな助けとなります。

ブレーンストーミング

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

プロトタイピング は、ユーザーが意図したソフトウェア製品の機能を解釈するために詳細機能を追加せずにユーザー インターフェイスを構築することです。 これは、要件についてより良いアイデアを与えるのに役立ちます。 開発者が参照するためにクライアント側にインストールされたソフトウェアがなく、クライアントが自身の要件を認識していない場合、開発者は最初に述べた要件に基づいてプロトタイプを作成します。 そのプロトタイプをクライアントに見せ、フィードバックを得る。

観察

専門家チームは、クライアントの組織または職場を訪問します。 彼らは、既存のインストールされたシステムの実際の動作を観察します。 クライアント側のワークフローを観察し、実行上の問題がどのように対処されるかを観察します。 The team itself draws some conclusions which aid to form requirements expected from the software.

Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development project. Hence they must be clear, correct and well-defined.

A complete Software Requirement Specifications must be:

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source

Software Requirements

We should try to understand what sort of requirements may arise in the requirement elicitation phase and what kinds of requirements are expected from the software system.

大きく分けて、ソフトウェア要件は 2 つのカテゴリに分類されるべきです。

機能的要件

ソフトウェアの機能的側面に関連する要件は、このカテゴリに入ります。

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

• ユーザーは管理者に任意のレポートを郵送できるべきである。
• ユーザーをグループに分け、グループに個別の権限を与えることができる。
• ビジネス ルールと管理機能を遵守すべきである。
• ソフトウェアは下位互換性をそのまま維持して開発する。 ソフトウェアの暗黙の、または期待される特性であり、ユーザーが想定しているものです。

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

  • Security
  • Logging
  • Storage
  • Configuration
  • Performance
  • Cost
  • Interoperability
  • Flexibility
  • Disaster recovery
  • Accessibility

  Requirements are categorized logically as

  • Must Have : Software cannot be said operational without them.
  • Should have : Enhancing the functionality of software.
  • Could have : Software can still properly function with these requirements.
  • Wish list : These requirements do not map to any objectives of software.

  While developing software, ‘Must have’ must be implemented, ‘Should have’ is a matter of debate with stakeholders and negation, whereas ‘could have’ and ‘wish list’ can be kept for software updates.

  User Interface requirements

  UI is an important part of any software or hardware or hybrid system. A software is widely accepted if it is –

  • easy to operate
  • quick in response
  • effectively handling operational errors
  • providing simple yet consistent user interface

  User acceptance majorly depends upon how user can use the software. UI is the only way for users to perceive the system. A well performing software system must also be equipped with attractive, clear, consistent and responsive user interface. Otherwise the functionalities of software system can not be used in convenient way. A system is said be good if it provides means to use it efficiently. User interface requirements are briefly mentioned below –

  • Content presentation
  • Easy Navigation
  • Simple interface
  • Responsive
  • Consistent UI elements
  • Feedback mechanism
  • Default settings
  • Purposeful layout
  • Strategical use of color and texture.
  • ヘルプ情報の提供
  • ユーザー中心のアプローチ
  • グループ ベースのビュー設定

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

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

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

  • 意図するソフトウェアの要件を分析し理解する
  • プロジェクトが組織の目標にどのように貢献するかを理解する
  • 要件源を特定する
  • 要件の検証
  • Requirements Management Planを開発し実施する
  • Business, Technical…,
  • 要件に優先順位をつけ、あいまいさを取り除くためのクライアントとの調整
  • クライアントおよびその他の利害関係者との受け入れ基準の最終決定

  Software Metrics and Measures

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

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

  ソフトウェアの測定値は、ソフトウェア工学の基本的な要件です。

  ソフトウェア測定は、ソフトウェア工学の基本要件です。ソフトウェア開発プロセスを制御するだけでなく、最終製品の品質を優れたものに保つのにも役立ちます。

  ソフトウェア エンジニアのトム デマルコは、「測定できないものは制御できない」と述べています。

  いくつかのソフトウェア指標を見てみましょう。

  • サイズ指標 – LOC (Lines of Code) は、主に、KLOC として示される、配信されたソース コード ラインの数千で計算されます。

    ファンクション ポイント カウントは、ソフトウェアによって提供される機能の尺度です。

  • 複雑性メトリクス – McCabe の循環的複雑性は、プログラム内の独立パスの数の上限を定量化し、プログラムまたはそのモジュールの複雑性として認識されるものです。

  • 品質メトリクス – 欠陥、その種類と原因、結果、深刻度の強さ、およびそれらの意味するところは、製品の品質を定義します。

    The number of defects found in development process and number of defects reported by the client after the product is installed or delivered at client-end, define quality of product.

  • Process Metrics – In various phases of SDLC, the methods and tools used, the company standards and the performance of development are software process metrics.
  • Resource Metrics – Effort, time and various resources used, represents metrics for resource measurement.
  Advertisements