Can I change my public IP address to a specific one?

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.1.1.1
                                 +------------------- GW4
                                 | 192.168.1.1
             +----------------- GW2------+
             | 192.168.16.1              | 192.168.33.1
      +---- GW1 -----+             ---- GW3 ----
      |              |
192.168.16.15   192.168.16.243
     YOU           ALICE

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).

Probably not, depending upon whether or not your ISP is implementing Ingress Filtering:

a technique used to ensure that incoming packets are actually from the networks from which they claim to originate.

If your ISP is implementing Ingress Filtering, then your forged packets will be dropped as they traverse your ISP's network, and will never reach your target.

The odds are that your ISP does implement it:

As of 2012, one report suggests that, contrary to general opinion about the lack of BCP 38 deployment, some 80% of the Internet (by various measures) were already applying anti-spoofing packet filtering in their networks.

Even in the absence of ingress filtering as described in the other answers, IP spoofing will hit another hurdle: the TCP 3-way handshake, and possibly higher-level handshakes.

TCP is the basis for many of the most common protocols, including HTTP, FTP, SMTP, POP3, IMAP and their TLS-secured counterparts, as well as SSH, and many many more.

When you attempt a TCP connection, you send a first packet (SYN). Server replies with SYN-ACK. Client sends ACK. During the SYN and SYN-ACK exchange, random sequence numbers are chosen and transmitted.

If you use a spoofed IP address, the server will send the SYN-ACK to the device which actually has that IP, not you. So you won't receive the server's sequence number, and no communication will be possible.

There used to be issues a few eons ago when the sequence numbers were predictable. That allowed you to send packets blindly on the TCP connection (you would not receive any answer, but you could still send requests). This should now be fixed everywhere (see RFC1948).

If somehow you still manage to do so, most protocols now use TLS on top of TCP, which adds yet another handshake which will very definitively prevent you from sending anything if you don't receive the return traffic.

The story is different for UDP and raw IP protocols, but those have more limited use.