Pre-emptive disclaimer: I'm not a lawyer, this is not legal advice.
In the US, before you can bring a lawsuit, there is something called "Rule 11" that must be overcome. Rule 11 sort of says that you need to have some evidence or reasonable belief to support your case before you can file a lawsuit. (This is a broad generalization and may not apply to all cases and all jurisdictions.) This is to prevent frivolous lawsuits .
In case of patent lawsuits, it often means that you may need to have proof that somebody is infringing, or a reasonable explanation of why you think, before you can file a lawsuit. In case of some products where implementation details are not openly available, this may seem like a Catch-22 situation, but rule 11 is a relatively low bar, and it may be possible to satisfy it without solid proof.
But the upshot is, typically a plaintiff may have to do infringement analysis before filing a lawsuit to, amongst other things, satisfy Rule 11. This applies to all kinds of patents, not only software. Often, instead of actual proof, the public comments of the alleged infringer (or an employee thereof) may provide sufficient basis. Once the lawsuit is in progress, however, there is a process called "discovery" which takes place, in which the attorneys of both sides demand access (which the other side is legally required to satisfy) to all material that may be relevant, including not only the source code / schematics / design docs / diagrams, but also emails, logs, internal memos, documentation, and all manner of communication related to the allegedly infringing product(s). As mentioned in the comments above, access to this may be restricted to protect trade secrets and the like.
However, what do you do before the lawsuit is filed and you need to do some sort of infringement analysis? Since you asked about software, let me talk about that.
Often, the code may be open source, for example, Linux or Android, which may make things somewhat easier. Even with access to the source, it is surprisingly difficult to show infringement. One example is "divided infringement", where two or more parties act together to perform all the steps in a claim. This is a very common occurrence in today's "cloud"-based world. (Or, in non-marketingspeak, a client/server setup where some of the steps are performed on the client and the rest on the server.) Until a recent case shook things up, this did not count as actual infringement. Alternatively, it is also difficult when when some steps are performed by the open-source software and the rest by a third-party, closed-source driver which is opaque to the casual observer.
Another problem is, even with access to source code, having to convince a lay jury that the technical mumbo-jumbo, that is called "source code", actually does what this other kind of technical mumbo-jumbo, that are called "patent claims" -- which look like English -- describes.
However, even without access to the source code itself, there are several possible ways to do infringement analysis:
Many patents cover aspects of the product that is readily observable, such as UI aspects or behavior of the software. Infringement can be shown simply by executing the software. (Apple's "slide-to-unlock" and "over-scroll bounce" patents that they used against Samsung are a good example of this.)
If the product is available as an executable, decompiling it and examining the assembly may be needed to show infringement. This means you literally have to reverse-engineer the software. This is, of course, quite difficult, and may be even more difficult to hold up in court. Even for languages like Java, which (if not obfuscated) decompile to code that is very much like the original source, it may be difficult to show infringement.
If the patent claims include network communication or protocols, it may be possible to show infringement by executing the software and running a packet sniffer to collect traces of packets being sent and received. Correlating those packets with changes in the behavior of the software may show infringement of the method. This is similarly difficult, and may be even more so if communications are encrypted. Sometimes, claims cover wireless communication methods, modulations or protocols, which means you need specialized (and expensive!) equipment, and the (even more expensive!) experts to operate them, to capture signals in order to detect infringement.
If the allegedly infringing software is hidden away on a server and provided as a service, you could try providing various inputs and observing the corresponding outputs, and try to show that this would only be possible if the service implemented the method of the claim. This, as you might guess, is also extremely difficult, and may in fact be impossible when the patented method covers such a narrow aspect of the service that the effects of the patented method in the outputs are negligible. However, a good example of this method, which is actually done on a daily basis, is "Search Engine Optimization", which is essentially reverse-engineering of Google's algorithm-du-jour to manipulate a given website's search ranking.
If you're lucky, somebody has already reverse-engineered the software in question, and has provided a write-up or, even better, an open-source alternative (or client, in the case of services) for you to examine. This is rare, but happens more frequently than you'd imagine. The open source world is rife with projects -- that somebody wrote to scratch their own itch -- which emulate, and are highly compatible with (and hence a very good approximation of), the original closed-source software.
There are many, many more types of software-based inventions, and as many ways to analyze the products for infringement. The list above is just to give you an idea of some possible methods. Contrary to what people may assume, it is actually very difficult to prove infringement of most patents.
However, if you think about this, it explains pretty well why there is a furor about "software" patents in the press these days. The patents that are easiest to prove infringement for happen to be patents that cover readily-observable aspects of software, such as those covering GUI elements (Apple's slide-to-unlock, over-scroll bounce-back) and high-level software behavior (Amazon's one-click), because they are easy to prove infringement of, and consequently, those are the patents that are asserted in patent disputes. There are undoubtedly much lower-level, technically in-depth patents that are being infringed, but which would be difficult to try in court in front of a lay jury, and hence are not asserted.
Think about it: would you rather try to prove infringement to a lay jury of Apple's over-scroll bounce-back patent  -- something you can demonstrate to them by simply using the allegedly infringing device in front of them -- or Samsung's patent about the length fields in packets , which could only be explained by providing an abstract technical explanation of wireless communication protocols, packets, networking and message fragmenting? Considering this, the outcome of the Apple v. Samsung dispute is hardly a surprise.
So of course, the patents that show up in tech media are the ones that are asserted, and it is no wonder that the patents being asserted are mostly high-level patents that can be easily shown to be infringing, which people decry as "obvious". Well, of course they are "obvious" (though not in the patent law sense), simply because they are easily observable and hence easy to show infringement for. However, that does not necessarily mean they are "obvious" in the patent-law sense, which has a very specific meaning that has nothing to do with how apparent it is or how apparently easy it is to implement. Similarly, these patents may also be "trivial" to implement, but triviality is (rightfully) not a requirement for patents: the RSA patent is pretty trivial to implement , but, by all accounts, was not obvious at the time.
- 4-line Python RSA program, http://www.cypherspace.org/rsa/python.html