| ||||||||||||
Product Details
|
The book's commonsense approach provides exemplary project management skills tailored to gathering (and refining, implementing, and eventually tracking) software requirements. While the book often cites recent software engineering studies, the focus always returns to practical management techniques. A case study for a chemical tracking application frames the book, and most chapters begin with anecdotes that demonstrate situations in which users and developers misunderstand each other about a software project's ultimate goals. (If you've ever worked in the field, these stories will probably sound all too familiar.)
This book offers hope, though, for improving your software design process, with dozens of tips on getting better design input from your customers and then using these requirements to generate a variety of design documents. There are numerous templates and sample documents too--a big help for the busy software manager.
Several standout sections cover negotiating difficult steps in the process, particularly how to manage shifting requirements as projects move forward and keep the various users and stakeholders content throughout the software process. Late in the book, the author surveys today's software management tools and shows how to pick the right ones for your organization.
Anchored by the author's considerable experience and software engineering expertise, this jargon-free and practical guide to software requirements can definitely give you the edge in managing software projects more efficiently. --Richard Dragan
Topics covered: software requirements specifications (SRS); business and user requirements; risk management; the requirements process; sample documents and templates; requirements development: elicitation, analysis, specification, and verification; rights and responsibilities for software customers; best practices; project management tips; process assessment and improvement; types of users; product champions; use cases and other diagrams; tips for prototyping; managing requirements change; change centered boards (CCBs); evaluating and using requirements tools; requirements traceability matrix; impact analysis. --This text refers to an out of print or unavailable edition of this title.
Without formal, verifiable software requirementsand an effective system for managing themthe programs that developers think they’ve agreed to build often will not be the same products their customers are expecting. In SOFTWARE REQUIREMENTS, Second Edition, requirements engineering authority Karl Wiegers amplifies the best practices presented in his original award-winning text?now a mainstay for anyone participating in the software development process.
In this book, you’ll discover effective techniques for managing the requirements engineering process all the way through the development cycleincluding dozens of techniques to facilitate that all-important communication between users, developers, and management. This updated edition features new case examples, anecdotes culled from the author’s extensive consulting career, and specific Next Steps for putting the book’s process-improvement principles into practice. You’ll also find several new chapters, sample documents, and an incisive troubleshooting guide.
Discover how to:
No matter what kind of software you build, or what your role in the development process, SOFTWARE REQUIREMENTS, Second Edition, delivers expert guidance and field-tested techniques for engineering software success.
Suggested Tags from Similar Products(What's this?)Be the first one to add a relevant tag (keyword that's strongly related to this product)
|
|
Share your thoughts with other customers:
|
||||||||||||||||||||||
|
Most helpful customer reviews
5.0 out of 5 stars
Product delivered as described,
This review is from: Software Requirements (Paperback)
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.
3 of 3 people found the following review helpful
5.0 out of 5 stars
Best Practices in Requirements Engineering. Must-Have.,
By
This review is from: Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle. (Paperback)
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!
3 of 3 people found the following review helpful
3.0 out of 5 stars
General Book on Requirements,
By Al Biglan (Pittsburgh, PA USA) - See all my reviews
This review is from: Software Requirements (Paperback)
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 :
Share your thoughts with other customers: Create your own review
Want to see more reviews on this item?
|
Most recent customer reviews |
|