Customer Reviews

UML for the IT Business Analyst: A Practical Guide to Object-Oriented Requirements Gathering

5 star:		(10)
4 star:		(7)
3 star:		(2)
2 star:		(1)
1 star:		(1)

 

 

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.

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.

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.

Finally Business and Engineering Can Speak the Same Language

It's an honor that I can be one of the first to write a review of Howard's new book 'UML for the IT Business Analyst'. Finally, a book has been written that 'connects the dots' between the business community and the software engineering community. Howard has written the book that I wish I had in my library when I was at university and later while first learning to use the UML to perform OO Analysis and Design. The book is extremely well written and easy to understand. Not only would it make an excellent college textbook for both business and computer science majors, it is a book that every business analyst, project / program and product manager will want to keep close at hand as a desk reference as it is filled with all sorts of real-world examples of applicable 'best practices'. Howard has also managed to bridge the long-standing communication gap between the business and engineering communities. Using the UML to capture, model, and analyze requirements is a stroke of pure genius -- as the UML is a powerful 'translation' tool -- almost a kind of 'universal translator' that allows the business world to effectively communicate with and be understood by the software engineering world. Howard provides some very helpful templates, as well as special sections early on where he clearly translates some of the more obscure and complex definitions of the UML. These 'What they say:' sections provide the actual textual definitions from the UML 2.0 specification. These are then followed by 'What they mean:' sections where Howard cleverly and clearly explains in simple 'layman's' terms just 'What they say'' REALLY means. I wish he would have included a laminated 'cheat- sheet' containing all of his 'What they mean:' translations on them. I would then copy it and hand it out to the sponsors, every key stakeholder, and every single team member in attendance for each new project 'kick-off' meeting. I would also make sure to give a copy to all project team members (developers, testers, and product support), and all subject matter experts and end-users who will participate in the requirements capture, modeling, and analysis phase of the project. In addition to these most helpful UML definitions, Howard provides an actual case study that allows the reader to literally 'walk-through' every single step of the process for producing a fully developed business requirements document. As a self-study tool or a college text 'UML for the IT Business Analyst' is written in such a way that an entire chapter's content can be 'locked in' memory by simply re-reading and reviewing the 'Chapter Objectives' and 'Chapter Summary' sections. As for the design and formatting of the book -- again Howard demonstrates that he clearly understands design, balance, aesthetics, use of white space... Every chapter and each individual sub-section is formatted for the highest readability, and each table, chart, diagram or sample artifact, is fully described in meticulous detail. The writing itself is smooth and flowing (which is generally quite challenging to do with books written for both a highly technical engineering audience as well as a much more business focused audience). Finally, the case study is completely believable -- based upon 'real world' experience and not some imaginary set of 'sunny day' scenarios used to explain theoretical principles. Howard has made it possible for the reader to literally use the chapters to set breakpoints and then 'step through' every event that happens during the capture, modeling, and analysis of business requirements leading to a thoroughly 'usable' set of UML-based artifacts. The BRD template alone is worth the investment to buy the book. In over 20 years of working in the computer industry, I have never seen a more thorough example of what should be included in a BRD -- it's that good! I truly thank Howard for writing this book as I believe that it provides much needed information as well as a fully developed model for how to practically elicit, capture, model, and analyze requirements for complex IT and software engineering projects. As a former managing consultant, and a project, program, and product manager,(working daily in the trenches), without question, I professionally and personally recommend 'UML for the IT Business Analyst' to every one of my colleagues in the industry, and I encourage any technical professional who has a passion to learn to better understand their customer's wants and needs, to provide the best possible customer focus and service, to deliver quality products and applications that the customer really can and will use, to become a truly superior business analyst, project, program, product manager, whose primary goals include 'personal excellence and self-mastery' -- then buy, study, learn and USE the 'best practices' that Howard has captured in 'UML for the IT Business Analyst'. Then you'll be able to write your own 5-star review. I can't wait to see what Howard will write about next.

Howard actually personally delivered training at my company based on this book. We had originally planned a different training cirriculum based on a collection of material across several of the courses offered by a university, for which Howard had previously provided training. We agreed that due to our company's recent changes and migration to a more agile development process, that the book content was more appropriate for our situation, even though his book is not specific to agile development. Rather it is relevant to any development process utilized. The book provides excellent integration with Rational Rose, which is the de facto modeling tool in the industry. The examples in the book are very relevant to those developing enterprise applications, which Howard has a great deal of experience developing. I highly recommend this book and any opportunity you may have to take a training class lead by Howard.

I'm not so sure that I like the title to this book. What it's really about is teaching the IT requirements writer to communicate with the programmer folk about what he wants a business software system to do. Perhaps a title like Teaching the Business Folk How to Talk with the New Object Oriented Programmers. True, he does use UML to define the business model. But if you understood the problem you'd still not necessarily understand that UML is what you need.

Object Oriented programmers talk funny, at least as far as we old fashioned procedural programmers are concerned. Mr. Podeswa uses a 'What They Say -- What They Mean' approach to help us understand the jargon of the object oriented world. Then he combines thing we can feel and touch to describe these words. For instance a specialized class like 'Samsung Camera Phone' belongs to the generalized class of 'Mobile Phone.'

