Hi Kohei,
Kohei Yoshida schrieb:
On 10/27/06, Nikolai Pretzell <[EMAIL PROTECTED]> wrote:
Kohei Yoshida schrieb:
> In a not-so-ideal world, things don't always go as planned.
> Requirements grow organically over the development life cycle of that
> feature, but the spec document may not always get updated.
There is a clear rule in the current spec process: Spec and code have to
be in sync exactly when the CWS is set to the state "ready for QA". It
may be earlier but that is not required. It must not be later.
Again, you just stated the current rule, but is it actually working as
expected? ;-)
Not always. But is that a reason not to try?
> Ideally, the developer should also be responsible for updating the
> spec document to ensure that it keeps up with the requirement change
> over the development cycle.
The developer not only should be, but is responsible for this.
Again, that's the current rule, and the point of this thread, as far
as I understand, is to question such rule.
And, say,
one developer with good will volunteers to implement that feature, and
is told that it is the developer's responsibility to make sure that
the spec is kept in sync with the implementation.
> A month later,
> there is a meeting (or discussion) between developers and
> non-developers and a conclusion is reached to change one or two
> aspects of that feature. In this particular scenario, I don't think
> it's reasonable to assign the task of updating the spec to the
> implementor alone.
"Responsible" does not mean he has to do the actual work. But the
developer is the one who after all sets a task to fixed. He cannot do
this, if the spec is not in sync, because either the implementation is
buggy or the spec. In the latter case the QA cannot test (it verifies
against the spec, what else?). And a feature that cannot be verified is
not yet done.
Who actually does the change (in spec or code) is an internal problem of
the I-team and they should come to a consensus within that team, IMO.
Actually, every feature that changes behaviour needs a spec.
Or, as Thorsten wrote, the already existing spec may need to be updated.
How else
should the QA be able to test the new feature? Against what should it do
that testing?
IMHO a feature description, and in case of ambiguities, an email or
two to the developers asking for clarification should suffice for most
cases (e.g. feature A introduce a new check box. When it's checked,
it does X, when it's not checked, it does Y The check box should have
the label that reads "Enable XYZ").
A feature description is a spec, isn't it? Except of that the contents
of the clarifying emails need to be transfered into it, too, because
else that information is lost (for the QA for example).
Why we use a template is only, because it is easy to forget things, for
example: Did I think about all error conditions? The template tries to
reduce the chance of forgetting.
Nikolai
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
