You can send out a packet with whatever IP address you like.
Then, one of the routers along the way might decide the packet makes no sense (it is a "martian packet") and discard it. Consider this:
| 192.168.16.1 | 192.168.33.1
+---- GW1 -----+ ---- GW3 ----
You send out a packet with a source address of 10.0.0.36 and directed to, say, 172.16.16.172. GW1, serving your network which is 192.168.16.0/24, only expected to receive packets matching 192.168.16.0/24, and your packet doesn't match, so it is dropped. You could spoof a connection coming from your "neighbour" Alice, but no more.
Even if GW1 did not complain, it would forward the packet to the next hop, which serves the whole 192.168.0.0/16 branch and also would ignore your packet.
And so on and so forth (the IP I used are actually not all that routable, but it's an example).
Granted, many routers won't do "ingress filtering" because they'll be obsolete or will believe it unnecessary and not cost-effective. But it only takes one hop to wreck the transmission.
Even without this hurdle, the difficulties are not over, because let's say you succeed in delivering to your target a packet coming from 10.0.0.36. The target will reply -- and will reply to 10.0.0.36, so the reply packet will never get back to you. Indeed, should the reply packet arrive to 10.0.0.36, the latter would simply reset the connection as unsolicited.
This is a problem, because most protocols where you "only need to issue a request" are in fact sent over TCP, which requires a handshake between the communicating parties before any data can be sent. The major exception is HTTP/2,
And without that first reply packet you have precious little chance (not the same as zero chances, but still) of establishing a full TCP connection, without which you probably won't be able to send your request.
You might be able to do this using UDP, or other protocols which have no handshake, if the target application uses UDP (it probably doesn't).