31 of 32 people found the following review helpful:
5.0 out of 5 stars
How to use UML as a BA, June 9, 2006
This review is from: UML for the IT Business Analyst: A Practical Guide to Object-Oriented Requirements Gathering (Paperback)
Many other good books are available for learning the UML. There are good books for learning to write Use Cases. This book's real strength is that it offers a practical method for Business Analysis that uses the UML and Use Cases. This is very important because books explaining UML typically offer lots of details and a focuss on how developers might use the UML in blueprinting a system; this book, instead, explains when, why, and how the BA can use the UML and Use Cases to model and analyze the business context and business requirements, as well as ensure that business value is delivered.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
29 of 30 people found the following review helpful:
4.0 out of 5 stars
Clean, reasonable guide to OO and UML for beginner to medium level BA, February 2, 2007
This review is from: UML for the IT Business Analyst: A Practical Guide to Object-Oriented Requirements Gathering (Paperback)
There are so many opinions about how UML should be used and none can claim universal application. It is not only the complexity of UML and OO methodologies, but the variety of software tools that support these methods and then you have to deal with an infinite variety of real life situations and people. At the end of the day, a BA must write documentation and communicate findings, outcome and models to stakeholders, users, developers, architects and sometimes to third parties involved in the project. Every single person has a different view, companies have different document templates and actors have different education and skills. How can you write a book to teach UML and make anyone happy? You can't. So, you have to get something from every book you read that suits you, your training and the project methodology used in your business.
I think that Howard manages to walk you through the complexity of all this, recognising the inherent limitations that I listed above and present a framework that you can use to expand your horizons. The author is reasonably disciplined about the UML standard, so this is not a popular book for, say, accountants or florists that want to know about UML. Another positive point of this book is that you are provided with documentation templates that you can use straight away to write business requirements for your next project. Additionally, the author combines the description of UML constructs with an induction into OO methodology. Some authors fail to make this connection between the standard and the work methodology.
The book is written by using a real life project large enough to cover almost every aspect of UML. Howard is quite practical, whenever he feels that in practice some tools are not widely used, he will say so and avoid spending too much time on something just to show you how much he knows. The examples are simplified to keep the size of the book at a sane level. The depth of the book is adjusted so that beginners are not intimidated by the complex concepts, especially when it comes to discuss static modelling.
The last section of the book talks about testing and spends sufficient on explaining the foundation of structured test methodology. Testing is becoming more and more specialised work and progressively fewer business analysts do both business requirements and test implementation. However, it is important to connect these two activities, and Howard does that very well. Testing should be based on business requirements and verify that the requirements are fulfilled.
One not so positive comment that I would make about the book, is that it mixes too much the role of the business analyst and system analysts. I believe that he should have put more emphasis on separating the roles, because they require distinct set of skills. Also he should have made the reader aware that the project management methodology has an impact on the way the business analyst works. The subject of project management is not discussed very much here. If you work in a large organisation this is an important factor to consider. On the book cover the claim is that you will learn how to use IBM Rational Rose. I think that this is a little bit exaggerated. Overall this is a clean, nice and useful book, if you fall in the right category.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
21 of 21 people found the following review helpful:
5.0 out of 5 stars
Finally a UML book with techniques for the business analyst, July 6, 2005
This review is from: UML for the IT Business Analyst: A Practical Guide to Object-Oriented Requirements Gathering (Paperback)
hiho,
I have worked with requirements analysts for years helping them apply UML modeling and we have had to patch together a reading list from use-case texts and chunks of object-oriented modeling texts. There was never one book that gave them the requirements modeling techniques they needed without being predominantly about detailed software modeling. Here is a text tuned for the needs of the analyst.
This text introduces the object-oriented paradigm and walks through a methodology for creating a proper requirements model with UML. It goes from business use cases to system use cases and then into detailed static and dynamic analysis. When I say detailed I mean detailed enough for a requirements analyst to create a complete, cohesive set of requirements artifacts; this book is not about what it takes to model the details of a particular technical architecture.
In allaying the emphasis on more technical modeling, the author is free to cover a full end-to-end methodology that starts with modeling the business, marches through detailed requirements modeling, and ends up with a test strategy aligned with the requirements and the business.
Highly recommended.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
