既存の製品のソフトウェア要件を記述する方法
数年にわたって、企業は学際的な（ファームウェア、ソフトウェア、ハードウェア）製品を開発しました。 SRS（ソフトウェア要件仕様）は作成されていません。現在、見込み顧客はSRSを望んでいます。
どのように書いてアプローチするのですか？コードを読みますか？ユーザーマニュアルを書いて要件に変換しますか？
顧客が既存のソフトウェア用にソフトウェア要件仕様書を作成するように求めている理由を質問します。要件は通常、設計とテストの推進に使用されます。要件を満たすデザインを作成し、要件にトレースするテストを使用して、デザインが実際に要件を満たしていることを確認します。
既存のソフトウェア（または市販の購入済み製品）については、何らかのソフトウェア設計記述（SDD）をお勧めします。テスト（特に BDDスタイル で記述されたテスト）は、関係者が理解できる方法でソフトウェアシステムの特性（機能および一部の品質属性）を記述できます。これはSDDの一部として機能し、適切なグラフィック、表、およびテキストのモデルが別のコンポーネントとして機能します。詳細のレベルは、作成している製品のタイプ、およびドキュメントを受け取るクライアントとの合意および関係に大きく依存します。
SDDが適切または適切でない場合は、顧客と協力して顧客が軽減しようとしている懸念を正確に理解し、顧客と協力してそれらに対処するための最良の方法を見つける必要があります。これは、SDD、コード、または実行中のシステムからSRSをリバースエンジニアリングすることを意味する場合があります。
エンドユーザーはソースコードに興味がありません。そのような雑草に入る必要はありません。彼らは製品全体に興味を持っています。
「製品は何をするのか」と自問してください。それをよく知っている人と協力し、それが行うすべてのことを見つけ、それぞれに1つまたは2つの要件を記述します。
可能な限り、要件はテスト可能でなければなりません。製品が要件が示すとおりに機能することをどのように示すかを検討してください。 「検査による」テストは、最後の手段にすぎません。
特にsoftware要件ドキュメントの後にある場合は、最初に全体的な要件を検討する必要があります。これにより、ソフトウェアが実行する必要があることがわかります。