Geeks With Blogs

@UMLGuy
  • UMLGuy @LeeHate are you still selling art? I would like to license Vodun Bokor for book/ebook cover. It's incredible! You're very talented. about 768 days ago
  • UMLGuy @kzoomoo Indeed. You know 2 of my influences. Characters have multiple influences, but Father and Daughter partly inspired by your family. about 1154 days ago
  • UMLGuy @SteveAndrews That is awesome news, man! You worked hard for that. about 1155 days ago
  • UMLGuy The Night We Flushed the Old Town in Digital SF V2. Kindle: http://t.co/8cVA6zw It's about ecological disaster. And beer. about 1170 days ago
  • UMLGuy @kzoomoo Sounds like a very happy birthday! Your kids are great, as always. about 1305 days ago
  • UMLGuy @julielerman You're in Bangalore and Bali... and you need cheap tickets to feel lucky? I would call that great fortune in itself. about 1305 days ago
  • UMLGuy So weird watching Dr. Gregory House M.D. play Bertie Wooster. Same facial expressions convey completely different meanings. about 1305 days ago

News LoungeWare is now available. The UML Guy T-Shirt
Ulterior Motive Lounge UML Comics and more from Martin L. Shoemaker (The UML Guy),
Offering UML Instruction and Consulting for your projects and teams.
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.

Posted on Tuesday, December 16, 2008 6:11 PM It's all about communication. , Requirements Patterns and Antipatterns , Code is not Enough | Back to top


Comments on this post: An Argument for Requirements Analysts

# re: An Argument for Requirements Analysts
Requesting Gravatar...
Martin,

Again for references! Are there any books you recommend on requirements analysis? Does McConnell's PSD go into detail about requirements analysis? I love code complete 2nd ed, so wouldn't mind another great explanation from McConnell.

Otherwise Software Requirements 2nd Ed is on my list of books to read soon. Is there another requirements gem out there?
Left by Stacy Vicknair on Dec 17, 2008 10:13 AM

# re: An Argument for Requirements Analysts
Requesting Gravatar...
Stacy,

Oops! I did this more in "motivational" mode than "documentational" mode, so I didn't get into references. PSD doesn't give much detail, just makes a strong case and a small mountain of references. It's about 20% as long as Code Complete 2, so it's a faster read.

Weigers is a very good place to start. Leffingwell and Widrig, Managing Software Requirements, is good but kinda dry. Eriksson and Penker, Business Modeling with UML, is good for the UML side of the work. And Fowler, Analysis Patterns, is full of "stock" analyses of common problem domains.

And of course, I hope you'll like my own book, if I ever finish it. I'm really trying to target year end.
Left by Martin L. Shoemaker on Dec 17, 2008 10:28 AM

# re: An Argument for Requirements Analysts
Requesting Gravatar...
Oh, and Jonathan Babcok's blog http://jonathanbabcock.com has given me lots of insights.
Left by Martin L. Shoemaker on Dec 17, 2008 10:33 AM

# re: An Argument for Requirements Analysts
Requesting Gravatar...
Thanks again Martin, glad this blog doesn't charge, or I'd be running up quite the tab.

There's so many places to start becoming a better developer / analyst, I've got to focus on having great references that fit my situations. I wasn't criticizing the lack of references; moreover I was saying, "Once again, I'm the one looking for references!"
Left by Stacy Vicknair on Dec 17, 2008 11:05 AM

# re: An Argument for Requirements Analysts
Requesting Gravatar...
You're becoming my most frequent -- and most welcome -- commenter. So even if you need to criticize, please do!
Left by Martin L. Shoemaker on Dec 17, 2008 11:37 AM

# re: An Argument for Requirements Analysts
Requesting Gravatar...
"If we don’t know our requirements, we can’t have quality."

Thanks, Martin, for the great post - and possibly a new tagline!
Left by Jonathan Babcock on Dec 18, 2008 10:37 PM

# re: An Argument for Requirements Analysts
Requesting Gravatar...
Thanks, Jonathan! I'm hoping to convince my client to make it their tagline, too!
Left by Martin L. Shoemaker on Dec 19, 2008 10:46 AM

# re: An Argument for Requirements Analysts
Requesting Gravatar...
No arguments from me. Every team needs requirements.

I know the XP folks say they don't need a separate requirements analyst role, that the team members write the user stories and the code. But I know some VERY successful XP teams that have found it helped A LOT to have a specific person on the team who is trained to interact with end users and do the work of eliciting and analyzing requirements.

Eliciting is not the same as collecting - requirements analysts are not note takers. We must question, probe, determine the real needs, and not just accept what we are told at face value.

I think of myself as the storyteller on the project team. First I have to determine the story of the project, then I have to tell it over and over in many different forms for many different audiences.

I added your blog to my blogroll at http://www.writingusecases.com :-)

Geri
Left by Geri Schneider Winters on Jan 02, 2009 9:19 AM

# re: An Argument for Requirements Analysts
Requesting Gravatar...
Geri,

I am truly honored by your comments. I recommend your book, Applying Use Cases, more often than any UML book but UML Distilled -- and I usually recommend both books at the same time, since I think they work well together. In fact, since my own UML book has a .NET focus (and is out of print!), I recommend yours more than mine.

I'm happy to learn about your blog. I'll add it to the blogroll when I get to my home machine.

Thanks!
Left by Martin L. Shoemaker on Jan 05, 2009 9:44 AM

# re: An Argument for Requirements Analysts
Requesting Gravatar...
"Say it with me, people: 'Requirements! Requirements, Requirements!' "

Martin, I've learned a lot from your blog! Maybe I'll even be able to apply some of it to my hobby-level programming environment!

Thanks for such entertaining education!

Cheers,

Mitch

Left by Mitchell Allen on Jan 05, 2009 3:11 PM

# re: An Argument for Requirements Analysts
Requesting Gravatar...
Mitch, it's truly a better blog thanks to your questions and comments. You've made me think more, reach farther, and communicate better. Thanks!
Left by Martin L. Shoemaker on Jan 05, 2009 3:47 PM

Your comment:
 (will show your gravatar)
 


Copyright © Martin L. Shoemaker | Powered by: GeeksWithBlogs.net | Join free