This book is a classic. Well written and to the point. It helps resolve what requirements are and should be. I have done requirements for 30 years and I learned a lot! Wish it had been out sooner in my career.

After I purchased this product, Amazon prompted me with an option to buy an electronic version. I take notes on everything I read so I thought it was a great idea and was happy the book was available electronically. After copying a few pages of text, however, without warning, I received a notification that I was at my limit. At my limit. Amazon provides a generic notice that some publishers limit copying, but there is no information anywhere indicating that this was one of those books. No notification as I was copying text that there was a limit. This is a huge case of false advertising. Now I wonder about the other digital book I bought, "How will I know if there's a limit?"

The book itself is good, but my wasted money on the electronic version, which is useless to me now, has tainted my opinion about the publishers and Amazon for not clarifying that there were limitations.

Requirements Engineering is very important in order to create useful software. In chapter 1 the author also emphasizes the importance of the relationship between customer and development team. In the section titled "requirements bills" of rights and responsibilities for software customers, he summarizes the most important points. If the relationship and the communication between you and your customers is bad, you can't expect to write useful software.

Therefore you also need to take the communication between you and your customers into account. I recommend reading chapter 4 "giving and receiving criticism" in Effective Communication Skills for Scientific and Technical Professionals

In the appendix of "software requirements" there is an assesment which you can use to assess your current requirement pratice. It allows you to figure out the areas in which you can further improve your requirements engineering.

This book touches all important areas of requirements engineering and is a recommended reading for everyone who wants to write useful software.

This book covers all the different aspects of software requirements in a very concise way. Very interesting is the description of the elements and relationship between "Business Requirements", "User Requirements", "Business Rules", "Quality Attributes", "System Requirements", "Functional Requirements", "External Interfaces" and "Constraints". In appendix it has a good example on the requirements for an hypothetical Cafeteria Ordering System.

If you are enamored with The One Big Document approach to software requirements, then this is your book. Read it and enjoy.

If like me you have been on many projects where The One Big Document approach didn't work, stay clear of this book. While it gives some great advice on how to solicit feedback, it still advocates the traditional approach of defining a document that encapsulates all the requirements of the customer.

Why is this a bad thing? Here are some specific examples that should give you pause:
1) Requirements are notoriously open to interpretation. What the customer wants and what they eventually get can be and are often two very different things. It doesn't matter if your document is ten pages or ten thousand.
2) A requirements document is a product in and of itself, separate from the system that it tries to describe. It takes a great deal of resource and discipline to keep it current with the actual system over time, and in many shops this is a losing proposition.
3) Because it is a pain to keep up to date with the system, shops that I've been in have labored under the false optimism that they can come up with a perfect document up front. If there is one constant in software engineering though, it is that the needs of the customer are never static.
4) I have seen developers approach requirements documentation with the attitude that if it is exacting enough, the customer will be cornered because changes to the initial spec will be too odious to make later.

None of this is to say that there should not be requirements - there absolutely should! But I have come to believe after all these many years of software development that the best way to obtain requirements is to actually make them executable artifacts of the system (aka high level acceptance testing, which the author gives scant description of).

For anyone that is interested, I would recommend the book 'Fit for Developing Software'. Here are some of the things about this approach that have obvious advantage over the writing of massive requirement specs:
1) Tests are basically scenarios that illustrate system behavior. They are laid out in such a way that a non-programmer could easily come up with them.
2) Such behavior is expressed in a concrete way that is anything but ambiguous.
3) There is no need for the customer to exhaustively define everything up front. If they refine their expectation/needs after some period of time, they can alter the acceptance tests accordingly in collaboration with Product Managers and/or development staff.
4) All stakeholders have a way of knowing the state of the development process at any time.
5) A delivered system is either correct (passes all of the acceptance tests) or it is not. There is no room for interpretation.
6) The acceptance tests are always in sync with the system because they are executable. If a test does not pass, it reflects either a bug in the system or the need to revisit the tests.

This approach does not completely obviate the need for any kind of formal documentation. However, from what I have experienced with it so far, it does reduce a significant amount of the cost that would otherwise be spent on The One Big Document. It does this by showing what the system must do in a manner that is measurable, rather than simply stating it.

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 processimpact.com. 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.

Great book and great condition.
The book is straight to the point with many examples. Unlike other text book, this one is never boring. Nicely written. I give the author A+

It is really the best software requirements book I've ever read. Pragmatic, concise, full of example and still exhaustive. It describes the main processes of Requirements Engineering (Requirements Developement and Requirements Management), plus a section dealing with imroving your own Requirements processes.
I strongly raccomend this book to everyone interested in adopting a more efficent Requirements process.

