Requirements Naming and Numbering

Requirements are fundamental to the definition of a problem (or opportunity) and the solution must be traced back to this definition.

Requirement Names and Descriptions

There are many schemes that are used to name requirements and Enterprise Architect is flexible enough to support any scheme that is used. There are two locations you can add textual information to a Requirement: the element name, which has a limit of 255 characters, and the 'Notes' field, which is effectively unlimited. Some schemes specify that a single definition of the requirement is entered and no notes are needed. Other schemes prescribe a short name and specify that the requirement is clarified with detailed text. If notes are not used it is common practice to use some type of numbering system so the Requirement can be referred to unambiguously.

When Requirements appear in diagrams the name will by default be displayed but a modeler can choose to display any one of a number of the requirement's compartments including the notes. This technique creates expressive diagrams that reveal the details of the requirement and help the reader or reviewer to understand the Requirement more fully.

Sequential Numbering

Good practice often recommends that Requirements are given a sequential number when they are created so they can be referred to in stakeholder workshops, change requests, conversations with System Integrators or implementation teams. Using a name in this situation is often unwieldy and subject to error so a sequential number is preferred. Enterprise Architect has a facility called Auto Names and Counters for this purpose that can be used to assign a sequential number to any element type including Requirements. It includes a prefix definition, a counter and a suffix definition allowing numbers such as: 'REQ007 - Manage Inventory' to be created. These can be further refined to numbering systems such as this architectural requirement: 'ARR134 - Payloads for internal component interfaces must use an XML format'.

The counter is added to the name and is displayed in all views of the repository including the Project Browser, Relationship Matrix, search results and diagrams.

Numbered Hierarchies

When Requirements are written in word processors they typically use a numbering scheme called Outline Numbering, which assigns a number to the first level heading such as: '4 Inventory Requirements' and then a sub-heading is numbered by adding a period and a number such as '4.1 Stock Levels' and again down a another level '4.1.1 List Stock Levels'. Enterprise Architect has a facility called Level Numbering that applies hierarchical numbering to the elements in a Package. This is a useful mechanism that is displayed in a number of locations including the Project Browser, the Specification Manager, Diagram List and Package List. It must be remembered, however, that if the order or the level of the elements in the Package is altered they will be assigned new numbers based on their new position; this makes this mechanism unsuitable if immutable numbers are needed.

Numbered Packages

This is a hybrid method where Packages are used to create a high level naming and numbering structure and the Requirements in each Package are numbered using the Package identifier and a number to identify them. So Requirements for the Fulfillment of Orders could be contained in a Package named '2.4 Fulfill Orders' and an individual requirement in this Package could be named 'FO-01 Process Credit Card Payments'. This would be manually maintained or a Script could be written to ensure that the numbers were correctly assigned.

Globally Unique Identifier

Every element, diagram and connector in an Enterprise Architect repository is given an immutable and unique reference in the form of a Globally Unique Identifier (GUID). The GUID is assigned to the element when it is created and is guaranteed to be unique across time and space. Thus requirements can ultimately be referred to by this unique identifier. While the GUID is a powerful and irrefutable way of referring to a Requirement it is not practical to use it in discussion with stakeholders because of its length and the fact that it is not memorable. The GUID's purpose is to be able to track and manage a Requirements provenance particularly when Enterprise Architect is used to generate Requirements to other tools. It is also used as the identifier in the XMI exchange format.

Proprietary Numbering Systems

There might be projects or programs of work that will, for regulatory or commercial reasons, specify a proprietary numbering system that must be used with Requirements. For this reason one of Enterprise Architects in-built schemes might not suffice; in this situation the user can create their own numbering scheme using the Scripting facility in combination with Tagged Values.