Writing Better Requirements (英語) ペーパーバック – 2002/8/21
Kindle 端末は必要ありません。無料 Kindle アプリのいずれかをダウンロードすると、スマートフォン、タブレットPCで Kindle 本をお読みいただけます。
Ian Alexander is an independent consultant specialising in Requirements Engineering. He has written several training courses on systems and requirements engineering. He has led hundreds of training courses on systems engineering, requirements, DOORS, and DXL, and has run numerous practical workshops on scenarios, trade-offs and requirements. He was co-author of an Addison-Wesley book on HTML 3 and its 2nd Edition on HTML 4. He is the author of the Scenario Plus for Use Cases toolkit, and is a well-known speaker and writer on scenario usage. He is currently on a technology project to investigate the reuse of specifications for control systems in the German automobile industry. He helps to run the BCS Requirements Engineering Specialist Group and the IEE Professional Network for Systems Engineering. He is a Chartered Engineer.
Richard Stevens is the founder of QSS, the firm that launched the pioneering Requirements Management tool DOORS, the world¿s most popular requirements tool. He is the co-author of books on "Systems Engineering", "Software Engineering Standards", "Software Engineering Guidelines" and "Understanding Computers". In 1998, Richard was appointed as the first European Fellow of INCOSE, the International Council on Systems Engineering.
|星5つ 36% (36%)||36%|
|星4つ 27% (27%)||27%|
|星3つ 15% (15%)||15%|
|星2つ 15% (15%)||15%|
|星1つ 7% (7%)||7%|
So it had things like " the main thing you need to know is...... then missing pages. *grrrrr*
Appart from that it looked like a useful book and Amazon were very good about sorting out the return.
It was quite funny irony realy, with the focus of the book being on quality and not letting mistakes reach live and so on.
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.
The content is good, although only related to stakeholder requirements elicitation and structuring, nothing about requirement mgmt.