Book a Demo

Author Topic: Structured Auto numbering  (Read 11617 times)

mikewhit

  • EA User
  • **
  • Posts: 608
  • Karma: +0/-0
  • Accessing ....
    • View Profile
Structured Auto numbering
« on: October 06, 2004, 07:18:46 am »
For items like Requirements, it would be useful to be able to control Auto Element Naming (numbering) at the Package level, so that within a package, numbering could start at 0001 (or as required), with the prefix (possibly partially numeric) then being made different for each package.

An alternative would be to have a 'hierarchical numbering' option which would allow automatic numbering in the traditional structured 1.2.3.1 format where descending one (package) level would insert a '.' and restart the auto-numbering.

Thomas_Nilsson

  • EA Novice
  • *
  • Posts: 3
  • Karma: +0/-0
    • View Profile
Re: Structured Auto numbering
« Reply #1 on: October 22, 2004, 01:25:05 am »
I am not sure I like the suggestion of hierarchical numbering based on packages. You are fried if you need to restructure your packages.

In general a simple sequential numbering is sufficient and often better because it does not lock the structure into the identifiers.

thomaskilian

  • Guest
Re: Structured Auto numbering
« Reply #2 on: October 22, 2004, 02:50:26 am »
Instead I'd like to have an orthogonal handling of autonumbering. That is: when I open any element with autonumbers or press the appropriate new button, then the autonumber should appear in the name field with the cursor right behind. Currently the behaviour is different for all autonumbered elements (try Use Case: number appears automatically as expected but is selected, immediate typing removes the number; Issues in the System Frame: need to press "Auto" to create an autonumber and click into the name field).

mikewhit

  • EA User
  • **
  • Posts: 608
  • Karma: +0/-0
  • Accessing ....
    • View Profile
OK, how about keyword expansion ?
« Reply #3 on: October 22, 2004, 03:18:45 am »
Yes, my suggestion is not perfect.

What I wanted was particularly for Requirements, as you might have guessed, and I would really benefit from some clever way to organise the hierarchical 'outline' style of numbering in a SRS-type document.

The existing linear numbering does not lend itself well to documentation, given the fact that you might create requirements in any old order throughout your subsystem requirements packages.

Maybe even allow the numbering to be package-relative or have expanded keywords ('%p' ?) in the Element name field.

More thought required - but more suggestions too !!
Thanks.

dlundy

  • EA User
  • **
  • Posts: 21
  • Karma: +0/-0
    • View Profile
Re: Structured Auto numbering
« Reply #4 on: October 24, 2004, 07:08:03 am »
I find that I strongly sympathize with Mike's request for hierarchical numbering. The need in Requirements documents to be reference via a hierarchy (outline) is important.

However, I rely on the the Unique Identifier assigned to a Requirement to enable me to track it regardless of where is logically positions.

It seems to me that this feature request would be better served if we could somehow produce the Package Prefix to be prepended during output/report generation.

Dan
Dan Lundy

allenmarshall

  • EA Novice
  • *
  • Posts: 8
  • Karma: +0/-0
    • View Profile
Re: Structured Auto numbering
« Reply #5 on: October 26, 2005, 06:55:32 am »
I would echo or vote for all these points.  An SRS is almost always going to be printed with requirement numbers that are particular to the assignment, not some internal GUID() or whatnot.  So may be use cases themselves.   Providing a simple (maybe even rudimentary ) outlining approach for numbering would be extremely helpful.

It would also be nice to make numbering a field that can be validated for uniqueness, format and completeness e.g. if enforced,  no req. can be entered lacking a number, with a dupe, or out of hierarchical format...

JV

  • EA Novice
  • *
  • Posts: 12
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Re: Structured Auto numbering
« Reply #6 on: August 30, 2006, 01:04:35 am »
I also would have auto numbering but not hierarchical numbering because of later restructuring of packages/requirements. By my mind number of requirement/feature/issue/use case must stay as it was when you created it. Why? Because it would be better if number doesn’t change. This way you have always same number when talking with business, programmer etc.

Other problematic issue for me is, that if I move internal requirement to external, it doesn’t get a number this is for me big problem.

Unique number would help me much.

Take care

tponnet

  • EA Novice
  • *
  • Posts: 5
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Re: Structured Auto numbering
« Reply #7 on: September 15, 2006, 04:04:28 am »
For traceability reasons I believe that auto-numbering with unique numbers really is a must.
I'm looking at EA from a QA point of view so that is something I'm really interested in.
I'd disagree with Allen Marshall that the SRS almost always comes in printed form. I guess that depends on your company.
I believe we have at least two issues here.
1. Getting auto-numbering in a configurable way that satisfies most users.
2. When additional requirements are identified that you want to be added in between existing requirements, the auto-numbering system should be able to cope with that.

Speaking just for myself something loosely based on the Word numbering formats mixed with the already existing Auto Name counters would be ideal. For example:

Level 1<myprefix>1234<MySuffix>
Level2<myprefix>1234<MySuffix>
...
When adding a new requirement you should be able to drag and drop/move it into the required position and then get asked if you want to change the number. For example Req_5456 becomes Req_2342.002
Hope that makes sense.

Seeing that this thread started in 2004 but is still very much active indicates that this isn't seen as something vital. It probably isn't to people using it for Business and Use Case modelling. For myself who wants to use it for QA purposes it is absolutely vital.

Thanks,

Thomas