Customer Reviews

Software Requirements (Dv-Best Practices)

5 star:		(36)
4 star:		(15)
3 star:		(1)
2 star:		(1)
1 star:		(0)

 

 

Karl Wieger's book is destined to be classic in software requirements. It delivers a large set (over 40) no-nonsense best practices in highly readable, non-nonsense manner. I believe every project manager, IT (Information Technology) and business analyst, and IT account manager should read this book. Further, developers would do well to read it to gain critical insight into the 'big picture' of requirements engineering.

The book is broken down into three sections: the case for requirements engineering best practices ("What and Why"), the requirements discovery, verification and validation process ("Software Requirements Engineering"), and the essentials of requirements management ("Software Requirements Management"). Throughout, the dual necessities of doing requirements right (verification) and doing the right requirements (validation) is addressed. Wiegers has thoroughly delved into the literature in the software requirements field. The text is liberally spiced with tidbits of data to support the business case for implementing these best practices. I found myself making notes in the inside cover and folding back pages to reference again as I read through the book.

Early in the book, Wiegers presents a set of software engineering best practices which are classified into priority (high, medium, low) and difficulty (high, medium, low). Although you may disagree with the specific rankings for your shop, this table is an excellent example of modeling appropriate requirements engineering practices - prioritizing requirements! Other goodies abound. For example, a partial case study flows throughout the book which gives the reader enough of an idea of what a use case, dialog map, text requirement, etc. looks like to get the concept being resented. Each chapter ends with a concise list of suggested next steps, providing the reader with concrete actions to take to implement the practices covered in that chapter. In addition, there are numerous sample templates (e.g. Risk Item Tracking, Software Requirements Specification), several excellent checklists (e.g. Inspection Checklist for Software Requirements Spec, Software Elements Affected by a Proposed Change,), visual models (e.g. Requirements Traceability Links, Change Control Process) and a wonderful "bill of rights" for the software customer which boldly and directly asserts both rights and responsibilities of the customer.

A set of example models is provided in the chapter called "A Picture is Worth 1024 Words". You will need to read other books or take training on the mechanics, notations and semantics of these models for visualized functional requirements. But the author covers the key models and their purpose succinctly.

This book is easy to read, cuts to the chase, and provides a bounty of information that will wet our appetite to take action. This book is not a requirements engineering method or methodology, which would prescribe step-by-step protocols of task, roles, and techniques. Rather, like the classic cookbook The Joy of Cooking, you will find well-proven, sensible, and reusable practices. In Software Requirements, you will find the right ingredients and essential practices needed to 'cook' tasty requirements.

If you are looking for a very direct, down-to-earth approach to developing and managing requirements, this is the book for you. If you believe that managing requirements is overhead that you cannot support, you need to read this book. Karl takes a very practical approach to requirements development and management. He explains his approach in a succinct manner and provides very good examples to make his point. This book should be a mandatory read by all software development project managers, whether they come from the business or technical side of the business. Additionally, Karl's book makes good reading for anyone who is affected by the development of a software system such as business visionaries, end-users, quality assurance, business analysts, technical writers, trainers, and developers.

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.

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

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.

This is a great book. It provides clear and concise approaches to solving classic requirements problems. It is not just about software, it can be applied to any system or project. It is not written in software terms, it avoids the software worlds attempt to create new terms for everything.

This is not a book by an academic but by someone who has worked in industry and solved problems, just like those that you face.

The book includes templates, checklists and guidelines that are easy to use. I also liked the clean style of the book and it is very easy to read. You can apply all or part of the suggested process to your own projects.

A more detailed review will appear in the Winter Issue of Insight, the magazine of the International Council on Systems Engineering (INCOSE)

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.

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