Systemd: Requires vs wants
As heemayl noted in the comment, the man page answers your question. From the web:
Wants=
A weaker version of Requires=. Units listed in this option will be started if the configuring unit is. However, if the listed units fail to start or cannot be added to the transaction, this has no impact on the validity of the transaction as a whole. This is the recommended way to hook start-up of one unit to the start-up of another unit.
And
Requires=
Configures requirement dependencies on other units. If this unit gets activated, the units listed here will be activated as well. If one of the other units gets deactivated or its activation fails, this unit will be deactivated. This option may be specified more than once or multiple space-separated units may be specified in one option in which case requirement dependencies for all listed names will be created. Note that requirement dependencies do not influence the order in which services are started or stopped. This has to be configured independently with the After= or Before= options. If a unit foo.service requires a unit bar.service as configured with Requires= and no ordering is configured with After= or Before=, then both units will be started simultaneously and without any delay between them if foo.service is activated. Often, it is a better choice to use Wants= instead of Requires= in order to achieve a system that is more robust when dealing with failing services.
Note that this dependency type does not imply that the other unit always has to be in active state when this unit is running. Specifically: failing condition checks (such as ConditionPathExists=, ConditionPathExists=, … — see below) do not cause the start job of a unit with a Requires= dependency on it to fail. Also, some unit types may deactivate on their own (for example, a service process may decide to exit cleanly, or a device may be unplugged by the user), which is not propagated to units having a Requires= dependency. Use the BindsTo= dependency type together with After= to ensure that a unit may never be in active state without a specific other unit also in active state (see below).
From the freedesktop.org page
Your service will only start if the multi-user.target has been reached (I don't know what happens if you try to add it to that target?), and systemd will try to start the display-manager.service before your service.
If display-manager.service fails for whatever reason, your service will still be started (so if you really need the display-manager, use Requires=
for that).
If the multi-user.target is not reached however, your service will not be launched.
What is your service? Is it a kiosk system? Intuitively I'd suppose you want to add your service to the multi-user.target (so its launched at startup), and have it strictly depend on the display-manager.service via Requires=display-manager.service
. But that's just wild guessing now.