Post

2 followers

Request a Feature

Ability to tailor a different "ID" per defined requirement type

Hi,

I think this idea has been raised previously (prior to moving to the new support platform) but I'll raise it again so it's "visible":

At the moment, all requirements regardless of the requirement type, get assigned an ID as 'REQ-1', 'REQ-2' etc. I'd like the ability to be able to define the ID naming convention per requirement type.

eg. Using a simple example.

Currently:

Functional Reqs

REQ-1 Some functional req

REQ-2 Some other functional req

Business Rule

REQ-3 A business rule

Constraint

REQ-4 Some constraint

Proposed:

Functional Reqs

FR-1 Some functional req

FR-2 Some other functional req

Business Rule

BR-1 A business rule

Constraint

CON-1 Some constraint

If the concern for not implementing this is that it might 'break' how the reports and other internal logic works within CC, then perhaps you could get around this by keeping the 'ID' as is (and consider it an internal identifier) and add an additional field where the user defined ID naming convention could be used.

I know their is already the ability to add custom fields to a requirement but this method is a bit clumsy in this instance. ie. If I am rapidly adding a number of Business Rules en masse for instance, I'd like the system to auto assign the ID's as BR-1, BR-2, BR-3 etc without retrospectively having to open up each requirement, keep track of the next sequential number, and manually keying it in as I currently have to do.

Thanks

Adam

Adam Bradley February 06, 2011 01:32

Please sign in to leave a comment.

3 comments

Hi Adam,

Yep, we still have that request in our database (configurable prefixes) and it's still visible. I'll add your latest comments to the entry so it will get some more visibility during our next release planning sessions.

Another idea would be to store each type of requirement in a separate package file and configure that package file to contain a customized prefix. For example, when you do a right mouse click on a package in the project browswer, you can save it as a separate file. When you do that, you'll be presented with a dialog that will allow you to specify a prefix for the elements. So, if you create package file to store only Functional Requirements, you could give it a prefix of FR- and each new requirement added to that package would be prefixed with REQ-FR-. Just a thought...

Thanks for the feedback,

Jeff

Jeff Marver February 07, 2011 21:57 0 votes

Hi Jeff,

Thanks for getting back to me and for your idea. Actually, while it still would be a useful option to have, over the past day or two I've been having a think about the way I name my requirements along with researching some ways others do it and I've come up with something I really like which sort of lessens the need for the feature I described.

The basic idea is that I come up with a unique id stored in the requirement name.

eg. In the following example, I have a requirement with three child requirements. To date I've been naming requirements like so:

FR-1 Encrypt Images

The system shall store all images in encrypted form.

FR-1.1 Encryption Algorithm

The system shall employ the use of an industry standard type encryption algorithm.

FR-1.2 Encryption New Image

The system store newly added images in encrypted form as they are loaded

FR-1.3 Encryption Historical Image

The system shall convert all existing historical images into encrypted form

I'm now going with the following naming convention:

FR - Encrypt Images

The system shall store all images in encrypted form.

FR - Encrypt Images.Algorithm

The system shall employ the use of an industry standard type encryption algorithm.

FR - Encrypt Images.New

The system store newly added images in encrypted form as they are loaded

FR - Encrypt Images.Historical

The system shall convert all existing historical images into encrypted form

I like this approach as it leaves no "gaps" in requirements numbers (should I delete requirements) and also it promotes re-usability of those requirements more cleanly across multiple projects. Also, it solves the issue of being able to sort requirements by name logically when producing reports.

Thanks

Adam

Adam Bradley February 08, 2011 08:41 0 votes

I like the numbering convention Adam first proposed because when you're looking to create the traceability matrix and you're exporting it into excel format then those long names can become a bit of a format issue.

Thanks
Ingrid

Igeronimo March 06, 2016 15:56 0 votes