Requirements Explained (Define, Lifecycle, States)

Requirements are formal and are usually preceded in the process by documents that capture the thoughts and ideas behind the requirements. These thoughts and ideas form the basis for the existence or need of a feature. Such documents are sometimes referred to as user stories or idea documents.

The Requirements feature allows you to create rich text documents (for capturing ideas, stories, motivations and other reference material) and manage them in one place with the formal requirements. The Requirements feature is accessible through the Requirements tab.

Requirements and the text documents can be organized in a hierarchical manner, like the file/folder system on a computer.

Requirement Lifecycle & States

A requirement (more specifically a requirement version) needs to be finalized before it is considered ready for fulfillment and validation. Finalization typically involves having one or more reviewers review the requirement specification for accuracy and completeness. Reviewers are typically those who have a stake in the correct release of the feature that the requirement specifies.

A requirement version owner usually completes the specification and then sends it for review to the reviewers. Reviewers can then choose to accept the specification for finalization or can request changes. If changes are requested, the owner of the requirement version can retract it back for editing to make the requested changes and then send it for review again.

Only when all reviewers have given their acceptance in the review process can the owner then mark it as FINAL. Once the requirement version if marked as FINAL, it can no longer be edited. But a new version can be derived.

A requirement version owner can choose to self-approve it instead of sending it for review. That is a policy decision of the project team. Self-approving a requirement version also results in the version being marked as FINAL.

Requirement lifecycle when reviewers are involved

Requirement lifecycle when NO reviewers are involved (Self Approval)

Thus, a requirement can evolve using versioning. When a requirement is created, its first version is created. To derive a new version of this requirement, the previous one must first be finalized after a review or self-approval.

Requirement lifecycle states when reviewers are involved (Self Approval)

Requirement lifecycle states when NO reviewers are involved (Self Approval)