Please note : This help page is for an older version of Enteprise Archtiect. The latest help can be found here.

Model Requirements

Requirements are fundamental to the success of any project, regardless of the process being used. Many organizations have traditionally stored and managed their requirements in text tools like spreadsheets and word processors; these requirements often remain hidden from the development process. Using Enterprise Architect’s model based approach to requirements engineering turns requirements into first class modeling elements. They can be displayed on diagrams and related to the stakeholders that own them, and traces can be created connecting them to other down-process model elements such as Use Cases and application Components.

Properties such as status, phase complexity and difficulty can be assigned to each requirement, which helps you to manage them easily.




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

Requirements Internal requirements

Requirements in the Model

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 'Advanced | Turn On Level Numbering' option to highlight the order and arrangement of the Requirements quickly and easily.

This 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 document.

Design Custom Document Templates Requirements Diagram Turn On Level Numbering

Use Cases

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.

Composite Element Use Case Diagram Example Traceability Diagram Use Case Create a Rule Flow Activity Connector Requirement Trace: Tracking Dependencies Activity Diagram State Machine Diagram Sequence Diagram Actor Communication Diagram