December 29, 2005

CRUDdy use cases and Shakespeare

Posted in Requirements, Use case at 9:05 am by Scott Sehlhorst

We’ve moved to tynerblain.com/blog – this post is now here

Advertisements

9 Comments »

  1. 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

  2. A Muser said,

    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.

  3. 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.

  4. 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.

  5. Bjorn Aannestad said,

    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.

  6. Kevin Smith said,

    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.

  7. 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!

  8. 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.

  9. 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.”


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: