Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Use Case for scheduled updates
Previous Previous
 
Next Next
New Post 4/27/2012 4:21 AM
User is offline Peter Herring
13 posts
10th Level Poster


Use Case for scheduled updates 

Hi,

I'm currently documenting the requirements for a case managment application my comapny panning to develop. I've written a number of use casesalready, but I am currently deliberating whether this is the correct approach for a couple of the areas.

The first is where the system will need to make automated updates to cases according to some defined business rules. This is likely to be done as some kind of scheduled job that will run daily and make the necessary updates. 

Most of the detail is in the business rules , and in fact there is not that much in the way of behaviour to document. My question is whether you would still write a use case, albeit a rather short one, or perhaps use some other means to document the requirements.

Similarly, we will also receive certain updates via a third party who is involed in the case. They will call a web service our end and we will need to process the messages we receive from them and update the appropriate cases accordingly. The updates will be sent to us in realtime, and the type of update varies. We've already specifcied the interface in terms of the inputs and outputs, but I still need to define how the system updates cases when it receives these updates. Again, is a use case the best way to document it?

Any advice you can offer would be grately appreciated

Regards

Pete

 
New Post 4/27/2012 6:42 AM
User is offline Kimbo
454 posts
5th Level Poster


Re: Use Case for scheduled updates 
Modified By Kimbo  on 4/27/2012 8:46:29 AM)

 Hi Peter,

From your description I can see two use cases:

One is something like 'Update Case' triggered by something like the system clock or a scheduler. I nearly always end up with an actor called 'scheduler' that is an external system triggering an activity based on some time.

You also have another use case called something like 'Receive Message' where the actor is the other system. The fact you use web services is irrelevant but there is definitely a function there.

Kimbo

 
New Post 4/27/2012 9:42 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Use Case for scheduled updates 

Pete:

Regarding your second question.    If your system is not too complex, then a single use case is the way to go.   If, however, your system is complex, then you need effective decomposition of processes and inputs/outputs.  Use cases offer little in the way of effective decompostion.  Only Data Flow Diagrams do.

Tony

 
New Post 5/4/2012 4:30 AM
User is offline Peter Herring
13 posts
10th Level Poster


Re: Use Case for scheduled updates 

Hello again

Many thanks for your helpful responses.

Kimbo, your suggestion was pretty much what I had gone with so I will continue with that.

Tony, I haven't really had that much experience with DFD's before other than high level context diagrams. It's certainly something I would like to  spend some more time looking at as it looks like a very useful technique.

I have another question around finding the right goal level in your use cases. As I mentioned perviously we are buidling a tool for case managment. Now in my company they tend to use the concept of a "Manage" Use case quite regularly to rollup common behaviour such as CRUD into one use case. Im not completely adverse to this concept under the right circumstances. 

In this system I have the concept of a "case manager" Actor. One of his main responsibilties is to manage hire car requests from vehicle dealerships while they are repairing a customer's vehicle.  For each day that the vehicle is being repaired the dealer must supply information about that repair, and request a hire car for that day on behalf of the customr. For each day of hire the case manager will detimine if the hire is justified, and set it to authorised (paid for by us) , unauthorised (rebilled to the dealer) , or we require more info to make a decision. This is acheived by simply setting a predefiend status agaisnt each day of hire that has occured. The Case Manager may or may not add a note after setting this status, it is completely  optional. At the end of the case, the case manager will finalise the hire car, which basically means that the status of each day is now fiixed an cannot be changed prior to this the case manager may chagne the status of any day), this also sends some data to a couple of external systems.  

So, I currently have a number of use cases for this case manager:  set hire day authority, finalise hire car, add case note.

It was suggested by a colleague that I could roll these up into a "Manage Hire" or" Manage Case" Use Case. My argument, however, was that the goal level is too high since managing the hire is something that typically takes place over the lifecycle of the case, which could be, and often is, weeks. I have alway been taught to write use cases using the single sitting rule, where the goal of the use case should be something that is acheivable in one sitting (eg, apply for a loan, buy goods, withrdraw cash) . and that those goals should provide value to the Primary Actor. 

My current thinking is that these use cases are genrally all single, all be it short, one sitting interactions with the system. In the case of set hire authority, a case manage may open a case, review the repair inforamtion associated with 3 days of hire, set those three days to authorised and leave that case, and  this is fairly typically.  

 I would be keen to know your thoughts, and perhaps how you would have approached this or any advice//tips you can offer from your previosu experiences. 

Regards

PETE 

 

 

 

 

 

 
New Post 5/4/2012 6:47 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Use Case for scheduled updates 

Peter:

In essence, what you are talking about how you decompose your system.   Question:  How do use cases actually guide you in decomposing (or combining) your analysis into various levels of abstraction?  Answer:  They don't.  You are using a "get it done in one sitting" rule, but the use cases do not actually guide you.   You arrive at that decomposition by some exercise  independent of use case construction.

Please remember, that with moderately complex systems, five levels of decomposition are very typical to handle the complexity.   Guidance by the modeling technique in decomposition is critical in such situations.   Even at about three levels, without guidance by the modeling technique itsself, decomposition will soon become pretty oblique.  Only Data Flow Diagrams, via essential interface analysis, actually guide a BA in achieving an effective decomposition.

Tony

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Use Case for scheduled updates

Community Blog - Latest Posts

A business analysis checklist helps you stay organized while you work through projects. It includes questions that will help you identify problems in your current processes, and suggest improvements for future projects. Understand the Problem Before you start writing code, you need to understand what problem you're solving. This means u...
I’ve heard “The End is Near!” for Business Analysts for almost 20 years.  Waterfall project management, with its need for formal requirements, is dead…a dinosaur…so 1990’s.  To be honest, that’s mostly true.  With the publishing of the Agile Manifesto in 2001 there was no need for a 2-inch-...
Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change. As business analysts, we identify and define the solutions that will maximize the value delivered by an organization to its stakeholders. We look for opportunities for new business models and new ways to work together. ...

 






 

Copyright 2006-2022 by Modern Analyst Media LLC