How to deal with requirements and use cases in this kind of situation?

Question

Recently I've started to work with object oriented analysis and design and it seemed very interesting to me as a way to get work done better. But I'm still in doubt with one kind of situation. If this is not the correct site to ask about it, sorry for that.

Well, if I have to design a system that allows one user to register customers, sell products and so on, we have someone that will operate the system, in the sense that actor is kind of obvious for some of the use cases - the actor we will consider on the use case "Register New Customer" is simply the responsible for that action in the company of the customer that is purchasing the software.

Now, there are sometimes that this doesn't happen. I'll give an example: I've developed once a system to manage templates for websites in PHP. In that time, I didn't develop it within an object oriented context, but I was thinking on bring this system into object orientation to practice object oriented analysis and design. The point is that the system is very simple: "it takes some configurations written in a xml file, takes a URL and maps it to a file".

The point is that there's no interaction between the users of the websites and the system. The only thing that happens is that the user requests a URL and the system selects one html file that matches this URL in some way, and embed this html into a template specified in the xml. In cases like that, the only functional requirements I can think of are:

• The system must allow the user to specify the folders of templates into an xml file;
• The system must get the information of directories from the xml file;
• The system must load one specific file corresponding to the requested url inside one template file;
• The system must allow the replacement of placeholders into the template by values specified on code;

The problem is: for instance, although I thought of them as functional requirements, all of them has to do directly with how the code must be made. Only the third one really fits what I understood of functional requirement. Also the use cases are a little complicated, every action is took by the system itself. The only use case could be "Request Page" with actor being "Site Visitor" and this would imply that the scenario would be just "The user inputs the url into the browser window and the system loads the page."

So, in cases like that, when we are dealing with code will simply be reused into some other code (this is an example, it's just a bunch of code that a developer can use to load pages independent of a template), how should we deal with requirement analysis, use cases and so on?

As I've said, the PHP system I wrote is just an example, I'm really asking in general. Could someone give some hints or reference (some article, tutorial, something like that), that shows how to deal with this?

Thanks very much in advance!

Answer 1

Actors need not be people!

Any system, device, or, external program can be an actor as long as it is recognizably a separate entity which either uses or is used by the system you are developing.

Technical actors usually fall into the "used by" category, as things like "Authentication Server", "Payment Processor" etc.

In you case though would seem to revolve around only two uses cases. "Requesting System receives rendered output" and perhaps "Administrator defines template"

Answer 2

Use cases like Register New Customer belong to the business- or domain view and describe interactions between end-users and the system.

The purpose of use cases is to allow communication between the software developer and non-technical end users, stakeholders, managers.

Use cases describe what has to be done but not how is it implemented.

Your sentences The system must ... describe how is it implemented which are important implementation details. In my opinion implementation details do not belong to use cases. End users are usually not interested in folders, xml, file, placeholder. In your system, end users want to register new customers and sell something to them.