An Argument for Requirements Analysts

Productivity vs Defect Removal

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 Crosby wrote, “Quality is free.” But it’s free only in terms of ROI, meaning the investment must be made first; and it’s only free if you first define what you mean by “quality”.

Fortunately, Crosby provided the appropriate definition as well: quality is conformance to requirements. That can be a concrete, quantifiable definition; but in some way it just moves the problem down the road, leaving us to define requirements: not just the term, but the specific requirements of our projects. It leaves us with this inescapable truth:

If we don’t know our requirements, we can’t have quality.

…we must define quality as “conformance to requirements” if we are to manage it.

Philip B. Crosby,
Quality is Free: The Art of Making Quality Certain

Analysis Capability and Impact on schedule

Data from Boehm et al., Software Cost Estimation with COCOMO II

Recent surveys have found that the most frequent causes of software project failure have to do with requirements problems – requirements that define the wrong system, that are too ambiguous to support detailed implementation, or that change frequently and wreak havoc on the system design.

Steve McConnell,
Professional Software Development

Poorly defined requirements are endemic to the software development industry. Boehm’s research on factors that affect development schedules and costs show that:

Excellent requirements analysts can reduce a project’s schedule by almost 30%, while inadequate analysis can increase the schedule by over 40%.

Again and again, schedule pressures lead teams to start developing before they have sufficient requirements definition.

Even though requirements analysis is a key skill, the topic isn’t as “hot” as new technologies and tools that are promoted by vendors and conferences and magazines. And many development teams feel swamped just trying to keep up with technologies and tools.

Martin L. Shoemaker

Influences on Schedule

Data from Boehm et al., Software Cost Estimation with COCOMO II

Among all personnel factors, Analyst capability has the widest range of impact (multiplier range of 2, worst case divided by best case). Teams may tout their application experience as a strength; but application experience has an Influence Range of only 1.51. Application and platform experience combined have an Influence Range of 2.11. Teams would never throw out their domain knowledge and develop for an entirely new platform; but poor requirements practices have almost the same Impact Range.

These teams aren’t foolish, yet they foolishly let a critical aspect of their process get out of control on project after project. A look at their team rosters may give a clue as to why: while there are many roles on the rosters, there may be none with requirements as a primary responsibility. Marketing and sales have requirements responsibilities, but many conflicting responsibilities as well. Lead engineers are supposed to verify requirements; but they are also too busy, and are commonly focused on solutions, not requirements. Designers and developers also focus more on how than on what. Traditionally in software development, analysts have primary responsibility for and are evaluated on the correctness of requirements.

The role of requirements analysts is
to define the problem in a verifiable form,
so that teams may recognize a valid solution.

And next you must ask: who owns that responsibility in your organization? If the answer is “no one” or “I don’t know”, there’s a ripe opportunity to cut your schedules by 30% to maybe even 50%, all while improving your quality.

Code is not enough. It’s all about requirements; and that’s all about communication.

The UML Learning Path

(Click picture for a larger image.)

The UML Learning Path

No, I’m not going to name any of the devs who inspired this post. They wouldn’t know who I am, anyway.

But it takes an extremely high degree of arrogance to go from “I don’t see a way to use this” to “This has no value, no matter who says they’re getting value out of it. So I’ll dismiss it, and I’ll mock them” Either arrogance, or more likely, insecurity: “I don’t understand this; so since those people think it’s important, either they understand something I don’t, or they’re fools. I’ll mock them, so everyone thinks they’re fools. That will make me look smart.”

And that insecurity manifests in a lot of places on a lot of topics, not just UML: Agile Development, Orchestrated Development, CMMI, Test Driven Development, C#, Java, Ruby, linux, .NET… Any time you move from “I don’t see it” to “It’s worthless”, look around: if other developers are putting those tools to productive use, then it’s not worthless. It just doesn’t help you. So do you call it worthless, and imply they’re fools? Or do you openly mock them, demonstrating that you’re a fool?

Or do you follow the only exit path in this diagram? There is only one, after all. Once you get UML, you’ve gotten it for good. You may not use it all the time, but you’ll understand when and why you should use it. But the only exit path is the middle: you recognize that UML (or Agile, or Orchestrated, or…) is having some value on some projects, so it’s not worthless; but you just can’t see the value. You remain open-minded.

Business Actors

On Twitter, @ClearSpringBA asked:

@UMLguy to show a “parent” actor over subsidiaries, do I use the generalization feature in UML? (doing an actor-UC diagram, new to it)

Wordy cuss that I am, I answered multiple times:

