The OFL Project Requirements Management Procedures and Policies


  • We shall first identify stakeholders. (Champion == Pete?, managers == Us?)
  • We shall find out how/where requirements additions and modifications. (Pete?, documentation?, websites?)
  • Where appropriate, we will request that we be notified directly of requirements changes. (eliminating polling lag)
  • That said, we shall also frequently poll for new requirements.

    tracking and versioning

  • We wish we had the luxury of professional requirements-management tools at our disposal (DOORS, RequisitePro, etc..)
  • will be our central repository of requirements. (blog)
  • Using "Edit This Page" functionality, any team member can add or modify entries via the web.
  • Using a weblog generally provides a high degree of availability
  • Using a weblog eliminates the problem of document synchronization
  • Using a weblog allows all project participants to modify the requirements, even if they are geographically separated.
  • Access will be controlled via username/password security
  • We shall manage requirements version control by announcing a policy of maintaining a single, monotonically increasing version baseline (ie. No need for version branching)
  • Historical versions will be archived via cvs.
  • We shall communicate requirements changes to all stakeholders (via an email distribution list?)
  • As each requirement is individually addressable (see Miscellany below), they shall be individually versioned

    identification standards

  • Each requirement shall have a unique identifier.
  • Bidirectional traceability is being considered.
  • Conflicting requirements shall be reconciled by engaging the champion (Pete) as an unbiased arbiter.

    metadata attributes

  • Each requirement shall have a status. One of: { Proposed, Approved, Implemented, Verified, Deleted, Rejected }
  • Each requirement shall have a stability, on a scale of 1 to 3, 1 being the most stable.
  • Each requirement shall have a date, origin, and author of creation
  • Each requirement shall have a date, origin, and author of modification
  • Each requirement shall have an implementation priority
  • Each requirement shall note any other requirements it is dependent on.

    roles and duties

  • The three of us comprise the OFL Change Control Board to analyze the impact of change
  • Zo shall focus on documentation
  • Alex shall focus on analysis
  • Les shall focus on elicitation
  • We shall each work on all parts at some point


  • We shall make an RSS Syndication feed available, to allow other sites to display our project requirements
  • Each requirement is individually addressable and editable
  • ... thus each can be remotely referenced (via RSS) in other documentation
  • ... thus versioning can be managed at a more granular level than simply: "the requirements document changed"

    UserLand Frontier Download