Truck Month Summer Reading Amazon Fashion Learn more Discover it Fifth Harmony Father's Day Gift Guide 2016 Fire TV Stick Grocery The Baby Store Find the Best Purina Pro Plan for Your Pet Amazon Cash Back Offer DrThorne DrThorne DrThorne  Amazon Echo  Echo Dot  Amazon Tap  Echo Dot  Amazon Tap  Amazon Echo Starting at $149.99 All-New Kindle Oasis AutoRip in CDs & Vinyl Shop Now SnS

Customer Reviews

4.5 out of 5 stars47
Format: Paperback|Change
Price:$39.99+ Free shipping with Amazon Prime
Your rating(Clear)Rate this item

There was a problem filtering reviews right now. Please try again later.

on October 12, 2003
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!
0Comment|34 people found this helpful. Was this review helpful to you?YesNoReport abuse
on March 23, 2003
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.
0Comment|16 people found this helpful. Was this review helpful to you?YesNoReport abuse
on August 11, 2003
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.
0Comment|16 people found this helpful. Was this review helpful to you?YesNoReport abuse
on July 28, 2003
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!
0Comment|13 people found this helpful. Was this review helpful to you?YesNoReport abuse
on November 16, 2012
I did not find this book as good as other reviewers seemed to think.

To give a bit of a background, I'm work on a fairly complex robotics system with both hardware and software components. Determining system requirements is one of the major tasks that I perform on a daily basis.

I did find this book useful, as after reading it I had a much better perspective from the 5000 foot level of how requirements affect the entire business organization and product development process. It really drills down the importance of understanding what it is you are trying to build before designing a product. This book is 100% useful to engineers that focus on hardware as well as software - don't be fooled by the title.

My main gripe with the book is that it reads like an overly verbose company work instruction (imagine a dry and somewhat boring employee orientation manual). There are entire pages of material that could have been summed up much better in a paragraph or so, or with an effective picture. Many of the flow charts in the book for example read like your typical overly complex and useless business process charts that no one would ever actually reference when they do their job.

For the record, I don't have a problem with flow-charts, but they need to be simple to be effective, and despite what I stated above, there are a couple flow-chart gems in the book.

On to the specifics...

Section I of the book focuses on a very general overview of requirements, roles that different people perform in relation to requirements (i.e. designers, product managers, project managers, system analyst, testers, etc.). I found most of this material to be useless, except for comparing how my company structured itself versus standard practice across the industry. I imagine that anyone working at a company with any sort of formalized requirements process wouldn't get too much out of this section either.

Section II is a bit better. It begins with a focus on the business aspects of requirements. Without a clear scope document and business vision, the requirements are meaningless. It goes on to argue the importance of customer feedback during the requirements development process. I think some clearer explanation on gathering customer feedback, with specific case studies for how to drill down customer desires into tangible features to incorporate into a product would have gone a long way here... but I generally agree with the philosophy. Much of the use case / customer feedback chapters were too general to be useful though.

Section II also covers good practices in documenting requirements. I took this part for granted because my company has many of these practices already in place, but had I been working for a smaller company or startup, I would have found these organizational tips to be invaluable. This is really great material if you don't have any formalized process in place.

Section III covers a lot of issues related to version control, changing requirements during the development process, maintaining traceable requirements... This section is boring, and could have benefited by being more concise as well. Reading it did give me a better perspective of the requirements process however.

Section IV, a very short section, was really one of the best parts of the book. It ties together the other sections in some of the effective flow charts of the book as to how requirements management is a PROCESS, and one that lies at the heart of good product development. If you've ever been through a project and had a gut feeling that major decisions were being rushed without due consideration, or that the wrong tasks were being prioritized, this section will crystallize how things should have gone in that project. It covered a few things I hadn't seen before, such as measuring requirements volatility, which is a good way to get a handle on how well the product is defined over a long period of time.

