What is the difference between SRS, RA, FRS, BRS documents?

Question

I know I should ask this question in "Theoretical Computer Science" stack community. But as the name suggests, that community would provide me answer which is everywhere on internet-Theoretical. But I asked here because I want the following answers:

• I want practical use cases and tangible difference between these documents in context of software development.
• Is there any need or reference of documentations during software testing?
• What factors should be added to these documents for testing and software quality?
• Which document out of all serves best to assure software quality and helps in testing?

Full Forms for reference:

SRS: Software Requirement Specificaltion/Study.

BRS: Business Requirement Specification/Study.

RA: Requirement Analysis.

FRS: Functional Requirement Specification/Study.

Answer 1

The short-short answer - it depends.

The longer version

Despite the names and theoretical definitions, the differences in practice in my experience come down to how a particular organization chooses to use them. What one company calls a Business Requirements Document, another will call a Functional Specification. I've seen (and worked with) Use Case documents that cover business requirements, internal software requirements, technical specifications, functional specifications, use case information, and test specifications. It works for that organization.

My recommendation is that you learn the theoretical definitions, but expect the real-world usage to vary; and work with whatever definition(s) your employer chooses to use. They will have a reason for doing things the way they do, which may be simply that it worked for them at some point in the past and hasn't become painful enough to change.

Answer 2

It always boils down to the question of how much documentation do we actually need and when does it start to become waste. Waste is documentation no one ever reads or uses. I think a lot of this documentation waste is created in the world. Its our task to minimize it :)

So to answers your last question

Which document out of all serves best to assure software quality and helps in testing?

I would answer none of the above.

In some industries a documented audit-trail for security, privacy or other reasons might be mandatory, but as an Agilist I prefer:

Working software over comprehensive documentation

My teams documents as much as they really need to build high quality software. Preferable in an easy to access and update-able format like a good wiki. What this documentation actually contains depends per team and their needs.

Tests are preferable documented in a form that they can be automated and are included near the source code as unit-tests, but also automated integration and functional tests.

When issues do arise we do a Root-Cause Analysis and update or extend our (test) documentation or process to prevent similar situations in the future.