Writing a killer use case for a cron job [closed]

Question

I'm a beginner when it comes to writing use cases, but I searched a lot and most of the materials I found mentioned that I should concentrate on the business value to the customer when writing a use case.

example: Use case for a search page

1- User opens search page  
2- User provides the search word
3- The system presents the search results

Of course it was easy to write the use case as the system had some kind of UI that that user interacted with.

However, what if I'm writing a use case for a cron job?

I was developing a module that basically connects to a number of ftp servers to download some files then the downloaded files are parsed to generate some reports and finally these reports are uploaded to my company's ftp server.

The problem is the only business value for the whole module is the generation of the reports (i.e. The team who requested that module only cares about the reports not anything else).

This is the use case I came up with:

1- The system downloads the files from the ftp servers.
2- The system generates the reports from the files.
3- The system uploads the reports to the company's ftp server.

However as I was reading Applying UML and Patterns, 3rd released edition the author introduced a monopoly game use case as follows:

A whole game in just 3 steps!!! I thought since the whole purpose of the game is just the simulation then maybe that's why he didn't mention any details, and maybe I should do the same too.

---

So now I have exactly 3 mixed questions:

1- Should use cases focus entirely on the business value for the customer and ignore internal operations?

2- In case a cron job is invoked how to determine the business value if the customer has no interaction what so ever with the system?

3- A colleague of mine actually contradicted with my approach entirely and he insisted that I should write as much details as possible in a use case (as instead of The system downloads the files from the ftp servers it should be decomposed to the smaller functions that make this feature such as get list of servers from DB,connect to ftp server, check if there are any files, download file,delete file from ftp server,close connection). Is this correct or better?

Answer 1

UML has rules but UML is not a methodology. You either adopt a methodology or use your best judgment. The answers below are based on my own judgment.

1- Should use cases focus entirely on the business value for the customer and ignore internal operations?

Use cases may be used during requirements gathering. Such use cases focus on what the customer wants and understands mostly. Use cases can also be used for design and testing. In this type of use case, you should not ignore internal operation scenarios that affect the output. Such cases are sometimes sub-cases of the ones used in requirements gathering. However, in practice, when the use case is too detailed, it becomes a process. You need to decide which tool to use for which level of detail and which audience.

2- In case a cron job is invoked how to determine the business value if the customer has no interaction what so ever with the system?

Cron jobs are invoked as a result of an event that is meaningful to the business in some context, for example end-of-accounting-period. The business gains value by receiving the report and analyzing its contents on the event the business specified in the requirements. The real value is not in the cron job firing, the real value is in making the specific report available to the customer (or at least generated) at that specific event (time).

3 - Your third question (not listed so that the answer is concise)

What you are describing is the question text for question 3 is a detailed process not a use case. You better use a UML activity diagram for that type of detail and leave the high level covered in the business use case.

Answer 2

Behind every use case there's a story or 'use case scenario'. You need to think about that first before breaking things down into steps and actors and so on. Also, don't forget that time can be an actor.

To start with, it shouldn't matter if the story begins and ends at points that are outside the scope of the project, it at least sets the context and it's easier to narrow things down later. Don't dwell on these 'outer limits' but at least consider them - who's using the reports, how are they using them, what happens if they're late, what happens if they don't arrive at all?

You could end up with something like:

1. User sets timer (or asks the system admin to) to produce reports daily
2. The timer event triggers the system
3. The system updates the reports
4. Next day, the user has a fresh set of reports to...

Answer 3

In my understanding the usecase (or userstory) should concentrate on what is requiered. (for example a customer in a web-shop can search for a product by brandname)

in your examples you concentrate on how the requirement can be implemented. (i.e. steps needed to implement the usecase).

to answer you question

 > Writing a Killer use case for a cron job

A Cronjob is a technical implementation detail that does not have a businessvalue of its own.

the killer use case would be: "if the webshop crashes most of its data can be restored from the backup within 10 minutes"

One implementation detail of this usecase would be that there is a cron job that backs-up the data every 10 minutes.

Answer 4

When writing "batch" use cases I have always found they read better if the define the "Scheduler" as an actor. In your case the "Scheduler" is "cron" but in the great tradition of use cases "Scheduler" is generic and free of implementation details. Also in your case create an Actor "The Other System" or whatever to represent the ftp server. So:-

1. Scheduler - requests Sales report generation.
2. System - requests Widet Sales data from Widgets Server.
3. Wdiget server - sends files.
4. System - generates Widget Sales reports.
5. System - sends reports to Widgets server
6. Use case ends.

Remember use cases are about the interaction of the proposed system with anyone or anything else. Interactions within the "System" should never appear in use cases.

Answer 5

2- In case a cron job is invoked how to determine the business value if the customer
has no interaction what so ever with the system?

Get to the why. Why are you doing this cron-job? Is someone else downloading these reports by hand every day and sorting them out in excell?

Then you can describe your value for the business as: "saves 2 hours of work every day which translates in savings of about $10k/year."

(edit)

(i.e. The team who requested that module only cares about the reports not anything else).

The requesting team should prove the business value, not you. You can give an estimate of what the costs of the technical implementation are going to be. Then the guy in charge can make a decision whether or not to go through with it.

Answer 6

Here's a 'real' use case I'm probably going to implement

I have a Google Spreadsheet that I track equipment repairs on. It contains various information (ex serial number, repair request number, etc). This report is just for internal tracking purposes but at the beginning of each month a snapshot of the current state needs to be taken and consolidated into a report.

The system is setup to cover two purposes. First, to repair/replace all gear that is damaged or non-functional. Second, to maintain detailed records of what broke, and how long it took to fix it so the cumulative data can be taken into perspective when the next generation of gear is specified.

The bad part about this setup is, the reports are generated manually which requires a lot of copying/pasting and the potential for human error.

To solve the problem, the algorithm is simple. Loop through the items in the listing and copy them into the proper section (based on type) excluding all that contain a return date (the date it was given back and closed out).

To implement this, Google Apps Scripting now is capable of running scheduled jobs. The code would run once a month, generate the report document, and email a link for the document to the FSR for final inspection before being forwarded up the chain.

This would save an estimated 4 hours of work/month for 4 FSRs. Altogether that makes 192 hr/yr in 'real' savings. The greatest benefit is, the computer generated reports scale much better than human interaction does.

I assumed 4 FSRs but the increase in throughput may open opportunities to pick up more work in the future. To give another member the same capability is as easy as copying the status template.