On Requirements
Roger Cauvin has some really interesting points on “Requirements and Apple’s “Time Machine”:”
CRUD requirements assume that users actually want to create, update, and delete information. But users don’t really want to create, update, and delete information. They want to access it to achieve some larger goal. Enabling the user to create, update, and delete information is one way to manage and make the information available, but it is by no means a utopian design.
Remember Gmail and the ‘delete’ button? Why on Earth would anyone want to delete e-mail? Notwithstanding some privacy concerns and obsessive-compulsive issues, what users really want is to be able to find, read, and respond to messages of interest. Deleting e-mail helps eliminate clutter that can interfere with these goals, but it’s not an end in itself. Thus it is not a requirement.
Similarly, conventional requirements documentation for a backup service would include specifications such as:
The system shall enable the user to backup files.
..
Yet these specifications and use cases do not represent real requirements. No user wants to backup files. They want to be able to restore files. Backing up the files is an unfortunate design necessity to which the user would prefer to be completely oblivious.
So first, this is great. (I’m tempted to talk about writing requirements, or software testing in the same vein: No one wants to do them, but we do them.*) Still, there was something wrong, and I wasn’t quite comfortable with what Cauvin wrote. I’ve held a job in which creating backups seemed important. It absorbed lots of my time. Really, the important bit was verifying the backups existed, were safely offsite, and could be restored.
No, actually the problem is that there are times when being oblivious to what your system is doing is wrong. There are times when I want to destroy data. They may be rare, but let’s take my 8 year old tax docs. I’d like to destroy them. They serve only to carry risk. Last I checked, TurboTax didn’t allow me to not enter a SSN. So if I used TurboTax, I’d have this file which I wanted to destroy. Now, how does Secure Empty Trash interact with Time Machine? Do I have t remember the feature exists, and then search out old revisions of the file?
Or at gmail. An old boss recently mailed me a grant proposal. (Wrong Adam.) I deleted it without reading the proposal. I bet it was really juicy stuff, and I’m glad my email wasn’t going through gmail where I can’t delete the email.
So, overall, I agree. The CRUD method of thinking about requirements is a useful exercise in completeness of functional specification. It’s not a good requirements method. At the same time, feature interaction can lead to surprising places.
* That’s not quite true, I know people who test things for the sheer joy of seeing how they’re made. Lots of them are vulnerability researchers, some are other forms of testers.
Cauvin link via Anton Chuvakin, sign photo from “Bilder aus Swieqi.”
[Update: Don’t miss the insightful comment about ways to address transparent backup and security from Simson Garfinkel.]
I’m looking forward to seeing what Apple has done. I’ve been working on this problem since 2003, and discuss the conflict between the desire to have hard delete and the desire to have recovery against accidental deletion in my PhD thesis. One idea is to have the backups encrypted and to throw away a bit of the key every day, so that the backups become harder and harder to recover after they are “deleted.” Another idea is to have what I call a “delayed unrecoverable action” where the deletion happens a day or two after the command is given.
http://www.simson.net/thesis/ if anybody is interested in reading it.
> Thus it is not a requirement.
This is a bit strong. A requirement can be based on other requirements. It can be derivative and indeed all requirements are derivative at some level. Someone who puts together the requirements always takes *some* responsibility in making design decisions; where they seem “obvious” and represent our best understanding.
In this sense, we are better off saying that behind the current set of requirements are other, deeper, higher level requirements. The current set represent our best stab at moving them towards technical implementation.
Simson, … interesting point to characterise it as a recovery under some circumstances but not all.
In trying to make chat traffic safe, I was struck by the complete contrast of those who want to keep all messages forever and those that want to treat chat as “casual conversations.” Both side have a view that is logical.
It seemed at the time that the best way to deal with this was to set up a contractual agreement on each session that expressed the recovery and availability conditions. E.g., colours or buttons that indicate “casual” versus “recorded.” Getting the choice to the two parties seems to be fairer than hiding the choice from one of the parties.
Thanks for your thoughts, Adam. You wrote:
There are times when I want to destroy data. They may be rare, but let’s take my 8 year old tax docs. I’d like to destroy them.
I like this example. It’s actually very similar to the Gmail delete issue. The question to ask is, why do you want to destory your 8 year old tax documents?
Just as with the Gmail delete button, it’s most likely a privacy issue. It does you no harm to be able to access the information; any problems stem from others being able to access it and use it against you.
The real requirement, therefore, is a nonfunctional privacy constraint. It may very well be that enabling the user to destroy backups or parts of backups is the most practical implementation. But it’s not a requirement. Ideally, the user is still insulated to the extent possible from having to be aware of the backup mechanism.