Does everyone remember the movie Goodfellows? The central character was based on a real life criminal named Henry Hill. I want to talk about Hill and what it has to do with this, but first things first.

Karl Wiegers writes in such a way that if you blink you may miss something." He packs it in. Dilute? I don't think so. I love writers like that, the ones that top it off. Make no mistake Wiegers' goal is to educate, instruct, and improve your skills as an IT professional. Last year, I listened attentively as Wiegers explained use cases in that same condensed way. I took notes and drew diagrams. I like Software Requirements, it is a good book. Wiegers writes much better than he presents.

I wrote that review some time ago. I read the book again and I missed something. I'd like to add to the review. It was better the second time.

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.

The book covers what it says it does and is well written. With many references to other's work you get the good part of a bunch of books for the price of one (There is also a lot of original content).

I have never read a software requirements book, but I have been writing software requirements of a long time. The book covers 'everything', so there is a lot of stuff that I knew already. It was worth reading though.

This book is written with devlopers voice. This covers partical scenario along with the theory. Great book to start with for Software Requirements Engg.

I got a lot of good information out of this book, and I'm glad I bought it. The problem I have with it is the same problem I have with a lot of computer books. IT'S TOO LONG!!! There's way too much text in that book, and wading through it to get to the good stuff was tedious. The author did a good job of completely covering the topic, and he offers a lot of useful information about gathering, documenting and utilizing software requirements. Maybe for the next version, they'll get someone to edit the manuscript for extraneous content.

This book very good reading about human requirements process. This book clearly LIMITED in that it covers requirements process mostly for non-critical business toy software.
Requirements analysis and specification techniques are not covered in sufficient details, especially old classic methods - for that I would recommend "Software Requirements" by Alan M. Davis. Wiegers completely skipped FORMAL METHODS which makes this book only 50% useful. Hey there is things like Z-language and method! Have you heard about them ?! This book is recommended as reading by SWEBOK and IEEE CSDP program so I have to give it one additional point.

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!

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.

Great book. Easy read. buy it. Do it!

This book presents a bright view of software requirements elicitation, development, analysis and management. The consequences of developing requirements in three major steps (business, user and functional requirements) are explained in a way that is easy to read and, at the same time, full of insight.
Nevertheless, we must disagree with the author in a very fundamental point. Wiegers clearly states across the book that requirements must not be polluted with design issues or otherwise biased towards a specific solution, but they must just present the needs. This is a widely assumed point that we do not share. From our viewpoint, developing and writing the requirements for a software system is one of the first modeling activities in the project lifecycle, and modeling is nothing but creating a new model or applying an existing one. In any case, models do not live hidden behind users' daily practice, waiting for us developers to uncover them; on the contrary, they are synthesized as needed, confronted with empirical and intuitive experience and given an ok mark if they can explain, with more or less accuracy and efficiency, the observed reality. The very word "development" in "requirements development" strongly suggests the idea of creating a model. We think that requirements development is fundamentally a modeling activity, and therefore it implies a specific solution. Of course, the chosen solution is specified at a very high degree of abstraction, and many more detailing steps will be needed in order to transform it into the final source code. The SRS in Wiegers's book is a model, and therefore it carries plenty of design issues. What must be avoided is to give them too much detail as to make them inflexible for further modeling. Please have a look at the Metis methodology for more information on our concepts of "modeling" and "design".

Despite the conceptual argument we have posed, we have liked the book, and we do recommend it.

Whether you are a customer, project manager or member of a project team, you can't go wrong with this book on software requirements. If you are only going to read one book on software requirements this is about as good as it gets. Wiegers writes in an eminently readable style. He doesn't claim that any one way is right for everyone. Instead he provides a variety of tips and techniques you can choose from at will to help you communicate with your customer (or vendor), document your requirements, and track and manage them. Most of his ideas are quick and simple to implement and should show distinct benefits almost immediately. This book is one I go back to time and again when working on process development and improvement for my organization. Read it!

This is a solid book covering the requirements gathering process. My only concern is for shops that try to implement the entire process verbatim.

In today's web development world, customer expect progress every 30 days (a la XP Programming). If you force every project down the Use Case, FUnctional Specs, UML diagrams path, then there's no way to get incremental projects out the door that quickly.

My suggestion is to customize your process and take the best from this book. Use the majority of processes for large projects, but keep in mind that most projects that don't deliver any incremental value with 30-90 days of start, will either be cancelled or fail.

