Deriving Features from Stakeholder Needs

Features are derived from stakeholder requests. It is important to keep track of which feature

was derived from which request.◦ so when the stakeholder requests are stored in

RequisitePro, they could be traced to the features implementing them.

Requests gathered from stakeholders do not necessarily have the attributes of a good requirement.

Deriving features from stakeholder requests gives you a good opportunity to fix that.

Introduction

One approach is to go through all STRQ requirements and apply appropriate transformation to create one or more FEAT requirements.

The following transformations may be applied.

Introduction

Copy: If no changes are required, STRQ can be copied to FEAT exactly as is.◦ It is okay to have different types of requirements

with the same text. However, avoid requirements of the same type having the same text. In this case, requirements are redundant.

Example:◦ STRQ: “The user shall be able to purchase a ticket

online, without the necessity of calling the travel agent.”

◦ Nothing is wrong here, so we can copy the requirement.

Copy

Split: If the requirement is not atomic, we can split it into two or more requirements.

Example:◦ STRQ: “The system shall provide the opportunity

to book the flight, purchase a ticket, reserve a hotel room, reserve a car, and provide information about attractions.”

◦ This requirement is a combination of five atomic requirements, which makes traceability very difficult.

Split

Clarification: Clarification, or explanation, may be applied when the original requirement is unclear or ambiguous.

Example:◦ STRQ: “The capability to cancel a ticket purchase

should be available.”

◦ Clarification is needed as to who shall be able to cancel ticket purchases (user, customer service representative, or administrator).

Clarification

Qualification: We achieve qualification by adding restrictions or conditions to the requirement. It may help to resolve contradictory requirements.

Qualification

Combination: Redundant or overlapping requirements may be combined into one.

Combination

If the requirement is not abstract, and it includes some unnecessary details, we may apply generalization.

Generalization

Cancellation: Sometimes the requirement needs to be deleted. This may happen when the requirement is infeasible, unnecessary, or inconsistent with another requirement.

Cancellation

Completion: If the set of requirements is incomplete, we may need to add requirements at this stage.

Completion

Correction: Correction may mean either rewording the requirement to fix grammar, spelling, or punctuation, or changing a portion of the requirement that is untrue.

Correction

Unification: Requirements that use inconsistent vocabulary can be unified.

Unification

Adding details: If the requirement is not precise enough, we may add details. This technique is often used to make testable requirements from untestable ones.

Adding details