Unique Requirement IDs

[crd]

How have others managed providing Unique Requirements IDs across projects?

Looking to implement - many projects in one database.  I have never liked the auto-numbering within EA - would appreciate thoughts on this one?

[jfzouain]

Don't use the Auto-number for requiremnt and create your numbering based on the project.

[Geert Bellekens]

Each requirement already has a unique ID.
If you look at the properties window (View|Element Properties) you'll find the field GUID which is a (globally) unique id for the requirement element.

Geert

[qwerty]

The drawback is that GUIDs are not very good to remember. Usually you want an id in the form AAAA-NNNNN (A = alpha, N = numeric) or the like which can be used in reports to easily identify requirements by humans. So either you have some extra tool (external like DOORS or an MDG like RaQuest) or you have an own addin which provides a unique ID in the format you like (this is a bit tricky, though).

q.

[Stefan Bolleininger]

it is not as difficult, as it might sound. every time, a new requirement is created, suppress the elements dialog and get the current numbering from the autonumber and replace the alphanumeric part.

than call up the element properties dialog again :-)

or, if your initial requirement-cration is not very diofficult and has not many features you may create your own dialog for it.

makes the creation much more handy for it.

greetings

Stefan

[crd]

Yes, GUID is the unique identifier, but not real user friendly when producing reports or for reference purposes during facilitated sessions.  

Thanks for confirming.  Since EA has so much functionality - I wanted to make sure I wasn't missing something.

I will have to dust off my API code skills.  

[Doug Blake]

I dont use auto numbering at all. As small packages get completed, I turn them into FEATURES, which along with level numbering, allows me to fix requirements numbering as I want it. Its not perfect, because EA level numbering stops at the first Package up the tree, hence the conversion to feature.

By the time the Requirements are complete, they reside as the leaves of a tree whose other nodes are all features.

I never delete a requirement, marking its status as obsolete or deleted, so as not to upset the numbering. New requirements are always added to the end of a feature sub tree.

The output document is generated using EaDocX which maintains the numbering perfectly.

[Robert Sheridan]

I like to have requirements numbered as then they are uniquely identfied even if you change the name to make it clearer.  I actually prefer the EA autonumbering as I dislike structured numbering and relying on analysts to correctly create a unique number manually results in duplicates.

On one programme we decided that we wanted to use structured requirement numbering to show the project that the requirement was gathered under and acheived that by doing the requirement gathering in a seperate project file using the autonumbering with a suitable prefix and suffix and imported the finalised requirements into the master repository.