Essential Systems Analysis

By Stephen M. McMenamin and John F. Palmer

No Synopsis Available.

• Format: Paperback
• Language: English
• ISBN: 0132879050
• ISBN13: 9780132879057
• Release Date: January 1984
• Publisher: Yourdon
• Length: 408 Pages
• Weight: 1.65 lbs.
• Dimensions: 10.3" x 0.8" x 7.3"

Customer Reviews

Seminal work on IT design, code and architecture level

When this book was authored, code design was in. Architecture as a formal discipline was just a glimmer in the eyes of futurists. Today we focus on architecture. McMenamin and Palmer's seminal work is as valuable today as when authored. It ranks co-equal with Structured Analysis and System Specifications by Tom Demarco. McMenamin left MIT with Ed Yourdon to actively pursue computer science. We are all far ahead for his adventures and authorship. This book is masterfully authored with clear illustrations and examples, a cogent and highly applicable treatise on designing good systems.

A milestone in system analysis

This book changed the way I thought of system analysis when I first read it in 1984. Those ideas are still relevant today. Its key ideas include the notion of technology independent requirements and a rule of thumb (perfect technology) for recognizing them. It was the first book (that I read) to recommend the use of both Data Flow Diagrams and Entity Relationship Diagrams to provide a balanced depiction of business requirements. It distinguished between the essence (core requirements) of a system and its incarnation, this was an important refinement on the notions of logical and physical models which to this day are seldom well defined. It identified the "old physical tar pit" as a major risk area in structured analysis and suggested ways to avoid getting stuck. Finally it proposed the notion of blitzing requirements as a technique for dealing with real-world time constraints. This book was essentially a sequel to Structure Analysis and System Specification, the ground breaking book on structured analysis by Tom DeMarco. (The authors of this book were close business associates of DeMarco.) I still recommend this book, but it is no longer my first choice. That book is Complete Systems Analysis by James & Suzanne Robertson. (The Roberson's are also business associates of DeMarco.) Their Atlantic Systems Guild web site is worth visiting.

The definitive book on creating logical data flow diagrams

Gane and Sarson's original book on data flow diagramming said that you should convert your physical data flow diagram to a logical data flow diagram. It was a little like the New Yorker cartoon: "Miracle occurs here." McMenamin and Palmer finally tell us precisely and in detail exactly how to do that. Well done!

Cuts to the core on how to find and document requirements.

The lessons in this book pass the test of time and are still useful in the Object-Oriented era. The authors clearly describe how to separate routine and expected requirements (aka. "custodial" processes for validation and security) from the data, processes, and rules that make up the baseline business process a client wishes to assist with software. There are several books on how to *draw* requirements models (ie. ERD, DFD, FDD, IDEF, et al.), but this book focuses more on *what* to put in the model. I have consulted on many projects where 100's of pages of "requirements" were documented, yet the documents actually contained 60% design preferences (in detail), 20% expected requirements (ie. performance, security, backup/recovery, installation, service, etc.), and (at most) 20% core, unchanging, business requirements. This book helped me guide these teams to discover and document what their customers needed and wanted, and separate these essential requirements from the typical fluff and "no-duh" staements that had previously been passed-off as their requirements document. OO zealots can gain useful insights from this book on what makes up a "business requirement", if they can put aside their bias against traditional structured modeling techniques. Mark Lucas, Houston, TX Feb 1997