Customer Reviews

Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle.

5 star:		(21)
4 star:		(7)
3 star:		(1)
2 star:		(0)
1 star:		(0)

 

 

The book is like a brand new one. It is delivered as described. Will do business with this seller if possible. Amazon is money saver.

How do you know if you have good software requirements? Some use the simple technique of checking if the requirements definition is complete, clear, and consistent. Every book on requirements engineering has some variation of this theme and in this book, you are advised to check if the requirements statement is complete, correct, feasible, necessary, prioritized, unambiguous, and verifiable.

If you haven't used techniques like this one before, it is definitely a good idea to pick up a solid book like this one on the best practices in requirements engineering. There are several good books in the market on the topic of software requirements and this is one of the best ones out there.

I found three other books that complement this one - Requirements Engineering by Kotonya and Sommerville (used more as a textbook), Managing Software Requirements by Leffingwell and Widrig (part of the Object Technology Series), and Effective Requirements Practices by Ralph R. Young (comes with a CD-ROM).

If you are a project manager, business analyst or anyone that has a lot to lose because of bad requirements, you will benefit tremendously from this current book being reviewed. The book is divided into three parts - What and Why, Development, and Management of Software Requirements. The part names are self explanatory. This book is very readable and is full of best practices that stand true to their name!

The unique things about this book - in chapter 2, the author outlines the Requirements Bill of Rights for Software Customers and the Requirements Bill of Responsibilities for Software Customers. When I first read this, I felt like every customer has to read this before attempting a software project. Chapter 10 has an excellent description of different diagrams useful in requirements documentation - DFD (data flow diagram), ERD (entity-relationship diagram), STD (state transition diagram), dialog map, and class diagrams. I think all books on software requirements should ideally have some variation of these topics.

Important topics like traceability are given an excellent treatment in this book but the only thing lacking is how to manage requirements in software processes involving iterations (the mainstay of the Rational Unified Process and other newer software development methodologies). There are only 13 pages devoted to this topic and even then it is indirect - Chapter 12: Risk Reduction Through Prototyping.

Otherwise, I have no complaints about this book and I believe that it is a basic to intermediate in level (definitely not an advanced book). Overall, I believe it indeed captures the best practices in the field of requirements engineering. It is also a good price, so enjoy!

This book is written as an entry level text on Requirements and how they relate to a project. It does a very good job touching most of the important points of the Requirements Engineering and Management processes. It presents more of a managerial view of the process and does not cover many important points in enough detail to be a good "how to" guide. Most of the book presents simple solutions that are often very complicated in the real world. Case in point :
If you are looking for tips how to "arrest creeping requirements and manage change requests" (back cover) This book will give a good 15 page summary (280-296) of the process (big text) but not enough insight to determine if the process is sufficient, or what can be modified to fit specific scenarios. In the section "Controlling Scope Creep," it mentions "The most effective technique for controlling scope creep is the ability to say no." Very true, but how do you tell Sr. Management (your boss) no? The customer negotiating future payment milestones and functionality? This is good advice, but little more than a flowchart, some recommendations for setting up a Change Control Board and suggested Change Request data items. If the book wanted to aim itself at a more experienced audience, some examples or more complete picture of control mechanisms/processes should be included.
(I pick on the above point, but other books on Requirements only indirectly mention controlling requirement creep) Similar limited treatment is given to complex issues like Use Case generation.

If I were VP of Projects, and my Project Managers had limited exposure to the requirements processes, I'd buy them all this book. If I were VP of Engineering, I'd expect anyone with 2+ years of project experience to already have a working understanding of 75% of this book.

