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.
#
Scott Sehlhorst said,
December 29, 2005 at 11:33 am · Edit
Here’s a link to an article at IBM’s developerWorks from Simon Johnston, talking about the tradeoffs between bottom-up and top-down approaches to defining SOA (service oriented architecture) requirements. He notes that bottom-up approaches tend to drive more CRUD.
http://www-128.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=352&entry=96749
#
A Muser said,
December 30, 2005 at 9:27 am · Edit
I’ve come to fundamentally disagree with the whole concept of requirements driven development. (Not with the concept that you need to figure out what you want to build before you build it, but with the concept that the gedanken experiment of a formal requirements document is the way to get there).
Your analogies using Shakespeare are apt – it is unlikely that Shakespeare, given either “end†of the requirements driven process (defning or implementation) could have produced the works of art he did.
To produce software works of art, an assembly line doesn’t work. If you can point to even a few examples of software works generally considered brilliant that were built this way, I would be surprised. And if you had to look hard, it makes my point – 99.9% of software is built this way, and it sucks.
#
Scott Sehlhorst said,
December 31, 2005 at 7:44 am · Edit
Muser – thanks for the comments.
99.9% of software is written by developers who place the keyboard squarely in front of the monitor and sit with good posture in chairs while they work.
We know from the body of ergonomics research that this is a good way to sit at the keyboard, but it certainly isn’t sufficient to make software not suck. Proper posture definitely won’t assure great software – and neither will managing requirements. Doesn’t mean that we shouldn’t do either one of them.
Would love to hear more about why you’ve lost faith in RDD. I believe that if you’re not getting value out of requirements, you’re not doing them right or you didn’t have the right people doing them.
#
Roger L. Cauvin said,
December 31, 2005 at 8:45 am · Edit
Agile development bridges the gap between top-down versus bottom-up approaches. The fundamental premise behind agile methods is that you will get it wrong the first time. That is, your conception of the requirements will be wrong, and the initial architecture will be suboptimal.
So agile methods avoid BUFR (big up-front requirements) and BUFD (big up-front design). But agile still calls for UFR and UFD, just wihout the “big†part. Then you iterate, revisiting and revising the requirements and design each iteration. Essentially, you do a bit of top down and a bit of bottom up each iteration.
#
Bjorn Aannestad said,
December 31, 2005 at 11:08 am · Edit
My view of requirements documentation (and engineering documentation too) is that their main purpose is to help everyone on the assembly line come to a shared understanding of how the system is to behave.
The goal isn’t to document every detail, but to reduce the chance that customers, management, sales, and the product manager are surprised by what got built.
The are cases where (maybe big) up-front requirements are necessary — when the software contains complex calculations based on domain expertise. Likewise, if the software is to implement new algorithms or a new architecture these should ideally be designed via prototypes, and then specified in detail before being handed to the implementation team. These specifictions must include details of why things were and were not done a certain way, so that implementation team can improve that design. This makes them “bigâ€, but necessarily so.
I’ve found that agile development works best for those parts of the system that are “shallow†like user interface, navigation, reporting, workflow. Agile techniques also work best when the team is already experienced, disciplined, and can instrictively head toward optimal solutions most of the time.
#
Kevin Smith said,
January 2, 2006 at 9:09 pm · Edit
I can think of a number of advantages to having documented requirements up front:
(1) Shared understanding of goals (product to be built)
(2) Forcing stakeholders to think in depth about end result prior to desing
(3) Controlling scope creep. A strong change management process is essential, but isn’t worth nearly as much if you don’t have a solid baseline. When the customer (external or interal) wants to make a change, conversations are much easier (and much less expensive) when you’ve already agreed on the requirements.
(4) Reference. If reqs aren’t well-documented, diverse developers may have diverse approaches, which can get expensive.
(5) Customer sat. through comparison of end result to inital reqs + formally requested changes.
Scott Sehlhorst said,
January 3, 2006 at 11:34 am · Edit
Thanks all for the great comments. Muser has posted The Deforestation of Requirements on his blog. He goes more into details about his perspective and opinions. Good stuff and worth a read!
I’ve also received a handfull of emails from folks who chose not to post. I’ll post some excerpts from these emails (anonymously) in the following comments. Thanks again all!
Scott Sehlhorst said,
January 3, 2006 at 11:50 am · Edit
From I’ll know it when I see it:
“[…]People don’t depend on Shakespeare for reliable transportation, to save their life in an accident, to diagnose heart disease, etc. People depend on engineering to handle these functions. Formal requirements are not about writing “great†software, whatever that is. Formal requirements are for writing consistent, maintainable, secure software that does exactly what it’s supposed to – no more and no less. â€
“[…]Formal requirements are about getting what you ask for, and about documenting what you ask for so that execs, marketing, sales, and all the other parts of your organization know exactly what they are supposed to be doing. It’s even more critical if you are outsourcing parts of your development, like validation, for example. In outsourcing, if it’s not documented in a formal spec, it definitely won’t be done properly (but it’s not a guarantee, either…).â€
“[…]And what the hell is a “software work of art?†Before you write a reply, I used to be a coder, programmer, software developer, whatever you want to call it; I understand the concept of “elegant code.†It’s has the same recognition criteria as “pornography†vs. art…people can only identify it by example, as in “I’ll know it when I see it.†I’ll observe that elegant code does not affect a product’s probability of success because it’s not visible to the folks who buy and use the software.â€
My thoughts on his response
These are some great comments about the value of a methodical software development process being critical to the success of critical software.
However, I do not believe that engineering and art are mutually exclusive. Elegance in engineering isn’t just about bit-twiddling, it is about understanding what problems to solve and finding innovative ways to solve them.
The notion of using Lagrange functions to estimate traffic levels and manage quality of service in telecommunication hardware is elegant. It redefines the problem in a tractable way, allowing for reasonable solutions.
Sending information on an AC power line by superimposing higher frequency data is elegant, as are TDM and WDM protocols for optical communication.
Being able to control the tire pressure on a Humvee from the driver’s seat, both to reinflate a flat and to adjust traction levels based upon terrain is a great solution to the “I get shot when I try and change a flat†problem. Much better than trying to design the perfect tire.
Velcro for little kids shoes probably saves every mom an hour a week.
Putting soap on the tip of a screw before driving it into wood (to prevent splitting) saves the time of predrilling a hole for the screw, and yields a stronger joint.
These same “higher level†signs of elegance are present in software too.
o Gmail uses tags for organizing email.
o Search-based configuration software allows solutions to otherwise intractable problems.
o Mapping software calculates fastest routes for me (and incorporates construction information)
o RSS readers allow me to pull information instead of publishers having to push it.
#
Scott Sehlhorst said,
January 3, 2006 at 11:53 am · Edit
From Don’t shoot the messenger:
“[…]Is the challenge about requirements or the formal requirements process? If the latter, what’s really being asked is “Can one build great software in a committee?†And the answer is “no.†Committees bring compromise at every step of the process and the result is a hodge-podge of technology.â€
“[…]The negative vibe on requirements generally comes down to two problems: 1) poor product management and 2) a misguided view of innovation.â€
“[…]Railing against requirements is often another way of railing against poor product management. Too often, product managers are trying to document their opinions of a successful product. Students of Pragmatic Marketing have learned that product managers are messengers for the market. They know that “your opinion, although interesting, is irrelevant.†Product managers should bring market facts to the planning session instead of their opinions. And most of all, they should put those facts into context with problems, use scenarios, and personas.â€