- Taschenbuch: 240 Seiten
- Verlag: Dorset House; Auflage: illustrated edition (30. Mai 2005)
- Sprache: Englisch
- ISBN-10: 0932633641
- ISBN-13: 978-0932633644
- Größe und/oder Gewicht: 21,4 x 15,2 x 1,6 cm
- Durchschnittliche Kundenbewertung: 5.0 von 5 Sternen Alle Rezensionen anzeigen (1 Kundenrezension)
-
Amazon Bestseller-Rang:
Nr. 138.415 in Englische Bücher (Siehe Top 100 in Englische Bücher)
- Nr. 99 in Englische Bücher > Computer & Internet > Projektmanagement
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
Produktinformation |
Mehr über den Autor
Entdecken Sie Bücher, lesen Sie über Autoren und mehr
› Besuchen Sie die Seite von Alan M. Davis auf Amazon
› Besuchen Sie die Seite von Alan M. Davis auf Amazon
Produktbeschreibungen
Synopsis
In this guide, Davis helps developers find the proper balance between customer requirements and company resources. Among the topics he covers are the optimal relationship between requirement changes and the schedule; resolving disagreements concerning priority and satisfaction of requirements; and basic and advanced triage techniques. The appendice
Welche anderen Artikel kaufen Kunden, nachdem sie diesen Artikel angesehen haben?
Tags(Was ist das?)Bei einem Tag handelt es sich um ein Schlagwort, das zum Produkt passt.
Tags erleichtern allen Kunden die Suche und die Sortierung ihrer Lieblingsprodukte. |
Eine digitale Version dieses Buchs im Kindle-Shop verkaufen
Wenn Sie ein Verleger oder Autor sind und die digitalen Rechte an einem Buch haben, können Sie die digitale Version des Buchs in unserem Kindle-Shop verkaufen.
Weitere Informationen
Kundenrezensionen
Die hilfreichsten Kundenrezensionen
4 von 4 Kunden fanden die folgende Rezension hilfreich
Format:Taschenbuch
A.M. Davis war einer meiner großen Lehrmeister im RE. Er gilt bis heute unbestritten als einer der weltweit führenden Koryphäen und hat für einen Hochschuldozent schon eine fasst unglaubliche Erfahrung als Consultant bei den Global Playern in der Industrie (36 Jahre RE!).
Als ich vor anderthalb Jahren das Vorwort sein neues Werkes "Just Enough Requirements Management" gelesen hatte, bin ich aber fasst vor Lachen vom Stuhl gefallen. Die Werke, die ich von Davis damals gelesen hatte (1985-1999), waren stark formalistisch und Davis beschrieb hier seine Odyssee wieder zurück zu der natürlichen Sprache des Kunden und verpasst allen Beratern gleich eine doppelte Breitseite, die den stark formalistischen Overhead weiter leben wollen. Der Papst wechselt zum Islam! Z.B.:"Foremore, it is impossible for a consultant to walk into the office, examine a requirement, and tell you that it is either too detailed or too vague. The correct level of detail is completely dependent of the needs of customers." und gibt mit 220 Seiten Dynamit fortwährend den 95% aller Beratern, die Qualität von Anforderungen und Specs außerhalb des Konzeptraums festlegen wollen 'ein hinter die Ohren' und buddelt jene Autoren wieder aus, die Mitte der 90'er von der Masse Mundtod gemacht wurden! Während der aktuelle Trend sich stärker zu konnektivistischen Auspägungen des RE - Traceability, Ontologie, Automation, systemaische Analyse etc. bewegt, hält Davis den Ball flach - customer speech!. Sehr interessant ...
Das Buch ist voller Granaten:
Z.B., die Requirements Triage (benannt nach Entscheidung von Feldärzten während des Gefechts bei begrenzten Ressourcen wer leben darf oder sterben muss) zwischen Anforderungen, Terminen, Risiken, Prioritäten und Kosten. Fasst jeder Autor zum RE den ich gelesen habe, drückt sich vor diesen Thema und in diesen Buch ist es Schwerpunktthema.
Unter die dargestellten Unternehmensvorgehensmodelle - Customer Software Development, Customer System Development, Independent Software Vendor, Mass Market Embedded Software Builders, IT with Internal Analysts, with External Analysts and Using a Requirements Consultant - behandelt Davis u.a. auch Wettbewerbsfaktoren.
Oder allein die im Anhang B beigefügte Requirements Set mit runtergebrochenen Anforderungen, entwickelten Prioritäten, Aufwandschätzungen in Personenstunden, Releases, Risiko und dem verlinkten konzeptionellen Modellen. Das ist ein solcher Hinkucker, dass ich oft eine Kopie als Eröffnung in vielen Workshops zum RE verwende.
Selbst in den umfangreichen Referenzen und zusätzlichen Literaturhinweise kommentiert der Autor, was seiner Meinung nach besonders lesenswert wäre - was für eine Expertise!
Oder das Änderungsmanagement mit statistischer Erfolgswahrscheinlichkeit.
u.s.w.
Ein Schönheitsfleck: Harte Zahlen und Fakten werden hier nicht geliefert. Dafür muss man ergänzende Literatur verwenden. Ist mehr ein Wachschüttler hin zum Schleudertrauma :-)
Fazit: Fortgeschrittenden-Buch! Als Profi unbedingt kaufen!
Als ich vor anderthalb Jahren das Vorwort sein neues Werkes "Just Enough Requirements Management" gelesen hatte, bin ich aber fasst vor Lachen vom Stuhl gefallen. Die Werke, die ich von Davis damals gelesen hatte (1985-1999), waren stark formalistisch und Davis beschrieb hier seine Odyssee wieder zurück zu der natürlichen Sprache des Kunden und verpasst allen Beratern gleich eine doppelte Breitseite, die den stark formalistischen Overhead weiter leben wollen. Der Papst wechselt zum Islam! Z.B.:"Foremore, it is impossible for a consultant to walk into the office, examine a requirement, and tell you that it is either too detailed or too vague. The correct level of detail is completely dependent of the needs of customers." und gibt mit 220 Seiten Dynamit fortwährend den 95% aller Beratern, die Qualität von Anforderungen und Specs außerhalb des Konzeptraums festlegen wollen 'ein hinter die Ohren' und buddelt jene Autoren wieder aus, die Mitte der 90'er von der Masse Mundtod gemacht wurden! Während der aktuelle Trend sich stärker zu konnektivistischen Auspägungen des RE - Traceability, Ontologie, Automation, systemaische Analyse etc. bewegt, hält Davis den Ball flach - customer speech!. Sehr interessant ...
Das Buch ist voller Granaten:
Z.B., die Requirements Triage (benannt nach Entscheidung von Feldärzten während des Gefechts bei begrenzten Ressourcen wer leben darf oder sterben muss) zwischen Anforderungen, Terminen, Risiken, Prioritäten und Kosten. Fasst jeder Autor zum RE den ich gelesen habe, drückt sich vor diesen Thema und in diesen Buch ist es Schwerpunktthema.
Unter die dargestellten Unternehmensvorgehensmodelle - Customer Software Development, Customer System Development, Independent Software Vendor, Mass Market Embedded Software Builders, IT with Internal Analysts, with External Analysts and Using a Requirements Consultant - behandelt Davis u.a. auch Wettbewerbsfaktoren.
Oder allein die im Anhang B beigefügte Requirements Set mit runtergebrochenen Anforderungen, entwickelten Prioritäten, Aufwandschätzungen in Personenstunden, Releases, Risiko und dem verlinkten konzeptionellen Modellen. Das ist ein solcher Hinkucker, dass ich oft eine Kopie als Eröffnung in vielen Workshops zum RE verwende.
Selbst in den umfangreichen Referenzen und zusätzlichen Literaturhinweise kommentiert der Autor, was seiner Meinung nach besonders lesenswert wäre - was für eine Expertise!
Oder das Änderungsmanagement mit statistischer Erfolgswahrscheinlichkeit.
u.s.w.
Ein Schönheitsfleck: Harte Zahlen und Fakten werden hier nicht geliefert. Dafür muss man ergänzende Literatur verwenden. Ist mehr ein Wachschüttler hin zum Schleudertrauma :-)
Fazit: Fortgeschrittenden-Buch! Als Profi unbedingt kaufen!
Die hilfreichsten Kundenrezensionen auf Amazon.com (beta)
Amazon.com:
9 Rezensionen
21 von 24 Kunden fanden die folgende Rezension hilfreich
I really wish that I had written this book.
6. August 2005
Format:Taschenbuch
The title says it all, this book really does explore all of the issues surrounding how to do just enough requirements management on your software development projects. I'd argue that it provides the insight that you require to put together an requirements program within your organization that is right for you, one that is sufficiently agile yet still reflects your situation. It explores strategies for eliciting requirements, prioritizing/triaging requirements, specifying requirements, and finally managing requirements change. Davis managed to pull off what few writers can do - by exploring the requirements management spectrum he has presented a range of strategies which should speak to both traditionalists and agilists. For traditionalists he presents some pretty convincing arguments that the "big requirements document up front" strategy might not be all that effective, and for agilists he presents convincing arguments that we need to invest some effort in requirements documentation. Most important is a running theme throughout the book: the goal isn't to write a perfect requirements document, it's to deliver working software which meets the needs of your stakeholders in a timely and cost effective manner. Sounds like really great advice to me.
7 von 7 Kunden fanden die folgende Rezension hilfreich
Requirements Engineering - More isn't necessarily better
24. Januar 2006
Format:Taschenbuch
I was very impressed when reading Alan Davis' latest book on 'Just enough Requirements Management.'
In his past work he has worked on bringing more formalism into requirements engineering in order to make them correct. However, over time he realized that this doesn't solve the real problems, because the requirements are changing despite the fact they've been formalized in advance.
There are not many people who are confident enough to admit that they have learned over the past years which also means that they've changed their mind. Alan is competent enough doing so which makes him really authentic.
A real eye opener for most of the readers is probably his illustration of the reality of ongoing requirements activities despite using a waterfall approach.
In this fast moving world, it is essential to know how much requirements engineering is necessary in order to being able to moving on and it is even more important to know when to stop doing requirements engineering for being in-time on the market.
I really recommend reading this book in order to know what barely sufficient requirement engineering is all about.
In his past work he has worked on bringing more formalism into requirements engineering in order to make them correct. However, over time he realized that this doesn't solve the real problems, because the requirements are changing despite the fact they've been formalized in advance.
There are not many people who are confident enough to admit that they have learned over the past years which also means that they've changed their mind. Alan is competent enough doing so which makes him really authentic.
A real eye opener for most of the readers is probably his illustration of the reality of ongoing requirements activities despite using a waterfall approach.
In this fast moving world, it is essential to know how much requirements engineering is necessary in order to being able to moving on and it is even more important to know when to stop doing requirements engineering for being in-time on the market.
I really recommend reading this book in order to know what barely sufficient requirement engineering is all about.
2 von 2 Kunden fanden die folgende Rezension hilfreich
When the marketing and development teams square off, drop this book between them
21. April 2010
Format:Taschenbuch
As all veterans of the software development process know, the software development and marketing teams often square off in a verbal and textual tussle regarding what the software should do. The marketing team often adopts a rigid, "We've got to have it all in order to sell it" position and the development team an opposite, "we can only do a limited number of absolutely essential features." Extremes tend to dominate over the means and exaggeration is often used to make a position sound more believable. It is much easier to sell your position if you use, "the life of the company is at stake" statements.
The reality is of course almost always in the middle and that is where Davis is. In emergency medicine, triage is the process where when faced with an overwhelming number of patients they are placed in one of three categories.
*) Those that will die no matter what the medical people do. All that can be done here is to ease the transition.
*) Those that will live even if the medical people do nothing. These people can be given minor aid such as painkillers but no major effort should be expended.
*) The injured that will die if left unaided and that will live if treated. These are the people that are given the extensive medical aid. The most critically injured are placed first in the treatment queue.
Davis applies the triage principle to the features that are to be included in the software to be developed.
In a series of meetings, both sides discuss what features are to be included with the desires of the customers given priority. Although it may sometimes be true in theory, it is a rare occasion in practice when developers and marketers know more about what to produce than the customers do. Charts, principles and any other relevant and understandable documentation can be used to justify a position or to record a decision or a development tactic.
The contents of appendix A should be hung on the wall of every room where developers work. It is a summary of the steps to follow including the all-important ranking of the value of features and customers. The old saying about, "the customer is always right" is false, as Davis points out, it should be amended to say, "Your best customer is always right." When you receive a large number of requests for features you should prioritize the features according to the value to the company of each customer. If customer A buys $1M worth of products and customer B buys $1K worth of products, then customer A should be more right than customer B when a decision is made about a feature to include.
Completeness and rigidity in requirements are the enemies of the completion of major projects, so the goal is to develop an encompassing set of flexible requirements that provide enough direction for system development. Developing these requirements is not an easy task, but it is a doable one. You can make that more likely by reading this book and adhering to the principles.
The reality is of course almost always in the middle and that is where Davis is. In emergency medicine, triage is the process where when faced with an overwhelming number of patients they are placed in one of three categories.
*) Those that will die no matter what the medical people do. All that can be done here is to ease the transition.
*) Those that will live even if the medical people do nothing. These people can be given minor aid such as painkillers but no major effort should be expended.
*) The injured that will die if left unaided and that will live if treated. These are the people that are given the extensive medical aid. The most critically injured are placed first in the treatment queue.
Davis applies the triage principle to the features that are to be included in the software to be developed.
In a series of meetings, both sides discuss what features are to be included with the desires of the customers given priority. Although it may sometimes be true in theory, it is a rare occasion in practice when developers and marketers know more about what to produce than the customers do. Charts, principles and any other relevant and understandable documentation can be used to justify a position or to record a decision or a development tactic.
The contents of appendix A should be hung on the wall of every room where developers work. It is a summary of the steps to follow including the all-important ranking of the value of features and customers. The old saying about, "the customer is always right" is false, as Davis points out, it should be amended to say, "Your best customer is always right." When you receive a large number of requests for features you should prioritize the features according to the value to the company of each customer. If customer A buys $1M worth of products and customer B buys $1K worth of products, then customer A should be more right than customer B when a decision is made about a feature to include.
Completeness and rigidity in requirements are the enemies of the completion of major projects, so the goal is to develop an encompassing set of flexible requirements that provide enough direction for system development. Developing these requirements is not an easy task, but it is a doable one. You can make that more likely by reading this book and adhering to the principles.
Waren diese Rezensionen hilfreich?
Wir wollen von Ihnen hören.
Kunden diskutieren
|
Das Forum zu diesem Produkt
Fragen stellen, Meinungen austauschen, Einblicke gewinnen Aktive Diskussionen in ähnlichen Foren
Kundendiskussionen durchsuchen
|
Ähnliche Foren
|
||||||||||||||||||||||||||||||||||
Lieblingslisten
Ähnliche Artikel finden
- Fremdsprachige Bücher > Computer & Internet > Informatik > Systemanalyse & Design
- Fremdsprachige Bücher > Computer & Internet > Programmieren > Software-Design & Entwicklung > Softwareentwicklung
- Fremdsprachige Bücher > Computer & Internet > Programmieren > Sprachen & Tools
- Fremdsprachige Bücher > Computer & Internet > Projektmanagement
- Fremdsprachige Bücher > Computer & Internet > Software
Anhand des Sachgebietes nach ähnlichen Produkten suchen:
Ihr Kommentar
Möchten Sie die Produktinformationen aktualisieren oder Feedback zu den Produktabbildungen geben?
|
