Writing Requirements Document is a *.Pdf, *.Doc, *.Docs, *.Xml file describes what the your client needs from you "An Application" including but not limited to (Application Title, Purpose, Algorithms procedures and conditions, Notes and restrictions, Comments) these were the most famous requirements and your job as a programmer is to study well these points and design your applications according to it. Another way is to write it for your client if required, sometimes clients need to understand what you've done as a programmer, maybe they will hire some else in the future when you are not available.

This is different from VB .Net Documentations you won't be needing codes or anything, everything depends one the client's request or who ever requests it from you, as a programmer asked to provide this document, honesty is a must, you need to provide the client with everything, starting your logic to deploying methods and you shall accept to do it or not, it is controversial subject.

In the other hand 90% or Requirements Docs are provided by the client or requested by the contractor (Programmer) to ensure that his work (Application) will meet the client's demands to the fullest or at least almost the fullest.

The Requirements Doc. always/must be provided before the application's beginning by the client's to the programmer or along with the application by the programmer to the client.

Writing Event Planning Document is the same as the Requirements Doc. format file.

It describes what is going on the application's interface UI, specifically describes what happens (The event) when the client's user will click on something on your form or the form_load event itself.

For example, if you have a button in your applicaiotn you will provide its name and the events that are bound to it (Click, DBLClick,. .... etc) and what happens when the client's perform an event of those above, most Planning Events Docs are tables design.

It is provided when requested and as the Requirements Doc. it is a controversial point of view between the prgrammer and the client, you may or you may not provide it if requested.

The VB .Net Event Planning Doc. always/must be provided if agreed by your side as a programmer (contractor), you will describe each and every control's event triggers in your application to the client.

The VB .Net Event Planning Doc. always provided to the client along with application or after, and may be designed and logically configuered by the programmer before writing the codes or designing the UI (User Interface), it should give a full understanding description to the methods used in desgining the User Interface and events related to each control.

Writing Use Case Definition is the same as the Requirements Doc. and the Event Planning Doc.'s format file.

It describes the logic of/in the application you provide as a programmer to the client if requested. But this time it is a 50\50 chances, means it could be requested by the client or by you and also it should give you as a programmer the mean to reach the client's ideas about the application.

The Use Case Definition if requested by the programmer, means that the programmer is seeking the best image in the client's head and he wants to fully satisfies his client. If requested by the client means that the client already knows what he is seeking he is not just looking for a programmer, no! he is looking for a programmer to do this as he has in mind, maybe he already saw something and wants the exact same thing.

The Use Case Definition is more like terms to the programmer but also relieves him from over coding events that are not really needed ofcourse if asked by the client's side.

All of the 3 Documents ( Use Case Definition, equirements Doc and Event Planning Doc.) depends on the contract between you and the client.

I will show you how to do it in a small application project using VB .Net 2010 as if provided\requested by a client.