2

How and where to describe data fields and their behavior in business requirements document?

I have business requirements document setup this way:


1.4 General Requirements:

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 User Characteristics:

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  

3.2 Functional Requirements:

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 Use Cases :

3.3.1 Entering the address :

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

Where to write the required data fields to be entered by the users? for example address should have four data fields country,region,city,street

Let's say I added new section called 2.3 Data fields it contained sub-section called 2.3.1 address and within that I listed all the required fields, in that context how to link the data fields to the Functional Requirements so the document can be consistent and understandable?

  • Determining a data model isn't part of a requirement description. I'd recommend to leave that out at such stage. – πάντα ῥεῖ Oct 6 at 10:37
  • I'm torn of @πάνταῥεῖ's comment. In many cases, yes, I'd agree that specific fields is rather detailed, perhaps too detailed for requirements in many situations. But it can be useful if you need to maintain interoperability with other systems, are implementing standard forms, or perhaps for compliance purposes. Have you looked into data dictionaries any some specific examples of them? – Thomas Owens Oct 6 at 12:43
1

Let's first disambiguate for aligning the question with the standards, being understood that you may of course call your document as suits the needs and the standards of your company:

  • Business requirements should in principle describe business needs from a business point of view, such as business processes, business roles and responsibilities, and business rules. It may refer to business information ("address", "product reference") but not to fields of the software.

  • The content that you describe is very close to what the international standards (currently ISO 29148, formerly IEEE 830) calls a Software Requirement Specification (SRS).

Data requirements are software requirements and should therefore be part of the SRS. The 1998 version of IEEE 830 refers to the "Logical database requirements" (including description of the entities) and places them after the description of the functions (functional requirements + use cases in your document).

The advantage of placing the data description after the use case, is that it encourages to keep use-cases as high level requirements without going lost in the details. This is good, because use cases are not meant to be a detailed description of the user interface.

But the order is not normative and ultimately, we can all agree with the following recommendation of the standard:

Careful attention should be given to organizing the requirements to maximize readability.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.