Geeks With Blogs
Ulterior Motive Lounge UML Comics and more from Martin L. Shoemaker (The UML Guy),
Offering UML Instruction and Consulting for your projects and teams.
Requirements Patterns and Antipatterns Discussion of Requirements and my upcoming book.
Calculating the ROI for Requirements Analysis
My buddy Josh Holmes has written a very excellent post on the Return on Investment (ROI) for software. I recommend it to anyone who sees software as a business, not just a job or a hobby. Last week, the always-worth-reading Patrick Greene made a comment that made me start thinking specifically about the ROI for Requirements Analysis. Most teams and most managers know they have a requirements problem; but too many of them say, “But we’re too busy to fix it, so we’ll just start coding.” Or “We’d like ......

Posted On Monday, May 4, 2009 7:53 PM

Ulterior Motive Lounge Episode 32: Talking with Pilot
Continuing The Project that Time Forgot, a UML case study. (Click images for larger versions.) On the surface, this Episode may seem almost social. Demented and sad, but social. But if you could join Hacker Girl, reading Geek Girl’s Tablet PC over her shoulder, you might see a different picture: And you would also see this diagram: You saw a conversation. Geek Girl hopes that Pilot saw a conversation. But she saw an interview, and a chance to capture and model requirements. Let’s review the notation ......

Posted On Wednesday, March 4, 2009 4:06 PM

Overlooking the Obvious
I just wanted to rename a Word document while I was working in Word. You know what comes next. In practically every application out there, I have two choices: Close the app. Navigate to the file in Windows Explorer and rename it. Double-click it to reopen the file. Within the app, do a Save as…. Optionally delete the old file name. In both cases, both file names now appear in the Most Recently Used list, even though the old file may no longer exist. Yawn. We know how this works. But can you learned ......

Posted On Wednesday, February 25, 2009 12:10 PM

You're Selling Software
Update: Fixed a typo and a calculation error. Josh Holmes has a great post on Return on Investment (ROI). And by “great”, I mean great even by Josh’s usual standards. He worked hard on this one. I was privileged to review three drafts before he published it; and by draft two, I was saying, “Josh, this one’s a winner. I’m going to reference this one a lot.” So stop reading me, and go read what Josh has to say. I’ll be waiting here when you get back. OK, you’ve read it. Pretty scary, huh? But the scariest ......

Posted On Tuesday, February 24, 2009 3:33 PM

The Analyst's Chorus

I am the mirror, reflecting what you say to me.

I am the mirror, I’ll show you where you want to be.

Talk to the mirror, I’ll tell you what you really said.

Look in the mirror, I’ll draw the picture in your head.

There in the mirror: it’s what you didn’t know you knew.

I am the mirror, and I’m listening… to you.

Posted On Friday, February 20, 2009 4:00 PM

Requirements Patterns and Antipatterns: Checklists
There’s an old joke about an engineer called out of retirement by a company in trouble: their most vital machine has stopped working, and nothing they have tried will get it started again. The old engineer looks at the machine, studies it for a few minutes from different angles, and flips a switch. Presto! The machine starts to work, humming along like it never had a problem. The engineer hands the owner a bill for $10,000; and the owner says, “For flipping a switch? That’s outrageous! I’m not paying ......

Posted On Sunday, February 1, 2009 1:43 PM

Pattern 19. Requirements Archaeology
Diagnostic Checklist: Requirements Archaeology ? 70 Your project is to supplement, upgrade, or replace an existing system. ? 30 The existing system is poorly documented, or the documentation is out of date. ____ Total You can learn how to score the checklists here. Problem: The project is to supplement, upgrade, or replace an existing system, which is the de facto primary source of your requirements. Context: In many organizations, new work has to be done in a context of legacy systems, which embody ......

Posted On Sunday, February 1, 2009 1:13 PM