@ClearSpringBA Are subsidiaries subordinates or special cases? For ex, Supervisor is special case of Employee; Emps are subordinates of Supv

@ClearSpringBA For special case, genralization arrow from Supv to Emp. “Supv is an Emp with more responsibilities.”

Her questions back:

@UMLGuy thanks for all the info. subsidiaries are parent companies, can do everything on behalf of a sub.

UMLGuy so, i would draw the arrow toward the parent company? the arrow with the “big head”, generalization arrow? prob wrong terms!

I decided this had gotten complex enough that words weren’t working; so we went to email. Since this is general enough not to show any business info from her client, I thought I would share my response, in case anyone else finds it useful:

Here’s a simple diagram of business relationships:

Businesses as Actors

You can read it as follows:

  1. A Business is an Organization. Triangle arrow (“generalization” or “inheritance”) can be interpreted as “is a”.
  2. A Parent Company is a Business.
  3. A Parent Company has zero or more Subsidiaries, which are Businesses. (They might also be Parent Companies themselves, since a Parent Company is a Business.) The plain arrow can be interpreted as “has” or “contains” or “uses”. 0..* means any number, possibly 0. 1..* would mean any number, NOT 0. That could mean, for example, that a Parent Company MUST have at least 1 Subsidiary.
  4. A Business has 0 or 1 Parent, which is a Parent Company. The “topmost” Business has no Parent. All the others have 1.
  5. A Business has zero or more Partner Businesses.

I hope that clarifies things, and gets you thinking about new ideas. Please let me know if you have more questions.

And I hope it helps someone else, too!

Quality is NOT Free

A business classic tells us that Quality Is Free. The title is intentionally provocative: no, quality isn’t free, it just pays for itself. But first, you have to pay for it.

And that, unfortunately, is where we fail in the quality game so often. Corporations seem addicted to the practice of compartmentalized budgeting, or what I think of as “bucket budgeting”: you’ve got a bunch of different buckets you pour money into at the start of the fiscal period; and each bucket can only be spent on a particular purpose. When that bucket is empty, you can’t accomplish that purpose any more. Oh, the company may have some reserve you can tap; but you’re going to get frowned at for exhausting your budget.

I understand bucket budgeting as a planning tool. I think it makes perfect sense, for the same reason you should make estimates out of small elements. In fact, it should the exact same reason, because these budgets should be estimates, not shackles. You’ll correct over time.

And that’s where the failure comes in. Somehow, some way, in too many organizations, those buckets are shackles. Your bucket is what you can spend, what you will spend — regardless of the bottom-line impact of your spending. Even if every $1 spent out of your bucket brings $1.20 into the company, you only get to spend what’s in your bucket. This isn’t a new complaint, of course; and smart managers certainly keep an eye out for ways that spending money can save or generate more than they spend. But less bold managers don’t like to rock boats. They live within their buckets, because overspending their bucket gets them a bad review. It takes courage to stand up and make a case for more money in your bucket, unless you have a very clear, simple chain between the money you spend and the money that comes back in.

And the quality equation is particularly susceptible to bucket budget shackles. Quality does pay for itself, but it seldom shows up anywhere near the buckets where the costs came from. The cost of quality is measured in extra labor and time up front on preventing defects, along with extra labor and on the back end detecting and correcting defects. It’s also training time, which takes time away from “productive” work. It’s also management time and communications effort in getting everyone — execs, workers, and customers — to understand that seemingly slower time is actually faster in the long run.

The benefits of quality, meanwhile, are in reduced support costs, reduced rework costs, and increased customer satisfaction and loyalty. These do affect the bottom line; but they don’t put money in the buckets of the managers who have to pay for the quality in the first place.

A common sarcastic reaction I here among the workforce is “Quality is free, so management thinks they can have it without paying for it.” And sadly, this reaction is often justified. But I don’t think most managers are really that clueless. I do think many managers are shackled by bucket budgeting, and unwilling to buck the system for something that won’t have an effect on their budgets. The effect may be the same as cluelessness; but if we don’t understand the proper cause, we can’t devise the proper correction.

And no, I don’t know what that correction is. I mean, to me, the answer is simple: start treating budgets as estimates, not shackles; but I don’t think little old me is going to change corporate culture that drastically just by saying so.

Final note: this isn’t inspired by anything at my current client. Really, it’s not: I’ve been complaining about bucket budgeting for over a decade. But it’s true that my client is currently entering a phase where they’re trying to invest in quality in pursuit of benefits in the long run, and I want to do my part for that. There are forces that will push against that effort, and forces that will push for it. I’m doing a little writing to help me clarify how I can help push in the right direction.