I've been a business analyst (BA) for several years and have bought countless books on specific technologies, but have always had difficulty finding books on software requirements (in the general since). I'm currently involved in a large web based software project using the full Rational suite and have found this book very useful. Things I couldn't find in the Rational books, I found in this one. It not only delves into project methodologies and object orientated design, but it also gives the reader guidance in terms of defining project scope, drafting requirements, and dealing with clients (just to mention a few).

I highly recommend this book for any BA's, project managers and/or anyone wishing to learn more about what's involved with gathering and designing software requirements

Karl Wiegers makes the clearest and most convincing case I've seen yet for a disciplined approach to gathering and documenting detailed users' requirements. This is a must-read for:

- project managers,

- skeptical I.T. managers, esp. start-up entrepreneurs

- systems analysts, esp. less experienced ones

- open-minded sponsoring user representatives

This work, however, provides little practical guidance on how to actually do the analysis. Wiegers has the right idea in balancing established structured analysis (SA) with recent UML techniques, but the details and examples are much too sparse and vague to serve as a guide (e.g. data definition).

Highly recommended for anyone who thinks doing it right is a "luxury" his or her organization can't afford in today's competitive Internet-time-driven world.

A good book that accurately captures some of the best practices in requirements analysis around.

I bought the book having read Mastering the Requirements Process by Robertson and Robertson, the IEEE 830 Requirements standard, and some other books.

Software Requirements Best Practices is right up there at the top. I also highly recommend Mastering the Requirements Process.

This book is a practical guide to requirements development. The author draws from his own experience but also distills best practices from industry experts. We used this book to put a formal requirements structure in place which we hope will help to clarify what needs to be built before code development begins. The author points out that requirements errors are approximately 60 to 100 times more expensive to correct in code...I have delivered great software that the customer hated more times than I'd like to admit. If you don't bridge the expectations gap early and deliver what the customer wants it won't matter how beautiful your design and engineering is. One thing I appreciated about the author's approach was that it was not dogmatic and rigid, basically use what works in this model, discard the rest. One small criticism: it would have been nice to see a complete, end to end example of the requirements documents from vision and scope to use cases, to finally the functional spec, complete with suggested formatting conventions. If space was a consideration, then maybe a website could have been used to supplement the text.

I took a course recently on Software Requirements and (unfortunately) this was not one of the two required textbooks. (The two required books were Software Requirements by Davis and Software Quality by Jones.) Both the required books were fatally flawed. However, for a required paper, we needed to cite four books...and I ran across Software Requirements by Wiegers.

The book is well-written, well-organized, clear, and comprehensive. It strikes a good balance between the technical and the practical, between the theoretical and the actual.

If you're a professor looking for a book to use, please consider this one. And if you're a student discouraged by some other book (particularly the two I mentioned above), this one really works.

I found this an easy to read and follow book which I rate highly for Business Analysts. Its best for senior Business Analysts or Team Leaders who want to set up a requirements and specification process to be used by the team or department(This is how I used it and found it very good).

The best bits for me were the descriptions of prototyping (a great overview that cleared up my understanding) and how to run a Use-case workshop with business customers (essential stuff but never covered elsewhere).

The worst bits were that I found the vision and scope template not very useful for internal company development and in Chapter 9, Section 4 I longed for an actual example of how to convert/translate use cases into specifications. The latter is one thing where an example would have clarified the text.

Comparing this to Kovitz, I have Kovitz for my own personal development/tool as an analyst and this book for setting up a requirements plan/process and adminstering it.

The more time I spend running software projects, the more convinced I become that a strong requirements process is the hardest part.

This is an excellent book that covers developing a strong requirements process. Wiegers doesn't cover underlying philosophy (see Kovitz or Jackson), but he provides a useful reference. The book outlines many good practices - and his point about "good practices" versus "best practices" is well taken, but it is not as well organized as some other toolbox-style books.

A big part of establishing effective requirements gathering is selling the management team. This book doesn't really tackle this challenge.

The sample project is helpful, but I wish Wiegers had gone the last mile and attached the project requirements documents as an appendix.

Despite this list of gripes about what the book doesn't do, it has many, many good points and is written in a clear, if not lively, fashion. Recommended.

This book has changed the project process at our company from a free-for-all to a concrete, repeatable process that everyone involved agrees upon. The writing is distinctly unambiguous and understandable, dealing with a difficult and often misunderstood job in a deft fashion. I wish that I had read this 5 years ago.

Many books claim to provide best practices, this book delivers. From page one it is obvious that the author is writing from real world experience. Too many books on requirements are written by university professors with no real experience. I will insist that everyone working on my projects buy and read this book. My copy is loaded with notes and highlighter marks. If your are new to requirements dont waste your time with anything else. Perfect for the beginner.