My previous post about the jid3rL feature checklist indirectly brings up a good point: when is a feature "complete"?

In relation to a standards specification like id3v2, you might say that a specific feature is complete when it implements its part of the spec.

Depending on the granularity/hierarchy of the feature, the completeness of it could also come into question. For example, the id3v2 tag header has an unsynchronization flag, meaning that the tag following the tag header is encoded to be unsynchronized. If I read the tag header and understand it - including the unsynchronization flag - am I then complete? Or is the "tag header" feature complete only when I support the unsynchronization feature itself? These dependencies are up to the project manager, but should be noted somewhere.

For that situation I've separated reading the tag header from support for the features dictated by the header. I might want to make this more explicit in the checklist.

Another issue you have to be concerned about is regressions, or functionality that once worked but has been broken. Once you indicate that a feature is "complete" in a document you'll probably want to maintain that completeness. It is not uncommon for dependencies between features to reveal themselves during development, and a dependency could break one complete feature while you're implementing another.

To ensure that this does not go unnoticed, a suite of regression tests should be used to confirm that completed features are still functioning as new features are added. It would also be easier to verify the effectiveness of this regression test suite if the tests were organized to correspond to the specification document. Then it's much easier for people to independently verify that the library functions properly.

Note that this level of "completeness" is often unique to libraries which implement specifications or projects following a more spec-driven waterfall software development style. Most software is dynamic, changing over time with changing user demands. If features are changing, dependencies between the features change and the definition of "complete" changes for those features.

This is when more concrete definitions of features for a specific version of the software are necessary, to leave little room open to interpretation and allow confirmation of completeness. The project manager will also need to have some way of keeping track of all of the testing results and project implementation status data; either a speadsheet or custom software.

The project manager then needs to ensure that the regression tests are up to date with the current state of "complete" for each feature as the project changes, otherwise the existing regression tests may given him a false sense of security that everything is OK. Code coverage analysis may be able to help identify weakly tested areas.