Structured Analysis & Big, Thick Documents

253947_buried_alive

I’ve been reading Ed Yourdon’sJust Enough Structured Analysis” recently (by following this link, you can download the whole book in PDF if you’re willing to fill out a quick form) . What a great resource for business analysts! It provides all sorts of instruction, examples and exercises on modeling and principles of systems analysis.

I’ve known of Yourdon’s (@yourdon on Twitter) publications for a while, but, for some reason, I hadn’t come across his site and wiki until just last week. If you’re a business/systems analyst and haven’t checked it out,  I’d highly encourage you to do so.

There is lots of great, quote-worthy information on modeling in the book/wiki, and I may tackle some of those topics in future posts. For now I’ll just highlight (yet another) critique of the long, laborious document that we still often see used for requirements specification:

[A] 500-page narrative description of the user’s requirements (which is, in a crude sense, a model) could (1) thoroughly obscure all the system’s features, (2) cost more to build than the system itself, and (3) fail to verify the system analyst’s understanding of the user’s true needs.

I found this quote interesting and noteworthy for a couple reasons. First,  I had somehow always considered narrative specifications as an alternative to modeling  when, in fact, big thick documents (BTD’s) are models, too – albeit very “crude.”* Think of a blueprint for a building expressed in prose, for example. Sure, it’s possible, but why would you choose to do it that way?

Second, I can (unfortunately) vouch for the accuracy of all 3 conditions described in the quote above because I’ve seen all of them played out at one time or another during the course of my career – fortunately, none of them recently.

*To be fair, most SRS-type documents aren’t uniquely “narrative”. They typically do include some models/diagrams, and, if used properly to describe and provide context for the narrative, you have a fair shot at avoiding conditions (1) and (3), at least.

About the Author

Jonathan Babcock is a management and IT consultant with expertise in business analysis, process optimization and solution delivery methodology. Practical Analyst is his outlet for sharing what he's learned, and for interacting with solution delivery professionals across the globe.

Author Archive Page

6 Comments

  1. Thanks for the kind words. You should also be aware that my "Just Enough Structured Analysis" material is available on my website as a wiki, which means that you (and anyone else) can take advantage of the opportunity to make improvements and corrections to the material that I wrote originally.

    Ed

  2. JB, Thanks for blogging about what you read. I look forward to checking it out. I love the "just enough" concept. We need to do what adds value to the success of the project.

Post a Reply to Ed Yourdon Cancel Comment

Your email address will not be published. Required fields are marked *