I’ve been reading Ed Yourdon’s “Just 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.