- Gebundene Ausgabe: 560 Seiten
- Verlag: Addison Wesley; Auflage: 2nd ed. (17. März 2006)
- Sprache: Englisch
- ISBN-10: 0321419499
- ISBN-13: 978-0321419491
- Größe und/oder Gewicht: 20 x 3,4 x 24,9 cm
- Durchschnittliche Kundenbewertung: 4 Kundenrezensionen
- Amazon Bestseller-Rang: Nr. 278.822 in Fremdsprachige Bücher (Siehe Top 100 in Fremdsprachige Bücher)
- Komplettes Inhaltsverzeichnis ansehen
Mastering the Requirements Process (Englisch) Gebundene Ausgabe – 17. März 2006
Dieses Buch gibt es in einer neuen Auflage:
Kunden, die diesen Artikel angesehen haben, haben auch angesehen
Welche anderen Artikel kaufen Kunden, nachdem sie diesen Artikel angesehen haben?
Es wird kein Kindle Gerät benötigt. Laden Sie eine der kostenlosen Kindle Apps herunter und beginnen Sie, Kindle-Bücher auf Ihrem Smartphone, Tablet und Computer zu lesen.
Geben Sie Ihre Mobiltelefonnummer ein, um die kostenfreie App zu beziehen.
Wenn Sie dieses Produkt verkaufen, möchten Sie über Seller Support Updates vorschlagen?
Written in an engaging style and relevant for any software analyst or designer, Mastering the Requirements Process provides a powerful and useful guide to defining more complete software requirements that lead to better software overall. It's also filled with innovative advice.
The heart of this book is the authors' Volere Requirements Process Model, a step-by-step guide to gathering your requisites. Throughout this book, the authors use this process to explicate a single case study--a system for a municipality that will optimize the de-icing of roadways during snowy weather. Along the way, the book provides a solid guide to identifying and refining requirements, both functional and nonfunctional (such as performance and ease of use).
There are many excellent ideas in the book, including the notion of fitness for your requirements, which can be later used to track whether the software is successful. The book also wisely separates technology from requirements so that analysts can concentrate on understanding and modeling business problems instead of moving right away to the nuts and bolts of implementation. Even if you don't adopt the Volere model in toto, you can benefit from the concepts of "trawling" (a metaphor for the requirements-gathering process), quality gateways (in which tentative requirements are evaluated for inclusion in a project), and the wise use of patterns to help simplify the process.
Anchored by numerous examples (including many samples of successful requirements), the book provides an appealing mix of new ideas along with a remarkably clear presentation. In short, Mastering the Requirements Process provides useful advice that can make the project specification building phase of the software process easier and more robust. It provides the first steps for improving overall software quality for your organization. --Richard Dragan
Topics covered: Volere Requirements Process Model; project blastoff; determining requirements; user and stakeholders; project constraints; requirements constraints; use cases; business events; adjacent systems; innovation; trawling for requirements: apprenticing, interviews, and videotape; functional and nonfunctional requirements; fit criteria; quality gateways; traceability; prototyping and scenarios; low and high fidelity prototypes; patterns and requirements reuse; improving the requirements gathering process. -- Dieser Text bezieht sich auf eine vergriffene oder nicht verfügbare Ausgabe dieses Titels.
"If the purpose is to create one of the best books on requirements yet written, the authors have succeeded." --Capers Jones It is widely recognized that incorrect requirements account for up to 60 percent of errors in software products, and yet the majority of software development organizations do not have a formal requirements process. Many organizations appear willing to spend huge amounts on fixing and altering poorly specified software, but seem unwilling to invest a much smaller amount to get the requirements right in the first place. Mastering the Requirements Process, Second Edition, sets out an industry-proven process for gathering and verifying requirements with an eye toward today's agile development environments. In this total update of the bestselling guide, the authors show how to discover precisely what the customer wants and needs while doing the minimum requirements work according to the project's level of agility.Features include *The Volere requirements process--completely specified, and revised for compatibility with agile environments*A specification template that can be used as the basis for your own requirements specifications *New agility ratings that help you funnel your efforts into only the requirements work needed for your particular development environment and project*How to make requirements testable using fit criteria*Iterative requirements gathering leading to faster delivery to the client*Checklists to help identify stakeholders, users, nonfunctional requirements, and more *Details on gathering and implementing requirements for iterative releases*An expanded project sociology section for help with identifying and communicating with stakeholders*Strategies for exploiting use cases to determine the best product to build *Methods for reusing requirements and requirements patterns *Examples showing how the techniques and templates are applied in real-world situationsAlle Produktbeschreibungen
I am missing the real important points. Everything is gray in gray. I was just really quickly reading over the first 100 pages, but I think that's what it is. It is not helping me doing really better requirements.
e.g. getting used to Use Cases from Jacobson earlier on in my career was much more important and helpful than this whole book just about this theme-
Die hilfreichsten Kundenrezensionen auf Amazon.com (beta) (Kann Kundenrezensionen aus dem "Early Reviewer Rewards"-Programm beinhalten)
The main negative to me (as someone who doesn't deal with Software systems) is that even though it tries to be system independent, it has a very clear software flavour to it.
STYLE AND COMMUNICATION
The writing style is fairly light and very readable, and the book clearly communicates to the reader. The layout is good, with good sidebars for references, additional reading and quotes. Diagrams are easy to understand.
ICE BREAKER EXAMPLE
An example of a road de-icing system is introduced early in the book and is used throughout the book to illustrate the points that the authors are making. It was a good example, being a combination of hardware, software and people, and was used effectively.
A DEFINITE SOFTWARE FLAVOUR
Although the book seems to try to be system independent, there are a number of sections that lapse back into talking about software, which is the authors' background. Eg p 161. "The detail of each requirement is intended to be sufficient for the developers to write the correct software from it".
This also does affect the content of the material, so some of the messages do not apply to non software system. Eg p 186 talks about maintainability being about modifying the product to cater for changes in the organisation or environment. This may be applicable for software, but for hardware systems maintainability will be about ease and cost of repair, inspection etc
Because the author's experience is clearly rooted in the software world, there is some doubt in my mind as to whether the process recommended is ideally suited to non-software systems.
A reasonable chunk of the book talked about business uses cases and product use cases, and this was probably one of the best parts of the book for me, being not so familiar with this area. It clearly articulated with examples how to develop scenarios and then business and product use cases, without getting into the detail of UML and other modelling tools.
An interesting concept is the concept of Fit Criteria, which is a way of turning a potentially subjective or unverifiable requirements into objective and testable requirement. I'm not sure I agree with the author's approach of separating the fit criterion from the requirement, but the concept is certainly very useful.
The section on reviewing the specification had some good suggestions on how to check for missing requirements, which is one of the hardest things to do and is probably the most important.
There wasn't much about the actual writing of requirements: this is a book about the requirements process, so maybe it can be excused for not focussing on requirement writing.
However, the text is highly repetitive and wandering making it hard to read. One can only read the same thing in so many ways, so many times before wondering "what's the point?"
I think this would make a great introduction to requirements gathering process if it were written more concisely and to the point, with better English.
However, there is a lot of good information, if you can stay away through the reading.