Requirements Engineering (Practitioner Series) (英語) ペーパーバック – 2002/9/17
Kindle 端末は必要ありません。無料 Kindle アプリのいずれかをダウンロードすると、スマートフォン、タブレットPCで Kindle 本をお読みいただけます。
Written for those who want to develop their knowledge of requirements engineering process, whether practitioners or students. Using the latest research and driven by practical experience from industry, this book gives useful hints to practitioners on how to write and structure requirements.
- Explains the importance of Systems Engineering and the creation of effective solutions to problems
- Describes the underlying representations used in system modeling - data flow diagrams; statecharts; object-oriented approaches
- Covers a generic multi-layer requirements process
- Discusses the key elements of effective requirements management
- Includes a chapter written by one of the developers of rich traceability
- Introduces an overview of DOORS - a software tool which serves as an enabler of a requirements management process
Additional material and links are available at: http://www.requirementsengineering.info
"In recent years we have been finding ourselves with a shortage of engineers with good competence in requirements engineering. Perhaps this is in part because requirements management tool vendors have persuaded management that a glitzy tool will solve their requirements engineering problems. Of course, the tools only make it possible for engineers who understand requirements engineering to do a better job. This book goes a long way towards building a foundational set of skills in requirements engineering, so that today's powerful tools can be used sensibly. Of particular value is a recognition of the place software requirements have within the system context, and of ways for dealing with that sensitive connection. This is an important book. I think its particular value in industry will be to bring the requirements engineers and their internal customers to a practical common understanding of what can and should be achieved."
(Byron Purves, Technical Fellow, The Boeing Company)
This book really didn't hit the mark for me. It mainly falls down in not clearly communicating its content. It tries to cover a fair bit of territory in a small book, and the result is you can only understand it if you already know the content, which pretty much defeats the purpose of reading it.
A fair bit of the content covered things that I wanted to know more about, but I found that the book either told me things I already knew, or else covered things that I didn't know but didn't explain them properly. It is pitched at a reasonably high level, so if you are newer to the area you would get lost or baffled quickly.
It is a fairly short book, at a little under 200 small pages, and so coverage of some areas was very brief and as a result not informative.
The authors are from a software background, and although they have tried to make the book applicable to any systems engineering process, their software background does come through. Often content is explained using concepts and language from software engineering, which may not communicate well to those from other fields.
There is some use of examples in the book, and this does help to explain the concepts, but I found many of the examples were too limited or trivial to provide a deeper understanding.
Modelling section. Techniques were only briefly covered, and although the fact that there is an intimate relationship between modelling and requirements is stressed early on in the text, there is no significant explanation of how to use modelling to help generate requirements.
Chapter 4 has quite a good coverage of spec writing, but really quite brief (just 14 pages). Nothing specific is mentioned about reviewing, apart from the implication that the criteria for good requirements stated should be the basis for reviewing. The boilerplate requirement concept was quite good.
Perhaps the best chapter in the book for me was Chapter 7 on advanced traceability. This had some good ideas that were generally well explained, although at times the explanations used concepts and language that were targeted towards software types.
FORMATTING AND PRESENTATION
Despite my real desire to learn more about requirements engineering, I couldn't help my attention and interest level taking a dive whenever I read more of this book. It's hard work to digest - both in the writing style, the graphics, and the whole approach to informing the reader. Little effort has been giving to making the experience enjoyable or easy.
Diagrams are very basic, and typically uninformative. Have a look at the diagram on p116 in the "look Inside" function as a typical example. If figure 6.1 makes the text on this page clear to you, then disregard my comment about the diagrams being uninformative for your case.
Formatting of the document (eg font) is very dull, which adds to the lack of readability. There are also occasional editorial problems, like sentences chopped off with out an ending.
Maybe I'm being a little harsh on this book, because at the same time I was reading a book called "The non-designers Design Book", about designing documents. The Design book was a model of clear presentation, visually attractive, lots of clear examples and enjoyable to read, which Requirements Engineering was none of. Although the Design book is pitched straight at beginners, after reading it, the flaws in the design of Requirements Engineering book as a document were very obvious.