制約はソフトウェア要件を設計していますか？
今日、システムエンジニアリングを研究している同僚から、次のように言われましたソフトウェア設計の制約とGUIの要件（例：ソフトウェアは、プレゼンテーション、ビジネス、永続性の3つの層で開発する必要があり、GUIはツリーオブジェクトを使用する必要があります）構造を表示するには）notと見なされますシステムまたはソフトウェアの要件。
SRS（ソフトウェア要件仕様）のいくつかのテンプレートを調べました。 RUPのテンプレートでは、設計の制約とGUIの要件はソフトウェア要件の一種であると述べています。 IBMの新しいテンプレートでは、特定の要件の章から除外しています。
次に、制約ソフトウェア設計をソフトウェア要件と見なす必要がありますか？
ソフトウェア要件仕様（SRS） を作成している場合、GUI要件と設計制約の両方がそのドキュメントに取り込まれることを期待しています。
ISO/IEC/IEEE 29148-2011では、サンプルSRSの概要で、設計制約のセクションは「外部標準、規制要件、またはプロジェクトの制限によって課されるシステム設計の制約を指定する」ために使用されると述べています。ユーザーインターフェイスに関するセクションは、「ソフトウェア製品とそのユーザー間の各インターフェイスの論理的特性」を含むように設計されており、「必要な画面フォーマット」と「ページまたはウィンドウのレイアウト」、および「最適化のすべての側面」が含まれています。システムを使用、保守、またはその他のサポートを提供する人とのインターフェース」.
IEEE 830-1998のようなSRS標準の以前の反復を見ると、ドキュメントを構造化する複数の方法が見つかります。その上、多くの組織はソフトウェア要件仕様書を作成せず、要件を別の形式で保持している場合があります。
私はあなたの例が良いソフトウェア要件の例であるとは考えません。 3層設計を「必要」とするステートメントと、ツリーオブジェクトを「必要」とするステートメントは、どちらも設計上の決定事項です。
私の経験では、設計制約の例には、特定のプログラミング言語またはフレームワーク（またはそのバージョン）、特定のオペレーティングシステム、または標準への参照 参照アーキテクチャ の使用が含まれます（この参照アーキテクチャは、たとえば、アプリケーションの3層アーキテクチャの課税要件）。ユーザーインターフェイス要件の例では、ユーザーインターフェイススタイルガイドへの準拠が必要になる傾向があります（たとえば、モバイルアプリがモバイルOSスタイルガイドまたは会社のスタイルガイドのいずれかに準拠する必要がある）。
結局のところ、要件は、ソフトウェアが従わなければならない特性である必要があります。そうでないと、現在の環境での利害関係者のニーズを達成できません。