|Karl Wiegers, Principal
Consultant at Process Impact, has written many books, eBooks, articles, and essays on
many aspects of software engineering, software management, and software process
improvement. Many of the articles are available here for downloading, courtesy
of the original publishers.
Software Requirements, 3rd Edition, by Karl Wiegers and Joy Beatty, will be published in August 2013 by Microsoft Press. This is a fully updated version of the best-selling, award-winning book whose previous editions were published in 1999 and 2003. Covering the full scope of software requirements development and requirements management, this is a "good practice" guide that can help you elicit, analyze, document, validate, and manage the requirements for any project. This new edition describes how to adapt the practices to projects following an agile development life cycle. New chapters are included on specifying data requirements, writing high-quality functional requirements, and requirements reuse. Considerable depth has been added on business requirements, elicitation techniques, and nonfunctional requirements. In addition, new chapters recommend effective requirements practices for various special project situations, including enhancement and reengineering, package solutions, outsourced, business process automation, analytics and reporting, and real-time and embedded systems projects. Available now for pre-ordering from Amazon.com and O'Reilly Media.
Practical Project Initiation: A Handbook with Tools was published in 2007 by Microsoft
Press. Project initiation is the process of formally conceiving, approving, and launching a new project.
This book describes many actions that lay the foundation for a successful project. Both experienced and novice project managers will find the practices described here to be valuable.
Topics covered include: defining project success criteria and product release criteria,
project chartering, risk management, lessons learned and project retrospectives, metrics,
and many others. Each chapter includes several practice activities and worksheets to
help you begin applying the techniques immediately. A companion web site
provides numerous templates, procedure descriptions, spreadsheet tools, and other work aids to
help you launch your next project more effectively.|
More About Software Requirements: Thorny Issues and Practical Advice was published in 2006 by Microsoft Press. A companion volume to Software Requirements, 2nd Edition, this book addresses many questions that requirements analysts ask over and over again, most of which are not covered well in the current books on software requirements engineering. Some of these thorny problems don't have perfect solutions, but the book offers the practicing analyst practical options and ways to select the best approach in a given situation. Chapters cover topics of particular interest to managers, points of confusion around the use case technique, how to optimize your customer involvement, different ways to represent requirements information, and some key issues regarding requirements management. Several chapters provide a wealth of advice on how to actually write excellent software requirements, at an appropriate level of detail and without unnecessary design constraints. As more and more companies outsource their software development, the need for high-quality requirements is increasing. This book can help any analyst elicit, document, and manage better requirements.
Software Requirements, 2nd Edition was published in 2003 by Microsoft Press. The first edition won a 1999 Productivity Award from Software Development magazine. This book describes several dozen practices that can help you gather, analyze, document, verify, and manage your software project requirements. The emphasis is on realistic practical methods and process improvement, not theoretical models. Business, user, functional, and nonfunctional requirements are all addressed. Topics covered include customer involvement in the requirements process, use cases, prototyping, requirements prioritization, the software requirements specification, change management, requirements traceability, requirements management tools, and managing requirements risks. The second edition features more depth on every topic, a comprehensive requirements troubleshooting guide, an integrated set of sample requirements documents, and new chapters on the role of the requirements analyst, defining and using business rules, and applying requirements engineering to maintenance projects, package solution projects, outsourced projects, and emergent projects.
Peer Reviews in Software: A Practical Guide was published in 2002 by Addison-Wesley. This is a concise description of software peer reviews and inspections. It covers the inspection process in some detail, but it also describes a variety of other review types that cover a spectrum of formality. Several chapters address the cultural and interpersonal aspects of peer reviews, installing a review program in an organization, and recording and using inspection metrics. The emphasis is on a simple, practical approach to these important quality techniques that any organization can apply.
Creating a Software Engineering Culture was published in 1996 by Dorset House Publishing. It won a Productivity Award from Software Development magazine. A healthy software engineering culture is one in which managers and practitioners share a commitment to building quality software through the application of effective and sensible software processes. The book describes 14 cultural principles that I think are important in guiding how software is built. If you share my belief that these principles are important, you'll apply technical and managerial practices that I think will lead to superior software.
Project Initiation Handbook
This 72-page eBook gives you the guidance you need to get your project off to a solid start. Both experienced and novice project managers
will find a wealth of practical advice here. Most people learn the importance of taking these initiation actions
only through painful experience, when they look back and say, "Gee, I wish I had thought about doing that a year ago." Applying the techniques described in this handbook will help keep your team focused on the significant outcomes that signal success
The eBook includes many worksheets so you can begin applying the techniques described immediately.
“Are We There Yet?” Software Development, vol. 13, no. 9 (June 2005). Defining your product's release criteria is an essential part of laying the foundation for a successful project. "It's June 30, so we must be done" isn't the best plan. Your criteria must be realistic, objectively measurable, documented and aligned with what "quality" and "success" mean to your customers. This article provides many examples of how (and how not) to write effective release criteria.
(This content now appears as Chapter 5 in Practical Project Initiation)
“See You In Court,” Software Development, vol. 11, no. 1 (January 2003). Too many outsourced software development project wind up in litigation. The root causes of the project failure and resulting legal conflict are often related to the project's requirements, to communication issues, or to the project management approaches used (or not used). This article presents 15 recommendations for keeping your outsourced project on track and out of court. A checklist helps you perform a health check on your project, to see if it's heading for trouble.
“Good Money After Bad,” StickyMinds.com, (January 2002). Many software projects that suffer a lingering death should have been canceled much earlier. Although it is hard to pull the plug on a project with a weak business case, failing to do so does throw good money after bad. This article gives some tips on decision making that can help you avoid this outcome and shows how to use decision points to keep a good project moving along.
“Stop Promising Miracles,” Software Development, vol. 8, no. 2 (February 2000). This article describes the Wideband Delphi method for team estimation. Wideband Delphi helps you develop a detailed task list with individual task estimates from several estimators and lists of estimation assumptions. The individual stages in the Delphi process are discussed in detail.
(This content now appears as Chapter 11 in Practical Project Initiation)
“Know Your Enemy: Software Risk Management,” Software Development, vol. 6, no. 10 (October 1998). This paper provides an introduction to the principles of identifying and managing risks on a software project. Typical risk factors in several categories are identified, and two forms for documenting individual risks are included.
“Standing on Principle,” Journal of the Quality Assurance Institute, vol. 11, no. 3 (July 1997). Adapted from the Creating a Software Engineering Culture book, this article gives many examples of high-integrity and high-intelligence interactions among managers, developers, and customers.
“Recognizing Achievements Great and Small,” American Programmer, vol. 10, no. 5 (May 1997). The importance of simple recognition and reward for a job well done is not appreciated by many software managers. This article describes many techniques for using recognition as a way to enhance the effectiveness of your group.
“Creating a Software Engineering Culture,” Software Development, vol. 2, no. 7 (July 1994). This article describes several cultural principles about software engineering that I think are important. These principles imply certain technical practices and managerial behaviors that are conducive to creating an environment focused on software quality through effective processes.
“Implementing Software Engineering in a Small Software Group,” Computer Language, vol. 10, no. 6 (June 1993). Here I describe the first part of a journey taken by a small group at Kodak, as we learned how to apply metrics, CASE tools, structured quality practices, and improved requirements techniques to build better products.
“Getting the Most from a Requirements Management Tool.” This 10-page white paper describes the many advantages
that requirements management tools provide over traditional specification documents, the typical capabilities of such
tools, and numerous tips for getting a high return on your investment in an RM tool. Available for purchase for just $5.00
along with a white paper on "The Business Value of Better Requirements." See Requirements Engineering Set 7.
“The Business Value of Better Requirements.” Poorly written, ambiguous, and incomplete requirements cost software organizations a lot of wasted time and money. This 6-page white paper describes the many benefits of investing in high-quality requirements development and management processes, including a way to think about the return on investment that you can enjoy by making such improvements. Available for purchase for just $5.00 along with a white paper on "Getting the Most from a Requirements Management Tool." See Requirements Engineering Set 7.
“So You Want to Be a Requirements Analyst?” Software Development, vol. 11, no. 7 (July 2003). Everyone talks about "requirements analysis," but not much is said about the requirements analyst. What kind of person should do this job? What do analysts really do? What do they need to know? This article addresses these questions and summarizes some key analyst skills: listening, interviewing, analysis, facilitation, observation, writing, modeling, and more. Tips for the new analyst coming from either the technical or the user domain are also provided.
“Requirements When the Field Isn't Green,” STQE, vol. 3, no. 3 (May/June 2001). Many software project involve adding enhancements to existing systems, rather than developing brand new, "green field," systems. This article describes seven principles that can guide how you apply sound requirements engineering practices on a maintenance project.
“Habits of Effective Analysts,” Software Development, vol. 8, no. 10 (October 2000). The requirements analyst plays an essential role on the software project team. Here I describe the habits, practices, and characteristics of effective requirements analysts. A list of critical skills the effective analyst must master is also included.
“When Telepathy Won't Do: Requirements Engineering Key Practices,” Cutter IT Journal, vol. 13, no. 5 (May 2000). The best way to succeed with requirements engineering is to adopt known industry best practices. Eight such key practices are described in this article, helping any organization improve the way it elicits, analyzes, specifies, verifies, and manages its requirements.
“Karl Wiegers Describes 10 Requirements Traps to Avoid,” Software Testing and Quality Engineering, vol. 2, no. 1 (January/February 2000). This article describes ten traps lurking in the requirements engineering minefield. Several symptoms that you might be stepping into each trap are presented, along with some suggested strategies for avoiding the trap or extricating yourself from it.
“Customer Rights and Responsibilities,” Software Development, vol. 7, no. 12 (December 1999). The requirements process is most effective when it's based on a customer-developer partnership. This article suggests a 10-item "Requirements Bill of Rights" for software customers, and a corresponding customer "Requirements Bill of Responsibilities". Use these as a starting point for a dialogue with your key customers about how best to collaborate. Requirements sign-off is also discussed.
“First Things First: Prioritizing Requirements,” Software Development, vol. 7, no. 9 (September 1999). When there's too much to do and too little time, you need to know which requirements are top priority and which can wait. This article describes a scheme for prioritizing a set of requirements, features, or use cases based on their relative value, cost, and technical risk. A supporting Excel spreadsheet helps you try out this technique on your project.
“Writing Quality Requirements,” Software Development, vol. 7, no. 5 (May 1999). This article identifies 10 characteristics of excellent requirement statements and requirements specifications, and it states several guidelines for writing high-quality requirements. Several examples of not-so-good requirements are given, along with some suggestions for better ways to write them.
“Listening to the Customer’s Voice,” Software Development, vol. 5, no. 3 (March 1997). This article describes a case study in the application of use cases to the requirements gathering process. Use cases are the most powerful technique for requirements elicitation I've ever used.
Software Process Improvement Handbook
This 72-page eBook addresses many issues that can help software organizations implement and sustain a
successful process improvement program. Whether you're using the CMM or CMMI as
a process improvement framework, or just trying to learn how to work more effectively, you'll find a wealth
of pragmatic guidance and useful insights about how to steer your organization toward better productivity and quality.
The eBbook includes many worksheets so you can begin applying the techniques described immediately.
“Software Process Improvement in Web Time,” IEEE Software, vol. 16, no. 4 (July/August 1999). Basic process improvement activities can benefit even fast-moving teams doing Web development. This paper describes how Kodak's web development group undertook improvements in several aspects of project management, post-project reviews, risk management, change control, requirements engineering, development life cycle, and peer reviews. The approach taken and lessons learned are also presented.
“Read My Lips: No New Models!,” IEEE Software, vol. 15, no. 5 (September/October 1998). This essay suggests that the software industry has more than enough models and frameworks for areas like process improvement, testing, metrics, inspections, risk management, and design methodologies. What we don't have is a large fraction of practitioners routinely applying these existing models in an effective way. Perhaps you'll agree with me; perhaps not.
“Misconceptions of the CMM,” Software Development, vol. 4, no. 11 (November 1996). This article describes 14 misconceptions I have heard people state as facts about the Software Capability Maturity Model. The true story behind each misconception is also revealed.
“Seven Truths About Peer Reviews,” Cutter IT Journal, vol. 15, no. 7 (July 2002).
This article highlights seven important facts about peer reviews: peer reviews can take many forms;
inspections are a software industry best practice; there is no one true inspection method; peer reviews
complement testing; peer reviews are both technical and social activities; managers can make or break
a review program; and a peer review program doesn't run itself.
“Do Your Inspections Work?” StickyMinds.com, June 24, 2002. This is a condensed overview of three ways to measure results from your inspections: efficiency, effectiveness, and return on investment. It describes several data items that you can easily collect from your inspections and some simple metrics to calculate from those data items. Inspections provide an easy way to begin a quality metrics program.
“Humanizing Peer Reviews,” STQE, vol. 4, no. 2 (March/April 2002). Peer reviews are at least as much a social interaction as a technical exchange. This article addresses some of the social and cultural aspects of peer reviews, including ways to overcome resistance to the process, benefits that reviews provide for various team members, the role of management, and 10 signs of management commitment to the review process.
“When Two Eyes Aren't Enough,” Software Development, vol. 9, no. 10 (October 2001). Several different types of activities called "peer reviews" are described here, including inspections, team reviews, walkthroughs, pair programming, peer deskchecks, and passarounds. A table suggests which types of peer reviews are best suited for achieving specific review objectives.
“When Reviewers Can't Meet,” StickyMinds.com (August 2001). When participants in a peer review cannot meet face-to-face, you need to use distributed or asynchronous review techniques. This article describes several ways to deal with reviewers who are separated by space or time.
“Seven Deadly Sins of Software Reviews,” Software Development, vol. 6, no. 3 (March 1998). This article describes 7 common ways that technical reviews go wrong. Symptoms of the problem, and suggestions for getting the review back on track are also presented.
“Improving Quality through Software Inspections,” Software Development, vol. 3, no. 4 (April 1995). The basic elements of formal and informal software reviews are presented here, including a description of the formal inspection process.
“A Software Metrics Primer,” Software Development,
vol. 7, no. 7 (July, 1999). This article presents a brief overview of software
measurement. It describes why measurement is important, what you should measure,
and some techniques for creating a measurement culture in your organization. A
number of metrics that are appropriate for individuals, development teams, and
software organizations to collect are suggested, along with several tips for
making your metrics program succeed.
“Lessons from Software Work Effort Metrics,” Software Development, vol. 2, no. 10 (October 1994). Several groups at Kodak found that measuring the time spent on 6 different new development phases and 4 different maintenance activities not only wasn't that hard, but provided considerable insights into the way software was being constructed in those groups.
Last Modified: Monday, 18-Feb-2013 21:47:10 GMT