Robin Goldsmith
ROBIN GOLDSMITH has been president of Go Pro Management, Inc. consultancy since 1982. He specializes in requirements, quality/testing, software acquisition, project management, process improvement, metrics and Return on Investment (ROI). A prominent speaker and trainer, he is author of numerous articles, the Proactive Testing(tm) and REAL ROI(tm) methodologies, and the Artech House book Discovering REAL Business Requirements for Software Project Success.
Recent Comments
On “Examining the Software Development Lifecycle ”:
09:20 AM on February 06, 2010
Proactive Testing™ includes: 1. Using additional, more powerful approaches and techniques that most organizations don’t know about to plan and design Proactive User Acceptance Testing™ separately from traditional technical/development testing, up-front for execution at the end. UAT should be planned and designed in conjunction with defining the REAL business requirements, which generally involves far more than organizations typically consider. 2. Applying more than 21 ways to evaluate requirements accuracy and completeness, as well as clarity and testability. Most organizations use only one or two, typically weaker-than-realized, techniques to check requirements. 3. Applying more than 15 ways to evaluate design accuracy and adequacy. Again most organizations use only one or two techniques. 4. Using powerful, special Proactive Master Test Planning techniques early to identify ordinarily-overlooked big showstopper risks and to structure the testing so it most economically addresses the most important risks. 5. Using similar techniques to plan the most important detailed unit, integration, special, and system tests. These methods invariably spot numerous ordinarily-overlooked medium-sized feature, function, and capability risks that need to be tested. 6. For the most important, using powerful structured techniques to identify the set of test cases that need to be executed to give confidence the features, functions, and capabilities work. These methods further spot numerous small-risk test conditions that ordinarily are overlooked. 7. As with all the above, risks are analyzed to identify, implement, and execute the tests dealing with the highest risks for the most important things. 8. These methods enable catching and preventing many of the errors that traditional development and reactive testing miss. Executing the more thorough set of Proactive User Acceptance Tests which was designed early in fact catches more of the remaining fewer defects. 9. Proactive Testing™ enables delivering far better code, quicker and cheaper.
On “Bridge the Gap and Build the Right Software”:
11:23 AM on December 11, 2009
While multidirectional communications certainly are important, there’s a more fundamental flaw in this model that communication alone will not cure. So long as what the analysts define as the requirements have to be “communicated” to the business/users/customers/stakeholders, you don’t have the REAL requirements and will continue to suffer creep. REAL requirements are the business’/users’/customers’/stakeholders’. They are not what a developer translates into code. Developers code from design. A product, system, or software is not translated from, but rather is a high-level design response to the REAL, business requirements deliverable _whats_ that provide value when satisfied by the product _how_. The analysts’ first job is to discover what the REAL business requirements are. That involves much more than merely documenting customer requests; and too few analysts know to do it or how to do it. Reconciling various jargons is much less an issue because REAL business requirements are in the language of the business, which everyone should understand, but often don’t. Moreover, REAL business requirements tend to change relatively little. Rather, what is characterized as change mainly is changing awareness of unchanged, but previously unrecognized, REAL business requirements. When the REAL business requirements are not defined adequately, usually because conventional models don’t know to do it and instead encourage going directly to designing a presumed product solution, the product invariably fails to do what the business needs to achieve value. Merely more clearly communicating about the wrong product is unlikely to reveal what it should be, because the product sounds fine when it has no REAL requirements context.