Quality attributes

Quality attributes and their drivers appear on this page. These are also known as "non-functional requirements" in some circles.

Portability

Thunderforce will use primarily JavaScript code for maximum portability between the platforms that Thunderbird supports

• If needed, Java code can be used, but that may decrease the portability to only those platforms that support Java
• C++ should not be used unless if deemed as absolutely necessary. Using native code greatly increases the cost of portability and maintaining releases

To support the present feature set while promoting these quality attributes, Thunderforce will require at least Thunderbird 2.0. Earlier Thunderbird versions lack some of the core pieces of functionality that Thunderforce uses.

Security

• The user's authentication credentials can be saved in Thunderbird, though it will require the use of a master password to encrypt Thunderbird's database
  • Typically, Thunderbird lets the user decide if a master password should be used or not. Thunderforce will require it when Salesforce.com authentication credentials are stored in the Thunderbird password database

Usability

• To the maximum extent that makes sense, existing Thunderbird interfaces and objects should be reused to present Salesforce.com objects in Thunderbird. To the user, it should "feel" as if Thunderbird is a "first-class" Salesforce.com client. That is, users should not perceive Thunderforce to be a separate program from Thunderbird; they will operate as one, and Thunderforce will "get out of the way" as much as possible
• Should Salesforce authentication information be stored in the Thunderbird configuration? That can increase ease of use at the expense of security, though it should be possible to cache this information when a master password is being used to encrypt the database
• User interface screens should be vetted by the community and, if possible, usability experts to get feedback on ease-of-use

Performance

The following performance characteristics also factor in very large organizations (VLOs).

• Cache Salesforce.com data locally using Thunderforce 2.0's built-in SQLite database system to reduce API usage and network traffic
  • In addition to caching in a disk-based file, an in-memory cache is maintained to reduce disk seeks

Availability

• Thunderforce will use Thunderbird's offline mode and its SQLite database files to permit offline use of Salesforce.com within Thunderbird

Maintainability

• Thunderforce will be broken into distinct modules that communicate with other modules through interfaces. Architectural cleanliness will be promoted as much as possible
• The model-view-controller (MVC) pattern will be used both conceptually and in the module architecture. A high-level MVC view of Thunderforce can be summarized with the following:
  • View: XML User Interface Language (XUL) presentation
  • Controller: Manages state transitions bidirectionally between the view and the model
  • Model: Salesforce.com and, above that, the local cache

Extensibility

• Customer and third-party extension of Thunderforce will be promoted in the architecture through the use of public interfaces between modules and overridable module implementations. This can permit interesting integrations with custom entities, among other things

Any others?

• Please feel free to add more :-)!