zaineb wrote  Whatis the difference between a BRD and a FSD. ...Zaineb

Well, they are both documents... seriously, despite all the tools being pushed out there, most of these types of artifacts are still being done in Word or, worse yet, Excel.

Where I work these days, the BRD is the home of the "The system must" statements", while everything else that backs those up goes in the Functional Spec, like process descriptions.; the Functional Spec also contains descriptions of how outside actors (people or other systems) interact with the proposed system, bit does not specify "how". In this structure, the two are parallel and truly supporting documents; it is not the case where the Requirements come first and then the Functional Spec. In fact, major pieces of the Functional Spec need to be drafted before you can really define any "system must|" statements.

...but that's where I am working now, a client site from which I will eventually move on, so I will have to see what I find at the next client. In the past, I have seen everything that could be in a BRD and SFD in one document, or the interaction description being delayed to a design artifact. It really is just a matter of preferred packaging and communication, so if one way of doing it is working for a company, there is no need to change it.

zaineb wrote Thank You so much for the reply. It was very helpful. I am training to be a Business Analyst and hence I havent seen or work with  these documents in reality. From what I could gather ,the BRD contains the actual reqirements,stake holder list,estimated cost ,resouces ,team member rolesetc  and the FSD contains information which describes the realization of these requirements suc as usecase list, use case desciption, use case diagrams,acrivity dagrams etc... Please correct me if I am wrong. Thank you once again. zaineb

You pretty much have it.  The BRD contains the requirements or "what" the system must do.  Often it will also state "why" or the business rationale for the requirements.  The Functional Specification Document states more of the "how" the system must accomplish the requirements. 

Ideally, the majority of what is conveyed in the FSD will be in logical terms so that you aren't actually making development type design decisions, but inevitably some things have to be explained in physical terms.  The UI for instance.  You need to give the UI layout and requriements to the development team.