Alan Alda's Interviewing Tips for Uncovering Business Requirements Perhaps you've observed too-smart interviewers. Interviewers who try to impress others are missing the point. Ask simple, straightforward questions and you'll have a better chance of understanding complex concepts. (Apr. 2005 IntelligentEnterprise)

Picture Perfect Instead of asking customers what they want in a transaction or report or screen layout, and expecting them to provide precise specifications, it might generate more useful information to ask, "Which of these pictures (or options, formats, functions, designs, layouts, or whatever) is closest to what you want? And how does what you want differ?" (Jun. 2004 StickyMinds)

A Rational Design Process: How and Why to Fake It The picture of the software designer deriving his design in a rational, error­-free, way from a statement of requirements is quite unrealistic. No system has ever been developed in that way, and probably none ever will. Even the small program developments shown in textbooks and papers are unreal. (Sep. 2003 CobolReports)

Can Programmers Do Interaction Design? What differentiates H. logicus from Homo sapiens isn’t an addiction to caffeine or an aversion to daylight; it’s a difference in how we look at the world. To be fair to the programmers, they’re working trial-and-error because they can’t read minds, which is what it would take to turn the average Marketing Requirements Document into a product people can see and use. (Aug. 2003 Cooper Design)

Talking the talk The IT group wanted something with a lot of bells and whistles but couldn't agree on the details. Topics ranged from which products should be evaluated to whether servers and mainframes also should be managed. They were upset with business management whom they said were "stupid" and "weren't listening." Management was thinking of canning the project. (Jun. 2003 Network World Fusion)

Give ’em the Business I have a theory. I think that technical people are being insulated from important business matters. Perhaps it's because management wants technical people to concentrate on technical concerns. Perhaps it's because management isn't convinced that technical people understand anything about business strategy. (May 2003 StickyMinds)

Visual Requirements A good model possesses the soul of a crash-test dummy: it tests our ideas, facts, and assumptions; it is infinitely adjustable; and it can be tested repeatedly until we discover what we need. The best way to wipe out bugs is to find them before they're even created, when they're only drawings on the whiteboard. (May 2003 Software Testing and Quality Engineering)

Are You Passing the Requirements Buck? Are defining requirements and prioritizing them solely the responsibility of business-side stakeholders and not the concern of developers? It would be great if you had interested, technically astute business people who could clearly formulate software requirements and help with design and who are given adequate time to devote to the process, but this circumstance is far too rare to expect. (Apr. 2003 DevX)

Assuming the Worst about Requirements The pursuit of one discipline in college tends to produce vertical thinkers — deep reasoning down a specific path to arrive at a conclusion. To be good at analyzing anything you need to learn lateral thinking — broad, pattern thinking, which generates new patterns by changing perspective. (Mar. 2003 StickyMinds)

Across the Chasm Inside many IT organizations, cowboy programmers and code slingers are lionized as role models; the relationship with businesspeople is something begrudgingly to be managed, an inconvenience at best, a necessary evil at worst. IT teams want to get to code as soon as possible, and business requirements are just an obstacle to that goal. (Mar. 2003 Intelligent Enterprise)

How to avoid IT project failure Traditionally, businesses deal with legacy systems by creating more legacy systems - building layer upon layer, creating an overly complex base for a system that will be extremely difficult to adapt. In many cases, about 70 per cent of the entire code of a system is there to deal with exceptions which occur so infrequently as to make the investment questionable. (Feb. 2003 Silicon.com)

Making Your Design Real You've devoted time and energy to creating the perfect, goal-directed design for your product. Your programmers are ready and eager to start putting that design into code. So…now what? How do you communicate your design to your development team, accurately and in sufficient detail? (Jan. 2003 Cooper)

Do Requirements Change? The real business requirements for successful software are quite stable, even over relatively long periods of time. The apparent fluidity of requirements arise because the user fails utterly to express the real demands on the software usefully. Expecting a user to understand software design is like expecting a taxi driver to understand vehicle design. (Jan. 2003 Visual Studio)

See You in Court Outsourced or package projects that fail too often result in lose-lose litigation. Solid requirements and project management practices, coupled with effective communication and collaboration, will help keep lawyers from sucking your bank account dry while dueling with your supplier's counsel over a broken contract. (Jan. 2002 Software Development)

Why We Don't Build Software for Users There's a significant layer on top of programming that provides the bridge between business management and software construction. Real software architects do effective planning — they do research, work with stakeholders, and distill what the real goals are. Then they begin to synthesize a real solution and collaborate with the builders as they build. (Dec. 2002 Visual Studio Magazine)

The Paradox of ROI Most ROI studies have serious flaws that, at best, make it hard to translate the study's ROI numbers to your organization's real-world case. Even if a researcher can create one perfect set of questions to ask, few, if any, customers have the appropriate data, much less the time, to answer the questions. (Nov. 2002 Intelligent Enterprise)

A Measured Response I introduced metrics into a software company. They began the project thinking their customers were satisfied. Weekly alertsite and hotsite indexes demonstrated there was significant room for improvement. This led to a weekly meeting where lead developers met with the CEO to discuss how to lower the indexes. (Sep. 2002 Software Testing & Quality Engineering)

Requirement #1: Ask Honest Questions Use context-free and meta-questions to get past assumptions: "How does this work?" and "How might it be different?" may come back with surprises you hadn’t anticipated. Your clients will give better answers when you recognize that they are the experts. (Mar. 2002 StickyMinds)

Karl Wiegers Describes Ten Requirements Traps to Avoid Despite considerable evidence that it doesn’t work, many projects seem to rely on telepathy as the mechanism for communicating requirements from users to developers. Slighting the processes of requirements development and management is a common cause of software project frustration and failure. (Feb. 2002 StickyMinds)

Inspecting Requirements Industry data suggests that approximately 50 percent of product defects originate in the requirements. Perhaps 80 percent of the rework effort on a development project can be traced to requirements defects. Instead of waiting until the big honkin’ requirements specification is done, start holding informal reviews when it is perhaps 10 percent complete. (July 2001 StickyMinds)

Don't Be A Creep If someone comes up with a great new feature halfway through a project that will deliver greater business benefits than most of the other functionality already slated by the project's owners-that's not creep. That's smart thinking. In the digital economy, smart IT resource prioritization is a strategic competitive advantage. (May 2001 NetworkMagazine)

Balancing Act One of the significant departures from traditional project models is the extension of requirements analysis throughout the first half of the project cycle. In conjunction with analyzing requirements, it's important to produce prototypes to serve as straw men for feature sets and provide a realistic simulation target for evaluating alternatives. (Mar. 2001 Intelligent Enterprise)