I stumbled upon a puzzle. Please help me solve it.
It strikes me as odd, but there might be situations where a provider fails (i.e. the system will not be accepted by the customer), because he delivered MORE than was specified. I'm not talking about the bells and whistles here, that (only) wasted resources.
Imagine a hard- or software product that is designed to serve more purposes than required by the single customer. Any COTS product and any product line component should fit this definition.
Which kind of requirements could be exceeded, scalar and/or binary requirements? I think scalar requirements (anything you can measure on some scale) cannot be exceeded, if they do not constrain the required target on the scale on two sides. Haven't seen that (It's always "X or better", e.g. 10.000 transactions per second or more.
Even if it was constraint on two sides, this simply would mean a defect.
But there can be a surplus of binary qualities, i.e. functions. A surplus function can affect other functions and/or scalar qualities, I think.
Say, as a quite obvious example, the system sports a sorting function which was not required. A complex set of data can be sorted, and sorting may take some time. A user can trigger the function that was not required.
- This might derail overall system availablity (resonse time), a user required quality.
- It might open a security hole.
- It might affect data integrity, if some neighboring system does not expect the data to be sorted THAT way.
- It might change the output of another function, that was required, and that does not expect the data to be sorted THAT way.
(First fantasy flush ends here.)
So, if you find a surplus function in a system, what do you do? Call it a defect and refuse to accept the system?
Eager for your comments!
Thursday, November 27, 2008
Subscribe to:
Post Comments (Atom)
_BW_besser.jpg)
Posts
9 comments:
How about a situation where the developer is providing something to another party who intends to sell it to a third party.
Could it be that the middle man, perhaps with a monopoly position, might have some cunning plan about selling upgrades and endless support, and finds a product that exceeds the initially stated requirements an inconvenience.
Or what if the middle man's business is selling hardware and the fantastically economical performance of the software means that the high priced super-system the middle man wanted to sell simply won't be needed by the ultimate customer.
The middle man's requirements probably didn't state that something too good would be a problem for fear of this being seen by the ultimate customer.
I am not very worried. BUt of course it is not good for performance, security, maintenance etc to have an excess.!
With too many functions, one or more quality aspects of a system will suffer.
Too many functions often have a negative effect on understandabilty or intuitive usability, like in this article about featuritis. Or, as you mentioned already, the performance suffers.
Practically always, the architecture of the software gets more complex with every added function, resulting in a decreased mainainability and higher costs of changes.
The first thing I would do is requesting a test set and a test protcol for that function from the provider.
If there is no test set, it is definitly a defect.
If there is test set, it depends...
@all so far: Thanks for your comments!
3 answers from other sources (Roland, David and Sven, again. Thank you!):
1) if the additional features break some other requirements, like I suggested in my scenario, then the case is clear: surplus features are defects
2a) this brings up the question of the completeness of the spec as a whole. Only stated requirements lead to a failed tests.
2b) however, if we don't have a complete spec (as almost always), then, at least currently, any additional functions are irrelevant or unaffordable, increase complexity, decrease reliability, and increase lifecycle cost. The additional functionality should be removed and removal verified before system acceptance
2c and 3) the additional features can be assessed by formal change management. hence, they have a chance to loose their 'extra' status, by consious decision.
A feature which breaks a (previously unnoticed) stakeholder's interest in having his IP secured; e.g. an "export database" function which would enable a competitor to extract valuable engineering information.
Or a feature which would expose the stakeholder's performance in an unwanted way; e.g. a function in a generic planning software which would enable the user to directly compare the stakeholder's product to a competitor's product in detail.
Forgot to add: I would regard these as defects if the stakeholder who pays me does.
I'd add another category - capabilities that aren't aligned with the goals of the business. Often a little feature gets added because it's easy to do, but it's not aligned with the goals of the project. Leaving it in puts you at risk because customers will likely ask you to expand upon the functionality once you've exposed it to them, which diverts resources away from the your states goals.
Thank you all for your comments. I decided to write about the phenomenon in the future and hope I can come back to you to work on it.
Has anybody ever experienced really bad consequences from excess functionality?
You know, the scenarios presented here (including mine) seem to be hypothetical.
Post a Comment