We've all seen countless examples of software that ships with "minimum system requirements" like the following:

  • Windows XP/Vista/7
  • 1GB RAM
  • 200 MB Storage

How are these generally determined? Obviously sometimes there are specific constraints (if the program takes 200 MB on disk then that is a hard requirement). Aside from those situations, many times for things like RAM or processor it turns out that more/faster is better with no hard constraint. How are these determined? Do developers just make up numbers that seem reasonable? Does QA go through some rigorous process testing various requirements until they find the lowest settings with acceptable performance? My instinct says it should be the latter but is often the former in practice.

  • There's no definitive answer, but there is a question on Stack Overflow that might be relevant to your interests: stackoverflow.com/questions/398586/…
    – Thomas Owens
    Jun 24, 2011 at 21:38
  • Mostly they are meaningless these days as you don't know what other software will be doing on the system.
    – Ian
    Jun 24, 2011 at 21:51
  • 2
    I don't know what kind of software you design @Ian, but my software will always get the full, undivided attention of my users...they also read and memorize the user manual :-P Jun 24, 2011 at 21:57
  • 1
    I really appreciate that this question has 16 votes and the answers go 8, 4, 2... Jan 23, 2018 at 15:09

5 Answers 5


Frequently, the minimum requirements are set by looking at the types of systems that target market customers would actually use for the product in question and picking some reasonable cutoff that doesn't alienate the target customer and is something the QA department can test with a minimal additional hassle.

If you expect that most of your customers are going to install your product on relatively recent desktop computers, for example, you would probably look around and see that just about any low end desktop computer for the home is going to ship with 2 GB of RAM. So a recent computer is very likely to have at least 1 GB of RAM even if it's a couple years old. If very few of your customers are going to want to use a machine that only has 512 MB of RAM, the revenue of these sales is likely to be more than offset by the support requests (older machines are likely to have lots of other problems and incompatibilities that will cause problems and generate more help desk calls than other customers). So it may well be more profitable to avoid making sales to those customers.

This is roughly the same calculus that goes into figuring out what web browsers and screen resolutions you want to support. Even if the site may work fine on IE 6 in 640x800, if 99% of your users are using more recent web browsers and have larger screen resolutions, you're probably better off specifying that you support IE 7 and above and not trying to maintain an old IE 6 box/ VM for regression testing than you are in catering to the 1% of your target market that is using really old browser versions.



Typically a software company will release a beta version of their product (a few months to a few weeks before production release, depending on the size and complexity of the product). These beta versions might have metrics built-in to monitor and report to a server the performance of the application relative to the system specs. That, or they will simply rely on these beta testers to report back faithfully with their system specs and perceived performance.

Given a large enough sample set of data, it isn't hard to extrapolate an average system requirement.


There are several factors that are usually considered.

Some are hard requirements: I have a dependency that requires 1GB RAM, I use functionality that is incompatable with IE 6, etc.

Some are my expectations of the market vs testing effort: if I don't think many customers will use XP then I can require at least Vista and not have to test on XP (saving a lot of testing time and effort), if I expect customers to have high-end computers I can require a faster processor (saving my testers a lot of time too), etc.

"Minimum System Requirements" are really a statement of the minimum system that is officially supported. You can try to run the software on a lesser system and you might be successful, but if it doesn't work well don't complain to use because we warned you.


Some requirements can be determined based on the libraries you've included, for example the Win32 API CreateFile function states that it requires Windows 2000 Professional as the minimum supported client. Whether it does or doesn't, you'd be running a real risk to say you have a min. requirement of Windows 98.

Minimum memory requirements are, I think, tricky, because of dynamic allocation and recursion. You can estimate a stack size (recursive function calls could be a problem here) and you can estimate your heap size based on how you think your program will be executed. At the end of the day I think it's probably a ballpark.

Processor requirements, that aren't based on instruction set use or special features found on the chipset, are generally estimates I think, especially since I know I've run a lot of games on a P4 that called for a minimum of a Core 2 Duo ... I was grateful it ran, so I didn't complain about any performance issues :-)

I agree with the comments about browsers, resolutions, etc... it becomes "what you want to support" as opposed to a technical requirement. Similarly to my processor comment above, it may work, and if it does, great! If it doesn't ... well it's below the minimums and not supported ;)

Hope it helps.


Don't forget the input of the sales and marketing departments. If you know that most of the computers in business X that you're trying to sell to are of a given spec, that can also make a marketing "request" of engineering :) You might ask how sales knows the type of computers a client has. Simply take a discrete look at the Dell/HP/whatever model number on a machine during a sales call- most companies have service contracts so they're not mucking around in the innards of their PCs (what you see is what you get).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.