- Copyright date in all License Agreement documents (EULAs) reflect the year of the last "significant" work on either the software or the document itself. Mere bug fixes are not considered "significant" and do not require updating the copyright year.
- Any non-compiled code or documentation must be copyrighted. This includes anything that is semi-human-readable and part of the distribution (scripts, XML files, examples, etc.).
- Section 508 compliance (accessability testing). For any software that might be sold to any government agency.
- I18N testing. Even for software that is not going to be localized, it will be run on non-English Operating Systems and so it still must be able to handle double-byte characters and different code pages.
- Export compliance. For any software which will be available in any way to users outside of the country, the software needs to undergo applicable Export Compliance process for that country. At a minimum this will require a statement explaining what kind and strength of cryptography is required by or used inside of a product.
- Branding. Correct corporate icons, look-and-feel and other eye-candy. Company or product icons need to appear in installers and in the Add/Remove programs window... Company name (with Trademark symbol) needs to be on everything related to the product.
- Security testing and vulnerability assessments. The value of a software company's reputation is often greater than the sum of it's physical assets. Protecting goodwill and reducing possibilities of lawsuits make security testing essential in this age.
- Copy protection and licensing testing. The company software needs to have a reasonable amount of protection from piracy.
- Uninstallability. Anything that can be installed must be able to be completely uninstalled. See the reasons for goodwill and legal protection in the "Security testing" item, above.
- Usability. See the "Bill of User Rights" blog posting for details and see above for reasons.
- Standard versioning conventions. The way that products are versioned should be consistant throughout the company and should roughly follow the standards of the industry.
- Standard naming conventions. For example, on Windows, There must be an entry in Add/Remove Programs, the company name should appear with the product name.
- Software should adhere to good software industry standards. For example: on Windows, logging for services should be done through the Windows Event Log.
- Delivery. Standard corporate packaging and delivery should be adhered to. If other products for Linux are compressed using .tgz format, do not arbitrarily use a tar.bz2 format.
When creating new software or evaluating the quality of software, there are certain requirements of the company that the software needs to adhered to. I've started to put together a list of these "Corporate Requirements". I hope for this to be a living document; I encourage readers to add other items that they see that belong on this list.