ArsDigita Archives
 
 
   
 
spacer

SDM Application Requirements

by Dennis Gregorovic

I. Introduction

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 feature requests.

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 for.
  • Collaboration
    • 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.

  • Developer

    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.

  • Administrator

    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

V. Related Links

VI.A. Requirements: Data Model

1 Data Model

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 Package Releases

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 Modules

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 Tickets

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 User Interest

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.

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

NONE

VI.D. Requirements: User Interface

4 User Interface

4.1 Package 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.2 Release Information

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.3 Ticket Entry

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 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.5 Help

4.5.1 There should be a help page.
4.6 User Information

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 When? By Whom?
0.1 Creation 02-Oct-2000 Dennis Gregorovic
dennis@arsdigita.com
spacer