Use Case to Relational Mapping Sample
March 2, 2010
| The following table describes shortly the single relations between the information entities (it’s worth to note that in principle each relationship is a many-to-many relationship): | |||
|
Source |
Destination |
Relationship |
Description |
| Features | Vision & Scope | Rational | A feature is traced back to a goal stated in Vision & Scope, i.e. a justification is that it is part of achieving a business requirement. |
| Use Cases | Vision & Scope | Rational | A Use Case is traced back to a goal stated in Vision & Scope, i.e. the existence of this specific Use Case is justified by a business requirement. This relationship is, informative“ because not every Use Case must have a business requirement as a rationale. |
| Use Cases | Features | Uses | In a Use Case step a feature is used by an actor (human role or other system) to achieve a user goal. |
| Requirements | Vision & Scope | A requirements justification is probably directly derived from a business requirement. This is especially true for global nonfunctional requirements. | |
| Requirements | Features | To a feature a set of detailed requirements must be derived to specify the feature, so that the feature justifies the requirements. | |
| Requirements | Use Cases | Detailed requirements might be better understood when a Use Case is given that justifies that requirement. This relationship is informative“ because not every requirement must be justified by a Use Case. | |
| Test Cases | Use Cases | Use Cases are used to elicit test cases, so test cases might be better understood by stating the Use Cases they are derived from. This relationship is, informative“ because not every test case must be derived from a Use Case. | |
| Test Cases | Requirements | Tests | Each requirement must be tested by at least one test case. |
| The goal of the relationships is to support the requirements engineering process, i.e. all activities directly or indirectly related to the specification of a (evolving) subsystem. But the relationships make it possible to firstly reason about the justification of existing requirements and secondly to reason about the impact of requirements. Both are crucial for coping with evolving systems. The relationships can be made visible in a requirements management tool through the definition of “views”, which show entities related through a relationship to another entity. These views thus support the workflow of the requirements engineering process. | |||