web-dev-qa-db-ja.com

ビジネス要件ドキュメントのデータフィールドの説明

ビジネス要件ドキュメントでデータフィールドとその動作を説明する方法と場所は？

私はこのようにビジネス要件ドキュメントをセットアップしています：

1.4一般要件：

Req #   |   Ranking     |   Requirement  
1       |       H       |   The system shall be breaking into two sub-systems; one for the POS Admins and the other for the clients.
2       |       L       |   The system should automatically validates for the expected result in the user side before submitting to the server.

2.2ユーザー特性：

System             |   Role Name      |   No. of Users  | Responsibility / Activity   

POS Admin system   |  Finance Manger  |        1        | Responsible for delivering financial reports

Client-side system |  General Client  |        N        | Applying  for ...etc

.2機能要件：

Req # | Ranking |       System       | Role |  Requirement  
1     |    H    | Client-side system | ALL  | The system should have two type of addresses one for local and the other for out of country 
2     |    H    | Client-side system | ALL  | The system should enforce local address only, if the user entered their social security number as the id

.3ユースケース：

3.3.1住所の入力：

- Use Case ID:  00001
- Goal:    
- Pre-conditions:
- Post-conditions:
- Failure Outcomes:
- Flow of Events: 
- Alternative Scenarios:
- Inputs Summary:
- Output Summary:

ユーザーが入力する必要なデータフィールドをどこに書き込むか？たとえば、住所には、country、region、city、streetの4つのデータフィールドが必要です。

2.3データフィールドと呼ばれる新しいセクションを追加したとしましょう2.3.1アドレスというサブセクションが含まれており、その中に必要なすべてのフィールドがリストされています。機能要件へのデータフィールドを追加して、ドキュメントの一貫性と理解性を高めますか？

documentationrequirementsrequirements-managementsystems-analysis
2
user623949

最初に、質問を標準に合わせるために曖昧さをなくします。もちろん、会社のニーズと標準に合わせてドキュメントを呼び出すこともできます。

  • ビジネス要件 は、ビジネスプロセス、ビジネスの役割と責任、ビジネスルールなど、ビジネスの観点からのビジネスニーズを原則的に説明する必要があります。ビジネス情報（「住所」、「製品リファレンス」）を参照する場合がありますが、ソフトウェアのフィールドを参照することはできません。

  • あなたが説明する内容は、国際標準（現在 ISO 29148 、以前はIEEE 830）が ソフトウェア要件仕様（SRS）と呼ぶものに非常に近い 。

データ要件はソフトウェア要件であるため、SRSの一部である必要があります。 IEEE 830の1998バージョンは、「論理データベース要件」（エンティティの説明を含む）を参照し、機能の説明（機能要件+ドキュメントの使用例）の後に配置します。

ユースケースの後にデータの説明を配置することの利点は、詳細を失うことなく、ユースケースを高レベルの要件として維持することが推奨されることです。ユースケースはユーザーインターフェイスの詳細な説明ではないため、これは適切です。

しかし、その順序は規範的ではなく、最終的には、次の標準の推奨事項にすべて同意できます。

読みやすさを最大化するための要件の整理には、細心の注意を払う必要があります。

1
Christophe