Project Artifact Report Tracking System (PARTS)
Requirements Description (Version 1.0)

This document provides some details about the requirements for the proposed PARTS software application. (An high-level overview description of PARTS is found in the Concept Description.) This document has been written by our marketing department after interviews with the potential users of PARTS. It is not a complete requirements definition document nor a software requirements specification.

Words defined in the Glossary are put in italics font (at least the first time they are mentioned).


Overview:

The Project Artifact Report Tracking System (PARTS) is for use by software development teams to help them track problem reports for a wide variety of artifacts or work-products created during software development. The system records information about projects, team-members, artifacts and problem reports, storing this in some kind of repository. Certain users are given the manager role, which gives them certain priviliges such as assigning a problem report to a team-member. The system reports on stored information according to a variety of criteria. The system will support a log-in procedure based on a PARTS-specific user-id and password.


A. Users:

  1. When a user starts the PARTS client, they are presented with a login screen. This allows existing users to enter their user-id and password.
  2. A super-user id exists, and this user is allowed to create all other types of user, along with projects. This id's password is specified when the PARTS server starts.
  3. For each user, we store the user-id, full-name and password. Ids and passwords are PARTS specific, and do not have to have any relationship with other user-ids or passwords on the computer network.
  4. Certain users have the role of Manager. Each Project has at least one manager, and project/manager pairs are created by the super-user.
  5. Managers can create new users. Managers can assign a user to their projects, making them team-members for that project. A project's manager may give other team-members manager privilege. Managers can give users who are not team-members of their projects read-only privilige allowing them to view all information related to a project but not update that information. Managers can change any priviliges that they can set, and they can also remove a team-member from their projects.

B. Problem Reports:

  1. Problem Reports (PRs) are assigned a ID number (unique within projects) by the system. When they are created, a user must enter a short one-line description and a longer detailed description. The system stores the date the PR is created and the user creating the report with the PR.
  2. PRs are created about an artifiact. Each PR belongs to only one artifact, but every artifact can have more than one PR. Artifacts may have more than one version, and thus each PR also records which verstion of the artifact it references.
  3. Any project manager may assign a PR to a team-member, indicating that the assigned team-member will be expected to take care of the problem. A manager can change this assignment at any time.
  4. Each PR has a status value indicating its current status. The status is initially Unassigned when the PR is created. It is then Open after the Manager assigns the PR to a team-member. The team-member assigned to the PR can change the status to Resolved after resolving the problem that is recorded in the PR. The project manager may set the status to Abandoned to indicate that the problem will not be addressed.
  5. Each PR has a history log associated with it. Entries are made to the log either automatically by the system or by a team-member who is updating a PR. Automatic entries are made when the PR is created, when the manager changes the assignment of the PR to a team-member, or when any status change is made to the PR. Manual changes can be entered by any team-member, and these include a textual description to allow the member to say something about the problem. All entries are marked with a date-time stamp by the system.

C. Projects:

  1. Projects are created by the super-user, and they are given a short, unique identifying string when created. At creation the super-user assigns a project to a user, who then becomes a manager for that project. (This manager may give other team-members management privilige later on.)
  2. At any time the manager can edit a longer text description to provide more info about the project than the short id-string.
  3. When users log into the system, they choose which project they want to access by viewing a list of project id-strings.

D. Artifacts:

  1. Each artifact is associated with one project, and they are created by the project's manager. Upon creation the manager provides a short, unique id-string, and also a more detailed description of the artifact (which can be updated later).
  2. Artifacts have a status value, which is a string (whose value is unconstrained by PARTS). It can only be updated by a manager for the project. (It is assumed that this will be used for team-specific values like "completed", "reviewed", "planned", etc.)

E. User Operations and Services:

  1. Users log in.
  2. Users can change their password or full-name description.
  3. Any user can view the list of projects available in the system.
  4. Users can select which project they wish to work with (unless they have privilege "no access" for that project).
  5. A manager can create a new user for his or her project. The manager can make an existing user a member of the project.
  6. The manager can give any team-member the manager privilige (or remove it). The manager can give any non-team member "read-only" privilege for the project; by default all non-team-members have no access to the project.
  7. A manager can create a new artifact for a project, entering all information needed. A manager can update information associated with an artifact. A manager can update an artifact's information or delete the artifact.
  8. Any team member can create a problem report for a given artifact, supplying all initial information.
  9. Any team member can add an entry to a problem report's history log.
  10. The manager can assign any problem report in the project to a team-member (either initially or changing it from a previous assignment).
  11. The manager can delete a problem report or change its status.
  12. Any user who can view information about a project can make any query (described below) about the project information. Results of all queries can be printed.
  13. Users may get a list of artifacts for the projects, including their status.
  14. Users may get a list of all PRs for a given artifact in a project. Results will include information associated with the PR, except for the history log. From this report there will be a easy way to display the history log information for a PR that the user selects.
  15. Users may get a list of PRs as above, but limit the search to only those with a given status, or only to those assigned to a particular user, or only to those between certain dates.
  16. Users may get a list of PRs as above, but widen the search to all artifacts in a project.

F. General Requirements:

  1. The system will run in a client-server mode, allowing users to access the system from machines on a network by connecting to a central server that accesses the repository.
  2. PARTS is not responsible for backing up the repository on the server machine. Such operations will be carried out using operating system commands on the server machine.
  3. The PARTS server will be started manually by a user on the server machine, or automatically when the system boots.


Glossary and Definitions

Artifact
Something created by the software development team for which we wish to record problem reports. Also known as a work-product.
Manager
A user who has certain additional privileges for a given project.
Privilige
Each user has one of four privilege levels for each project: no-access, read-only, manager, update.
Project
A software development project that creates artifacts for which we wish to record problem reports.
Repository
A database or some kind of persistent data storage that records all information about all projects, users, artifacts, and problem reports.
Status
For problem reports, at any given time a PR has one of these status values: unassigned, open, resolved, or abandoned.
For an artifact, a string that can be modifed by a manager to reflect some status information for that artifact.
Team-member
A user of the system who is assigned to a given project.
Work-product
Another term for an artifact.