Systems Analysis and Design Methods [Hardcover]

Jeffrey Whitten (Author), Lonnie Bentley (Author)

Book Description

ISBN-10: 0073052337 | ISBN-13: 978-0073052335 | Publication Date: November 22, 2005 | Edition: 7th

Today's students want to practice the application of concepts. As with the previous editions of this book, the authors write to balance the coverage of concepts, tools, techniques, and their applications, and to provide the most examples of system analysis and design deliverables available in any book. The textbook also serves the reader as a professional reference for best current practices.

Editorial Reviews

About the Author

Jeff Whitten is Professor and department Head of Computer Technology (CPT). CPT offers baccalaureate degrees in both information systems development and telecommunications & networking. Professor Whitten is heavily involved in curriculum development and outreach. His main interests include systems analysis and design, computer-aided software engineering, rapid application development, and database development.

Lonnie Bentley is Professor and Associate Department Head of Computer Technology (CPT). CPT offers baccalaureate degrees in both information systems development and telecommunications & networking. As Associate Head, Professor Bentley is primarily responsible for academic affairs of the department. His main teaching and scholarly interests include systems analysis and design, computer-aided software engineering (CASE), rapid application development (RAD), and graphical user interface (GUI) design.

Product Details

• Hardcover: 768 pages
• Publisher: McGraw-Hill/Irwin; 7th edition (November 22, 2005)
• Language: English
• ISBN-10: 0073052337
• ISBN-13: 978-0073052335
• Product Dimensions: 11.1 x 8.8 x 1.2 inches
• Shipping Weight: 4 pounds (View shipping rates and policies)
• Average Customer Review: 4.0 out of 5 stars  See all reviews (26 customer reviews)
• Amazon Best Sellers Rank: #29,090 in Books (See Top 100 in Books)
  • #3 in Books > Computers & Technology > Computer Science > Software Engineering > Methodology
  • #12 in Books > Computers & Technology > Computer Science > Systems Analysis & Design
  • #28 in Books > Computers & Technology > Computer Science > Software Engineering > Information Systems

Customer Reviews

Most Helpful Customer Reviews

24 of 24 people found the following review helpful:

4.0 out of 5 stars Good Teaching Resource, April 10, 2006

By 

S. Barnes (Stillwater, OK United States) - See all my reviews
(REAL NAME)   

This review is from: Systems Analysis and Design Methods (Hardcover)

I have taught systems analysis and design methods for four years using this text or its previous editions. It has its strong and weak points. It covers the basics very well, and gives the students a good grounding in classical techniques. The authors have done a lot to include object-oriented techniques in the 6th and 7th editions. This meets my prefered approach since both techniques have their value, and analysts need to be familiar with both.
However, there are weaknesses. The authors focus on more traditional applications, with less coverage of more recent developments than I would like. Yes, they discuss web applications and some e-commerce elements, but it is "bolted on" and not well integrated into the methodology. Much of their GUI design sections need to be updated with a more web-centric approach, as most applications are going that way.
Finally, they fail to address in any substantive way how analysts shoud address the modern security needs around data integrity, user authentication, user authorization, the related access control issues, data privacy, appropriate use of encryption, and last but certaintly not least, backup and recovery of data content. It is my opinion that each of these topics need to be built into the process, not bolted on, and that to do this, it should be integral to the training of the analyst. These ommissions lead to my rating of 4 stars for an otherwise excellent text.

17 of 17 people found the following review helpful:

1.0 out of 5 stars Teachers - please don't use this book, February 24, 2009

By 

P.B. Mert (East Coast, USA) - See all my reviews

This review is from: Systems Analysis and Design Methods (Hardcover)