Finally in the appendices, there are a couple hidden gems that cover the maturity level of a company, and what level of requirements management are actually NEEDED by company depending on the project. For a simple project, requirement management tools would be major overkill.

Overall a good book for managing requirements. People that work on large, technically challenging projects in large groups / organizations would find this book especially useful. It suffers though from being way too long for the information that it is trying to impart.

My review might a little harsh, as I could see myself re-reading a couple selected parts of this book from time to time, but I simply would never rate this book anything close to 5 stars, and I'm surprised by how high other reviewers have esteemed this book.
0Comment|One person found this helpful. Was this review helpful to you?YesNoReport abuse
on October 18, 2006
In my opinion the hardest part about programming is gathering and analysing a complete, accurate and verifiable set of user requirements.

Unfortunately, good software requirements are also key to a project's success.

Those good at programming have laser-like focus and great analytical skills - usually traits associated those who are tend to be introverted / thinking and judging-oriented (cf. Myers-Briggs). Such people often find they have a tough when it comes time to gathering requirements e.g. listening and talking with users, understanding what they want, gaining their trust etc. - usually traits associated with those who are extroverted / feeling and perception-oriented.

As a person with some Introvert / Thinking and Judging tendencies, this book was the book that set me right and gave me a process I could follow and reference at any time during the requirements phase.

With the process and templates in place I can focus more on listening to what is being said and more importantly what is NOT being said (e.g. implicit or non-functional requirements)

The book is loaded throughout with best practices on

- Requirements Management (e.g. use change control)

- Project Management (e.g. manage requirement risks)

- Requirements Elicitataion (e.g. identify use cases)

- Requirements Analysis (e.g. create prototypes)

- Requirements Specification (e.g. Requirements traceability)

- Requirements Verification (e.g. Write test cases from requirements)

and so much more . . .

The book also contains some very helpful templates (e.g. Project Vision

template, Use Case template, and best of all a template Software Requirements Spec that seems to cater to all needs etc.). Each of these are great time savers.

For me this book covers 80-90% of my requirements questions and concern. I haven't found another requirements book that is as broad and approachable as this. Glad to see it in it's 2nd edition although I doubt there was much he could have added.
0Comment|4 people found this helpful. Was this review helpful to you?YesNoReport abuse
on January 29, 2015
if you've ever had to write requirements or deal with an SRS this is the absolute book for you. This is my bible as a business analyst. Lots of information provided in a fresh understandable way. minimal technical writing so it's very easy to follow.
0Comment|Was this review helpful to you?YesNoReport abuse
on March 9, 2012
This is a really great book on software requirements. It covers all the major points in sufficient detail but without too much fluff. It has the right mix of diagrams and illustrations to truly clarify the concepts. It can be used as a reference if you are only looking for one issue or you can use it to cover the whole topic.
0Comment|Was this review helpful to you?YesNoReport abuse
on January 23, 2013
It's a great book about the conventional development process of a software project. What I didn't like is that some of the things don't always apply in the agile development process that it is so common these days. I would recomend this book to anyone looking to work in the requirements development process of a software prodcut
0Comment|Was this review helpful to you?YesNoReport abuse
on August 14, 2007
When I first purchased this book back in 2006, I went through most of it fairly quickly, and even downloaded some of Wiegers supplementary material from Some of my colleagues took notice and together we formed a mini-workshop using the downloaded materials, which we used to gather requirements for an enhancement to one of the applications I assist in managing.

A merger and subsequent reorganization later, I found the time to finish the book. I recommend it for the developer or technical manager who finds themselves in a project that lacks thorough requirements development. The book uses appropriate tone and terminology to address its' intended audience; it is neither too simplistic nor overly dense. It has enough supplementary material to preclude the need to build a requirements development process from scratch without looking too much like a cookbook. Its' bibliography includes several classics and many references not familiar to me. All in all, a balanced book about requirements development and management.
0Comment|One person found this helpful. Was this review helpful to you?YesNoReport abuse