Requirements Engineering: A Good Practice Guide
Requirements engineering is one facet of large project development that is often overlooked. If more effort is put into the definition and documentation of what the system is to do, the end result will be more reliable and easier to improve. Requirements need formal analysis and review before the work begins. This book provides a guide to do this in a rigid, structured manner that will produce documentation and test plans needed to design a successful system.
Review By: Karen Johnson
03/12/2010I found this book to be quite basic, covering what is well known in the industry. On the one hand, it was a requirements refresher course and on the other hand, I didn’t find much new. As a refresher, it reminded me to consider whether requirements are well defined and testable. But the book didn’t share any experiences on how to amend or rewrite requirements that are not testable. It reminded me that stakeholders don’t always agree with each other and what havoc that causes on defining requirements. It didn’t offer any insights on resolving the political stickiness that occurs when stakeholders don’t agree. Although the book points to the practice of building user scenarios as a means to determine what is really needed from the proposed requirements, I didn’t learn any tips or tricks to harvest better user scenarios.
A quality assurance or testing person might not learn anything additional about requirements if they’ve been in the industry for a while. A newcomer could use the book as their first level class. This book would be best used as a reference book rather than as a straight read. Someone could use the chapters on the requirements document and requirements validation as they write or approve requirements or plan testing. Throughout the book, the section headings and summaries are well written and concise. Use the section headings as reminders throughout the requirements process. I didn’t use the index but it looked thorough. All of these things add to the book being used as a possible reference tool. This requirements book is written as a primer for the entire requirements cycle. The book addresses the requirements process, the requirements document, analysis and negotiation, describing requirements, system modeling, validation, management, requirements for critical systems, and formal specifications. I’ve detailed some highlights from the book.
Chapter 2, Practical Process Improvement, discusses the capability maturity model (CMM). A chart of basic guidelines lasting several pages, is concise, well thought out, and one of the book’s best assets. The chart pairs each tip with where in the requirements cycle the tip would be most applicable.
Chapter 8, Requirements Validation, is a natural chapter to read first for people in quality assurance, but the chapter offers little new information. Experienced quality assurance people can use the section headings as a reminder for user manuals, validation checklists, test cases, and more. Chapter 9, Requirements Management, offers good coverage regarding requirements traceability. Chapter 10, Requirements for Critical Systems, is a topic often overlooked in requirements books. The chapter offers insight to hazard analysis although it does not discuss failure modes or corrective and preventative actions plans.
Chapter 13, Viewpoints, offers a summary of the book. (This would be a good chapter to look at in a bookstore when you want to determine whether the book will provide you with the information you’re seeking.) Pulling together concepts presented earlier in the book and bundled into a sample life-like scenario, the chapter’s premise is that each stakeholder’s viewpoint unveils a potentially different perspective for each requirement.