Apple's Leopard OS will include a service called "Time Machine". It backs up users' files automatically and transparently so that users can restore their machine to any previous state.
The remarkable aspect of this backup service is its ease of use. Consequently, it is interesting to explore it from a requirements standpoint.
Remember why CRUD is crud? 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:
Or a use case such as:
A product manager who represents these design specifications as requirements is doing the company a disservice. It constrains product designers' creativity. Instead of thinking creatively about how they can completely shield the user from the burden of backing up files, they assume that the user must be saddled with this task, and any design work merely tinkers around the edges of making it easy.
The remarkable aspect of this backup service is its ease of use. Consequently, it is interesting to explore it from a requirements standpoint.
Remember why CRUD is crud? 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.
Create BackupYet these specifications and use cases do not represent real requirements. No user wants to backup files. They want to be able to restore files (or, better yet, just have their files available). Backing up the files is an unfortunate design necessity to which the user would prefer to be completely oblivious.
A product manager who represents these design specifications as requirements is doing the company a disservice. It constrains product designers' creativity. Instead of thinking creatively about how they can completely shield the user from the burden of backing up files, they assume that the user must be saddled with this task, and any design work merely tinkers around the edges of making it easy.
Comments