Quality attributes: Difference between revisions

From Thunderforce
Jump to navigation Jump to search
No edit summary
No edit summary
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
Quality attributes and their drivers appear on this page. These are also known as "non-functional requirements" in some circles.
Quality attributes and their drivers appear on this page in order of decreasing priority. These are also known as "non-functional requirements" in some circles.


==Portability==
==QA1: Localization==
*Should Thunderforce support Thunderbird 1.5 and 2.0 or just 2.0?
'''Priority: High'''
*If possible, Thunderforce should use only 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


==Security==
Both Thunderbird and Salesforce.com support localization. Thunderforce will leverage [http://wiki.mozilla.org/L10n Thunderbird's build-in localization capabilities] and Salesforce.com's labels to make Thunderforce available in many languages.
*Should authentication information be stored in the Thunderbird configuration if the user requests, or only when a master password is being used to encrypt the Thunderbird password database?


==Usability==
The following languages presently have translators. Please [mailto:thunderforce@moonlightdesign.org let me know] if you want to help out with localization.
*en-US: United States English
*vi: Vietnamese
 
Thunderforce will use the entity and field labels from Salesforce.com, enabling automatic use of language preferences and entity names from Salesforce.com within Thunderforce.
 
==QA2: Portability==
'''Priority: High'''
 
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 [[Features|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.
 
==QA3: Usability==
'''Priority: High'''
 
*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
*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
*User interface screens should be vetted by the community and, if possible, usability experts to get feedback on ease-of-use


==Performance==
==QA4: Security==
*Any specific performance attributes? These may include performance characteristics against very large organizations (VLOs)
'''Priority: Medium'''
 
*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
 
==QA5: Performance==
'''Priority: Medium'''
 
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
 
==QA6: Maintainability==
'''Priority: Medium'''
 
*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
 
==QA7: Extensibility==
'''Priority: Medium'''
 
*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
 
==QA8: Availability==
'''Priority: Low'''


==Any others?==
*Thunderforce will use Thunderbird's offline mode and its SQLite database files to permit offline use of Salesforce.com within Thunderbird
*Please feel free to add more :-)!

Latest revision as of 13:56, 9 May 2007

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

QA1: Localization

Priority: High

Both Thunderbird and Salesforce.com support localization. Thunderforce will leverage Thunderbird's build-in localization capabilities and Salesforce.com's labels to make Thunderforce available in many languages.

The following languages presently have translators. Please let me know if you want to help out with localization.

  • en-US: United States English
  • vi: Vietnamese

Thunderforce will use the entity and field labels from Salesforce.com, enabling automatic use of language preferences and entity names from Salesforce.com within Thunderforce.

QA2: Portability

Priority: High

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.

QA3: Usability

Priority: High

  • 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

QA4: Security

Priority: Medium

  • 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

QA5: Performance

Priority: Medium

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

QA6: Maintainability

Priority: Medium

  • 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

QA7: Extensibility

Priority: Medium

  • 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

QA8: Availability

Priority: Low

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