SRS: ソフトウェア要件仕様の基本

ソフトウェア要件仕様、略してSRSは、開発されるソフトウェア製品の詳細な説明を示す用語です。これは、ソフトウェア開発ライフサイクル（SDLC）の初期段階の1つと見なされます。それは、完成した製品への道しるべのようなものです。インターネットには、開発者が学ぶための多くの優れたSRSの例が提供されています。注意点は、地図のように、SRSは正確に従う必要があるということです。明確で簡潔で、追いやすいSRSを書くには、プロジェクトを理解するだけでなく、SRSのガイドラインも理解する必要があります。SRSが開発の準備が整ったときはどうやってわかりますか？それが優れているのは何ですか？それがこの記事で扱う内容です。

優れたSRSの特徴

開発者がプロジェクトを円滑に進めるために、SRS文書で達成すべき特定の要素があります。これらは3つのカテゴリに分けることができます:

• 意味のある質
• 目標を達成する特性
• 特定可能な要求の臭い

見てみましょう。

意味のある質

SRSの意味のある質は、開発者がプロジェクトの全範囲を理解するのに役立つ目的を持っています。

• 問題を分解する。 良いSRSは、問題をより簡単に解決できるチャンクに分解します。これにより、問題の理解が深まり、対処しやすくなります。
• 設計の入力を提供する。 SRSには、実装と展開を支援するための設計の詳細が含まれているべきです。
• フィードバックのためのコンポーネントを考慮する。 完成したソフトウェアのユーザーにとっての意味のある質は、フィードバックを提供する機会です。これは、強力なSRSを開発する際に考慮すべき点です。
• 検証戦略を含める。 要件が正しく述べられ、意図した通りに機能することを保証するために、検証戦略が実施されるべきです。
• 重要度で要件をランク付けする。 要件を重要度でランク付けすることで、開発者と利害関係者の両方に優先事項が明確に伝わります。プロジェクトが特定の締切に迫っている場合、スプリントの終わりなど、ランク付けシステムがあれば、開発者は優先順位を容易にシフトできます。
• 完全で簡潔、変更可能である。 完成した製品は、理解を促進するために開発プロジェクトの全体像をできるだけ簡潔に提示するべきです。また、フィードバックや変更に対応できるように、簡単に変更可能であるべきです。

目標を達成する特性

各開発プロジェクトには、事前に設定された目標のセットがあるべきです。これらの特性は、目標が達成され、プロジェクトが正しい軌道を維持するために使用されます。

• 作業の記述的範囲。 明確な作業の範囲を持つことは、最も重要な目標の一つです。範囲は、開発者をプロジェクトに導きます。それは、完成したプロジェクトがどのようなものであるかを定義することによって、そこに到達する方法を理解するのを助けます。
• エンドユーザーのための機能を定義する。 顧客の要件には、SRSに定義される必要があるエンドユーザーの特定の機能が含まれています。
• 利害関係者とのレビューの機会を提供する。 この文書の目的の1つは、プロジェクトマネージャーと利害関係者の間の透明性を持つことです。だからこそ、両者間でのSRSのレビューは、全体的な成功の重要な基準です。
• 明確なナビゲーション。 ナビゲーションを持つ明確で簡潔な文書構造は、開発者にとって重要な参照ポイントです。
• テストと改善。 どの開発プロジェクトにも、テストのためのフレームワークを持つことが目標です。もう1つの考慮点は、展開後にフレームワークをどのように改善するかです。SRSは両方に対処するべきです。
• コストを見積もる。 重要なことに、SRSは開発および展開のコスト、ならびに運用コストを見積もることができるべきです。

特定可能な要求の臭い

コードの臭いに似て、要求の臭いは、要求に問題があることを示す指標です。開発者はこれらの特性に注意を払い、必要に応じて変更を加えるべきです。これらは通常、要求アーティファクトに致命的なエラーを引き起こすことはないため、ケースバイケースで解決されます。だからこそ、これらは優れたSRSの特性の中に含まれています。これらの臭いに対する鋭い感覚を持つことで、あなたの仕事が良くなります。要求の臭いの例には:

• 曖昧な副詞と形容詞
• 主観的な言葉
• 最上級
• 否定的な文

優れたSRSのためのガイドライン

SRSの内容は、プロジェクトによって異なる場合があります。それでも、どんなに異なっていても、各プロジェクトは所定のガイドラインに従うべきです。これらのガイドラインは覚えやすく、頭字語がFACTSという言葉を綴ります。

