The local issue managers (those responsible for setting up an issue-tracking repository) must be able to define the issues that will be tracked. Since yaktrack will be used by both inexperienced users and expert users, this should not be necessary (because an inexperienced user should be able to get up and running with minimal effort), but should be possible, because an expert user should be able to track different types of issues, and define the attributes tracked in each. YakTrack installs a basic template for defects (the primary issue type that is tracked), so that inexperienced users can get going immediately; experienced users should modify or extend the basic template to add different issue types (requirements or improvements, for example) and refine existing issue types.
The user checks out their own version of the tracking repository and edits the template files "by hand" in a text editor. The template files will be simple XML templates (DTDs). This "by-hand" method may be extended in the future by creating a sort of "wizard".
| A created repository |
| A DTD to modify, if modifying an existing issue type |
| No submitted issues using the given type, unless the changes will not affect existing issues. |
| A valid DTD, usable by YakTrack for indexing and filing |
| A valid repository |
High
Generally, once per repository. It is rare (and could cause some problems) if DTDs are changed after issues using those DTDs have been submitted.
Table 4-11. Normal Course of Actions
| Actor Actions | System Responses |
| Refresh the local copy of the repository via version control | (as per version control software) |
| Edit the existing DTD with a text editor | (as per text editor) |
| Verify that the DTD is usable by YakTrack (see use case DEFINE.IS-VALID-TEMPLATE.UC) and check that the repository is still valid by auditing the repository (see feature AUDIT). | (as per feature AUDIT) |
The user runs the command yaktrack is-valid-template [template-name]. The system checks to see if the template satisfies the conditions of the simple XML DTDs used by the system, and gives a report of the check. It does not check to see if the given DTD works with any existing issue reports.
| A created repository |
| A DTD to check in the templates directory |
| Feedback to the user on the status of a dtd |
High
Low. It will primarily be used in initial system development, but will be used with the DEFINE feature on a regular basis.
Table 4-12. Normal Course of Actions
| Actor Actions | System Responses |
| Invokes the tool | loads the DTD |
| Verifies the DTD follows simple DTD rules | |
| Presents feedback to the user |
The user runs the command yaktrack register-template [filename]. The system checks to see if the template satisfies the conditions of IS-VALID-TEMPLATE, and then stores it into the repository using the name of the first element in the DTD. It will not store a template if one of the given name already exists.
| A created repository |
| A file of the given filename containing the new DTD. |
| If the given DTD is valid, it is installed in the repository's templates directory |
| Either way, feedback is returned to the user on the status of the procedure |
High
Low. It will primarily be used in initial system development, but will be used with the DEFINE feature on a regular basis, and will be used when users are creating their own repositories and templates.
Table 4-13. Normal Course of Actions
| Actor Actions | System Responses |
| Invokes the tool | loads the DTD from disk |
| Verifies the DTD follows simple DTD rules | |
| Opens a repository from the current working directory | |
| If the DTD is valid, installs it in the repository | |
| Either way, presents feedback to the user on the status of the request |
DEFINE.IS-VALID-TEMPLATE.FR1. The system should be able to read an XML DTD from disk
DEFINE.IS-VALID-TEMPLATE.FR2. The system will have a tool named "is-valid-dtd" which will be used to verify that a given DTD file is valid for use with yaktrack.
DEFINE.IS-VALID-TEMPLATE.FR3. The system should identify the presence of multiplicity operators in the element list of a DTD
DEFINE.IS-VALID-TEMPLATE.FR4. The system should identify the presence of choice groups in the element list of a DTD
DEFINE.IS-VALID-TEMPLATE.FR5. The system should identify the presence of optional elements in the element list of a DTD
DEFINE.IS-VALID-TEMPLATE.FR6. The system should identify the presence of any attributes which are not CDATA or enumerated attributes
DEFINE.IS-VALID-TEMPLATE.FR6a. The system should mark a loaded DTD as invalid for any disqualifying element, and communicate this fact to the user.
DEFINE.IS-VALID-TEMPLATE.FR7. The system should identify the presence of any attributes which are not #REQUIRED or #IMPLIED
DEFINE.IS-VALID-TEMPLATE.FR8. The system should ensure that each root element has a "yaktrackid" attribute which is #IMPLIED
DEFINE.REGISTER-TEMPLATE.FR1. The system should implement a command named register-template for adding new templates to the repository.
DEFINE.REGISTER-TEMPLATE.FR2. The system should check to see if the new template is valid as per the requirements of the DEFINE.IS-VALID-TEMPLATE functional requirements
DEFINE.REGISTER-TEMPLATE.FR3. The system should, if the template is valid, register it in the repository under the name of its root element (the first element declared in the DTD)
DEFINE.REGISTER-TEMPLATE.FR4. The system should display feedback on the result of the register-template request