Patterns for Business/Systems Analyst
|
|
Analysis Patterns are fast catching Design Patterns as a modus operandi. This book not only presents analysis models that you can use from day 1, but also gives you an insight into a master analyst at work. I recommend all Martin Fowler's books, but this is a good place to start for the BA.
|
|
|
Excellent book for all analysts
|
This is simply an excellent book; quite possibly the best book I have read on analysis.
Martin Fowler cheats by actually being able to write. He has a very lucid prose style making this a very readable book (a strength that also manifests itself in his book UML Distilled) even though it deals with complex subjects.
The book deals with using patterns to address particular business areas. However, it has a great deal to offer anybody interested in analysis or modelling (whether they are working in the OO world or not) and provides one of the best explanations I have read of the purpose and objectives of modelling.
Each problem area is presented very clearly and a number of different solutions are presented at different levels of abstraction (and hence complexity) with lots of useful insight into the factors that would determine the appropriate model.
Analysis Patterns is a book that bears reading and re-reading. I frequently refer it as an excellent source of interesting ideas on ways of approaching complex modelling & analysis issues. I have never managed to take one of the patterns and apply it as is; however, the ideas and concepts expressed in the book influence many of my models (even when the business problem I am tackling initially appears to be entirely unrelated to any of the patterns).
Frankly, this is a book I wish I had written.
|
|
|
Excellent practical experience
|
|
This book is clearly derived from practical experience using OO analysis on real projects. Added to that the chapters are well structured and build upon each other nicely. Upon first reading I immediately saw how the patterns reflected things I was seeing in my current project. Having read the book from beginning to end it now lives on my desk for regular reference during day to day work.
|
|
|
indispensable for those using OO analysis
|
|
I've got most of the books on patterns and find that this is the one I use the most. The writing is clear, the patterns address problems that I run into, and mostly the solutions are just what I need. This book is great to give to analysts who are having trouble agreeing with each other, because they often are persuaded by the book. It is great to give to analysts who are trying to master OO concepts, or to programmers who don't understand why things have to be so complicated. Everybody I know who has read it likes it. I just wish more people would read it! The only thing I don't like about the book is the notation. I wish he had used UML. On the other hand, after you spend a few days with it, it isn't hard to understand. It is just one more notation.
|
|
|
Strong advocate for the domain analyst
|
|
The analysis model is often forgotten. Too often designers will do just that -- design, i.e., solve the problem before serious inquiry into requirements analysis. This book addresses that which is between the use-case and detailed design model. It is the domain analysis model. Fowler is an excellent student of M. Odell, and it's high time that Odell's thinking was made accessible to the domain analyst. Fowler's book is general enough to get across the point that it is how we think about the problem that is the important part of modeling, and not some arcane "modelling process" that is significant to methodologists. A note about reusability, as pertains the title: to my mind it is this thinking which Fowler describes that is a part of modelling that is reusable. The output of his thinking, the actual models in his examples deriving largely from the financial domain, could be in fact reused. But it is the thinking that is important. The only bad thing I can say about this book is that I fear, by its title, it may not reach its desired audience of the domain analyst, because these are, quite frankly, the scientist, the doctor, the finance expert, etc. that can really benefit from modelling since they have the in-depth knowledge of the domain. It is the job of whoever reads this book to spread the message. Power to the domain analyst!
|
|
|
United States | 
United Kingdom | 
Canada