Author Topic: What really should go into the "name" field of requirement?  (Read 313 times)

mse

  • EA User
  • **
  • Posts: 106
  • Karma: +1/-0
    • View Profile
What really should go into the "name" field of requirement?
« on: August 14, 2019, 07:50:10 pm »
In a typical Requirement element in EA there is a Name and a Notes field. THe notes field is clearly the content of the requirement, however the name I have noticed is used in many ways in the literature. I have seen some use it for IDs like REQ001, REQ002, etc. Others have used names like "Update Order". What should go in there? I noticed if you use IDs, when you look at it in the browser, you have no idea what requirement is what, just a long list of random and unique IDs. I'm thinking of making an ID a tagged value instead. However, if I'm not mistaken, I think EA, if you set up a numbering scheme will automatically populate "name" with the numbering scheme everytime you create a requirement.


Geert Bellekens

  • EA Guru
  • *****
  • Posts: 9537
  • Karma: +274/-27
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: What really should go into the "name" field of requirement?
« Reply #1 on: August 14, 2019, 07:55:49 pm »
From a conceptual standpoint I would say that you want to put the name ("Update Order") in the name field, and the ID in another field (alias, tagged value)

However, there are pragmatical reasons to put both in the name field; mainly because then you can easily find RQ0236 by looking in the project browser.

I have a number of clients who chose for the combined system.
RQ0236 - Update Order


Geert

Sunshine

  • EA User
  • **
  • Posts: 867
  • Karma: +67/-5
  • Its the results that count
    • View Profile
Re: What really should go into the "name" field of requirement?
« Reply #2 on: August 15, 2019, 10:20:29 am »
Similar to what Geert has said we use name field for the name and alias for the ID which we set up for auto numbering. Why? Well my database design training has something about 3 normal forms and not using the same field for storing more than one piece of data.
Its also slightly easier to batch change one field in a script rather than parse a field and extract and change partial fields. Regular expressions make it easier I know but I use them so infrequently I have to relearn them each time.
Happy to help
:)

peterc

  • EA User
  • **
  • Posts: 84
  • Karma: +4/-0
    • View Profile
Re: What really should go into the "name" field of requirement?
« Reply #3 on: August 15, 2019, 05:03:45 pm »
I would use the Name field for a short name/title (like Update Order) with the Notes containing the full text of what the Update Order requirement is. I put a unique identifier in the Alias field.

qwerty

  • EA Guru
  • *****
  • Posts: 10625
  • Karma: +233/-194
  • I'm no guru at all
    • View Profile
Re: What really should go into the "name" field of requirement?
« Reply #4 on: August 15, 2019, 07:44:04 pm »
Basically what others said. However, requirements are best kept in dedicated systems so I usually add a stereotype property taking the ID from that system since in most cases EA will not be able to give a consistent unique numbering for the requirements.

q.

jfzouain

  • EA User
  • **
  • Posts: 124
  • Karma: +4/-1
    • View Profile
Re: What really should go into the "name" field of requirement?
« Reply #5 on: August 16, 2019, 12:17:59 am »
I almost agree with every body here, but based on my experience have never used EA auto numbering, I have a Naming Convention that I have used over 15 years gathering requirements, here is an example how I have done this, more in my eBook.

RIM01.08.01 - Inventory Adjustment Reason
(R-Requirement + I-Inventory Module + M-Maintenance Section+ 01- first requirement in this section + 08-Requirement number 8 of the section + 01-sub-requirement)

https://leanpub.com/uml-erpworkshop
Best regards

Jose Zouain