Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Structured Anal...  Use of Use Cases in a "Change Request" environment
Previous Previous
 
Next Next
New Post 10/3/2009 4:57 AM
User is offline Kimbo
454 posts
5th Level Poster


Use of Use Cases in a "Change Request" environment 
Modified By Kimbo  on 10/3/2009 7:02:34 AM)

 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

 
New Post 10/3/2009 4:34 PM
Online now... Adrian M.
755 posts
3rd Level Poster




Re: Use of Use Cases in a "Change Request" environment 

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


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
New Post 10/5/2009 12:00 AM
User is offline Kimbo
454 posts
5th Level Poster


Re: Use of Use Cases in a "Change Request" environment 

 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.

Kimbo

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Structured Anal...  Use of Use Cases in a "Change Request" environment

Community Blog - Latest Posts

Salesforce has established itself as one of the most reputable CRM platforms, providing important customer data to assist businesses in effectively managing their operations. Salesforce is the world's best CRM platform that helps businesses to keep up the data in an arranged or structured manner. Salesforce is the world's most popular...
There are big differences between data exploration versus data presentation. And you need to be aware of these differences as you're creating data stories and data presentations. Let’s start by defining our terms: Data exploration means the deep-dive analysis of data in search of new insights. Data presentation means...
Is Agile a reason to avoid documentation? I bet this question shows up again and again while working with product requirements. On one side, we have got long specifications, complicated diagrams, mystical technical design, too many prototypes and pretty obvious for engineers user guides (do we really need so much?). On the other side, can we actual...

 






 

Copyright 2006-2022 by Modern Analyst Media LLC