Business Requirements Document as PBI

Going to start with the statement that there are no such thing as best practices but there are a whole lot of good ideas that we can share.  The best practice is what benefits the teams using your Product Backlog Items(PBIs).  Have you asked them what information is beneficial to them and how they would like to see it organized?  If not, do that and then come back here and tell us what they said.  That way we can add another good idea to our knowledge base. 

Now, I'll share one of my good ideas.  Include the screen fields and their properties where it makes the most sense in the narrative you have.  How does that information help to complete the description of your PBI in a way that will be most useful to the people that will be addressing the need? Where is that information most relevant? In my experience it has been included in the design and not as part of the PBI.  The PBI describes the situation that needs to be addressed in order to provide value. What information is contained within it is determined through use of the items.  My teams usually have that kind of technical detail external to the problem statement unless it is absolutely necessary such as the case of a public API where those details can be requirements. Acceptance criteria will usually state something like "all fields are implemented to follow the communicated requirements".  

I have created a requirements document from the PBI which I have created in TFS

Omar, I have several questions based on your post:

1. Why are you creating similar content in multiple locations?   
2. Why doesn't your Product Backlog suffice as a sole repository for product requirements?   
3. Who is the audience/consumer for the requirements document?

I have created a requirements document from the PBI which I have created in TFS

Why? How will that help emergence and bolster the creativity of the team?

Thank you all for your help. Maybe I could not explain my question in a proper way!! mmm....

Actually we have done the development and all developers were satisfied. Now we are at the UAT stage and the customer insisting us to create a BRD, So I have created a document and added each PBI in a separate table that contains the ID, description, and acceptance criteria. Since not all business users care about the field mapping or let say they care more about the requirements, I did not add them to the acceptance criteria. I have created an appendix for them and referred to them from the acceptance criteria. So if you were me, will you do the same with the field mapping?

Regarding the second question, I will explain by example:

Business Rule:  Customer must have an Email Address.

Business Requirement:  Ability for bank staff to send and receive emails to the customer.

I explain that like this in the acceptance criteria:

 - Bank staff can send and receive emails from the customer. (See BR-001)

I will create the following table in the acceptance criteria:

ID                            Description

BR-001                   Customer must have an Email Address

how do you explain that???

Omar, what does your Definition of Done (DoD) look like?   Is completion of UAT part of it?

Tim, Yes the UAT is part of DoD for a release. And the PBI is done when it is content is developed and tested and shippable

If you're about to perform a UAT and the customer is asking for a requirements document, that leads to a couple of questions.

What type of product are you building? When building a SAAS software product, for example, I would not create a business requirements document for any customer. Instead, I would provide a specification of the system and expect that the customer maintains their own requirements for their intended use. I would also provide guidance with respect to aligning the customer's requirements with the specification and ensuring that they have the necessary capability to perform a UAT. If I were building a custom product, however, there would be more of a burden on me to ensure more coverage of all of the specific customer's requirements.

Was the need for a BRD specified earlier, perhaps as a contractual obligation? UAT happens late, after at least a portion of the product is built. It usually happens after design, integration, and verification activities. An understanding of the requirements is necessary in order to carry out those activities. It's wasteful, in the lean sense, to go through and reformulate the requirements from the format that you used to build the system to a different format to satisfy one customer's needs. If there was an expected deliverable, that should have been communicated much earlier. It would either be me for missing the fact that it was required or the customer would have to accept the cost (both in terms of money and time) to do the work to produce it).

If it ends up where you need to create this document, the right thing to do would be to work with the stakeholders to make sure it meets their needs. If the document doesn't meet their needs or expectations, you can likely expect rework. A displeased customer is also one that may not be a repeat customer. No one other than a consumer of the document can tell you how to best put it together in order for them to find it usable and useful.