SugarExchange Certification Checklist

Version: 0.2

The SugarExchange Certification process includes a comprehensive checklist of requirements at the presentation, system and network level. The areas covered during certification testing include platform component and configuration requirements, authentication and identity management, data access and API controls, Patch, update mechanisms, error and exception handling, and operating and licensing procedures

Non-Functional requirements

SugarExchange certification listing requirements

Checkpoint
Priority: 1 Product may not use name 'Sugar' in the product name
Purpose: Product may not use the string 'Sugar' in the product name, but provider can use name such as 'X for Sugar'.
Priority: 1 Sugar Trademarks must be followed
Purpose: Sugar trademarks must be followed. See Sugar Trademarks for more information.
Priority: 1 SugarExchange Terms and Conditions must be followed
Purpose: SugarExchange terms and conditions must be followed. See SugarExchange Terms and Conditions for more information.
Priority: 1 SugarExchange Listing Requirements must be followed
Purpose: SugarExchange standard listing requirements must be followed. See listing requirements for more information.
Priority: 1 An executed SugarExchange Listing Agreement must be in place
Purpose: SugarExchange Listing Agreement must be executed. Contact SugarExchange sales representative at SugarExchange@sugarcrm.com to obtain a contract.

Generic Product requirements

Checkpoint
Priority: 1 Generic Requirements
Purpose: All certified SugarExchange products must come with the following attributes defined in the SugarForge project definition:
Priority: 1 Screenshots
Purpose: When submitting/publishing, the provider must provide at least one screenshot - the 'main' screenshot that appears adjacent to the listing in SugarExchange.
Priority: 1 Detailed description of solution
Purpose: When submitting/publishing, the provider must provide a detailed description of the solution.
Priority: 1 Categories
Purpose: When submitting/publishing, the provider must specify at a minimum the following categories: Application; Provider; Sugar Edition; Sugar Versions; and Development Status.
Priority: 1 Sugar Editions
Purpose: The product must provide equal support for the Sugar Community, Sugar Professional and Sugar Enterprise editions.
Priority: 1 Development Status
Purpose: When submitting/publishing, the provider must specify, and the product must attain, a Development Status of '5 - Production/Stable' or '6 - Mature'.
Priority: 1 API Requirements
Purpose: Standalone products interfacing with the Sugar database must do so using the Sugar SOAP API.
Priority: 1 PHP Requirements
Purpose: PHP implementations must take into consideration the following guidelines: Supported Platforms.
Priority: 1 Windows Requirements
Purpose: Windows implementations may be written as DLLs and/or EXEs. Products must support Windows XP or later, and should support Windows 2000. These implementations must adhere, to the extent possible, to 'Designed for Windows XP' application specification, available here.

Product submission and out-of-box requirements

Checkpoint
Priority: 1 SugarForge definitions
Purpose: Product must be created in SugarForge (as a project) before submitting to certification. Product must have had some deployment in the field and prove to a be stable version before it is submitted for certification.
Priority: 1 Submission contents
Priority: 1 'About File'
Purpose: Application must contain an 'About' file or dialog which includes a brief description of the company and product.
Priority: 2 'Settings file'
Purpose: If the application requires a settings (configuration) file, this must be provided with installation or auto-generated on first run.
Priority: 1 System Icons
Purpose: Icons that refer to Sugar-related functionality in application must be approved in advance.
Priority: 1 Application Icons

Purpose: Product shall use application Icons provided by the provider.

Output: Icons should:

1. Represent the application - relate to the application thematically;

2. Be unique;

3. Have relevant tool tip information about the function they represent.
Priority: 1 Submission language
Purpose: When submitting, the provider must list the languages supported by the Product. Product must support all languages that provider listed during submission process.
Priority: 1 Clear Payment Terms
Purpose: If there is a cost associated with this service, it should be clearly described.
Priority: 1 Internationalization
Purpose: In order for a Product to be eligible for certification, it must be localized to the languages used in all target markets. If the Product is targeted for a global market, at least the top 5 Sugar languages must be supported. See Overview of Translating Sugar for details.
Priority: 1 Database support
Purpose: In order for a Product to be eligible for certification, it must support the MySQL database. See supported platforms for requirements.
Priority: 1 Documentation
Purpose: End-User documentation for any product should be unambiguous and explicitly document SETUP AND ALL OPERATIONS of the product. Documentation should be readily available, preferably via the SugarExchange Download link. User should not at any point have to guess how to do something; or perform some supported operation.
Priority: 1 Version and build number for ALL product components
Purpose: Every software component has a unique version and build number that can be referred to during testing.

