I feel like the feature creep comes from trying to solve too many
marginal problems. This suggests to me that the requirements document
isn't complete. It doesn't address the issues that are leading to this
complexity. Instead, it mostly deals with issues that are entirely
outside the scope of the model. I have tried to get these issues into
the requirements document, but have not succeeded. I believe that the
requirements document needs to state the support or lack of support for
scenarios like fan-in, fan-out, attribute defaulting and other issues
that are adding to the model complexity.
Let me illustrate where part of the problem lies. Fan-in has been a
hot issue in email messages today. It exists for a world where the
user cannot control feature selection directly through some client
interface and instead controls feature selection via printer
selection. Perhaps, we should assume that clients can select printer
features directly. The requirements document is silent on this whole
issue. Fan-in also exists to restrict access to some features by some
users. But I wonder if this requirement is also too marginal to deal
with for version 1.0.
Fan-in is easy to address at the end-user level -- we just pretend they
are separate printers. But at the administrative level, they will
become a nightmare. For example, if an administrator changes the value
of media in Printer A, does it also affect Printer B if both A and B
fan-in to output device X. The answer should be yes because the paper
is really in X and both A and B are really just views of X. But if B is
intended to offer a restricted view of X, then perhaps the answer is no
because B should not have access to whatever was changed.
Bob Herriot