The OFL Project Requirements Management Procedures and Policies
elicitation
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..)
http://requirements.obradovic.com/SRS 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
miscellany
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