Categorizing Stories

When using them I find that I have been saying to myself "You have been using this style to describe the functionaliy of a system for years, what makes this any different?" I can answer by saying "Before it was on scrap paper and emails to others, this is more directed". A measured step to add a little bit of formalism without sacrificing the usability of the process goes a long way.

The trouble I am in now is that I am trying to use the same style to describe EVERYTHING I am doing. This is the intense desire to have 'one mechanism'. But what I end up with is a bunch of stories that describe everything lumped into the one category.

I have had some success in placing stories into categories. Uncomplicated enough to get pass the quagmire of 'everything'.

Why do I have the desire to write a UnitTest for this?

Here are my categories:

Business/Feature "Display the account history for the client"
Techincal/Architecture "The current (whatever ex:AccountService) needs data from the old (whatever ex:Mainframe)
Technical/Science "The data is persisted in some proprietary data structure, the service needs it in XML"
Technical/Engineering "The system must have a minimum response time of 3 seconds"
Technical/Construction "The system should be written in Python"
Business/Admin "This joker needs to pay me for (whatever)"

Categories could run along the lines of traditional requirements engineering:

Functional Requirement == "When cancel is clicked the action should be stopped!"

Non-Functional Requirement == "It would be great if it was written in Python and utilized our RDBMS licence"

Process Constraint == "Task A must be completed within 30 seconds"

Just some thoughts, Richard Quinn