| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-xsQ27TDaTcUQ1VKUQG_HIQ" |
| name=",_T9FbYFRFEd2o7OqLaYh8nA" guid="-xsQ27TDaTcUQ1VKUQG_HIQ" changeDate="2008-08-19T07:20:27.924-0700" |
| version="7.5.0"> |
| <mainDescription><p>
 |
| Requirements&nbsp;realizations represent how one or more requirements are fulfilled in the design. This can take
 |
| various forms. It may include, for example, a textual description (a document), class diagrams of participating classes
 |
| and subsystems, and interaction diagrams (communication and sequence diagrams) that illustrate the flow of interactions
 |
| between class and subsystem instances.
 |
| </p>
 |
| <p>
 |
| In a model, requirements realization is typically represented as a UML collaboration that groups the diagrams and other
 |
| information (such as textual descriptions) that form part of the realization.&nbsp;&nbsp; If using use cases, the
 |
| collaboration may be further stereotyped as a use-case realization.
 |
| </p>
 |
| <p>
 |
| Note that there can be more than one realization of the same set of requirements.&nbsp; This is particularly important
 |
| for larger projects, or families of systems where the same requirements may be designed differently in different
 |
| products within the product family. Consider the case of a family of telephone switches which have many requirements in
 |
| common, but which design and implement them differently according to product positioning, performance and price.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
