Quality attributes: Difference between revisions
m (Quality attribute specification moved to Quality attributes: Made the name more sensical) |
No edit summary |
||
(4 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. | ||
== | ==QA1: Localization== | ||
'''Priority: High''' | |||
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. | |||
==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== | ||
'''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 | |||
* |
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