Attractiveness requirements

Checkpoint
Priority: 2 Looks
Purpose: Subjective measure. Does the product generally look nice in the OS desktop environment? Product should use high-quality graphics and icons that include 32-bit color and transparency
Priority: 3 Standard Sugar user-interface
Purpose: For embedded Products integrated using the Module Loader, use standard Sugar user-interface elements such as controls, menus, and windows and do not introduce tailored menus or controls to replace them. Use Sugar icons where applicable.

General Usefulness requirements

Checkpoint
Priority: 1 Integration with Sugar
Purpose: The Product must utilize the functionality provided by Sugar software without adversely affecting the operation thereof.
Priority: 1 Trial period
Purpose: All the products shall have a free trial period of at least 1 use and optimally 30 days.
Priority: 1 First use
Purpose: The first use of product must be free to the user. Product should not pop-up an up sell message to the user during the first usage. Products integrated using Module Loader must never produce pop-up messages or any other form of advertisement.
Priority: 1 Support
Purpose: Product must provide clear information to the users about how to contact the provider if support is required. Customer support requests must be responded to within a reasonable time.
Priority: 1 Help and documentation information
Purpose: User should be able to get the help and documentation for the topics in less than three user steps from the product's main application screen. The help pages and documents should be user friendly and easy to understand.

Functional requirements

Application Installation requirements

Checkpoint
Priority: 1 straight forward installation
Purpose: Installation process must be automatic: from accessing installation media only 'Yes' or 'Next' or 'Back' buttons are pressed. User does not have to backtrack or consult multiple sources of information. The installation process should be interactive and user friendly.
Priority: 1 seamless installation
Purpose: Installation is seamless regardless of what is being installed. If, for example, the Product requires another module, the second module must also be installed without interrupting the installation process.
Priority: 1 Product Setup time
Purpose: Product can be set up in a reasonable time. No product requires >10 minutes without consulting documentation. Ideally any product can be set up in < 5 minutes without consulting documentation.
Priority: 2 Release notes requirement
Purpose: All changes in the product are explained in documentation if it is a later version.
Priority: 1 No undesirable changes
Purpose: Subjective measure.
The product setup does not make any undesirable changes to the system. For example:
Setup does not change default tab or subpanel arrangement;
Setup does not install software or make configuration changes that affect application performance.
Priority: 3 Product installation onto alternate drives
Purpose: Standalone Product/drivers must be installable to alternate drives e.g. 'D:\Program Files'. As well as default 'C:\Program files.' Application must detect system files installed on other drives. There should not be any dependency on the drives for installation.
Priority: 1 Product upgrade prompts notification
Purpose: If installation of the Product requires an upgrade of the same Product, then user is notified about it during installation.
Priority: 2 Product upgrade is automatic
Purpose: Product is upgraded automatically when new versions become available. End-user must be prompted before accepting the upgrade.
Priority: 2 No restart necessary
Purpose: User should not need to restart system after installing the product.

Product information requirements

Checkpoint
Priority: 1 Product Publisher should be clearly identified
Purpose: Product publisher should be clearly identified, e.g. in Product Publisher screen.
Priority: 1 Product Privacy implications should be clear
Purpose: Product privacy implications should be clear, e.g. in information screen.
Priority: 1 Product rights to use, distribute, deploy should be clearly identified
Purpose: Product rights to use, distribute, redeploy should be clearly identified, e.g. in information screen. The product's end user license agreement must be easily accessible to the end user.

Product requirements

Checkpoint
Priority: 2 Product launches within reasonable time
Purpose: Any product launches within a reasonable time of invoking the product. Any delays in product startup are shown with a progress indicator.
Priority: 1 Product exit gracefully
Purpose: User must be able to exit/close gracefully from the product at any point.
Priority: 3 Product controls useful and non-redundant
Purpose: Product lists, checkboxes and menu items must instigate a valid action or actions.
Priority: 1 Product handles situations where Sugar instance not installed
Purpose: Product gracefully handles situation where Sugar instance is not installed. Product should error out or prompt the user to install the Sugar instance.
Priority: 1 Product handles situation where Sugar instance is not running
Purpose: Product gracefully handles situation where Sugar instance is not running. Product should start the Sugar instance and/or prompt the user to do so.
Priority: 2 Product menu and selection items clear and understandable
Purpose: All Product menu and selection items must be clearly understandable. All the menu and selection items should be easily understood by the user.
Priority: 3 Product graphics maximize display use
Purpose: Product graphics must be designed to maximize display use.
Priority: 1 Product screen content readable
Purpose: All Product screens content is readable to the naked eye.
Priority: 2 Product graphics scaled accordingly
Purpose: Product graphics should be scaled appropriately to the target display size.
Priority: 1 GUI Text is not truncated
Purpose: Product GUI text is not truncated.
Priority: 2 No inappropriate text in GUI
Purpose: Product must not contain obscene, profane, or irrelevant graphics or text. Basic shapes and pictograms that are easy to understand can be used.
Priority: 1 No advertisements in GUI
Purpose: Product must not contain any other parties' advertisements, but the following may be used:
  • up sell messages allowed,
  • no irrelevant banners or unrelated material)
  • one click away, up sell only;
  • two clicks allowed relevant targeted discrete;
  • three or more advertising is more open.