This is my first review on Amazon; I'm writing to point out some serious issues which have not been addressed by the previous 13 reviews.
To begin, I'm a second semester grad student in IS and this is the required text for my Systems Analysis & Design class.
I am now in my 7th week of class, and about halfway through the book. Others have mentioned that this book is overly broad and not deep enough - this is an understatement. I can only vaguely describe some of the stages of systems analysis. The problem, as I see it, is that the authors (un)creatively decided to use an iterative, rather than sequential, approach to teaching the subject matter. Chapters 1 and 3 present the main ideas. Chapter 5 goes into more detail about those same ideas, repeating some (but not all) of what was already discussed. I'm presently on Chapter 7 and can't decide if what is being discussed is even further elaboration of previous chapters. Why not have the subject matter be more sequential, like every other college textbook? Because iteration is one approach to systems analysis and design and the authors thought it a good idea to use this approach for a textbook.
Another negative effect of this approach is redundancy and lack of depth. Iteration not only makes it difficult for the newcomer to ascertain whether the current chapter's topic is new or not, it also takes a toll on a student's confidence. I believe that if the layout had been sequential, there would be more room for depth and clarity, not mention making the reading flow more naturally.
I am quite interested in learning the subject. But I'm almost halfway through the semester and I still don't know how or where to begin and proceed with the process. I've even downloaded and reviewed the supplementary material available on the authors' website.
If you're a teacher, please do your students a favor and consider another text. This might be somewhat palatable to computer programmers, engineers, or other highly technical folks but not all Information Science students come from these fields.

13 of 13 people found the following review helpful:

4.0 out of 5 stars Broad, but sometimes not deep, April 18, 2007

By 

wiredweird "wiredweird" (Earth, or somewhere nearby) - See all my reviews
(HALL OF FAME REVIEWER)    (TOP 500 REVIEWER)   

This review is from: Systems Analysis and Design Methods (Hardcover)

Whitten and Bentley have put together a very good text for a one-semester intro to systems analysis. After a wide-ranging introductory section, the real meat of this book appears in Parts 2 and 3: Analysis and Design.

Part 2 spends just one chapter on requirements discovery. This is the one section of the book that I found a lot thinner than it should be. The first problem is that requirements engineering is a field all its own, and has (or should have) direct connections to every work product that comes after in the development cycle. Although later chapters (especially use cases and even protoyping) offer additional ways to elicit meaningful requests from users, the whole task of making sure that the requirements are complete, consistent, and traceable to downstream effort is barely addressed. The second, and I think bigger problem is that the authors talk only about requirements from the users, plus "non-functional" requirements like reliability and performance. There's a lot to debate in categorizing requirements as non- or functional, depending on the kind of application, but the real defect in the discussion is one they share with most other authors in the field: they simply ignore the standards and regulations that affect system development. The SEC, FAA, and FDA impose requirements, as do legal enactments (HIPAA, ITAR for crypto, Sorbanes-Oxley), look&feel, and standards for networking, data exchange, and a gazillion other areas. Depending on the field you work in, you'll spend a lot more time worrying about regulatory and standards compliance than about anything the customer said.

Despite this uninspiring start, Part 2 moves along well. It presents use cases (though in a particularly fussy way), modeling techniques, and enough UML to help but not enough to overwhelm - and the whole can be quite overwhelming.

Part 3 addresses high level design. If your classroom is a typical one, this is where the students students with little, no, or ancient programming experience may start to struggle. It does a fair job with the common kinds of human-oriented IO, even if it shortchanges other systems with more intricate kinds of data manipulation (e.g. compilers or weather modeling). Because this addresses analysis as a separate task from programming, the authors have no reason to go into a lot of directly codable depth. This will frustrate the techies, but the little depth that it does address might intimidate thosewith more of a business orientation. It's a problem that I think has no solution as long as the people who build systems and the people who want them are in the same classroom.

Finally, Part 4 acknowledges the fact that systems are not just designed. Although it skips deployment and maintenance, this section does touch on low-level implementation and day to day operations. Now that they've gotten away from the core requirements, specification, and design content, I think the authors are making a quiet suggestion to the instructor who uses this book: it's your curriculum, add your spin to it. Everyone who looks this text over will see soft spots, but I'll bet that no two people see the same ones. We all come into this text with our own interests, specialties, experience, and strengths. One of the joys of teaching is the chance to add your own kind of depth to a course.

This is a fair cookbook. By that, I mean that you can follow the instructions and get a reliable set of results from it. Or, if you read this a little more broadly, it invites all the embellisments and complements that an active researcher or practitioner is sure to think of.

//wiredweird