G'day,
My newest contract involves mostly working on changes to existing systems rather than new, discrete pieces of work. There are no use cases for any of the functionality on any system at present.
If I'm creating new functionality then writing a new use case works of course. But, if its changing existing functions, it means I need to change a use case that hasn't been written. The only way I can see to do this is to write the whole use case from scratch including the change I want to make. This is a significant overhead that is probably unacceptable to my client.
Interested in your experience and advice on how I can handle this using a use case approach.
Cheers,
Kimbo
Hi Kimbo,
If the client is planning to use the current system for a long time to come then it might not be a bad idea to re-create the use cases from stractch. Think of this as documenting the "as-is" model of the functionality of the current system. You probably need to do that anyway (at least have an understanding of it) in order to know what to change. I'm not advocating that you reverse engineer the entire system but just those use cases which are changing. For the rest of the system, simply identify the use cases (in a use case diagram) and perhaps give them a short description but not more. This way, either you or future consultants can build upon that foundation to slowly fully document the current state of the system and then maintain that in the future. Of course - this takes discipline and commitment on the part of the client.
Another option is to simply create a set of "use case scenarios" which, as together, provide coverage of the functionality of the system which is changing. This way you still use your use-case centric skills and approach without having to document full use cases.
The key question is "why use cases"?
You either don't need to document how/where the changes fit in the existing system and business process in which case all you might want to use is annotated mockups of the existing system. However, if there is a need to place the changes in the context of existing business processes then re-creating the use cases is not such a bad thing. Another option would be to creat process flows (sequence diagrams) instead.
Hope this helps!
- Adrian
Hi Adrian,
Yes I pretty much have come to the conclusions you have. I think the idea of the process flows with your use case scenario idea may be the way to go. Like the idea of just doing the relevant scenarios rather than the whole use case. However I don't think the company will wear my time to create the process flows. We'll see. Its an insurance company with multiple complex systems. A lifetimes work to document and I have better things to do with my life :-)
I'm still interested in any ideas from others. Please post them here.
brought to you by enabling practitioners & organizations to achieve their goals using: