Hi Bernard,

It all depends on a miriad of factors.  They are different if you have reasons to make them different.

I've generally seen all requirements document in the same Business Requirements Document (BRD).  However - at times there are business reasons why there are different.  In the case when the business requirement comem from the line of business and need to be baselined - it is a good idea to have those as a separate document.  In some organizations, functional requirements tend to be document by the technical design team (systems analysts) perhaps using use cases and those tend to lend themselves well to be in separate documents.

If you have a small team, working on small projects, a combined document may work.

One of the advantages of having multiple documents is the ability of different team members working on different documents/areas at the same time. 

Before you create the template(s), you need to gather the requirements for "why" you need this template.  Of course - you're in trouble because you don't have a template to capture your requirements. Oops! 

Seriously - you need to understand why you're doing this and how these artifacts will be used.   Are there any requirements rearding traceability in which case you might want to use a spreadsheet to track requirements or, better yet, an off the shelf requirements management tool.  If the goal is to have requirements be signed-off by the business - is there a need to present them in a form other than text (such as UI Prototypes)? 

etc.  You need to apply business analysis techniques in order to arrive at the answer yourself since there is no off-the-shelf one-size-fits-all solution.

Hope this makes sense!

- Adrian

Hi All,

   The same confusion was with me once, but I am convinced with what is stated above that my thinking was perhaps correct. I can explain it in few sentences as;

    A requirement doc is something, which is a collection of statement that demand of something (process, system or change), that often highlights some needs or some way to accomplish certain task/goal. To a layman it will appear as a plain English statement of business writing asking for solution. These statements are often high level functional requirement as stated by client which will be further broken down into functional requirements according to the solution perceived. For example a requirement statement can been seen in "Use Case Goal" heading while creating use case specification doc which is a methodology of writing functional spec doc while putting requirement statements in BRD's (Business requirement Specification).

Hope this also help in above context...............Any modification in this concept will be welcomed!

Regard,

Kumar Rohit