If you have been on one or more projects and have touched the requirements process before, this book is not likely to present new information. If you are looking for in depth treatment of requirements, here is how I would break down some of the other books in this topic :
Wiegers : Good intro text, poor intermediate/advanced text. Good for managers with limited direct exposure.
Jackson : Very good encyclopedia (tho nothing more than an encyclopedia...) of terms, theories, etc. Aimed at an intermediate-advanced level
Kovitz : Very thorough text covering all aspects of requirements process (focused heavily on software) Better treatment of theory and better (more complete) examples than Wiegers. Intro-Intermediate level.
Robertson & Robertson : Same type of book as Wiegers, but better indexed (I like the "rules of thumb" in the margins). In some areas, I'd rate R&R higher (types of requirements, creating & reviewing the specification) and others Wiegers is better (management of the process, elicitation of requirements) Overall I'd give the nod to R&R
Leffingwell & Widrig : Very good presentation of pitfalls and suggestions for overcoming them. Very biased to the Rational model of a project, but a very good text with (in many cases) unique/interesting approaches. Aimed at all levels (one of it's downfalls) A good "other" or second book to have.
Thayer & Dorfman : I refer to this book the most. Excellent collection of articles. Wish they didn't include the IEEE standards tho (they are good standards, but most(?) engineers have access to them somewhere else) This is a good summary of many different aspects of Requirements Engineering & Management. May be tough as an intro text, but an excellent overall reference.

I'm somewhat of a software engineering/process geek. I find the process of creating a product more interesting than the actual code these days (though I like to code). Wiegers' book is THE bible, in my opinion, for eliciting and maintaining requirements.

He covers the issues involved in gathering requirements and keeping them up to date, often offering multiple ways to resolve issues. Wiegers, unlike many academic oriented books, fully acknowledges the political and cultural difficulties that arise when trying to institute a requirements program. Much of his advice is practical and he gives good pointers on the highst ROI practices, so you can inject a little at a time, rather than trying to change culture wholesale.

I'd give a 4.5 out of 5 if I could, due only to the "Next Steps" sections at the end of each chapter. The "Next Steps" are supposedly be small steps you can take to start using the advice Wiegers offers. Unfortunately, most of the steps start with "Take a page/chapter from your current requirements document...." I've worked at few companies that even have a requirements document, so I'm not sure how useful the "Next Steps" really are.

But, that complaint aside, this book is the best combination of reference information for techniques and advice on how to use them on the job.

When it comes to the development life cycle, there are generally two broad schools of thought: rigorous, waterfall approach; and the agile, iterative approach. This text sits in the heart of the rigorous, waterfall approach.

Iterative approaches are proven to be more effective at eliciting requirements, a fact which is somewhat embraced in the author's discussion of use cases; however, Jacobson originally envisioned use cases to replace other requirements documents as a central element in elicitation, rather than just being a quick diversion.

In reality, most of us strike a middle ground. Projects can't be run in most organizations without rigor, and Software Requirements is a thorough treatment or requirements development and management. The well-organized book is a quick read, and is filled with prescriptive advice, risks, sample forms, and checklists that can be applied to your requirements effort. No wonder the author won a Software Productivity Award for the effort!

This book faces a lot of competition from other books, which are supposed to tell you how to manage software projects in general, and the requirements gathering process in particular.
However, what sets this book apart from the vast majority of others is its absolute relevance (as opposed to being an arbitrary textbook). For example, this book recognizes the fact that often enough process improvements are deferred due to political reasons alone. The more you read it, the more you realize it addresses the same problems you have encountered while managing the requirements process.
But what really sets this book apart is that it actually tells you how to solve these problems, by offering feasible solutions that could be easily implemented, gradually, in real life scenarios. This, basically, means that the book could actually HELP you.

This book is a comprehensive, authoritative review of what good requirements are. I recommend it highly. However, it's not enough by itself. If you study and learn from Wiegers, you will know *what* good software requirements are and how to know if yours are good or not, but not how to get there. He does talk a lot about elicitation and analysis and so on, but in the end I found that I didn't yet have all the tools I needed. I recommend checking out Scott Ambler's excellent "The Object Primer" --- it ended up being what I needed to fill in the gaps.

This is an excellent book to understand Software Requirements, especially if you are new to Software Development. There are many views on "best practices" in the software industry, but Wieger's views are a good start.
If you starting into Software Product/Project Management, new to Software Development, getting into stuff like writing an SRS or a Marketing Requirements Document, this book will give you a good analytical understanding of the multiple issues that you need to understand and keep in mind.

This book describes everything you could want to know about writing software requirements. It is easy to read cover-to-cover, and is also an excellent reference book. This is one of the best technology-related books I've bought.

This book is full of practical details with checklists and next step suggestions. The beginning is rather steep, but the rest of the book a smooth read. If you are currently working in a more chaotic type of environment and suffer under anarchic management, then this book has no help to get started. It assumes a fairly mature of organization. But then it gives plenty of practical guides for all respects of improvement.