Life Lessons Flowchart image by nbrier
Craig Brown, who runs the fabulous project management/business analysis blog Better Projects made a call for participation to various bloggers in that niche to list the first and last analysis models we’ve used at work. Being the good sport that I am, here’s my reply.
The First
The first analysis model I can remember using was a basic swimlane process diagram. I used that quite a bit starting out as it is a) simple to pick up and use, and b) a picture is worth a thousand words and people just seem to “get” the simple flow diagrams. Mind, I purposely don’t call it an activity diagram, because, at the time, I don’t know all of the UML notation, but the simple MS Visio swimlane diagram is still one of my favorite tools, especially for illustrating simple busines flows to a non-technical audience.
The Latest
Just this past Friday, I spent some time on a couple types of analysis model diagrams.
The first was just your basic use case diagram. Yep, the one with the stick people pointing to their little goal bubbles. I’m going to take it to a meeting tomorrow afternoon with some business stakeholders and one of my design SME’s. It is more of a technology infrastructure project to optimize/automate some existing functions that still require a bit too much manual effort than a project for new functionality, so I am just trying to make sure that I’ve captured all the actors and functions that we think have a stake, or may be affected by the project.
Cockburn will tell you that in the early stages of use case modeling, we’re after “breadth before depth.” I’ve found that bringing the very basic draft diagram makes it easier to keep the players in the range of the level of detail I’m looking for at this early stage.
The second is a context diagram for a high-level business requirements document for a separate project (we call it a business requirements document, but for the Wiegers disciples out there, it equates to the vision and scope document). This is a diagram I use early in analysis to understand which other systems and groups interact with the project’s core system.
In this case, the context diagram isn’t a detailed communication diagram but a simple visual to help the project team make sure that we’re involving the right folks in our detailed analysis activities.
So, there you have it. I’m sure Craig would be glad to have you participate in the meme by commenting on his original post, or you’re welcome to do it here. I’d be equally interested in your responses.
Comments