1 / 14

Deriving Features from Stakeholder Needs

This guide explores how to derive meaningful features from stakeholder requests, emphasizing the importance of traceability in requirements management tools like RequisitePro. It discusses various transformation techniques such as copy, split, clarification, qualification, combination, generalization, cancellation, completion, correction, unification, and adding details. Each technique aims to refine stakeholder requests into clear and effective feature requirements, ensuring they meet the attributes of good requirements and are effectively implemented in the development process.

karma
Download Presentation

Deriving Features from Stakeholder Needs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Deriving Features from Stakeholder Needs

  2. Introduction • 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.

  3. 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.

  4. Copy • 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.

  5. Split • 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.

  6. Clarification • 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).

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

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

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

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

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

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

  13. Unification • Unification: Requirements that use inconsistent vocabulary can be unified.

  14. Adding details • 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.

More Related