Priority: 1 Error messages understandable
Purpose: Product error messages are clearly understandable and should be descriptive enough.
Priority: 2 No unnecessary screen repaint
Purpose: Product does not cause any unnecessary screen repaint.
Priority: 3 Notification messages displayed once
Purpose: Product notification messages are not displayed more than once.
Priority: 3 Non-active icons are grayed out
Purpose: Non-active icons are grayed out.
Priority: 1 Product should support multiple Windows user profiles
Purpose: Standalone Product should support multiple Windows user profiles: Privacy should be protected.
Priority: 1 licensing policies
Purpose: Product must specify license. NOTE: Licenses listed in submission/publishing tool are provided. Also, free trial should be available to users before they are required to pay. Costs should be fair and reasonable.
Priority: 1 Free bundled products
Purpose: Bundled Products must be free. They can have an advanced, paid version, but the bundled version must be free.
Priority: 1 Product Payment support
Purpose: Product must support payment through the SugarExchange ecommerce framework and PayPal.

Product Functionality/Compatibility requirements

High-Level Functionality

Checkpoint
Priority: 1 Product passes precursory pass of its functionality

Purpose: Product passes a high-level, cursory pass of its basic functionality.

Env. Needs: Same as basic needs for this section, plus user manual available.

Input: Using the user manual and pre-filled certification checklist submitted by the Provider as input, verify that a selection of documented operations/use-cases work as written.

Output: Operations work as intended. Operations invoke no errors native to the device or application.
Priority: 1 Product works with Sugar instance intuitively
Purpose: Product does supported operations with Sugar instance in an obvious, intuitive way, e.g. can move between Sugar tabs, select contacts, etc. This is according to what operations the Product supports.

Connection Management requirements

Checkpoint
Priority: 1 Product should identify itself correctly to Sugar instance
Purpose: When Product tries to access Sugar's API, it should identify itself truthfully. Purpose of API access should be clear.
Priority: 1 Product should correctly determine which API protocol to use
Purpose: When Product tries to access Sugar's API, it should determine the correct API protocol to use.

Reliability requirements

Error- and resource-usage requirements

Checkpoint
Priority: 1 Product does not render Sugar unusable
Purpose: Product does not disable or render Sugar functions unusable.
Priority: 1 Product does not create errors when without API access
Purpose: Product does not create errors when denied access to Sugar API.
Priority: 1 Product does not create errors when restarted on the fly
Purpose: Product does not create errors when restarted on the fly.
Priority: 1 Product does not connect to Sugar without permission
Purpose: Product does not connect to Sugar API without permission.
Priority: 1 Product does not cause memory leak
Purpose: Product does not constantly over consume system memory, i.e. memory usage does not stay, for example, 200 MB.
Priority: 1 Product does not freeze itself or Sugar
Purpose: Product does not freeze it or Sugar instance for longer than 1 minute (should be proper status message if it does).
Priority: 2 Product gives visible feedback on transition state
Purpose: Product gives visible feedback that it is not frozen.
Priority: 2 Product functions without errors on all supported Sugar versions
Purpose: Product functions without errors on all supported Sugar versions.
Priority: 1 Product graceful when no network services
Purpose: Product performs gracefully when network services are not available.

Security requirements

Checkpoint
Priority: 1 Product Credentials - no credential abuse
Purpose: If the product, its developer or distributor collects/accesses Sugar user credentials, Sugar security department must be immediately informed secure@sugarcrm.com.

Sugar On-Demand Requirements

Module Loader Requirements

Checkpoint
Priority: 1 Acceptable Use for Sugar On-Demand
Purpose: If the product is added to Sugar via Module Loader, the product must conform to the Module Loader Restrictions for Sugar On-Demand.