Customer Reviews

Requirements Engineering

5 star:		(4)
4 star:		(0)
3 star:		(0)
2 star:		(1)
1 star:		(0)

 

 

This book presents in the space of some 200 pages, split into 9 chapters, a clear and concise introduction to a state-of-the-art approach to requirements engineering (RE). It starts out by introducing a generic RE process, which is then instatiated, later in the book, into concrete processes for generating stakeholder requirements (i.e. user requirements) and system requirements.

The beautiful thing aboout this generic process (and the concrete ones to follow it) is that V&V and change management are intrinsically part of it. The authors are particularly strong in their treatment of traceability. They have gone into an unusual depth. The book has some good advice on writing better requirements . In particular, I find the idea of requirements boilerplates (i.e. templates for each class of requirements) extremely useful. The book concludes with an introduction/demonstration of the DOORS RE tool, from Telelogic (the affiliation of two of the authors).

Overall, this is an excellent book that every requirements engineer, should have on their desk.

I work in a large financial institution with projects that span across lines of business. I train on process improvement and requirements is one of the key areas I focus on. This book is short and to the point. It provides good examples and is a great read for someone who is just starting out in requirements management or requirements documentation. It provides information on the management aspects of requirements work and practical advice on requirements ellicitation.

The reference continues to be a classic and essential foundation for the growing requirements management domain, an area greatly needed in the complexity of software and systems engineering. It provides guidance to users, managers, developers, quality assurance, security experts, and analysts to overcome the basic challenges in systems development.

I have read a number of books on requirements engineering and I found this one to be by far the best aligned with my way of thinking for a number of reasons. It is very concisely written and therefore could be read, digested, and applied within a few weeks. The plentiful examples were realistic enough for me to understand every concept introduced. Many useful modeling techniques were introduced and explained. A good balance of text and matching clear diagrams were presented throughout. The methods and principles could be applied to relatively simple systems as well as being scalable to more complex systems. The authors didn't try to cover all aspects of systems engineering, but did reference other systems engineering concepts in a meaningful way such that requirements engineering could be placed in context, for example, the linkages to design and testing are explained, but those subjects are not. Different kinds of requirements, and their relationships to each other, are described and differentiated crisply. I spend a significant amount of time writing and managing requirements and I found this book very helpful. I refer to it frequently.

CONCLUSION
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.

GENERAL
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.

CONTENT
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.