SDM Application Requirements
This document describes the requirements for the Software Development Manager
(SDM) application. The SDM application helps to manage the release cycles of
software applications, especially with respect to tracking bug reports and
II. Vision Statement
Software development can be quite a difficult task, but organization,
collaboration, and feedback can help to produce a quality product. Through a
software-centric data model and features such as bug reporting and feature
requests, SDM help to make this task easier.
III. System/Application Overview
- Create Packages
- Create Modules within Packages
- Create Tickets - either Bug Reports or Feature Requests
- Associate tickets with a package and, optionally, a module
- Assign a ticket to a user
- Assign an expected release for completion for each ticket
- Assign a severity to each ticket
- Change the status of a ticket
- Create Releases
- Mark releases as live
- Upload a tarball for each release
- Automatically see which tickets were fixed for a given release
- Email Notification
- Choose to receive notice of changes to a particular ticket
- Choose to receive notice of changes to a package
- Automatically receive notice of changes to tickets you are responsible
- Rate the importance of tickets
- Comment on tickets
- My SDM - See all tickets, packages, and modules that you are responsible
for one page
IV. Use-Cases and User Scenarios
- End User
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
V. Related Links
VI.A. Requirements: Data Model
1 Data Model
1.2 Package Releases
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
1.5 User Interest
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
VI.B. Requirements: Administrator Interface
2 Administrator Interface
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.
VI.C. Requirements: API
VI.D. Requirements: User Interface
4 User Interface
4.1 Package Information
4.2 Release Information
4.1.1 Users should be able to see a list of packages that they can
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.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.
VII. Revision History
|Document Revision #
||Action Taken, Notes