|
Usually I'll use a phrase like "Request For Features" or "User Requirements", depending on classification/impact on the project. If for instance you're doing your pre-design phase assessment a feature could be delayed to/dealt with in a next release, but requirements deal with necessities which define the scope (or not) of a project.
A well defined project framework for me drives all parameters within the project (crew, client, products, tasks, skills, materials, quality, documentation, testing etc, etc) from 3 base parameters: money, time and resources.
The docs are the framework that bind it all together, no need to go overboard on methodologies like PRINCE2, Rational's Unified Process etc, just use common sense and define it as you would need it.
Why? Because the basis, most important part, is to make sure you *understand* what your client wants and your client understands and agrees with what, how, when and against which costs you're going to deliver it.
If you would want more formal info on project mgmnt docs and processes I could provide you with some, but this really ain't the forum for it, c'est un forum pour Linux, je comprends...
HTH somehow.
|
French/English : Cahier des Charges or User Report before Development
