views:

47

answers:

2

I have an abstract that includes the following (please feel free to change the formatting :

1. purpose
2. simulation models used
3. libraries, SDKs, and APIs used
4. major components of application in terms of the    
   windowing blocks, and types of user controls and settings offered in 
   the application for simulation operation
5. methods of controlling the input coordinates for the simulation to execute 
   and generate an output

However, now I'm unaware of which sub-blocks I should work on next in terms of the documentation. As someone who doesn't know what my application does, what do you think would be more useful to describe in further detail? Thanks in advance for suggestions.

+1  A: 

For a normal user be specific on purpose and settings in the application.

For a developer give more importance on libraries, SDKs and APIs used.

Also take a look at this SO question

How do you approach documentation (external, not in-code documentation)?

rahul
Knowing this information, if I'm writing it for both normal user and developer, should I write separate manuals for each?
stanigator
Better to write them separately.
rahul
+1  A: 

You've got at least two documents there. Users of the software care about 1, 2 and 5. Developers are interested in 3. Not sure whether 4 is implementation or UI.

I would strongly recommend first preparing the User Guide. What can I do with this software, how do I drive it? You may even find that you need to subdivied that separating the detailed Reference from the Guide.

The internal stuff can come later.

djna
Thanks for the recommendation. I think I would keep 1 for both documentations as the user and the developer would be interested in why they are using or making the software.
stanigator
yes that makes sense. The fundamental point I'm making is to focus on the needs of the reader at the point they are reading the document. As enthusiastic software folks it's all too easy for us to drop into implementation details, the "how", when the reader wants to know "what and why".
djna