design document before starting coding

How to prepare design document for a project enhancement without starting the coding work.

For the sequence and flow etc diagrams of the design document i need the class names, method names etc right even before starting the coding work.
any good links and references and tutorials, videos around this
please advise
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Chinmay PatelChief Technology NinjaCommented:
Please refer to this link as a starting point and evolve the document as per your actual requirements:

I have seen many complex ones but if you are just starting out, I recommend this one as a good starting point. And NO it is other way around in most organizations when you are an architect (and if you do your job right then), what you write in class names, method names and how you define features - will dictate how things are coded.
gudii9Author Commented:
can we write the document without touching single line of code? is that is possible?
what are free best open source tools for this purpose?
Chinmay PatelChief Technology NinjaCommented:
As I said in my first comment. It is the norm or better, the  right way of doing things. It is called Technical Design Document and most of the  teams follow the same pattern - especially when they follow waterfall development methodology. And as this is juts a document you can simply start with a document template and change it based on your requirements. There are many such templates available out there. The one I mentioned outlines a table of contents for such a template.
Owen RubinConsultantCommented:
Chinmay, that is a great template, thank you.
Gudii9, that template is a good start, but your particular project might not need all of. You will need to decide.
But before writing any code, you should create (this is a bit oversimplified but you will get the idea):
0. Often there may be a Marketing Requirements Document that gives a high view of what problem or solution they company is trying to answer by the project. Not necessary, but very useful.
1,  A docuement that spells out exactly what it is you are building. That is how you will know when you are done. It should specify the full set of features, inputs, outputs, standards (if any), open source code that may be used (make sure to get management OK on that.) and a basic concept for the look and feel with sketches of the UX. I would call that an Engineering Requirements Document  Think of that document as something you could hand to a sofwatre engineer and they would understand what you are trying to build.
2). If more than one person working on the project, the project lead needs to create a Technical Desgn Document like pointed out above, just skip that parts that don’t apple,to your project.
3. A document that assigns parts to each programmer.
3). Each team member should know what parts they are building, and before coding, should creat design documents that specify what each piece of code will do, what it accepts as inputs, what it returns as outputs, and anything external to itself that it may change, objects required, methods or functions it needs, method or functions that depend on this code, etc etc. Be detailed, so that any good programmer could take these documents and generate the correct code needed. These should be reviewed by the entire team, and put somewhere where everyone can read them. That way, you can prototype your calling routines to someone else’s code even before that code may be ready. Note that these small documents can be placed as comments inside each method or function as an aid to using the code.
4). While I typically manage agile teams, I always have a high level schedule created to drive the project. I like Microsoft Project for this because it gives a decent view of how all the code will come together, it can be updated as needed, and should you the critical path (dependencies) throughout the project.

These are good places to start. There are more documentation that is needed, like testing specifications, user instructions, etc, but that can come later.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.