design document before starting coding

gudii9
gudii9 used Ask the Experts™
on
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
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Chinmay PatelChief Technology Ninja
Distinguished Expert 2018

Commented:
Please refer to this link as a starting point and evolve the document as per your actual requirements: http://blogs.microsoft.co.il/gadib/2010/10/11/technical-design-document-template/

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.

Author

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 Ninja
Distinguished Expert 2018

Commented:
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.

Commented:
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.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial