Model Requirements

Topics

Topic

Detail

See also

Represent Requirements

In Enterprise Architect, a requirement can be modeled as an:

•

External Requirement - an expectation of the system or process, what the system or process must provide, modeled as an element; for example, a business requirement or a stakeholder request - Requirements at this level have their own properties and are reported on separately in RTF reports

•

Internal requirement - a responsibility of an existing element, what the element must do or accomplish, defined as a property of the element

Requirements Management in Enterprise Architect is primarily concerned with external Requirement elements and the elements that implement or realize them.

Requirement elements can be grouped and organized within Requirements diagrams.

The Requirement elements are connected to each other by Aggregate relationships to form a hierarchy:

It is quite usual to develop a package of many hundreds of Requirement elements, arranged individually and in hierarchies of varying complexity. In the Project Browser you can use the Turn On Level Numbering option to highlight the order and arrangement of the Requirements quickly and easily.

The following illustration shows a number of Requirements in a package, where Level Numbering makes the order and arrangement clear:

If elements are added, moved or deleted from the package, the numbering automatically adjusts.

This numbering can also be applied in the RTF report generator using the LevelNumber field in the Element section - {Element.LevelNumber}.

Requirements are implemented (realized) by model elements such as Use Cases, Classes, Interfaces and Components. There are many ways to trace either the Requirement for the feature or service modeled by the elements, or the elements that develop the requirement, most visibly in Traceability diagrams that depict the Requirements and the model elements connected by Realize relationships. The Realize connector enables members of the project team to keep design objectives and development in tandem, and the development path and purpose clear.

The more usual realization relationship is between a Requirement and a Use Case. A Requirement can be realized by one or more Use Cases, and a Use Case can realize one or more Requirements.

Whilst a Requirement defines a condition that must be met, the Use Case is the key to defining and visualizing how that condition is met. A Use Case diagram depicts the logical grouping of actions, processes and components to achieve a required result, and through the use of Actor elements also defines the user and/or system roles participating in the process.

Each Use Case (as a composite element) can contain a combination of child diagrams that define in greater detail how a particular activity or facility might be implemented - such diagrams include Sequence, Communication, Activity, State Machine and Business Rule Flow diagrams. The actual implementation of each Use Case is realized by Class, Component and Interface elements organized in their own diagrams. These realizations can also be captured and viewed in Traceability diagrams, depicting the full development pathway from initial requirement through to testing and production.