Welcome! This site specializes in providing tips and tools for Business Analysts and systems development in general. If you're new here, you may want to subscribe to my RSS feed. If you'd prefer, you can also receive my posts directly to your e-mail. Thanks for visiting!

A few notes and quotes from this past week’s reading.

On UML Modeling:

How to draw UML activity diagrams, Scott Ambler. Scott provides a brief, introductory-level list of guidelines by Scott Ambler for drafting UML activity diagrams.

The use and misuse of includes and extends, MJMurphy. This article discusses the notion that includes and extends stereotypes or frequently misused in use case diagramming. In summary:

Adding lots of includes and extends to your use case diagram can make it difficult to read so use them only when they improve readability and maintainability, and use them correctly. If you are modeling behavior that is common across use cases, consider the includes relationship. If you have complex alternatives and exceptions, consider using the extends.

From use case diagrams to context diagrams, Kevlin Henney. Touts the merit of the good, old-fashioned context diagram, and does a basic compare/contrast with use case diagrams.

• Defining the context diagram:

Context diagrams are intentionally simple with a clear responsibility: They clarify where in the world a system fits, offering an opportunity to discuss the roles that use it and are used by it. It should be possible to fit a context diagram plus a brief description of each external role on a single page.

• Context diagram as compared to the use case:

It is tempting to consider use case diagrams as context diagrams because they do indeed show context. However, use case diagrams show more than just a system and its context; they also show the behaviors the system is to fulfill. By contrast, a context diagram has the single, simple responsibility of showing the system and its context.

On Outsourcing/Offshoring:

Two bloggers that I respect and enjoy reading, Scott Sehlhorst (Tyner Blain) and Bill Miller (You Want It When?), are debating the merits of outsourcing. In Scott’s words, “We looked at pro’s and con’s, and our discussion centered around the best outsourcing model, and what the ramifications of outsourcing really are.”

Scott takes the view that “[complete technical outsourcing] is a recipe for long-term failure,” while Bill argues that “outsourcing is an inevitable change that needs to be accepted.”

I’m not even going to begin to try to parse and pick favorite quotes from the exchange. I encourage you to read it for yourself. Nice work, gentlemen!

On Managing Requirements:

3 tips to improve requirements management, Craig Brown. Craig points out that an open line of communication with and among stakeholders, clients and subject matter experts throughout the project is required to avoid requirements failure (ergo project failure). He adds that BA’s need to be skilled at managing requirements, and not just gathering them.

Related Posts