Requirements prioritization and project scope: Difference between revisions

From Thunderforce
Jump to navigation Jump to search
m (Moved the context diagram to the top)
 
(16 intermediate revisions by the same user not shown)
Line 1: Line 1:
The [[Requirements elicitation|requirements]] fed into the [[Features|feature list]], and the prioritization of those features will appear on this page.
The [[Requirements elicitation|requirements]] fed into the [[Features|feature list]], and the prioritization of those features will appear on this page.


==Feature Priorities==
==Context Diagram==
[[Image:Context Diagram.png]]
 
The context diagram above depicts the Thunderforce part of the system being built and the components that it interacts with. The user will interact with Mozilla Thunderbird, which will then invoke and receive instructions from Thunderforce. Thunderforce will use the SQLite database and Salesforce.com.
 
The user, of course, can also use Salesforce.com directly. This diagram depicts the two user access points to Salesforce.com that are relevant to Thunderforce. Due to this existence of two access points, Thunderforce will need to be mindful of changes performed directly in Salesforce.com, and Thunderforce will need to ensure that changes performed in Mozilla Thunderbird are propagated to Salesforce.com as soon as permissible.
 
==Requirements==
The [[Requirements|detailed requirements]] are listed on another page. The high-level requirements are listed below:
*[[Features#R1: Account Type|R1: Account Type]]
*[[Features#R2: Address Book|R2: Address Book]]
*[[Features#R3: Message Composition|R3: Message Composition]]
*[[Features#R4: Message Filters|R4: Message Filters]]
*[[Features#R5: Offline Mode|R5: Offline Mode]]
 
==Priorities==
Note that some features have dependencies upon each other. This is a general list, and the actual module priorities will likely include functionality from all modules as the top priorities. The initial focus will be on associating both incoming and outgoing email messages with Salesforce.com records, but the architecture will factor in the [[Features|present long-range set of features]].
Note that some features have dependencies upon each other. This is a general list, and the actual module priorities will likely include functionality from all modules as the top priorities. The initial focus will be on associating both incoming and outgoing email messages with Salesforce.com records, but the architecture will factor in the [[Features|present long-range set of features]].
#Address Book
*[[Features#R2: Address Book|R2: Address Book]]
#Message Filters
*[[Features#R4: Message Filters|R4: Message Filters]]
#Account Type
*[[Features#R1: Account Type|R1: Account Type]]
#Message Composition
*[[Features#R3: Message Composition|R3: Message Composition]]
#Offline Mode
*[[Features#R5: Offline Mode|R5: Offline Mode]]


==Task Priorities==
==Task Priorities==
Line 16: Line 31:
#Parallel work on the modules, focusing on those that address the account type feature
#Parallel work on the modules, focusing on those that address the account type feature
#First release
#First release
==Schedule==
The first release of Thunderforce is planned to occur around mid-August of this year. The details of the plan will work backwards from that release date.
The following table depicts the current schedule for Thunderforce. Note that week 18 is the week beginning on April 30, 2007. Items in the table cells indicate when those activities should be completed by, which can be by the end of the week indicated.
{| border="1"
! Week 18
! Week 19
! Week 20
! Week 21
! Week 22
! Week 23
! Week 24
! Week 25
|-
|width="12.5%" valign="top"|
*Project plan and scope
*Notional architecture
|width="12.5%" valign="top"|
*Identification of architectural risks
*Experiment planning
|width="12.5%" valign="top"|
|width="12.5%" valign="top"|
|width="12.5%" valign="top"|
*Experiment execution
*Architectural refinement
|width="12.5%" valign="top"|
*Module identification and assignment
|width="12.5%" valign="top"|
|width="12.5%" valign="top"|
*Initial integration tests
|}
<br>
{| border="1"
! Week 26
! Week 27
! Week 28
! Week 29
! Week 30
! Week 31
! Week 32
! Week 33
|-
|width="12.5%" valign="top"|
*Module plans
|width="12.5%" valign="top"|
|width="12.5%" valign="top"|
*Module unit tests
|width="12.5%" valign="top"|
|width="12.5%" valign="top"|
|width="12.5%" valign="top"|
*Modules developed
|width="12.5%" valign="top"|
*Integration tests run
|width="12.5%" valign="top"|
*Feature set for release stabilized
*Feature set for later release disabled
*Packaging
*First release
|}

Latest revision as of 06:02, 11 May 2007

The requirements fed into the feature list, and the prioritization of those features will appear on this page.

Context Diagram

Context Diagram.png

The context diagram above depicts the Thunderforce part of the system being built and the components that it interacts with. The user will interact with Mozilla Thunderbird, which will then invoke and receive instructions from Thunderforce. Thunderforce will use the SQLite database and Salesforce.com.

The user, of course, can also use Salesforce.com directly. This diagram depicts the two user access points to Salesforce.com that are relevant to Thunderforce. Due to this existence of two access points, Thunderforce will need to be mindful of changes performed directly in Salesforce.com, and Thunderforce will need to ensure that changes performed in Mozilla Thunderbird are propagated to Salesforce.com as soon as permissible.

Requirements

The detailed requirements are listed on another page. The high-level requirements are listed below:

Priorities

Note that some features have dependencies upon each other. This is a general list, and the actual module priorities will likely include functionality from all modules as the top priorities. The initial focus will be on associating both incoming and outgoing email messages with Salesforce.com records, but the architecture will factor in the present long-range set of features.

Task Priorities

  1. Notional architecture of the entire extension
  2. Identification of architectural risks
  3. Design and execution of experiments to reduce architectural risks
  4. Architectural refinement and modularization of the extension
  5. Parallel work on the modules, focusing on those that address the account type feature
  6. First release