CRUD (Create, Retrieve, Update, Delete) is an acronym used to refer to a set of mundane, important, and indirect (if not implicit) requirements or use cases. To create a report on orders, you have to first create the orders and retrieve them. Further, the ability to update (edit) and delete the orders is probably also important. Another description of the CRUD pattern is here.
When we write use cases, we don’t include trivial steps. For example, the precondition for a formal use case could include the user being logged in and authenticated with the ability to access the relevant information. We would not document logging in and authentication as part of the “create a report” use case. It is (nearly) redundant information, because it is (or should be) generally understood that the user must be logged in, if the system has an ACL. The user must also be using a computer, and it must be turned on.
The same concept can be applied to CRUDdy use cases – don’t document them (as high level use cases). Roger Cauvin writes two posts on this topic on his blog:
Cauvin: CRUD is Crud
Cauvin: Alternative to CRUD (and Roger and I have a good discussion in the comments on this one).
Ultimately projects will require you to do some kind of documentation of CRUD, the question is where in the process, and where in the artifacts the CRUD should be. Some approaches treat these as system use cases because they aren’t directly linked to generating value. Other approaches leave the CRUD to the implementation team.
It’s hard to imagine Shakespeare’s Hamlet without Yorick’s skull – but the ROI comes from the idea, not the chosen implementation.
Imagine Shakespeare writing Hamlet to conform to a requirements document (written by someone else). If the requirements had included a reference to Yorick’s skull, they would have been specifying implementation – and that’s bad. A good requirement would have been “convince audience that Hamlet is aware of the frailty of life”. It is up to the writer (developer) to come up with the jester, his skull, and a dramatic speech (design) as a way to convince the audience (requirement).
For Hamlet to be great, it needs both the great requirement (the idea) and the design (it’s chosen execution) to be great. A Bob Newhart conversation with a skull wouldn’t have achieved the ultimate goal, and a hastily designed “Yo! Horatio, we’re all gonna be worm food.” would be equally miserable.
Now imagine Shakespeare had written the requirements and been dependant upon someone else to write the play. It would have been torturously hard for him to not write Yorick’s skull into the spec once he had the idea to do it that way. But Shakespeare fundamentally would have had to rely on his writer (dev team) to come up with the implementation ideas, and not bake them into the spec. Baking the implementation into the spec is really just another form of micro-management
A product manager has to do the same thing, and resist the urge to write the skull into the spec.
Latest Articles
Comments on all Articles
