| || |
For naming of requirements, is it important to have identifiable names or are numbers fine? Right now at my work they have naming like:
- Is it practical to have the project number in the requirements name? To me it seems like if they are living requirements they should be tied to a system but not a project as a system may have more than one project using the system.
- Should the names be more descriptive to actually say the functionality? For example 14068_CPO_Login? Or does that not matter?
I'm going to go out on a limb here and say that it doesn't matter what you call them so long as you can trace them through your documentation. It's easier for humans to use names, and computers don't care if links are based on names or numbers. If you're building links into the system based on the requirement code, that's fine.
The project number is useful as a way of tracing what introduced which requirement - each project is likely to deal with a discrete chunk of functionality, so grouping your requirements by project means they're automatically grouped by functionality as well.
Great thanks :-)
Although I'll take your advice with a grain of salt seeing as how you had to go out on a limb haha. But it seems to make sense to me.
Personally I like using Prefix denoting the area/page then date stamp, then some sort of number so I can at a glance see when this requirement was implemented if I want to do some historical digging.
The project number is valuable as a method for following what presented which necessity - every project is liable to manage a discrete piece of usefulness, so gathering your prerequisites by task means they're naturally assembled by usefulness too.