User talk:Rmyers/Village

I'm trying to make and demonstrate a more methodological development model here. The documents are a simplified version of a system that I had used at a previous employer. A lot of their documentation needs are unnecessary in this framework. For example, there is no need to satisfy stockholders and a board, there is no need for a formal sign-off procedure.

Also somethings that required a lot of bookkeeping in a formal office document environment, such as maintaining verification and validation links up the chain from design back down to requirements can be handled more simply in this case with hyperlinks.

The initial documents are:

• Product Description: a relatively brief discussion of what the idea is.

• Requirements: again terse and simple, this shouldn't be taking a major part of the development effort. What need to be done functionally and technically. Items here carry all the way up to implementation. Anything in design or implementation should be able to trace back here. Every thing here should be covered.

• High Level Design: This is more complex. This describes approaches of how to meet he requirements.

Some document types I'm not tackling right now are:

• Marketing doc: this gives a very high level view of the project. It covers 'Why', 'User Experience', 'Data' and 'Feature Function' from the 10,000 foot level. Good things but maybe this is the function of the project home page

• Project Charter: the internal 10,000 foot view and the necessary sign-offs to get the ball rolling. I'm not sure how much of this may be appropriate, and whether most of what is can't be put into a requirements doc.

• Breaking Requirements into Functional and Technical: More detailed than we need, I think.

• Detailed Design: not there yet. Module documentation strings?

Rmyers