|Keep It Simple, Stupid|
large team v's small team developmentby g00n (Hermit)
|on May 13, 2003 at 01:22 UTC ( #257620=note: print w/replies, xml )||Need Help??|
Does any know of any good ... web-sites that define these documents
A good site to see *real* as opposed to theoretical software engineering is www.joelonsoftware.com. There is enough good information for you to put aside the fact that Joel is an ex-microsofty ;)
What are functional and technical design specifications?
you can read more about specifications here (1. why, 2. what, 3. how, 4. tips) but this is where it gets a bit murky. Specifications mandated by traditional software engineering work well for large teams working on *certain types* of projects - (Joel was product manager for MS Excel embedded language specification - VBA) But these techniques are not as efficeint for small teams whose deliverables may not be shrink-wrapped.
what about anti-specifications?
Extreme programming on the other hand is a light weight development process that avoids some of the pitfalls of *documented specifications* especially where you are developing in small teams (1 >= member <= 30) where rapidly changing *business, technical and functional* requirements are the norm for a non shrink wrap market.
So ask yourself what type of development will I be working with (large, small). What type of product will I be releasing (throw-away, internal, embedded, shrink wrapped?). Then check out the various different approaches to specification requirements in the links above.
In Section Meditations