- Define the Real Customer Needs
- Pitfalls
- Summary
- Key References and Suggested Readings
Key References and Suggested Readings
Barry Boehm. WinWin Spiral Model & Groupware Support System. 1998 Available at http://sunset.usc.edu/research/WINWIN/index.html. Dr. Boehm is Director of the University of Southern California Center for Software Engineering. The Center is under contract to the Defense Advanced Research Projects Agency via the Air Force Research Laboratory (formerly known as Rome Laboratories). It plans to develop (in collaboration with The Aerospace Corporation) a robust version of the WinWin System and to apply it to the domain of satellite ground stations.
Barry Boehm, Alexander Egyed, Julie Kwan, Dan Port, Archita Shah, and Ray Madachy. "Using the WinWin Spiral Model: A Case Study." IEEE Computer 1998:31 33–44. This University of Southern California Center for Software Engineering research project has three primary elements: (1) Theory W, a management theory and approach that says making winners of the system's key stakeholders is a necessary and sufficient condition for project success; (2) the WinWin Spiral Model, which extends the spiral software development model by adding Theory W activities to the front of each cycle; and (3) WinWin, a groupware tool that makes it easier for distributed stakeholders to negotiate mutually satisfactory system specifications. The authors found in this work that the most important outcome of product definition is not a rigorous specification but a team of stakeholders with enough trust and shared vision to adapt effectively to unexpected changes. The researchers believe that the approach will transition well to industry use.
Daniel P. Freedman and Gerald M. Weinberg. Handbook of Walkthroughs, Inspections, and Technical Reviews. 3rd ed. Chicago: Scott, Foresman and Co., 1990. This book provides a variety of examples of peer reviews and is a good source for organizations that want to consider alternative approaches.
Donald C. Gause and Gerald M. Weinberg. Are Your Lights On? How to Know What the Problem REALLY Is. 2nd ed. New York: Dorset House Publishing, 1989. As the title suggests, this book is interesting and light reading but offers valuable insights concerning real needs. The authors' perspective is that customers need assistance in defining their real requirements. A good requirements process will (1) identify the real problem, (2) determine the problem's "owner," (3) identify its root cause, and (4) determine whether to solve it. This is recommended reading for requirements engineers and their customers.
Tom Gilb and Dorothy Graham. Software Inspection. Reading, MA: Addison-Wesley, 1993. This book is about inspections of any work product, not just software. The authors' approach is very rigorous and therefore requires more training and is more expensive than normal peer reviews. However, it results in more defects being removed earlier, thus saving costs later in the development cycle. This book is invaluable for an organization that is committed to using inspections of work products—a proven method with good payback. Note that Rob Sabourin offers an economical inspections training and implementation approach. Contact him at rsabourin@amibug.com.
Rita Hadden. "How Scalable Are CMM Key Practices?" CROSSTALK 1998: vol. 11(4) 18–23. Hadden provides process improvement consulting services for organizations of all sizes. She notes that many practitioners are convinced that models such as the SW-CMM are not practical for small organizations because the cost of applying the recommended practices outweighs benefits. Her experience with more than 50 small projects does not support this view. The article describes using a disciplined, repeatable approach for projects of short duration. She concludes that CMM key practices are scalable.
Ivy Hooks. Guide for Managing and Writing Requirements. 1994. Available at ivyh@complianceautomation.com. This is a concise, well-written guidebook based on extensive experience by a practicing requirements engineer and consultant. It addresses scoping a project, managing requirements, how systems are organized, and levels of requirements, writing good requirements, requirements attributes, and specifications.
Ivy Hooks. Managing Requirements. 1994. This white paper is available at the Compliance Automation Web site http://www.complianceautomation.com/. It provides a good analysis of how failure to invest in the requirements process affects projects, and it describes major problems based on Hooks's experience. Also, it describes some of the characteristics of good requirements.
Ivy Hooks. Writing Good Requirements: A One-Day Tutorial. McLean, VA, 1997 Compliance Automation, Inc. Sponsored by the Washington metropolitan area chapter of the International Council on Systems Engineering, June 1997. This is an example of the types of briefings and courses that can be provided to facilitate a project or an organization in dealing with the requirements process. The pearl here is to ensure that you have a requirements process and that you take advantage of industry best practices in executing it. Don't find your own way and learn the errors of your ways at considerable financial, personal, project, and organizational costs.
Pradip Kar and Michelle Bailey. Characteristics of Good Requirements. 1996. Available at http://www.complianceautomation.com/. This document provides a valuable, readily available discussion of the characteristics of individual and aggregate requirements (note that characteristics of individual requirements are applicable to aggregates too). Kar and Bailey emphasize that writing good requirements is difficult, requires careful thinking and analysis, but is not magical. Time spent up front, carefully defining and articulating the requirements, is essential to ensuring a high-quality product. This is recommended reading for requirements engineers.
Joachim Karlsson and Kevin Ryan. "A Cost-Value Approach for Prioritizing Requirements." IEEE Software 14(5) 1997: 67–74. This is an excellent article that explains a method for prioritizing requirements (see the summary of their method provided in this chapter). Karlsson and Ryan provide a process for using the cost-value approach, utilizing the Analytic Hierarchy Process (AHP), which is also explained in their article.
Geri Schneider and Jason P. Winters. Applying Use Cases: A Practical Guide. Reading, MA: Addison-Wesley, 1998. This is a practical guide to developing and using use cases. Schneider and Winters provide examples from their experience and provide a case study that offers insight into common errors. An illustration of the UML notation for diagramming use cases is provided. Of particular use to requirements engineers is a "how-to" discussion on applying use cases to identify requirements.
I. Sommerville, P. Sawyer, and S. Viller. "Viewpoints for Requirements Elicitation: A Practical Approach." In: Proceedings of the 1998 International Conference on Requirements Engineering (ICRE'98), April 6–10, 1998, Colorado Springs, CO. New York: IEEE Computer Society, 1998: 74–81. Sommerville and colleagues introduce an approach called PREview to organize requirements derived from radically different sources. They show how concerns that are key business drivers of the requirements elicitation process may be used to elicit and validate system requirements. They note that PREview has been designed to allow incremental requirements elicitation (see Figure 4-12 for a high-level view of the PREview process).
Gerald M. Weinberg. The Secrets of Consulting. New York: Dorset House Publishing, 1986. Weinberg defines consulting as the art of influencing people at their request. As noted by Virginia Satir in the foreword, this book actually advises people on how they can take charge of their own growth. The author provides a light-hearted view of the role of a consultant, sharing valuable insights about people. A fundamental tenet is that we all need to follow a personal learning program. Several sources for readings and other experiences are provided.
Karl Wiegers. "First Things First: Prioritizing Requirements." Software Development Magazine 1999: 7(10):24–30. This is a good explanation of why requirements need to be prioritized and a helpful description of how to do it. Wiegers provides a Microsoft Excel requirements prioritization spreadsheet and other requirements tools that can be downloaded from his Web site, http://www.processimpact.com.
Karl Wiegers. "Habits of Effective Analysts." Software Development Magazine 2000: 8(10):62–65. See also http://www.sdmagazine.com. Wiegers provides thoughtful and provocative insights concerning the role of the requirements engineer (also called the requirements analyst, business analyst, systems analyst, or requirements manager), patterned after Steven Covey's acclaimed book The Seven Habits of Highly Effective People (Fireside, 1989). He emphasizes that requirements engineering has its own skill set and body of knowledge, which is given scant attention in most computer science educational curricula and even by most systems and software engineering organizations. Many organizations expect developers or project managers to handle this vital function on their own. A competent requirements engineer must combine communication, facilitation, and interpersonal skills with technical and business domain knowledge. Even a dynamite developer or a systems-savvy user needs suitable preparation before acting in this role. Wiegers recommends that every organization should develop an experienced cadre of requirements analysts, even though requirements engineering may not be a full-time function on every project. This article is recommended reading for all PMs and task leaders.