It would be nice to have a cookbook for all this, and some folks think methods like RUP or books are just that. But you have to customize what you make to meet the needs of your own team. I pull this out about once a week:
______ reads ______ to learn _______ so they can ______
"Developers read the design to learn class hierarchies so they can code them"
"Enterprise architects read the architecture document to learn what protocols the system uses so they can approve them or recommend changes"
Statements like this might tell you that you need a document. Or you might quickly spot better ways to communicate - presentation, code reviews, face to face meeting, etc.
See Scott Ambler's web sites - AgileModeling.com comes to mind - for some down to earth advice on when to make documents and models and when something else might be better.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Or main artifacts are a release plan (a simple spreadsheet), user stories (on index cards) and the code with unit tests. We also *should* have acceptance tests (working on it). Everyting else is very much dependent on the situation - recently we are doing more and more quick design sessions on the white board, often some UML mixed with freeform elements as needed.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus