An end user of a software product like ACS would use SDM to report bugs, request features, and check for information about the latest release. The user might check SDM to see which tickets that he opened have been fixed and whether thoses fixes are included in a specific release. The user also might find tickets that he is interested in following and choose to receive email notification when these tickets are modified.
A developer would use SDM to keep track of which bugs need to be fixed and which features need to be implemented. The developer might want to get a list of open tickets in a particular module, or all tickets that are assigned to him. SDM will be able to do this for him. The developer could also use SDM to record internal bug findings and feature requests in order to maintain a more accurate journal of the software's development.
An software project administrator would use SDM to keep track of the project's status and development. This includes tasks such as assigning tickets and managing the number of open ticket. the administrator would also use SDM to publish current releases and announce future release of the software
1.1 Packages
1.1.1 Each package must have a name.
1.1.2 Each package can either be active or inactive.
1.1.3 Each package can either be private or public.
1.1.4 Each package may have a description.
1.1.5 Each package may have one or more admins.
1.2.1 Each release must be specific to exactly one package.
1.2.2 Each release must have a version name that follows the guideline from the APM documentation.
1.2.3 Each release may have an anticipated release date.
1.2.4 Each release may have an actual release date.
1.2.5 Each release must have exactly one manager.
1.2.6 Each release may have a description.
1.2.7 Each release may have release notes.
1.2.8 Each release may have text field describing supported platforms.
1.2.9 Each package may have zero or one release which is marked as current.
1.3.1 Each module must belong to exactly one package.
1.3.2 Each module must have a name.
1.3.3 Each module must have exactly one owner.
1.3.4 Each module may have a description.
1.3.5 Each module may be active or inactive.
1.3.6 Each module may be public or private.
1.3.7 Each module may have a list of users, who can then use it if it is private.
1.4.1 Each ticket must have a type - either bug, feature, or task.
1.4.2 Each ticket must be associated with exactly one package.
1.4.3 Each ticket may be associated with a module.
1.4.4 Each ticket must have a status.
1.4.5 Each ticket must have a severity.
1.4.6 Each ticket may have an expected release for completion.
1.4.7 Each ticket may have an actual release for completion.
1.4.8 Each ticket must have a summary.
1.4.9 Each ticket may have a description.
1.4.10 Each ticket may assigned to any number of users.
1.4.11 Each ticket may be rated by each user at most one time.
1.5.1 Each user can specify any number of packages and/or tickets that he is interested in.
1.5.2 Each user can select the frequency of email notifications that he prefers.
2.1.1 Administrators should be able to create and edit packages.
2.1.2 Administrators should be able to create and edit modules.
2.1.3 Administrators should be able to create and edit releases.
2.1.4 Administrators should be able to edit ticket information.
2.1.5 Administrators should be able to delete tickets.
2.1.6 Administrators should be able to remove ticket assignments.
2.1.7 Administrators should be able to switch tickets between module.
4.1 Package Information
4.2 Release Information
4.1.1 Users should be able to see a list of packages that they can view.
4.1.2 Users should be able to see a list of the modules in a package that they can view.
4.1.3 Users should be able to see a list of all outstanding tickets in a package.
4.1.4 Users should be able to see a list of all resolved tickets in a package.
4.1.5 Users should be able to see a list of all releases of a package.
4.1.6 There should be a UI for the user to indicate interest in a package.
4.3 Ticket Entry
4.2.1 Release information must include the release manager.
4.2.2 Release information must include the release date applicable.
4.2.3 Release information should display the anticipated release date, supported platforms, and release notes.
4.2.4 Release information should include a list of implemented features.
4.2.5 Release information should include a list of fixed bugs.
4.2.6 Release information should include a list of known bugs.
4.2.7 If the release has an associated file, the user should be able to download it.
4.4 Ticket Information
4.3.1 If the ticket is a bug, the user should be able to select the release where the bug was found.
4.3.2 The user should be able to select the module (if there is one) that the ticket specifically applies to.
4.3.3 The UI should provide a default severity, but the user should be able to change it.
4.3.4 The user must be able to enter in a summary of the ticket.
4.3.5 The user should be able to enter in a description of the ticket.
4.3.6 There should be a page after ticket entry that allows the user to confirm the ticket information.
4.5 Help
4.4.1 There should be a UI for the user to rate a ticket.
4.4.2 There should be a UI for the user to indicate interest in a ticket.
4.4.3 There should be a page that displays ticket information such as module, ticket creator, creation date, ticket type, severity, status, expected completion, actual completion, releases affected, and users assigned.
4.4.4 There should be a page that displays the history of a ticket.
4.4.5 There should be a UI for assigning users to a ticket.
4.4.6 There should be a UI for allowing users to comment on a ticket.
4.6 User Information
4.5.1 There should be a help page.
4.6.1 There should be a UI for displaying all packages that a user manages.
4.6.2 There should be a UI for displaying all releases that a user manages.
4.6.3 There should be a UI for displaying all tickets opened by a user.
4.6.4 There should be a UI for displaying all tickets assigned to a user.
4.6.5 There should be a preferences page where each user can set their preferences for SDM-specific features such as email notfication.
| Document Revision # | Action Taken, Notes | When? | By Whom? |
|---|---|---|---|
| 0.1 | Creation | 02-Oct-2000 | Dennis Gregorovic |