Ulterior Motive Lounge Episode 31: The Teams Split Up
Continuing The Project That Time Forgot, a UML case study in comic strip form... (Click pictures for larger images.) After a long hiatus due to weather, illness, work, conferences, and more stuff than I can explain, the Lounge is back. This Episode gets the ball rolling for Act II, so there’s not much new UML content here yet. But I can give you a few diagrams of the team’s review process. The process starts with some preliminaries, then splits into three threads of operations, each with a separate ......

Posted On Saturday, January 31, 2009 12:59 AM

Ship It On The Side

Curtis Gray informs me that the first Ship It On The Side podcast is now published.Listen to us talk about building and shipping great software while holding down day jobs.


Posted On Saturday, November 29, 2008 3:59 PM

Requirements Night at Ulterior Motive Lounge
Inspired by Steve Ballmer, here's some cheerleading for the most important part of the software development process... UPDATE: Here's a larger, more legible WMV version. Once upon a time, I wrote a book. Or rather, I wrote all but one-half of chapter 3 of a book: Requirements Patterns & AntiPatterns, sold to Addison-Wesley. For various reasons -- partly lost motivation when my Dad died, partly needing to put food on the table, partly just not finding time -- I've never been able to finish chapter ......

Posted On Monday, November 17, 2008 1:01 PM

An Argument for Requirements Analysts
An attempt to trade quality for cost or schedule actually results in increased cost and a longer schedule. Steve McConnell, Professional Software Development What has long been known in other businesses is true for software development as well: if you cut corners for shorter schedules or lower costs, you will get longer schedules, higher costs, and higher defect rates; but if you take the right measures to lower defect rates, you can get lower defect rates and shorter schedules and lower costs. As ......

Posted On Tuesday, December 16, 2008 6:11 PM

Ulterior Motive Lounge Episode 27: Meet the Crew
Continuing The Project That Time Forgot, a UML case study in comic strip form... (Click pictures for larger images.) There's the business, and then there's the role of the system within the business. If all you focus on is the role of the system, you can miss chances to see where the system's really needed. So time permitting, I would rather start by understanding the whole business and then work inward. Oh, sometimes the division is very clear: if my client asks for a change to their payroll system, ......

Posted On Friday, December 5, 2008 5:34 PM

The Echo Effect
The primary conundrum in requirements analysis is simple: how can you be sure that you understand what the user said or wrote? Analysts have to master the terminology and domain of the customers. Only customers can verify that analysts have done so. This is made more difficult by many forces: The difficulty of learning a new domain and new terminology. The slippery nature of language. Overloaded language: you understand the words they’re using, but not the domain-specific way in which they’re using ......

Posted On Saturday, November 15, 2008 3:34 PM

The Outline Effect
And as long as I'm posting UML tips to get you ready for the case study, there are two other analysis effects you should strive for. The first of these is The Outline Effect. It’s difficult to learn a new domain. Analysts have to constantly learn new domains and requirements. They’re always learning and studying. How can they better focus on the information that they gather and draw knowledge from it? Some teams work in the same domain from project to project, but many teams tackle a new domain with ......

Posted On Saturday, November 15, 2008 3:33 PM

The "Martin the Moron" Effect
Inevitably as I discuss modeling and requirements, I find myself discussing The "Martin the Moron" Effect. And that's important enough that I wanted to revisit it here. The "Martin the Moron" Effect is as simple as this: I want to hear "Martin, you're a moron" on day 2 of a 200 day project; because if I don't, then it's almost guaranteed that on day 500, I'll hear, "Martin, you're a moron, and we're not paying for this!" Early modeling is not about being right; it's about being wrong, but in interesting ......

Posted On Saturday, November 15, 2008 3:31 PM

Absolutely! (Not!)
There are only two words you should never believe: "only" and "never". Oh, and "always". And "every", "each", "none"...Yeah, that's more than two. You didn't believe "only", did you? Never do that! Whenever the stakeholders tell you an absolute, don't believe them. Challenge them on it. Make them prove it. Make them defend it. Make them put it in writing. Or if it's not the right time to be challenging them, make a note of it; and then later, come back and challenge them and make them defend it and ......

Posted On Saturday, November 15, 2008 3:24 PM

Copyright © Martin L. Shoemaker | Powered by: