Laura

Your use case experiences mirror my own. I find use cases are an important tool in my toolbox. I use them when we’re talking about interactive processes in our requirements sessions. We link them in closely with the wireframe development calling out to the wireframe in the use case at the appropriate step. Think lots of stickies and flip chart paper with taped lines to start with!

However, I feel the need to turn to other methods when we dive down into the “nitty gritty” of complex business rules, such as integrations with accounting systems. I struggle to find good tools to represent those rules (spreadsheets anyone?) and how to link those complexities into the one step that they pertain to without getting into too much system language for our end users. Would love to hear yours (and anyone elses) thoughts on those topics.

Thanks again – I really enjoy your blog!
Caroline

Thanks for sharing your story. Interesting how we can have different ways of accomplishing the same end goal.

In terms of how we can be sure that our discovery artifacts are correct if we only deliver a subset, I suppose I would say, concretely speaking, no, but we can make them good enough. As I’ve done iterative projects, there is sometimes a need to circle back to documents that you’ve already “completed” in an earlier iteration and make revisions. This works nicely in an agile process because you can just create a new story to hold and prioritize the change as opposed to a more rigorous change control process that might be necessary for a use case with sign-off. Regardless, what was defined in an earlier iteration was good enough to get started. And the information you have later in the process is much better because you might actually be reviewing something in a demo environment, so the change is more informed that if you were just working from your requirements documentation.

So for me, when I start on something I use whatever tools seems most appropriate to help me understand what’s going on, what needs to be fixed/improved, etc. I like context diagrams and process flows, but when I think of starting something new, I think I tend to approach them from a UML standpoint. Who is doing what with what? And then we make sure that those answers make sense in terms of the business strategy and process efficiency.

Then once I do understand, I can pull out the artifacts (be they requirements, wireframes, context digrams, data flows, decision trees, or use cases) which best communicates to my stakeholders.

Clearly use cases fill that role for you during your discovery and the ultimate deliverable is something that varies for you as well, depending on your target stakeholder. So the question for me is: Can we be sure that our discovery artifacts are correct, if we only deliver a subset of them for sign off? How much does that matter?