This is an example of the writing style where the author is leading us by the hand (with things like sample work sheets) to producing a model that the object programmers can understand. Lo and behold, it's using the UML.

There are many good books that deal with UML from an end-to-end systems life cycle perspective. There are few books geared to address our role as Business Analysts in a world which wants to see requirements expressed using the Unified Modeling Language and Use Cases. (Finally something for us!)

The things I liked best about this book are:
1. The material presented is quite extensive and provides more than just UML.
2. Information provided has supporting rationale and examples.
3. There are a number of templates that can be used right away.
4. Workshop Case studies which show how theory hits reality.
5. Good readability - not an abstract academic treatise but written to guide a learner.

I was not enthused by the provision of tool coverage specific to Rational Rose. For the type and number of models that we, as Business Analysts, produce Microsoft Visio works just fine. I think it would have also been useful to distinguish what UML models and artifacts belong in a Business Requirements Document versus a Software Requirements Specification. I am not fully convinced that all the models presented by Howard Podeswa would be understood or appreciated by the end-user, the sponsor, the typical business user. The models are invaluable for telegraphing to the development team direction going forward but not as valuable for John User who is asked to sign off on a Business Requirements Document.

The reason that you are reading this review is probably because you have just become, or are considering becoming, a Business Analyst (IT), and are looking for suitable learning material to assist you down that path. If this is the case, there is something you should know - there is no one, clear definition of the job title `Business Analyst (IT)'. For this reason, you will undoubtedly find varying degrees of positive and negative reviews on just about any book ever written on the subject - this book included. With that in mind, I propose to give you first, my hopes and expectations for buying this book, and then why I found it a positive experience. If you can identify similarities between yours and my expectations and hopes, then I think it's fair to assume that you can expect to benefit from it as I did. (But that isn't to say that if you don't identify those similarities, that you won't find something in it for you - only that I can't say whether or not you will be satisfied).

So, I have been in the IT business for very many years, and I have (at one time or another) worked in all of the disciplines (as defined by RUP) of the project lifecycle, and my job title is currently `Business Analyst (IT)'. I am certified OCUP UML and RUP Solution Designer, which means that I am familiar with both the nuts and bolts of the UML, and of the software development process (as defined by IBM) as a whole. But these experiences and certificates individually do not collectively confer the title Business Analyst (IT) by anyone's standards. Correctly, completely and clearly eliciting and documenting business requirements such that they can be used to guarantee a successful implementation of the contract between Business stakeholders and software developers takes much more than that.

So, what was I looking for in a book? A workflow that would enable me to confidently ask the right questions of the right people at the right time. A logical place to store the captured information. The appropriate level of detail to put into models and documents to enable me to progress efficiently with the dialog between respective stakeholders. The right places to store and cross-reference additional artifacts. The means to cross reference different pieces of each model to ensure consistency and completeness. How, when and where to consider testing aspects. The means to bring it all together. In other words, what I wanted was to `see' and `feel' the complete process in action, not just the parts.

I can safely say that I got what I was looking for. Every project in every company is different, and `Adapting the software development process' is the first thing that is always necessary when starting a new project. There will be tasks to perform that are not covered by this book, and there will be tasks detailed in it that are not necessary in some situations. Nevertheless, this book is a great foundation for the BA (IT) and I have seen little else that tackles the subject as well.

My hat is off with sincere thanks to the author.

UML for the IT Business Analyst is a great 'field guide' for Business and Systems Analysts at various levels of experience. The key thing I like about the book is that it teaches and also encourages truly "collaborative" working in building a business solution.

Collaborative Working

True collaborative working is something that I have found to be the most commonly missing ingredient on IT projects of all sizes. IT and business-side Analysts need to work with various stakeholders and players of varying levels while attempting to deliver true business solutions. Not an easy task, but from my years of experience in the field as a Business Architect I can testify that it is indeed possible.

This book goes a long way to showing you how.

UML for the IT Business Analyst is a resource that provides Business and Systems Analysts with tools and templates for success. You can pick the section that applies to your circumstances, your project or your experience level and go and implement it.

Gets a thumbs up from me 'Bayo Akinola-Odusola any day...and I don't give thumbs up that easily!

I've given this book 2 star. 1 because it just is not overly useful & is quite prescriptive. The 2nd star because, the title is bang on - It really is UML book for Tech-oriented BA's.
Given the content, this really could have been written with 1/10th of the content, paper & cost.

This will have some value for tech-heads wanting to write "something up" in a structured (template-prescribed) manner, but if you have any remote BA experience you will not be satisfied will shelling out for this book. It seemed to have interesting self-bias that I couldn't put my finger. I tried using the format & approach in this book for role I had a few years ago that demanded exactly the approach outlined in this book. I spent more time of trying to extract the practicality of it, than I did in actually writing my spec... which was after realised I was wasting my time.

Summary: Good to techies to entry level analysis only.