Example Use Cases for PARTS

Here are two examples of how use cases can be used to document requirements for the PARTS system.

Use Case PR1: Create Problem Report for an Artifact.

  1. Description: This describes how a new problem report is created to record information about an artifact (or work-product) that is defined in a project.
  2. Actors: Member.
  3. Preconditions: The Member must be logged into the system.
  4. Flow of Events for Main Scenario:
    1. Member selects one Artifact using any method for doing so that the System supports.
    2. Member requests that a new Problem Report be created for this Artifact.
    3. The System creates a new Problem Report for that Artifact.
    4. The System stores the creation time and the Member's ID information in the new Problem Report. It also sets the status of the Problem Report to unassigned.
    5. The System allows the Member to update the Problem Report.
    6. The Member enters a description for the Problem Report.
    7. The Member saves and closes the Problem Report.
    8. The System stores the Problem Report data.
  5. Alternative Scenarios:
    1. Member Cancels Creation. Any time between Steps 2 and 7, the Member cancels the creation of the Problem Report. The system stores no new information for this artifact.
  6. Postconditions: not applicable
  7. Special conditions: not applicable

Use Case PR2: Assign Problem Report to Member

  1. Description: This describes how a new problem report is created to record information about an artifact (or work-product) that is defined in a project.
  2. Actors: Manager.
  3. Preconditions: The Manager must be logged into the System.
  4. Flow of Events for Main Scenario:
    1. Manager selects one Problem Report for an Artifact using any method for doing so that the System supports.
    2. Manager requests the assignment task be carried out by the System.
    3. The System displays all team Members for the current Project.
    4. Manager selects one Member and confirms that this Member be used.
    5. The System associates the Problem Report and the selected Member, storing that the Member is assigned this PR.
    6. The System sets the status of the Problem Report to open.
  5. Alternative Scenarios:
    1. Manager Cancels Assignment. Any time between Steps 2 and 4, the Manager cancels the operation.
    2. PR Already Assigned. If the Problem Report has already been assigned to a Member, after Step 2 the System warns the Manager of this, and asks for confirmation that the existing assignment should be changed.
  6. Postconditions: If the task completes, then the selected Problem Report will have status open, and a new "assigned" link or relation will be stored for the Problem Report and the selected Member.
  7. Special conditions: not applicable