Question: I have experience testing from a business perspective but I'm currently working in an system which is a small part of a bigger system, so I don't have a clear vision of the entire business value flow.

From a black box perspective its just a service with one input and one output:

Input: a cronjob starts the service and it will query a DB for specific cases where it should send an email;

Output: the system sends a reminder email and write in the DB that the email was sent.

The developers write unitary tests, integration tests and system test. Its pretty well covered by tests from a white box perspective.

From a black box perspective, which kind of test can I put in place?

Answer: 
I would start with what you have, the inputs and outputs, then start questioning. I like to go through a bunch of what if's, such as in your case "what if the database is unavailable?" or "what if the mail queue is full?" or something like that. If you can't come up with questions like that, then ask the developers "what didn't you test that you think I should?".

Often I am testing a small portion of a larger system in isolation, or just changes to only a specific smaller piece of something larger. Then you need to check the overall flows for the bigger pieces to the smaller, and the other way around. Definitely start with the requirements, and there are always requirements somewhere, and then start looking at what you have and think outside the box, so to speak, to whatever else there is that might fail or be an input or output that may or may not fail, or be other than what was expected.

I find it helps to know the whole system, but its often not necessary, as in many cases it depends on what it is you are trying to accomplish.
As a system of systems, black box really doesn't have a meaning (except what it means to you in your context). Let's take your last statement at face value, that the developers have unit, integration, and system testing well covered. I assume your question can be rephrased as "Give me some ideas for contributing to the team!" :)

Ok, here goes:

* I assume the last DB write has a time stamp. Play with changing the time bases of the systems. Try cases of nearly the same (e.g. time zones), wildly in the past, wildly in the future, leap years, etc.
* Play with connectivity. Get from the DB, then make the DB connection unavailable when the confirmation attempt is made. Try glitching it for a few seconds, a few minutes, a few hours. Does the output queue if the DB is unavailable? If so, does it lock up the service? Can you overrun the queue? Likewise, try making the mail server unavailable for a few seconds, a fews minutes, etc.
* Next, play with network noise. Get a network simulator and inject some random error bits in the initial DB read, the email send, and the DB confirmation. Keep increasing the lag, bit error rate, etc. until you get a failure. Was the failure unexpected? Did it corrupt any of the messages without the system detecting the corruption?
* Try invalid messages. Put all kinds of random characters in the DB fields, mail address, mail body, mail subject, etc. Can you make the system crash using invalid characters in the fields?

Those are just a few suggestions based on your general specs. Good hunting!