Business Analyst Training

Requirements elicitation, writing, analysis, and modeling by IIBA Endorsed Education Provider.

www.requirementssolutions.com

Business Analysis Bookstore
In Association with Amazon.com
Help PicoSearch
Free Business Analyst Skills Test for CBAP Looking for Business Analysis Training

The Inmates Are Running the Asylum : Why High Tech Products Drive Us Crazy and How To Restore The Sanity

Buy the Book
Summary TOC Look Inside Comments Reviews
Alan Cooper (Preface), Paul Saffo
April 1999, Sams, Hardcover, 261 pages, ISBN 0672316498

Instructor-led, virtual, and self-paced training for Business Analysts What Do Business Analysts Do?
How to Elicit Business System Requirements
e-Learning, virtual workshops and webinars Try our new Virtual Workshops and e-Coaching
for today's Business Analysts (BA's) and Subject Matter Experts (SME's)

Summary
Buy the book
The Inmates are Running the Asylum argues that, despite appearances, business executives are simply not the ones in control of the high-tech industry. They have inadvertently put programmers and engineers in charge, leading to products and processes that waste huge amounts of money, squander customer loyalty, and erode competitive advantage. Cooper offers a provocative, insightful and entertaining explanation of how talented people continuously design bad software-based products. More importantly, he uses his own work with companies big and small to show how to harness those talents to create products that will both thrill their users and grow the bottom line.
 
analysis bookstore top
BA books: Table of Contents
Buy the book
  • Foreword
  • Preface

Part I - Computer Obliteracy

  • Chapter 1 - Riddles for the Information Age
    • What Do You Get When You Cross a Computer with an Airplane?
    • What Do You Get When You Cross a Computer with a Camera?
    • What Do You Get When You Cross a Computer with an Alarm Clock?
    • What Do You Get When You Cross a Computer with a Car?
    • What Do You Get When You Cross a Computer with a Bank?
    • Computers Make It Easy to Get into Trouble
    • Commercial Software Suffers, Too
    • What Do You Get When You Cross a Computer with a Warship?
    • Techno-Rage
    • An Industry in Denial
    • The Origins of This Book

  • Chapter 2 - Cognitive Friction
    • Behavior Unconnected to Physical Forces
    • Design Is a Big Word
    • The Relationship Between Programmers and Designers
    • Most Software Is Designed by Accident
    • "Interaction" Versus "Interface" Design
    • Why Software-Based Products Are Different
    • The Dancing Bear
    • The Cost of Features
    • Apologists and Survivors
    • How We React to Cognitive Friction
    • The Democratization of Consumer Power
    • Blaming the User
    • Software Apartheid

Part II - It Costs You Big Time

  • Chapter 3 - Wasting Money
    • Deadline Management
    • What Does "Done" Look Like?
    • Parkinson's Law
    • The Product That Never Ships
    • Shipping Late Doesn't Hurt
    • Feature List Bargaining
    • Programmers Are in Control
    • Features Are Not Necessarily Good
    • Iteration and the Myth of the Unpredictable Market
    • The Hidden Costs of Bad Software
    • The Only Thing More Expensive Than Writing Software Is Writing Bad Software
    • Opportunity Cost
    • The Cost of Prototyping

  • Chapter 4 - The Dancing Bear
    • If It Were a Problem, Wouldn't It Have Been Solved by Now?
    • Consumer Electronics Victim
    • How Email Programs Fail
    • How Scheduling Programs Fail
    • How Calendar Software Fails
    • Mass Web Hysteria
    • What's Wrong with Software?
    • Software Forgets
    • Software Is Lazy
    • Software Is Parsimonious with Information
    • Software Is Inflexible
    • Software Blames Users
    • Software Won't Take Responsibility

  • Chapter 5 - Customer Disloyalty
    • Desirability
    • A Comparison
    • Time to Market

Part III - Eating Soup with a Fork

  • Chapter 6 - The Inmates Are Running the Asylum
    • Driving from the Backseat
    • Hatching a Catastrophe
    • Computers Versus Humans
    • Teaching Dogs to Be Cats

  • Chapter 7 - Homo Logicus
    • The Jetway Test
    • The Psychology of Computer Programmers
    • Programmers Trade Simplicity for Control
    • Programmers Exchange Success for Understanding
    • Programmers Focus on What Is Possible to the Exclusion of What Is Probable
    • Programmers Act Like Jocks

  • Chapter 8 - An Obsolete Culture
    • The Culture of Programming
    • Reusing Code
    • The Common Culture
    • Programming Culture at Microsoft
    • Cultural Isolation
    • Skin in the Game
    • Scarcity Thinking
    • The Process Is Dehumanizing, Not the Technology

Part IV - Interaction Design Is Good Business

  • Chapter 9 - Designing for Pleasure
    • Personas
    • Design for Just One Person
    • The Roll-Aboard Suitcase and Sticky Notes
    • The Elastic User
    • Be Specific
    • Hypothetical
    • Precision, Not Accuracy
    • A Realistic Look at Skill Levels
    • Personas End Feature Debates
    • Both Designers and Programmers Need Personas
    • It's a User Persona, Not a Buyer Persona
    • The Cast of Characters
    • Primary Personas
    • Case Study: Sony Trans Com's Passport
    • The Conventional Solution
    • Personas
    • Designing for Clevis

  • Chapter 10 - Designing for Power
    • Goals Are the Reason Why We Perform Tasks
    • Tasks Are Not Goals
    • Programmers Do Task-Directed Design
    • Goal-Directed Design
    • Goal-Directed Television News
    • Goal-Directed Classroom Management
    • Personal and Practical Goals
    • The Principle of Commensurate Effort
    • Personal Goals
    • Corporate Goals
    • Practical Goals
    • False Goals
    • Computers Are Human, Too
    • Designing for Politeness
    • What Is Polite?
    • What Makes Software Polite?
    • Polite Software Is Interested in Me
    • Polite Software Is Deferential to Me
    • Polite Software Is Forthcoming
    • Polite Software Has Common Sense
    • Polite Software Anticipates My Needs
    • Polite Software Is Responsive
    • Polite Software Is Taciturn About Its Personal Problems
    • Polite Software Is Well Informed
    • Polite Software Is Perceptive
    • Polite Software Is Self-Confident
    • Polite Software Stays Focused
    • Polite Software Is Fudgable
    • Polite Software Gives Instant Gratification
    • Polite Software Is Trustworthy
    • Case Study: Elemental Drumbeat
    • The Investigation
    • Who Serves Whom
    • The Design
    • Pushback
    • Other Issues

  • Chapter 11 - Designing for People
    • Scenarios
    • Daily Use Scenarios
    • Necessary Use Scenarios
    • Edge Case Scenario
    • Inflecting the Interface
    • Perpetual Intermediates
    • Pretend It's Magic
    • Vocabulary
    • Breaking Through with Language
    • Reality Bats Last
    • Case Study: Logitech Scanman
    • Malcolm, the Web-Warrior
    • Chad Marchetti, Boy
    • Magnum, DPI
    • Playing Pretend It's Magic
    • World-Class Cropping
    • World-Class Image Resize
    • World-Class Image Reorient
    • World-Class Results
    • Bridging Hardware and Software
    • Less Is More

Part V - Getting Back into the Driver's Seat

  • Chapter 12 - Desperately Seeking Usability
    • The Timing
    • User Testing
    • User Testing Before Programming
    • Fitting Usability Testing into the Process
    • Multidisciplinary Teams
    • Programmers Designing
    • How Do You Know?
    • Style Guides
    • Conflict of Interest
    • Focus Groups
    • Visual Design
    • Industrial Design
    • Cool New Technology
    • Iteration

  • Chapter 13 - A Managed Process
    • Who Really Has the Most Influence?
    • The Customer-Driven Death Spiral
    • Conceptual Integrity Is a Core Competence
    • A Faustian Bargain
    • Taking a Longer View
    • Taking Responsibility
    • Taking Time
    • Taking Control
    • Finding Bedrock
    • Knowing Where to Cut
    • Making Movies
    • The Deal
    • Document Design to Get It Built
    • Design Affects the Code
    • Design Documents Benefit Programmers
    • Design Documents Benefit Marketing
    • Design Documents Help Documenters and Tech Support
    • Design Documents Help Managers
    • Design Documents Benefit the Whole Company
    • Who Owns Product Quality?
    • Creating a Design-Friendly Process
    • Where Interaction Designers Come From
    • Building Design Teams

  • Chapter 14 - Power and Pleasure
    • An Example of a Well-Run Project
    • A Company-Wide Awareness of Design
    • Benefits of Change
    • Let Them Eat Cake
    • Changing the Process

  • Index
 
analysis bookstore top
Business Analysis Books: Reviews
Buy the book
Amazon.com
In this book about the darker side of technology's impact on our lives, Alan Cooper begins by explaining that unlike other devices throughout history, computers have a "meta function:" an unwanted, unforeseen option that users may accidentally invoke with what they thought was a normal keystroke. Cooper details many of these meta functions to explain his central thesis: programmers need to seriously reevaluate the many user-hostile concepts deeply embedded within the software development process.

Rather than provide users with a straightforward set of options, programmers often pile on the bells and whistles and ignore or deprioritize lingering bugs. For the average user, increased functionality is a great burden, adding to the recurrent chorus that plays, "computers are hard, mysterious, unwieldy things." (An average user, Cooper asserts, who doesn't think that way or who has memorized all the esoteric commands and now lords it over others, has simply been desensitized by too many years of badly designed software.)

Cooper's writing style is often overblown, with a pantheon of cutesy terminology (i.e., "dancing bearware") and insider back-patting. (When presenting software to Bill Gates, he reports that Gates replied: "How did you do that?" to which he writes, "I love stumping Bill!") More seriously, he is also unable to see beyond software development's importance--a sin he accuses programmers of throughout the book.

Even with that in mind, the central questions Cooper asks are too important to ignore: Are we making users happier? Are we improving the process by which they get work done? Are we making their work hours more effective? Cooper looks to programmers, business managers, and what he calls "interaction designers" to question current assumptions and mindsets. Plainly, he asserts that the goal of computer usage should be "not to make anyone feel stupid." Our distance from that goal reinforces the need to rethink entrenched priorities in software planning. --Jennifer Buckendorff

Booknews, Inc.
Armed with solutions to the dilemma of how dependent every one of us is becoming on electronic products, the author argues that, despite appearances, business executives are simply not in control of the high-tech industry. He explains how talented people continuously design bad technology-based products and uses his own work to show businesses of all sizes how to harness talent to create products that will both thrill users and grow the bottom line.

 
analysis bookstore top
 
Requirements
  Business Rules
Prototyping
Requirements Analysis
Requirements Definition
Requirements Documentation
Requirements Engineering
Requirements Management
Requirements Traceability
User Interfaces
Miscellaneous
Requirements Validation
  Acceptance Testing
Test Cases
Test Data Engineering
Test Planning
Testing Tools
Business Process Modeling (BPM)
  Data Flow Diagrams
Decision Tables
Process Analysis
Process Improvement (BPI)
Process Models
Facilitation
  Conducting Meetings
JAD
Miscellaneous
Data Analysis
  Data Models
Miscellaneous
NEW RELEASES
Business Systems Analysis
Best Practices
Interviewing Techniques
Methodologies
Problem Analysis
Request for Proposal (RFP)
Requirements Elicitation
Task Analysis
Unified Modeling Language (UML)
Use Cases
Workflow Analysis
Home Links CBAP Business Analyst Skills Test Business Anlayst Training Inquiry