Draft Process

From IGSTK

Jump to: navigation, search

Agile Requirements Development Process (formal):

  1. Agile developer identifies the need for a new component or enhancement that is extensive enough to justify a requirement.
  2. The WIKI page should be separated into two sections. Open requirements and Iteration-directed requirements. Each section should be separated into the Requirements Taxonomy headers as shown in: http://public.kitware.com/IGSTKWIKI/images/2/2b/REQ-Taxonomy.pdf
  3. The developer should write the drafted requirement and place correctly (i.e. pertinent section) on the WIKI.
  4. The team will consider requirements both open and iteration-directed during weekly telecons.
  5. When a requirement is discussed and approved in a preliminary state, then the requirements lead will move the requirement the PHP Bug tracker
    1. The requirement should be classified (i.e. Severity Field) as either"Style Guideline", "Design Guideline", or "Functional Requirement"
    2. The requirement should be put in the assigned status ("New"/"Unconfirmed"/"Assigned")
    3. The number should be picked based on REQ XX.XX.XX format (e.g. REQ 06.02.10) (This is consistent with the taxonomy)
    4. The requirement number should be appended in bold to the requirement text in the WIKI
  6. If the requirement is tagged for an iteration, then the software code should be developed that corresponds to the requirement.
  7. Once the code is developed is should be moved to the Sandbox.
  8. As the code is tested and reviewed, this may require changes to the requirements
    1. Changes to the requirement text should be entered to the WIKI and discussed during the telecon.
    2. Once a change is agreed upon, again the Requirements Lead makes the correction to the bug tracker by adding a comment
    3. The changed requirement should be stated as NEW_REQ_TEXT: <New requirements text> (i.e. NEW_REQ_TEXT: The tracker component shall report the maximum refresh rate and time latency on demand.)
  9. Once the code is properly tested and ready for release, the requirement status is moved to "Verified" concurrently with iteration completion


Agile Requirements Development Process (fast-tracked):

  1. Agile developer identifies the need for a new component or enhancement that is extensive enough to justify a requirement.
  2. The WIKI page should be separated into two sections. Open requirements and Iteration-directed requirements. Each section should be separated into the Requirements Taxonomy headers as shown in: http://public.kitware.com/IGSTKWIKI/images/2/2b/REQ-Taxonomy.pdf
  3. The developer should write the drafted requirement and place correctly as an open requirement on the WIKI.
  4. The team will consider requirement as an open requirement at the next weekly telecons.
  5. When a requirement is discussed and approved in a preliminary state, then the requirements lead will move the requirement the PHP Bug tracker
    1. The requirement should be classified (i.e. Severity Field) as either"Style Guideline", "Design Guideline", or "Functional Requirement"
    2. The requirement should be put in the assigned status ("New"/"Unconfirmed"/"Assigned")
    3. The number should be picked based on REQ XX.XX.XX format (e.g. REQ 06.02.10) (This is consistent with the taxonomy)
    4. The requirement number should be appended in bold to the requirement text in the WIKI
  6. As an open requirement, the software code should be developed that corresponds to the requirement.
  7. Once the code is developed it should be moved to the Sandbox.
  8. Since fast-tracked software changes tend to be somewhat smaller in scope the code should be approved during a telecon
    1. Any changes to the requirement text should be entered to the WIKI as discussed during the telecon.
  9. Code should be moved to the main repository and requirements text updated in the bug tracker.


Comments from Telecon (1/5/2006):

  1. Consider requirements that are independent of the iterations -Andinet
  2. Need to understand that this process suggests that requirements should be discussed prior to development -KG

Comments from Telecon(1/19/2006):

Personal tools
TOOLBOX
LANGUAGES