First off, not all requirements are hard requirements, but rather the minimum supported hardware. If someone has less than the minimum, it may run – but not optimally, or it may not run at all. In either case, its not a supported system and the problems you have are your own.

The simplest way to get hardware requirements is guess. The developer looks at their machine and says “Yep, it runs on mine, that’s the requirements.”

In a more rigorous environment, the development company has a suite of test systems. It may not be in house (non in house apple developers occasionally use the Apple Compatibility Lab). As part of the testing process, one tests on all the hardware available and determines the minimum requirements for it to run.

Another factor in hardware requirements is the base requirements for the operating system. In theory, Windows 7 requires a minimum of 1GB of ram to run. So testing against a 512 MB system running Windows 7 is nonsensical.

Test the system running with 1 GB of ram. Does it work? Nope… upgrade the ram. Repeat the test and upgrades until the application works in a supportable way and list those as the minimum requirements.

When performance becomes part of the promise of the software the ‘supportable’ includes that in addition to actually running, that the operation meets the minimum performance expectation.

Hardware requirements fall into a couple of different buckets. Often you’ll include requirements from a few of these buckets when determining specific hardware requirements for any software system you build.

Technical Constraints in the Architecture

These are the kinds of requirements that absolutely must be satisfied by the built system and are specifically designed into the system from the start. For example, “x86 processor is required.”

An easy example that comes to mind is Microsoft Office for Mac. Originally Macs used Power PC CPUs while Microsoft Windows was strictly targeted at “IBM Compatible” machines (mostly using x86 processors). Because Windows and thus Office only worked on x86, a completely new set of code (with different technical constraints) was written to support Office on Power PC for Mac OS. Once Mac moved to Intel x86 processors, the old Power PC optimized Office for Mac no longer worked — and technical constraints once again changed for a new version of Office for Mac on Intel. Applications optimized for 32 vs. 64 bit is another easy example.

Implicit Hardware Requirements

Sometimes you don’t actively choose to constrain yourself, but other decisions you make implicitly force requirements on to you. A common scenario is building on top of any kind of framework.

As an example, if you are building a .Net 4.0 application, .Net 4.0 has hardware requirements vetted through Microsoft’s hardware labs. Now your application requires at least the same hardware requirements that the .Net 4.0 framework requires.

Contextual Hardware Requirements

Most of the time when you’re talking about hardware requirements what you are really talking about is how you support specific quality attribute scenarios. Things like performance, reliability, availability, and other -ilities.

This is something I deal with often in making hardware recommendations for customers building applications on top of IBM InfoSphere Data Explorer (basically a Big Data search engine platform). Data Explorer’s basic requirements are minimal (you can run it on a laptop), but hardware recommendations for any specific Big Data application (read: requirements) comes down to specific quality attribute scenarios for that application. How quickly should data be indexed? How many queries per second should be processed? How much down time is acceptable?

Identifying specific quality attribute scenarios draws a line in the sand and lets me make a recommendation for minimum hardware requirements based on those scenarios — X number of CPUs with Y amount of RAM, Z Gigabytes of hard drives, N redundant systems. In our case, we have basic formulas (determined through extensive testing in our hardware labs) that use assumptions from the quality attribute scenarios to help determine a starting point for a hardware recommendation. This recommendation becomes the requirement for that specific Big Data application.

In this example, for any production system, a laptop really won’t do even though it technically meets the “minimum” requirements. The context of that implementation — the specific scenarios and data, whether it’s running in production or not, and so on, dictate the hardware requirements.

If the assumptions in the scenarios change, then so will the hardware requirements. So the phrase, “Y GB RAM is required to run the software properly,” really means “Y GB of RAM is needed to crawl X million documents in Z hours or a rate of ABC docs/min.”

Minimum Supported Hardware Requirements

That is, the hardware specifications expected to work correctly and that your Support group is prepared to help troubleshoot. Generally this is the set of hardware to which you have direct access, either your development machine or through a testing lab of some kind.

One example of this is pretty much any Android app that has been released. As an Android developer you test your app through some software simulators, probably on at least a few physical devices. But there are 1000s of different devices running Android, many of which with little… quirks …that could cause your app to run into problems. In most cases, you’ll still offer support if a user runs into problems. And in most cases users won’t run into problems even though you didn’t specifically test on that hardware variation. Microsoft has this problem too with Windows — how many different video card, motherboard, cpu, memory combinations are out there?

Basically, identifying minimum supported hardware is like saying “this software works on my machine, I expect that it will work on machines similar to mine, lots of folks have used this software on lots of different machines without problems, your mileage may vary, and if you have a problem I’ll do my best to help/fix but I can make no guarantees.”

For some applications the requirements may actually be hard requirements, such as when the developer has analyzed or profiled their app and knows exactly how many megaflops, MIPS, polygons per second, array working set sizes, etc. are required to meet some specified performance benchmark.

For small developers, cost may be the issue. They only have one system available, and so they declare that system’s specs as the minimum, as they haven’t been able to test the app on anything else (slower, smaller, etc.) and have little clue on how the app would do with less resources.