Collaborative Systems: Easy To Miss The Mark by Jocob Morgan.
From the post:
Map out use cases defining who you want collaborating and what results you want them to achieve. Skip this step in the beginning, and you’ll regret it in the end.
One of the things that organizations really need to consider when evaluating collaborative solutions is their use cases. Not only that, but also understanding the outcomes of those use cases and how they can map to a desired feature requirement. Use cases really help put things into perspective for companies who are seeking to understand the “why” before they figure out the “how.”
That’s what a use case is: the distilled essence of a role within your organization, how it will interact with some system, and the expected or desired result. Developing use cases makes your plans, requirements, and specifications less abstract because it forces you to come up with specific examples.
This is why we created a framework (inspired by Gil Yehuda) to address this. It breaks down as follows:
- — Identify the overall business problem you are looking to solve (typically there are several).
- — Narrow down the problem into specific use cases; each problem has several use cases.
- — Describe the situation that needs to be present for that use case to be applicable.
- — Clarify the desired action.
- — State the desired result.
For topic maps I would write:
Map out use cases defining what data you want to identify and/or integrate and what results you expect from that identification or integration. Skip this step in the beginning, and you’ll regret it in the end.
If you don’t have an expectation of a measurable result (in businesses a profitable one), your efforts at semantic integration are premature.
How will you know when you have reached the end of a particular effort?