- Taschenbuch: 176 Seiten
- Verlag: Addison Wesley; Auflage: 01 (17. Juli 2002)
- Sprache: Englisch
- ISBN-10: 9780321131638
- ISBN-13: 978-0321131638
- ASIN: 0321131630
- Größe und/oder Gewicht: 15,2 x 1,3 x 23,4 cm
- Durchschnittliche Kundenbewertung: 1 Kundenrezension
Nr. 249.921 in Fremdsprachige Bücher (Siehe Top 100 in Fremdsprachige Bücher)
- Nr. 1165 in Softwareentwicklung (Fremdsprachige Bücher)
- Komplettes Inhaltsverzeichnis ansehen
Andere Verkäufer auf Amazon
+ EUR 3,00 Versandkosten
Writing Better Requirements (Englisch) Taschenbuch – 17. Juli 2002
Kunden, die diesen Artikel gekauft haben, kauften auch
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?
Well-written requirements are crucial to systems of all kinds. This text explains and demonstrates exactly what requirements are for, and how to write them. It provides practical techniques and defines key terms, explaining and illustrating to develop the skills of good requirements writing.
Experience has shown us that investment in the requirements process saves time, money, and effort. Yet, development efforts consistently charge ahead without investing sufficiently in the requirements process. We are so intent to develop the technical solutions that we are unwilling to take the time and effort to understand and meet the real customer needs.
--From the Foreword by Ralph R. Young, author of Effective Requirements Practices
If you are involved in the systems engineering process, in any company -- from transport and telecommunications, to aerospace and software -- you will learn how to write down requirements to guarantee you get the systems YOU need.What skills will I learn?
- How to write simple, clear requirements -- so you get what you want
- How to organize requirements as scenarios -- so everyone understands what you want
- How to review requirements -- so you ask for the right things
0321131630B05282002 Alle Produktbeschreibungen
Dieses Produkt bewerten
Derzeit tritt ein Problem beim Filtern der Rezensionen auf. Bitte versuchen Sie es später noch einmal.
Die hilfreichsten Kundenrezensionen auf Amazon.com
The Book Provides Practical Advice
The book provides good practical advice on writing requirements. Alexander and Stevens follow their own advice for writing requirements in the book by using simple words that contribute to the books readability. The book is written in a manner that will not intimidate non-technical personnel so it may given to the entire project team, including customers and users. (Wait... I just had a novel idea...we should teach our customers and users how to write requirements.)
Here are five of many valuable tips from Writing Better Requirements
1. Perspective on the requirements effort. The authors state approximately 5% of the project effort and up to 25% of the schedule duration should be put on project requirements.
2. Guidance on structuring requirements. Improper structuring is identified as a primary cause of poor requirements. The structuring discussion includes a useful table that documents problems and solutions for structuring requirements. For, example, the authors characterize one problem as Some requirements can be applied simultaneously or in any order and provide the common sense solution of Mark whether sections in the structure are sequences, parallels or alternatives. Overall the authors provide some good alternatives to challenges on how to effectively structure requirements.
3. Plenty of exercises. Another valuable aspect of this book are the exercises provided after a lot of the sections in the book. The exercises provided are well thought out and solutions are included at the end of the book. In addition to the exercises examples are provided to clarify and reinforce key points.
4. Guidelines on conducting a requirements workshop. Important guidelines on how to conduct a requirements workshop are discussed including room lay out and facilitation tips. The book has a good glossary of terms.
5. Lists of other sources of requirements. The book includes a nice list of other sources of requirements. One of these sources that is often overlooked is problem reports from the previous system. The authors state these problem reports can often be turned around into requirements. This is a powerful method to ensure improvement of the future system.
Writing Better Requirements should be a part of every project managers library. I give it 5 of 5 stars! Make your life easier and give it as a holiday gift for your users and customers.
Dr. James T. Brown PMP PE CSP
Author - The Handbook of Program Management
I know a thing for sure: it is only you [a user] and your task; a piece of work to perform in order to achieve a state that is meaningful from an organisational point of view. Note that there is no difference whether the task is to be performed by a fully automatic system function or by a manual user with no computer support.
Nothing more to say, when it comes to theory. Now about the book.
I strongly believe in an approach the authors propagate. Discovering user requirements means you are not thinking about any particular software, hardware or technology. What you are trying to achieve is finding out what a pure state of things is supposed to occur. Unless you forget about IT, this is not a daunting task. Easier said than done.
For ordinary people wanting to identify and gather REAL & PURE user requirements, this book might be a perfect companion. You will not find here any technical stuff concerned with the internals of a computer application, so much beloved by (some) hard-codders, especially the young ones not wanting to hear about messy organizational workflows.
Even if you are a species coming from a planet IT, you should read the book. There is only one but: DO NOT SEEK TO DISTANCE YOURSELF FROM REALITY, that is the world of non-technical users having nothing in common with classes, events, services or rules. Ask yourself this: why the hell a nice&competent girl from Customer Service Department is supposed to tell the difference between A BUSINESS SERVICE (i.e. a building block of SOA) and CUSTOMER SERVICE (i.e. a business function)?
The book is certainly intended for those interested in WHAT a product [not always being a system] is supposed to do, instead of HOW app developers are going to make THE WHAT happen or with what technology THE WHAT might be designed.
'I wanna know how to precisely define what problems a product must [requirement] and could [affordance] solve in such and such circumstances [constraints]'
'do read the book'.
The authors clearly state about the differences between functions, requirements, constraints, and capabilities. All of this without being fluffy. I, for instance, could never agree there exists sth called “a functional requirement”. It is not an appropriate phrase, an oxymoronic one, I’d say. Either FUNCTION or REQUIREMENT. Period.
This book might be of considerable assistance to analysts or users wanting to learn rules of defining requirements related to grammar. It'll help you recognise:
a) which words or phrases are of no or little use (there are many such words);
b) how to build sentences when writing requirements (educated native speakers may fail to write clearly);
c) how to separate requirements from design (needs versus solutions, business versus technology);
d) how to avoid ambiguity and wishful thinking (the latter occurs when you know what a process is supposed to do, but do not have even the slightest idea how it really works).
Last but not least the book does not contain even an iota of abstract ideas.
Another area of eh...the book has a chapter giving quite a few examples of how not to write a requirement, including some good descriptions on why they are bad requirements. Great! That is definitely useful information. However, the next logical step would have been to show how the requirement could have been re-written to be better. Well, that next logical step is missing.
Also, when I read the title "Writing Better Requirements", my takeaway is not how to begin writing requirements. My takeaway is, now that you know how to write requirements, here's how to make them even better. I don't think the book takes it to that next level, but that could just be my opinion. I was expecting more examples of problem area requirements, like how to capture state transition requirements, how best to organize requirements that belong in a specific state and also belong in a scenario or feature section of the requirements.
Overall, there is some decent information in the book, which is why I gave it 2 stars instead of 1. I just think the book could have been executed much more comprehensively and more focus should have been given to experienced requirements writers as the name of the book implies. Instead, it is just little more than an overview of requirements writing geared towards beginners.