• 機能要件。 SRSの機能は、開発プロジェクトそのものとは異なります。この文書の機能要件は、実装のためのフレームワークを提供することで、文書全体を通じて明らかであるべきです。
• 分析モデル。 分析モデルは、特定の要件の仕様を詳細に検討することを可能にします。例えば、「カートに商品を追加する」という要件は、サイズや数量などの他の詳細を考慮していない命令です。これらは、機能要件と設計を結びつける分析モデルを使用して詳細化できます。
• 認知モデル。 これは、開発者がシステムが他者（通常はエンドユーザー）によってどのように認識されるかを理解するのを助けるモデルです。
• 仕様の内容と構造。 これはデータ辞書としても知られています。各エンティティに関連するすべてのデータに加えて、組織のフローチャートが含まれているべきです。
• 仕様。 仕様自体のガイドラインは、開発プロジェクトのストーリーを語るのに十分堅牢で、範囲や規模の変更を許可するのに柔軟でなければなりません。

優れたSRSの構造

SRSを構造化する方法は1つではありませんが、いくつかのモデルが例として役立ちます。これまでの特徴とガイドラインに従っていれば、良いスタートを切っています。文書をまとめる際には、あなたのフレームワークは次のようになるかもしれません:

目的/序論

• 定義
• システム概要
• 参考文献

全体の説明

• 製品の視点
  • システムインターフェース
  • ユーザーインターフェース
  • ハードウェアインターフェース
  • ソフトウェアインターフェース
  • 通信インターフェース
  • メモリ制約
• 設計制約
  • 運用
  • サイト適応要件
• 製品機能
• ユーザー特性
• 制約、仮定、依存関係

特定の要件

• 外部インターフェース要件
• 機能要件
• パフォーマンス要件
• 論理データベース要件
• ソフトウェアシステムの属性
  • 信頼性
  • 可用性
  • セキュリティ
  • 保守性
  • 移植性
• 特定の要件の整理

上記の例は、IEEEソフトウェア要件仕様ガイド（Std 830-1993）からの適応です。IEEEは、SRS要件の業界基準を設定する組織です。これは、SRSを作成する際に最も広く使用される基準セットであり、各機関のニーズに合わせて適応できます。

構造の定義

上記の例のいくつかの主要なコンポーネントは次のとおりです:

目的/序論

目的セクションは、SRS文書全体を要約する必要があります。これは、ビジネス文書のエグゼクティブサマリーに似ており、プロジェクトのトーンを設定します。通常、このセクションの主要なコンポーネントには、定義、システム概要、および参考文献が含まれます。これらは、開発プロジェクトの重要なテーマを確立するのに役立ちます。

全体の説明

全体の説明は、要件や他のサブセクションの概要を提供します。要件は、特定の要件セクションで詳細に説明されます。全体の説明の目的は、要件に影響を与える決定要因を考慮することです。全体の説明のサブセクションは、製品の視点、設計制約、製品機能、ユーザー特性、制約、仮定、依存関係です。これらはすべて、要件を完了する際のニーズと課題を予測することに関連しています。設計制約には、ソフトウェアのコンプライアンスからハードウェアの制約まで、すべてが含まれます。

特定の要件

特定の要件セクションの目的は、開発に必要なすべての要件を詳細に説明することです。このセクションは、設計者が要件に従って製品を作成するためのフレームワークを提供します。特定の要件セクションには、外部インターフェース要件、機能要件、パフォーマンス要件、論理データベース要件、およびソフトウェアシステム属性が含まれます。これらのサブセクションは、プログラム全体の機能に必要な要件のセットを詳細に説明します。

優れたSRSの作成

今、あなたは優れたSRS文書を作成する方法を知っています。迅速な検索を行えば、この新しい知識を適用できるさまざまなテンプレートが見つかるでしょう。100%自信がない場合でも、最初に正しく行うことが重要です。SRSは、開発プロジェクト全体の基礎です。最終的には、この文書の目標は、完璧なSRSを持つことよりも、プログラム開発の円滑な実施を支援することです。私たちが議論した主要なコンポーネントの中で、あなたのSRSはフレキシブルで、変更可能で、スケーラブルでなければなりません。プロジェクトの要求に合わせて変化できるように。これが一度に受け入れる情報が多く感じられる理由です。この記事は、複雑な実践の高レベルの概要を提供します。SRSの研究へのアプローチは、すべての開発プロジェクトを利害関係者に提示する方法に似ています—理解しやすい情報の塊で。文書の各セクションを進むにつれて、少しずつ受け入れてください。次の開発プロジェクトでは、学ぶ時間を取った自分に感謝するでしょう。すべての物事と同様に、練習はSRSを強化します。しかし、これらのガイドライン、特性、構造の推奨は良いスタートです。

追加リソース

• BMC DevOpsブログ
• ソフトウェアエンジニアリングにおける展開パイプライン（CI/CD）
• エクストリームプログラミングとは何か？
• Python対Go: 違いは何ですか？
• ウォードリー・バリューチェーンマッピング: それは何か、そしてあなたのものを作成する方法

これらの投稿は私自身の意見であり、必ずしもBMCの立場、戦略、または意見を表すものではありません。