are you talking about a spec sheet kind of situation?
what we do when a new system is asked to be developed (keep in mind it is a smaller company)
we talk to the key people that are going to use the system. get feedback, ideas, and so forth and write them down on a spec sheet. The spec sheet will say what the application is going to accept, what it is going to manipulate, and what it is going to return. if everyone agrees on the final spec, all spec additions are halted until the BETA is available. a group of testers then play with the application, storing the bugs in a bug database and writing ideas or improvements on spec sheet 2. this goes on for a few weeks or a month etc. once the spec sheet 2 and bugs are accounted for, all spec and bug additions are halted and the program is changed and bugs are fixed. application is then deployed. all additions or subtractions are added to a spec 3 which is used for the version 2 of the product
The title of your thread and the body of your question don't really match. If your boss is asking you to create a ROLLOUT STRATEGY then he's asking for a plan of how to go about deploying your system when it's done, not a specification of what the system is supposed to do prior to writing it. Ask your boss for a clarification before you waste any time on further research.
If he's really asking for the latter, then what jlego says is a good approach for a small application. Verify with your boss and continue doing that.
she gave me a list of the things i need to document
and the first item on the list is the Roll out strategy follow by project planning.
as i said i'm just new in programming and i really don't know what to do.
i already clarify it to her because i made a research about roll out strategy and i find the answer now i'm starting to write the project plan of the system that were going to develop.
No apology necessary...but I think you can take the whole scenario as a valuable lesson... NEVER TAKE ANYTHING FOR GRANTED. This is hugely important as an IT professional. If you don't understand something, keep asking questions until you do, and the person you ask the question of agrees that you understand. More mistakes are made by "assumptions" that are not verified than probably any other method. And, for documentation, be sure you review it periodically with the customer and your boss so you don't go off in the wrong direction and have to re-do a bunch of work. Well done, and keep doing what you're doing...and you probably impressed your boss as well.