要件エンジニアリングのための EARS 表記の採用

要件ステートメントは、INCOSE の規則に従って評価されます。 これらの標準は、組織が実装前に要件の実現可能性と品質を評価するのに役立ちます。 評価プロセスには、次の XNUMX つの主要な基準が含まれます。

• 明確 – 書面による要件は明確で、読みやすく、理解しやすいものでなければなりません。 アクター間でやり取りされる肯定文を使用して情報を明確に指定します。 すべての要件には明確な成功基準を記述する必要があります。 簡単な語彙を使用し、略語を避けるようにしてください。 たとえば、「ユーザーは監査ログ レポートを表示できるものとする」などです。
• アトミック – 各要件は個別のテスト ケースとして扱う必要があります。 and、or などの接続詞は、要件を逃す可能性があるため使用しないでください。 このような用語はソフトウェア開発者やテスターが要件を見落とす可能性があるため、これは特に重要です。 複雑なニーズを小さな部分に分割して、それぞれを個別にテストできるようにすることが、このような事態が起こらないようにするには XNUMX つの方法です。
• 明確 – 不明確、不完全、または矛盾した要件は、エラーややり直しにつながる可能性があります。 これを防ぐには、要件が最終決定される前に、すべての関係者が要件をレビューする必要があります。 これは、対処できるギャップを早期に特定するのに役立ちます。
• 検証可能 – 必要に応じて何度でも参照できるように、開発チームの全員がドキュメントにアクセスできる必要があります。 要件は明確でなければならないため、チームメンバーはそれ以上の情報を望んでいません。 これらはすべて SRS ドキュメントからアクセスできる必要があります。
• 必要 – 各要件は、ユーザーが本当に必要とするもの、または外部インターフェイスの存在により標準または統合のニーズを満たすために必要なものを文書化する必要があります。 また、各要件には認可された情報源があることが重要です。
• 独立した設計 – 各要件は、実装方法ではなく、何が必要かを定義する必要があります。 要件では、内部の詳細ではなく、外部から観察されるシステムの特性を定義する必要があります。
• 実現可能 – 各要件は技術的に実行可能である必要があり、予算、期限、プロジェクトに影響するその他の制限を考慮して実装する必要があります。 要件は、コスト、スケジュール、テクノロジーなどの実際の状況を反映する必要があります。 将来の技術の進歩に依存すべきではありません。
• 完全 – 要件ドキュメントには、開発チームとテスターが製品を完成させ、バグなくユーザーの要件を満たしていることを確認するために十分な情報が含まれている必要があります。
• 正解 – 文書に指定されている要件は、あらゆる種類の混乱を避けるために非常に正確である必要があります。 抜け穴、曖昧さ、主観、最上級、または比較があってはなりません。 したがって、正しい要件を作成するには、正しい情報を入手し、収集した情報を正しく文書化する必要があります。