I use points for reviews and hold onto 1.0, 2.0 etc for the versions I am asking for approval on. Also add the date/time so if ttere are incremental versions you cna track them.

I also try to limit the number of people I ask for approvbal from - usually no more than three if I can help it.  Everyone else is a reviewer.

adrianpunt wrote Thanks Craig, What we do is requirements in progress are tagged with 0.x throughout the review process and the first official submission into the development queue becomes V1.0. Theorectically, V1.0 should be accepted by all stakeholders. Any changes from thereon are 1.x, and for major panelbeating we proceed to 2.x, 3.x etc. Thanks Adrian

Hi Adrian,

One thing that works well is to match the version of the document with the version number from your version control system (i.e. Source Safe, PVCS, etc.).  Also make sure you keep track of date of the most recent change.

However, when working with requirements, the version of the actual document is not as relevant as the status of each individual requirement.  It is nice to have a system which allows for a rich set of attributes for each requirement such as:

• Requirement ID (unique identifier) - does not change
• Short Description
• Long Description
• Last Edit Date
• Last Edited By
• Created On
• Created By
• Priority (high, medium, low, etc.)
• Status

In addition, I like to maintain additional attributes which allow me to categorize the requirement such as:

• Domain Area (filter by specific business domain)
• Key Stakeholder (the champion/sponsor of this requirement)
• Requirement Type (Functional, Security, Usability, etc.)

Best regards,

- Adrian M.