- Paperback: 480 pages
- Publisher: Butterworth-Heinemann; 1 edition (August 30, 2005)
- Language: English
- ISBN-10: 0890422982
- ISBN-13: 978-0750665070
- ASIN: 0750665076
- Product Dimensions: 6.5 x 1.1 x 9.5 inches
- Shipping Weight: 1.8 pounds (View shipping rates and policies)
- Average Customer Review: 15 customer reviews
- Amazon Best Sellers Rank: #1,692,769 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
Customers who viewed this item also viewed
“This stuff works. Competitive Engineering contains powerful tools that are both practical and simple - a rare combination. Over the last decade, I have applied Tom Gilb's tools in a variety of settings including product development, service delivery, manufacturing, site construction, IT, eBusiness, quality marketing, and management, on projects of various sizes. Thousands of engineers have been through Competitive Engineering training and Planguage workshops that I have authored. The vast majority of students immediately recognize their value and go on to use them beneficially on projects. Competitive Engineering is based on decades of practical experience, feedback, and improvement, and it shows.
― Erik Simmons, Intel Corporation, Requirements Engineering Practice Lead, Corporate Quality Network
“Fundamentally, the book presents a new take on best practices in systems engineering and management… The book passed my value-added test, when I realized that I was photocopying several pages for future reference, to be part of my “toolkit of helpful tips and techniques. I particularly enjoyed reading the 10 often witty, summary principles in each chapter…Perseverance pays off with Competitive Engineering. The book is not a quick read, which Tom acknowledges. You have to carefully study some of the pages to understand the concepts being presented. The reward occurs when you glean the nuggets of wisdom from the numerous practical examples, case studies, and Planguage examples. Tom’s way of presenting the CE concepts makes the book a useful addition to the systems engineer’s library.
― Jerry Huller, Raytheon
“I found Planguage to be an interesting and noble idea for the enhancement of communication in the product development environment…Systems engineering professionals wanting another perspective on applying SE techniques to real product development and those wanting to add additional techniques/ methods to their toolbox will gain most from this book. Readers should have a fundamental knowledge of systems engineering principles and some practical product development experience to realize the full value of this work. I found the chapters describing "Impact Estimation", "Evolutionary Project Management" and "Specification Quality Control" to be specifically relevant and ripe for application to various product development environments.
Overall, the book passes my acid test as a useful reference for Systems engineering professionals... Tom meets his objectives in providing a current definition of Planguage concepts and providing a handbook of fundamental SE principles ready for application with his practical experience and unique product development perspective.
― Martin Coe President-Closed Loop Engineering, Technical Program Director- INCOSE Colorado
“…for those professionals serious about tackling the requirements specification effort in any real project. I am excited about it. He offers his Planguage for structuring the system engineering process and gets at issues of risk, success and failure criteria and evolutionary project development in a rational way. This book is a must read, re-read and study for students and practitioners working in the murky area of mapping the problem domain to the solution domain…It is, as promised, a Handbook. Buy it, and you will use it. It will not collect dust on your bookshelf. This book is a wonderful contribution to our Software Engineering literature.
― ACM SIGSOFT Software Engineering Notes, January 2006
“Competitive Engineering is an original, experience-based, stimulating, thought-provoking, entertaining, and well worth reading software engineering book.
― IMPROVE, Software Process Improvement Newsletter
“Tom Gilb, the father of the Evo methodology, shares his practical, real-world experience for enabling effective collaboration between developers, managers and stakeholders.
Although the book describes Planguage (a specification language for systems engineering) in detail, the methodological advice alone is worth the price of the book. Evo is one of the truly underappreciated agile methodologies, and as a result, Gilb's thought-provoking work isn't as well-known as it should be, although I suspect that that will change with this book. The book describes effective practices for requirements and design specification that are highly compatible with the principles and practices of Agile Modeling, yet it goes on to address planning activities, quality and impact estimation. I suspect that this book will prove to be one of the "must read" software development books of 2006.
― SD's Agile Modeling Newsletter, February 2006, By Scott W. Ambler, Ambysoft
“I found the rules, principles, and process descriptions associated with the Planguage method particularly interesting and helpful.
― Jayesh G. Dalal, Software Quality Professional, June-August 2006
Competitive Engineering is a revolutionary project management method, proven by organizations worldwide
Top customer reviews
There was a problem filtering reviews right now. Please try again later.
Alas I cannot comment about how well his approach works, but it was highly recommended by academics in systems engineering.
Specifically, I found the various requirement-development templates that were provided as a good means of collecting thoughts around requirement topics. In my attempts to apply the templates, they helped refine my thoughts as to the issues surrounding requirements development.
The book refers to the author's web site for further information and examples. I'd give that site a 2 ½ star rating, as the information there was rougher information than provided in the book.
I'd recommend this book for anyone contemplating requirement development. The reader is left to generate their own examples.
The centrality of quality specifications means significant gains for the broadest spectrum of stake-holders who stand to win with the System Of Interest (SOI). Take this specification as an example to clean up:
"The new system will use Foo language running on OS Bar and ensure top industry quality response time on web requests."
People in the field have seen specs like these. Hopefully you aren't writing them. There are what Gilb classifies as "Major defects" in this spec. Which web requests, the front page or all of them pulling from the various databases? Can the old system be incrementally upgraded instead of an entirely new development environment? Why use Foo and Bar if something else gets the job done better, faster, and with less resource utilization? Just how fast is "fast", anyway?
In Competitive Engineering you're told to get measureable quality requirements, record who requested that requirement, and exactly what "success" is defined as. That allows you to go back to the requester with notes such as "If we use OS Baz we'll get a 27% increase in CPU performance" and let them make a decision or escalate to the project funder. You're also encouraged to weed out "design constraints"; at least out of the mandatated and into the labelled area "Design Constraint". Wouldn't it be great if you got a specification that let you design the best you could without technical input from someone that can't use a web-browser?
See if you can understand my re-write of the above spec into Planguage.
Response Time on Front Page of Company Website.
Type: Performance Requirement
Owner: F. Flintstone
Stakeholders: Marketing, Server Support, Corporate Intelligence, , <Current Advertisers/Business partners>
Ambition: The front page of the corporate website should respond fast enough to keep the viewer's attention.
Description: Marketing research indicates the typical business website viewer makes an opinion on the website, and thus the company, within 20 seconds. Our corporate site pulls data from three different databases and a sizeable image library, taking an average of 26.87 seconds on a home DSL/Cable modem equivalent network. Marketing advantage can be gained if we can grab viewer attention noticibly faster than our two nearest competitors who average 23.43 and 26.09 seconds, respectively.
Vision: Enough accurate information provided quickly enough to keep the customer on our site.
Scale: Time, in Seconds, to a complete front page load on the equivalent of a 250K network connection.
Past [Front page, 1 Apr 07]: 26.87 seconds
Goal [1 November 07]: 19 seconds <- Marketing Director: BR
Stretch: 15 seconds
Wish: 9 seconds
Design Constraint: Supportability <- Server Support Manager WF Must utilize <Currently supported OS/Hardware>.
Design Constraint: Security <- Corporate Intelligence BB Must meet <Current security guidelines>.
------------------------ end of spec example --------------------
Probably the only thing that might confuse you about that specification is the use of text within "<...>". Planguage uses that to denote a "fuzzy requirement"; something that is defined but not with the concreteness you'd like. In this example, however, it would be relatively simple to query B. Rubble for the specific guidelines her team seeks to enforce. The use of fuzzy requirements also allows for change over time; more OS versions may become supported while others are obsolete.
When I read part of an electronic copy of the text I had a problem. My antiquated home printer could not print it and if I used the work printer I view the output as a possession of my employer. The book is written as part instruction, part reference manual; I bought my own copy because I know I'm going to use it for the next few years and several employers.